Windows Server Identity

Tell us about your PDF experience.
Identity and Access documentation

Access and Identity technologies enable secure Active Directory environments on-
premises and in cloud-only and hybrid deployments where some applications and
services are hosted in the cloud and others are hosted on premises.
About Identity and Access technologies
ｈ WHAT'S NEW
What's new?
ｅ OVERVIEW
Privileged Access Management for Active Directory Domain Services & AD DS
Windows 10 for the enterprise: Ways to use devices for work
Active Directory Domain Services
Active Directory Federation Services
Windows Local Administrator Password Solution (LAPS)
Solutions and Scenario Guides
ｃ HOW-TO GUIDE
Secure access to company resources from any location on any device
Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication
Across Company Applications
Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications
Manage Risk with Conditional Access Control
Older versions of Windows Server
ｅ OVERVIEW
Windows previous versions documentation

Search for specific information
Solutions and Scenario Guides
Article • 07/29/2021
Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012
With Microsoft's access and information protection solutions, you can deploy and
configure access to corporate resources across your on-premises environment and
cloud applications. And you can do it while protecting corporate information.
Access and Information Protection
Guide How can this guide help you
Secure access to This guide shows how to allow employees to use personal and
company resources from company devices to securely access corporate applications and data.
any location on any
device
Join to Workplace from Employees can access applications and data everywhere, on any
Any Device for SSO and device. Employees can use Single Sign-On in browser applications or
Seamless Second Factor enterprise applications. Administrators can control who has access to
Authentication Across company resources that are based on application, user, device, and
Company Applications location.
Manage Risk with In this scenario, you enable MFA based on the user's group
Additional Multi-Factor membership data for a specific application. In other words, you will set
Authentication for up an authentication policy on your federation server to require MFA
Sensitive Applications when users that belong to a certain group request access to a specific
application that is hosted on a web server.
Manage Risk with Access control in AD FS is implemented with issuance authorization

Conditional Access claim rules that are used to issue a permit or deny claims that will
Control 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 This article provides step-by-step instructions to implement the

Enrollment Web Service Certificate Enrollment Web Service (or Certificate Enrollment Policy
for certificate key-based (CEP) / Certificate Enrollment Service (CES)) on a custom port other
renewal on a custom than 443 for certificate key-based renewal to take advantage of the
port automatic renewal feature of CEP and CES.
Dynamic Access Control: Scenario
Overview
Article • 09/27/2022
In Windows Server 2012 , you can apply data governance across your file servers to
control who can access information and to audit who has accessed information.
Dynamic Access Control lets you:
Identify data by using automatic and manual classification of files. For example,
you could tag data in file servers across the organization.
Control access to files by applying safety-net policies that use central access
policies. For example, you could define who can access health information within
the organization.
Audit access to files by using central audit policies for compliance reporting and
forensic analysis. For example, you could identify who accessed highly sensitive
information.
Apply Rights Management Services (RMS) protection by using automatic RMS

encryption for sensitive Microsoft Office documents. For example, you could
configure RMS to encrypt all documents that contain Health Insurance Portability
and Accountability Act (HIPAA) information.
The Dynamic Access Control feature set is based on infrastructure investments that can
be used further by partners and line-of-business applications, and the features can
provide great value for organizations that use Active Directory. This infrastructure
includes:
A new authorization and audit engine for Windows that can process conditional
expressions and central policies.
Kerberos authentication support for user claims and device claims.
Improvements to the File Classification Infrastructure (FCI).
RMS extensibility support so partners can provide solutions that encrypt non-
Microsoft files.
In this scenario
The following scenarios and guidance are included as part of this content set:
Dynamic Access Control Content Roadmap

Scenario Evaluate Plan Deploy Operate
Scenario: Central Access Policy Dynamic Plan: A Central Deploy a - Modeling

Access Access Policy Central Access a central
Creating Central access policies Control: Deployment Policy access
for files allow organizations to Scenario (Demonstration policy
centrally deploy and manage Overview - Process to Steps)
authorization policies that map a business
include conditional expressions Deploy request to a Deploy Claims
using user claims, device Claims Across central access Across Forests
claims, and resource Forests policy
(Demonstration
properties. These polices are - Delegating of Steps)
based on compliance and administration
business regulatory for Dynamic
requirements. These policies Access
are created and hosted in Control
Active Directory, therefore - Exception

making it easier to manage and Mechanisms
deploy. for Planning
Central Access
Deploying Claims Across Policies
Forests
Best Practices
In Windows Server 2012 , the for Using User
AD DS maintains a 'claims Claims
dictionary' in each forest and
all claim types in use within the - Choosing the
forest are defined at the Active right
Directory forest level. There are configuration
many scenarios where a to enable
principal may need to traverse claims in your
a trust boundary. This scenario user domain
describes how a claim traverses - Operations to

a trust boundary. enable user
claims
-
Considerations
for using user
claims in the
file server
discretionary
ACLs without
using Central
Access
Policies
Using Device
Claims and
Device Security
Groups
-
Considerations
for using static
device
claims
- Operations to
enable device
claims
Tools for
Deployment
-
Scenario: File Access Auditing Scenario: File Plan for File Deploy Security - Monitor
Access Access Auditing with the Central
Security auditing is one of the Auditing Auditing Central Audit Access
most powerful tools to help Policies Policies
maintain the security of an (Demonstration that Apply
enterprise. One of the key Steps) on a File
goals of security audits is Server
regulatory compliance. For - Monitor

example, industry standards the Central
such as Sarbanes Oxley, HIPAA, Access
and Payment Card Industry Policies
(PCI) require enterprises to Associated
follow a strict set of rules with Files
related to data security and and
privacy. Security audits help Folders
establish the presence or - Monitor

absence of such policies; the
thereby, they prove compliance Resource
or noncompliance with these Attributes
standards. Additionally, on Files
security audits help detect and
anomalous behavior, identify Folders
and mitigate gaps in security - Monitor

policy, and deter irresponsible Claim
behavior by creating a record Types
of user activity that can be - Monitor

used for forensic analysis. User and
Device
Claims
During
Sign-in
- Monitor
Central
Access
Policy and
Rule
Definitions
- Monitor
Resource
Attribute
Definitions
- Monitor
the Use of
Removable
Storage
Devices.
Scenario: Access-Denied Scenario: Plan for Deploy Access-

Assistance Access- Access-Denied Denied
Denied Assistance Assistance
Today, when users try to access Assistance (Demonstration
a remote file on the file server, - Determine Steps)
the only indication that they the access-
would get is that access is denied
denied. This generates requests assistance
to helpdesk or IT model
administrators that need to - Determine

figure out what the issue is and who should
often the administrators have a handle access
hard time getting the requests
appropriate context from users - Customize

which makes it harder to the access-
resolve the issue.
denied
In Windows Server 2012 , the assistance
goal is to try and help the message
information worker and - Plan for

business owner of the data to exceptions
deal with the access denied - Determine

issue before IT gets involved how access-
and when IT gets involved, denied
provide all the right assistance is
information for a quick deployed
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: Classification-Based Scenario: Plan to deploy Deploy

Encryption for Office Classification- for Encryption of
Documents Based classification- Office Files
Encryption based (Demonstration
Protection of sensitive for Office encryption of Steps)
information is mainly about Documents documents
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 into Your Scenario: Get Plan for Deploy
Data by Using Classification Insight into Automatic File Automatic File
Your Data by Classification Classification
Reliance on data and storage Using (Demonstration
resources has continued to Classification Steps)
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: Implement Scenario: Plan for Deploy

Retention of Information on Implement Retention of Implementing
File Servers Retention of Information on Retention of
Information File Servers Information on
A retention period is the on File File Servers
amount of time that a Servers (Demonstration
document should be kept Steps)
before it is expired. Depending
on the organization, the
retention period can be
different. You can classify files
in a folder as having a short,
medium, or long-term
retention period and then
assign the timeframe for each
period. You may want to keep a
file indefinitely by putting it on
legal hold.
File Classification Infrastructure

and File Server Resource
Manager uses file management
tasks and file classification to
apply retention periods for a
set of files. You can assign a
retention period on a folder
and then use a file
management task to configure
how long an assigned retention
period is to last. When the files
in the folder are about to
expire, the owner of the file
gets a notification email. You
can also classify a file as being
on legal hold so that the file
management task will not
expire the file.
７ Note
Dynamic Access Control is not supported on ReFS (Resilient File System).
See also
Content type References
Content type References
Product evaluation - Dynamic Access Control Reviewers Guide
- Dynamic Access Control Developer Guidance
Planning - Planning a Central Access Policy Deployment

- Plan for File Access Auditing
Deployment - Active Directory Deployment
- File and Storage Services Deployment
Operations Dynamic Access Control PowerShell Reference
|Community resources|Directory Services Forum|

Scenario: Central Access Policy
Article • 04/21/2022
Central access policies for files enable organizations to centrally deploy and manage
authorization policies that include conditional expressions that use user groups, user
claims, device claims, and resource properties. (Claims are assertions about the
attributes of the object with which they are associated). For example, to access high-
business-impact (HBI) data, a user must be a full-time employee, obtain access from a
managed device, and log on with a smart card. These policies are defined and hosted in
Active Directory Domain Services (AD DS).
Organizational access policies are driven by compliance and business regulatory

requirements. For example, if an organization has a business requirement to restrict
access to personally identifiable information (PII) in files to only the file owner and
members of the human resources (HR) department who are allowed to view PII
information, this policy applies to PII files wherever they are located on file servers
across the organization. In this example, you need to be able to:
Identify and mark the files that contain PII.
Identify the group of HR members who are allowed to view PII information.
Create a central access policy that applies to all files that contain PII wherever they
are located on file servers across the organization.
The initiative to deploy and enforce an authorization policy can come for many reasons
and apply to multiple levels of the organization. The following are some example policy
types:
Organization-wide authorization policy. Most commonly initiated from the

information security office, this authorization policy is driven by compliance or a
high-level organization requirements, and it is relevant across the organization. For
example, HBI files are accessible to only full-time employees.
Departmental authorization policy. Each department in an organization has some

special data-handling requirements that they want to enforce. For example, the
finance department might want to limit access to finance servers to the finance
employees.
Specific data-management policy. This policy usually relates to compliance and
business requirements, and it is targeted at protecting the correct access to the
information that is being managed. For example, financial institutions might
implement information walls so that analysts do not access brokerage information
and brokers do not access analysis information.
Need-to-know policy. This authorization policy type is typically used in

conjunction with the previous policy types. For example, vendors should be able to
access and edit only files that pertain to a project they are working on.
Real-life environments also teach us that every authorization policy needs to have
exceptions so that organizations can quickly react when important business needs arise.
For example, executives who cannot find their smart cards and need quick access to HBI
information can call the Help Desk to get a temporary exception to access that
information.
Central access policies act as security umbrellas that an organization applies across its
servers. These policies enhance (but do not replace) the local access policies or
discretionary access control lists (DACL) that are applied to files and folders. For
example, if a DACL on a file allows access to a specific user, but a central policy that is
applied to the file restricts access to the same user, the user cannot obtain access to the
file. If the central access policy allows access, but the DACL does not allow access, the
user cannot obtain access to the file.
A central access policy rule has the following logical parts:
Applicability. A condition that defines which data the policy applies to, such as
Resource.BusinessImpact=High.
Access conditions. A list of one or more access control entries (ACEs) that define
who can access the data, such as Allow | Full Control | User.EmployeeType=FTE.
Exceptions. An additional list of one or more ACEs that define an exception for the
policy, such as MemberOf(HBIExceptionGroup).
The following two figures show the workflow in central access and audit policies.
Figure 1 Central access and audit policy concepts
Figure 2 Central access policy workflow
The central authorization policy combines the following components:
A list of centrally defined access rules that target specific types of information, such
as HBI or PII.
A centrally defined policy that contains a list of rules.
A policy identifier that is assigned to each file on the file servers to point to a
specific central access policy that should be applied during the access
authorization.
The following figure demonstrates how you can combine policies into policy lists to
centrally control access to files.
Figure 3 Combining policies
In this scenario
The following guidance is available to you for central access policies:
Plan a Central Access Policy deployment
Deploy a Central Access Policy (Demonstration Steps)
Dynamic Access Control: Scenario Overview
Roles and features included in this scenario

The following table lists the roles and features that are part of this scenario and
describes how they support it.
Role/feature How it supports this scenario
Active AD DS in Windows Server 2012 introduces a claims-based authorization platform

Directory that enables the creation of user claims and device claims, compound identity,
Domain (user plus device claims), new central access policy (CAP) models, and the use of
Services role file-classification information in authorization decisions.
File and File and Storage Services provides technologies that help you set up and manage
Storage one or more file servers that provide central locations on your network where you
Services can store files and share them with users. If your network users need access to the
Server role 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 Users can access files and folders on the network through the client computer.
client
computer
Deploy a Central Access Policy
(Demonstration Steps)
Article • 07/29/2021
In this scenario, the finance department security operations is working with central
information security to specify the need for a central access policy so that they can
protect archived finance information stored on file servers. The archived finance
information from each country can be accessed as read-only by finance employees from
the same country. A central finance admin group can access the finance information
from all countries.
Deploying a central access policy includes the following phases:
Phase Description
Plan: Identify the need for policy and the Identify the need for a policy and the
configuration required for deployment configuration required for deployment.
Implement: Configure the components and Configure the components and policy.
policy
Deploy the central access policy Deploy the policy.
Maintain: Change and stage the policy Policy changes and staging.
Set up a test environment

Before you begin, you need to set up lab to test this scenario. The steps for setting up
the lab are explained in detail in Appendix B: Setting Up the Test Environment.
Plan: Identify the need for policy and the

configuration required for deployment
This section provides the high-level series of steps that aid in the planning phase of your
deployment.
Step Step Example
#
1.1 Business To protect finance information that is stored on file servers, the finance
determines department security operations is working with central information security
that a to specify the need for a central access policy.
central
access
policy is
needed
1.2 Express the Finance documents should only be read by members of the Finance
access department. Members of the Finance department should only access
policy 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 Targeting:

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

the file - Department
properties - Country
required for
the policy
1.5 Determine Claim types:

the claim - Country
types and - Department

groups
required for User groups:
the policy
- FinanceAdmin
- FinanceException
1.6 Determine Apply the policy on all finance file servers.

the servers
on which to
apply this
policy
Implement: Configure the components and
policy
This section presents an example that deploys a central access policy for finance
documents.
Step Step Example

#
2.1 Create claim types Create the following claim types:

- Department
- Country
2.2 Create resource properties Create and enable the following resource
properties:
- Department
- Country
2.3 Configure a central access rule Create a Finance Documents rule that includes
the policy determined in the previous section.
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 file
servers servers.
2.6 Enable KDC Support for claims, Enable KDC Support for claims, compound
compound authentication and authentication and Kerberos armoring for
Kerberos armoring. contoso.com.
In the following procedure, you create two claim types: Country and Department.
To create claim types

1. Open Server DC1 in Hyper-V Manager and log on as contoso\administrator, with
the password pass@word1.
2. Open Active Directory Administrative Center.
3. Click the Tree View icon, expand Dynamic Access Control, and then select Claim
Types.
Right-click Claim Types, click New, and then click Claim Type.
 Tip
You can also open a Create Claim Type: window from the Tasks pane. On the
Tasks pane, click New, and then click Claim Type.
4. In the Source Attribute list, scroll down the list of attributes, and click department.
This should populate the Display name field with department. Click OK.
5. In Tasks pane, click New, and then click Claim Type.
6. In the Source Attribute list, scroll down the list of attributes, and then click the c
attribute (Country-Name). In the Display name field, type country.
7. In the Suggested Values section, select The following values are suggested:, and
then click Add.
8. In the Value and Display name fields, type US, and then click OK.
9. Repeat the above step. In the Add a suggest value dialog box, type JP in the Value
and Display name fields, and then click OK.
Windows PowerShell equivalent commands
The following Windows PowerShell cmdlet or cmdlets perform the same function as the
preceding procedure. Enter each cmdlet on a single line, even though they may appear
word-wrapped across several lines here because of formatting constraints.
PowerShell
New-ADClaimType country -SourceAttribute c -SuggestedValues:@((New-Object

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

MS-DS-MultivaluedChoice -SharesValuesWith country
Set-ADResourceProperty Department_MS -Enabled $true
Add-ADResourcePropertyListMember "Global Resource Property List" -Members

Country
Add-ADResourcePropertyListMember "Global Resource Property List" -Members

Department_MS
The next step is to create central access rules that define who can access resources. In
this scenario the business rules are:
Finance documents can be read only by members of the Finance department.
Members of the Finance department can access only documents in their own
country.
Only Finance Administrators can have Write access.
We will allow an exception for members of the FinanceException group. This group
will have Read access.
The administrator and document owner will still have full access.
Or to express the rules with Windows Server 2012 constructs:
Targeting: Resource.Department Contains Finance
Access Rules:
Allow Read User.Country=Resource.Country AND User.department =

Resource.Department
Allow Full control User.MemberOf(FinanceAdmin)
Allow Read User.MemberOf(FinanceException)
To create a central access rule

1. In the left pane of the Active Directory Administrative Center, click Tree View,
select Dynamic Access Control, and then click Central Access Rules.
2. Right-click Central Access Rules, click New, and then click Central Access Rule.
3. In the Name field, type Finance Documents Rule.
4. In the Target Resources section, click Edit, and in the Central Access Rule dialog
box, click Add a condition. Add the following condition:
[Resource] [Department]
[Equals] [Value] [Finance], and then click OK.
5. In the Permissions section, select Use following permissions as current

permissions, click Edit, and in the Advanced Security Settings for Permissions
dialog box click Add.
７ Note
Use the following permissions as proposed permissions option lets you
create the policy in staging. For more information on how to do this refer to
the Maintain: Change and stage the policy section in this topic.
6. In the Permission entry for Permissions dialog box, click Select a principal, type
Authenticated Users, and then click OK.
7. In the Permission Entry for Permissions dialog box, click Add a condition, and add
the following conditions:
[User] [country] [Any of] [Resource] [country]
Click Add
a condition.
[And]
Click [User] [Department] [Any of] [Resource] [Department].
Set the Permissions to Read.
8. Click OK, and then click Add. Click Select a principal, type FinanceAdmin, and then
click OK.
9. Select the Modify, Read and Execute, Read, Write permissions, and then click OK.
10. Click Add, click Select a principal, type FinanceException, and then click OK. Select
the permissions to be Read and Read and Execute.
11. Click OK three times to finish and return to Active Directory Administrative Center.
PowerShell
$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.
PowerShell
New-ADCentralAccessPolicy "Finance Policy" Add-ADCentralAccessPolicyMember
-Identity "Finance Policy"
-Member "Finance Documents Rule"
To apply the central access policy across file servers by using Group
Policy
1. On the Start screen, in the Search box, type Group Policy Management. Double-
click Group Policy Management.
 Tip
If the Show Administrative tools setting is disabled, the Administrative Tools

folder and its contents will not appear in the Settings results.
 Tip
In your production environment, you should create a File Server Organization

Unit (OU) and add all your file servers to this OU, to which you want to apply
this policy. You can then create a group policy and add this OU to that policy..
2. In this step, you edit the group policy object you created in Build the domain
controller section in the Test Environment to include the central access policy that
you created. In the Group Policy Management Editor, navigate to and select the
organizational unit in the domain (contoso.com in this example): Group Policy
Management, Forest: contoso.com, Domains, contoso.com, Contoso,
FileServerOU.
3. Right-click FlexibleAccessGPO, and then click Edit.
4. In the Group Policy Management Editor window, navigate to Computer

Configuration, expand Policies, expand Windows Settings, and click Security
Settings.
5. Expand File System, right-click Central Access Policy, and then click Manage
Central access policies.
6. In the Central Access Policies Configuration dialog box, add Finance Policy, and
then click OK.
7. Scroll down to Advanced Audit Policy Configuration, and expand it.
8. Expand Audit Policies, and select Object Access.
9. Double-click Audit Central Access Policy Staging. Select all three check boxes and
then click OK. This step allows the system to receive audit events related to Central
Access Staging Policies.
10. Double-click Audit File System Properties. Select all three check boxes then click
OK.
11. Close the Group Policy Management Editor. You have now included the central
access policy to the Group Policy.
For a domain's domain controllers to provide claims or device authorization data, the
domain controllers need to be configured to support dynamic access control.
To enable support for claims and compound authentication for

contoso.com
1. Open Group Policy Management, click contoso.com, and then click Domain
Controllers.
2. Right-click Default Domain Controllers Policy, and then click Edit.
3. In the Group Policy Management Editor window, double-click Computer

Configuration, double-click Policies, double-click Administrative Templates,
double-click System, and then double-click KDC.
4. Double-click KDC Support for claims, compound authentication and Kerberos

armoring. In the KDC Support for claims, compound authentication and
Kerberos armoring dialog box, click Enabled and select Supported from the
Options drop-down list. (You need to enable this setting to use user claims in
central access policies.)
5. Close Group Policy Management.
6. Open a command prompt and type gpupdate /force .
Deploy the central access policy

Step Step Example
#
3.1 Assign the CAP to the appropriate Assign the central access policy to the
shared folders on the file server. appropriate shared folder on the file server.
3.2 Verify that access is appropriately Check the access for users from different
configured. 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
a. Logon to File Server FILE1 as contoso\administrator, using the password
pass@word1.
b. Open File Server Resource Manager. To open File Server Resource
Manager, click Start, type file server resource manager, and then click File
Server Resource Manager.
c. In the File Server Resource Manager, click File Classification Management ,
right-click Classification Properties and then click Refresh.
4. Open Windows Explorer, and in the left pane, click drive D. Right-click the Finance
Documents folder, and click Properties.
5. Click the Classification tab, click Country, and then select US in the Value field.
6. Click Department, then select Finance in the Value field and then click Apply.
７ Note
Remember that the central access policy was configured to target files for the
Department of Finance. The previous steps mark all documents in the folder
with the Country and Department attributes.
7. Click the Security tab, and then click Advanced. Click the Central Policy tab.
8. Click Change, select Finance Policy from the drop-down menu, and then click
Apply. You can see the Finance Documents Rule listed in the policy. Expand the
item to view all of the permissions that you set when you created the rule in Active
Directory.
9. Click OK to return to Windows Explorer.
In the next step, you ensure that access is appropriately configured. User accounts need
to have the appropriate Department attribute set (set this using Active Directory
Administrative Center). The simplest way to view the effective results of the new policy is
to use the Effective Access tab in Windows Explorer. The Effective Access tab shows the
access rights for a given user account.
To examine the access for various users

1. In Hyper-V Manager, connect to server FILE1. Log on to the server by using
contoso\administrator. Navigate to D:\ in Windows Explorer. Right-click the
Finance Documents folder, and then click Properties.
2. Click the Security tab, click Advanced, and then click the Effective Access tab.
3. To examine the permissions for a user, click Select a user, type the user's name,
and then click View effective access to see the effective access rights. For example:
Myriam Delesalle (MDelesalle) is in the Finance department and should have

Read access to the folder.
Miles Reid (MReid) is a member of the FinanceAdmin group and should have
Modify access to the folder.
Esther Valle (EValle) is not in the Finance department; however, she is a

member of the FinanceException group and should have Read access.
Maira Wenzel (MWenzel) is not in the Finance department and is not a

member of either the FinanceAdmin or FinanceException group. She should
not have any access to the folder.
Notice that the last column named Access limited by in the effective access
window. This column tells you which gates are effecting the person's permissions.
In this case, the Share and NTFS permissions allow all users full control. However,
the central access policy restricts access based on the rules you configured earlier.
Maintain: Change and stage the policy
Step Step Example
#
4.1 Configure Device Claims for Clients Set the group policy setting to
enable device claims
4.2 Enable a claim for devices. Enable the country claim type for
devices.
4.3 Add a staging policy to the existing central access Modify the Finance Documents Rule
rule that you would like to modify. to add a staging policy.
4.4 View the results of the staging policy. Check for Ester Velle's permissions.
To set up group policy setting to enable claims for devices
1. Log on to DC1, open Group Policy Management, click contoso.com, click Default
Domain Policy, right-click and select Edit.
2. In the Group Policy Management Editor window, navigate to Computer

Configuration, Policies, Administrative Templates, System, Kerberos.
3. Select Kerberos client support for claims, compound authentication and

Kerberos armoring and click Enable.
To enable a claim for devices

1. Open Server DC1 in Hyper-V Manager and log on as contoso\Administrator, with
2. From the Tools menu, open Active Directory Administrative Center.
3. Click Tree View, expand Dynamic Access Control, double-click Claim Types, and
double-click the country claim.
4. In Claims of this type can be issued for the following classes, select the Computer
check box. Click OK.
Both the User and Computer check boxes should now be
selected. The country claim can now be used with devices in addition to users.
The next step is to create a staging policy rule. Staging policies can be used to monitor
the effects of a new policy entry before you enable it. In the following step, you will
create a staging policy entry and monitor the effect on your shared folder.
To create a staging policy rule and add it to the central access
policy
1. Open Server DC1 in Hyper-V Manager and log on as contoso\Administrator, with

2. Open Active Directory Administrative Center.
3. Click Tree View, expand Dynamic Access Control, and select Central Access Rules.
4. Right-click Finance Documents Rule, and then click Properties.
5. In the Proposed Permissions section, select the Enable permission staging

configuration check box, click Edit, and then click Add. In the Permission Entry for
Proposed Permissions window, click the Select a Principal link, type Authenticated
Users, and then click OK.
6. Click the Add a condition link and add the following condition:
[User] [country]
[Any of] [Resource] [Country].
7. Click Add a condition again, and add the following condition:

[And]
[Device]
[country] [Any of] [Resource] [Country]
8. Click Add a condition again, and add the following condition.

[And]
[User] [Group]
[Member of any] [Value](FinanceException)
9. To set the FinanceException, group, click Add items and in the Select User,
Computer, Service Account, or Group window, type FinanceException.
10. Click Permissions, select Full Control, and click OK.
11. In the Advance Security Settings for Proposed Permissions window, select
FinanceException and click Remove.
12. Click OK two times to finish.
PowerShell
Set-ADCentralAccessRule
-Identity:
"CN=FinanceDocumentsRule,CN=CentralAccessRules,CN=ClaimsConfiguration,CN=Con
figuration,DC=Contoso.com"
-ProposedAcl: "O:SYG:SYD:AR(A;;FA;;;BA)(A;;FA;;;SY)(A;;0x1301bf;;;S-1-
21=1426421603-1057776020-1604)"
-Server: "WIN-2R92NN8VKFP.Contoso.com"
７ Note
In the above cmdlet example, the Server value reflects the Server in the test lab
environment. You can use the Windows PowerShell History Viewer to look up the
Windows PowerShell cmdlets for each procedure you perform in Active Directory
Administrative Center. For more information, see Windows PowerShell History
Viewer
In this proposed permissions set, members of the FinanceException group will have Full
Access to files from their own country when they access them through a device from the
same country as the document. Audit entries are available in the File Servers security log
when someone from the Finance department attempts to access files. However, security
settings are not enforced until the policy is promoted from staging.
In the next procedure, you verify the results of the staging policy. You access the shared
folder with a user name that has permissions based on the current rule. Esther Valle
(EValle) is a member of FinanceException, and she currently has Read rights. According
to our staging policy, EValle should not have any rights.
To verify the results of the staging policy

1. Connect to the File Server FILE1 in Hyper-V Manager and log on as
contoso\administrator, with the password pass@word1.
2. Open a Command Prompt window and type gpupdate /force. This ensures that
your Group Policy changes will take effect on your server.
3. In Hyper-V Manager, connect to server CLIENT1. Log off the user who is currently
logged on. Restart the virtual machine, CLIENT1. Then log on to the computer by
using contoso\EValle pass@word1.
4. Double-click the desktop shortcut to \\FILE1\Finance Documents. EValle should still

have access to the files. Switch back to FILE1.
5. Open Event Viewer from the shortcut on the desktop. Expand Windows Logs, and
then select Security. Open the entries with Event ID 4818under the Central Access
Policy Staging task category. You will see that EValle was allowed access; however,
according to the staging policy, the user would have been denied access.
Next Steps
If you have a central server management system such as System Center Operations
Manager, you can also configuring monitoring for events. This allows Administrators to
monitor the effects of central access policies before enforcing them.
Scenario: File Access Auditing
Article • 07/29/2021
Security Auditing is one of the most powerful tools to help maintain the security of an
enterprise. One of the key goals of security audits is regulatory compliance. Industry
standards such as Sarbanes Oxley, Health Insurance Portability and Accountability Act
(HIPAA), and Payment Card Industry (PCI) require enterprises to follow a strict set of
rules related to data security and privacy. Security audits help establish the presence of
such policies and prove compliance with these standards. Additionally, security audits
help detect anomalous behavior, identify and mitigate gaps in security policies, and
deter irresponsible behavior by creating a trail of user activity that can be used for
forensic analysis.
Audit policy requirements are typically driven at the following levels:
Information security. File access audit trails are often used for forensic analysis and
intrusion detection. Being able to get targeted events about access to high-value
information lets organizations considerably improve their response time and
investigation accuracy.
Organizational policy. For example, organizations regulated by PCI standards

could have a central policy to monitor access to all files that are marked as
containing credit card information and personally identifiable information (PII).
Departmental policy. For example, the finance department may require that the
ability to modify certain finance documents (such as a quarterly earnings report)
be restricted to the finance department, and thus the department would want to
monitor all other attempts to change these documents.
Business policy. For example, business owners may want to monitor all
unauthorized attempts to view data that belongs to their projects.
Additionally, the compliance department may want to monitor all changes to central
authorization policies and policy constructs such as user, computer, and resource
attributes.
One of the biggest considerations of security audits is the cost of collecting, storing, and
analyzing audit events. If the audit policies are too broad, the volume of audit events
collected rises, and this increases costs. If the audit policies are too narrow, you risk
missing important events.
With Windows Server 2012 , you can author audit policies by using claims and resource
properties. This leads to richer, more targeted, and easier-to-manage audit policies. It
enables scenarios that, until now, were impossible or too difficult to perform. The
following are examples of audit policies that administrators can author:
Audit everyone who does not have a high-security clearance and tries to access an
HBI document. For example, Audit | Everyone | All-Access |
Resource.BusinessImpact=HBI AND User.SecurityClearance!=High.
Audit all vendors when they try to access documents that are related to projects
that they are not working on. For example, Audit | Everyone | All-Access |
User.EmploymentStatus=Vendor AND User.Project Not_AnyOf Resource.Project.
These policies help regulate the volume of audit events and limit them to only the most
relevant data or users.
After administrators have created and applied the audit policies, the next consideration
for them is gleaning meaningful information from the audit events that they collected.
Expression-based audit events help reduce the volume of audits. However, users need a
way to query these events for meaningful information and ask questions such as, "Who
is accessing my HBI data?" or "Was there an unauthorized attempt to access sensitive
data?"
Windows Server 2012 enhances existing data access events with user, computer, and
resource claims. These events are generated on a per-server basis. To provide a full view
of events across the organization, Microsoft is working with partners to provide event
collection and analysis tools, such as the Audit Collection Services in System Center
Operation Manager .
Figure 4 shows an overview of a central audit policy.

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

Active AD DS in Windows Server 2012 introduces a claims-based authorization platform

Directory that enables creating user claims and device claims, compound identity, (user plus
Doman device claims), new central access policies (CAP) model, and the use of file
Services role classification information in authorization decisions.
File and File servers in Windows Server 2012 provide a user interface where administrators
Storage can view the effective permissions for users for a file or folder and troubleshoot
Services role access issues and grant access as required.
Article • 07/29/2021
The information in this topic explains the security auditing enhancements that are
introduced in Windows Server 2012 and new audit settings that you should consider as
you deploy Dynamic Access Control in your enterprise. The actual audit policy settings
that you deploy will depend on your goals, which can include regulatory compliance,
monitoring, forensic analysis, and troubleshooting.
７ Note
Detailed information about how to plan and deploy an overall security auditing
strategy for your enterprise is explained in Planning and Deploying Advanced
Security Audit Policies. For more information about configuring and deploying a
security audit policy, see the Advanced Security Audit Policy Step-by-Step Guide.
The following security auditing capabilities in Windows Server 2012 can be used with
Dynamic Access Control to extend your overall security auditing strategy.
Expression-based audit policies. Dynamic Access Control enables you to create

targeted audit policies by using expressions based on user, computer, and
resource claims. For example, you could create an audit policy to track all Read and
Write operations on files classified as high-business impact by employees who do
not have a high-security clearance. Expression-based audit policies can be
authored directly for a file or folder or centrally through Group Policy. For more
information, see Group Policy using Global Object Access Auditing.
Additional information from object access auditing. File access auditing is not
new to Windows Server 2012 . With the right audit policy in place, the Windows
and Windows Server operating systems generate an audit event each time a user
accesses a file. Existing File Access events (4656, 4663) contain information about
the attributes of the file that was accessed. This information can be used by event
log filtering tools to help you identify the most relevant audit events. For more
information, see Audit Handle Manipulation and Audit Security Accounts Manager.
More information from user logon events. With the right audit policy in place,
Windows operating systems generate an audit event every time a user signs in to a
computer locally or remotely. In Windows Server 2012 or Windows 8, you can also
monitor user and device claims associated with a user's security token. Examples
can include Department, Company, Project, and Security clearances.Event 4626
contains information about these user claims and device claims, which can be
leveraged by audit log management tools to correlate user logon events with
object access events to enable event filtering based on file attributes and user
attributes. For more information about user logon auditing, see Audit Logon.
Change tracking for new types of securable objects. Tracking changes to

securable objects can be important in the following scenarios:
Change tracking for central access policies and central access rules. Central
access policies and central access rules define the central policy that can be
used to control access to critical resources. Any change to these can directly
impact the file access permissions that are granted to users on multiple
computers. Therefore, tracking changes to central access policies and central
access rules can be important for your organization. Because central access
policies and central access rules are stored in Active Directory Domain Services
(AD DS), you can audit attempts to modify them, like auditing changes to any
other securable object in AD DS. For more information, see Audit Directory
Service Access.
Change tracking for definitions in the claim dictionary. Claim definitions

include the claim name, description, and possible values. Any change to the
claim definition can impact the access permissions on critical resources.
Therefore, tracking changes to claim definitions can be important to your
organization. Like central access policies and central access rules, claim
definitions are stored in AD DS; therefore, they can be audited like any another
securable object in AD DS. For more information, see Audit Directory Service
Access.
Change tracking for file attributes. File attributes determine which central
access rule applies to the file. A change to the file attributes can potentially
impact the access restrictions on the file. Therefore, it can be important to track
changes to file attributes. You can track changes to file attributes on any
computer by configuring the authorization policy change auditing policy. For
more information, see Authorization Policy Change auditing and Object Access
auditing for File Systems. In Windows Server 2012 , Event 4911 differentiates file
attribute policy changes from other authorization policy change events.
Chang tracking for the central access policy associated with a file. Event 4913
displays the security identifiers (SIDs) of the old and new central access policies.
Each central access policy also has a user friendly name that can be looked up
using this security identifier. For more information, see Authorization Policy
Change auditing.
Change tracking for user and computer attributes. Like files, user and
computer objects can have attributes, and changes to these attributes can
impact the user's ability to access files. Therefore, it can be valuable to track
changes to user or computer attributes. User and computer objects are stored
in AD DS; therefore, changes to their attributes can be audited. For more
information, see DS Access.
Policy change staging. Changes to central access policies can impact the access
control decisions on all computers where the policies are enforced. A loose policy
could grant more access than desired, and an overly restrictive policy could
generate an excessive number of Help Desk calls. As a result, it can be extremely
valuable to verify changes to a central access policy before enforcing the change.
For that purpose, Windows Server 2012 introduces the concept of "staging."
Staging enables users to verify their proposed policy changes before enforcing
them. To use policy staging, proposed policies are deployed with the enforced
policies, but staged policies do not actually grant or deny permissions. Instead,
Windows Server 2012 logs an audit event (4818) any time the result of the access
check that uses the staged policy is different from the result of an access check
that uses the enforced policy.
Deploy Security Auditing with Central
Audit Policies (Demonstration Steps)
Article • 07/29/2021
In this scenario, you will audit access to files in the Finance Documents folder by using
the Finance Policy that you created in Deploy a Central Access Policy (Demonstration
Steps). If a user who is not authorized to access the folder attempts to access it, the
activity is captured in the event viewer.
The following steps are required to test this
scenario.
Task Description
Configure Global Object In this step, you configure the global object access policy on the
Access domain controller.
Update Group Policy Settings Sign in to the file server and apply the Group Policy update.
Verify that the global object View the relevant events in the event viewer. The events should
access policy has been applied include metadata for the country and document type.
Configure global object access policy

In this step, you configure the global object access policy in the domain controller.
To configure a global object access policy
1. Sign in to the domain controller DC1 as contoso\administrator with the password

pass@word1.
2. In Server Manager, point to Tools, and then click Group Policy Management.
3. In the console tree, double-click Domains, double-click contoso.com, click

Contoso, and then double-click File Servers.
4. Right-click FlexibleAccessGPO, and click Edit.
5. Double-click Computer Configuration, double-click Policies, and then double-click

Windows Settings.
6. Double-click Security Settings, double-click Advanced Audit Policy Configuration,
and then double-click Audit Policies.
7. Double-click Object Access, and then double-click Audit File System.
8. Select the Configure the following events check box, select the Success and
Failure check boxes, and then click OK.
9. In the navigation pane, double-click Global Object Access Auditing, and then
double-click File system.
10. Select the Define this policy setting check box, and click Configure.
11. In the Advanced Security Settings for Global File SACL box, click Add, then click
Select a principal, type Everyone, and then click OK.
12. In the Auditing Entry for Global File SACL box, select Full control in the
Permissions box.
13. In the Add a condition: section, click Add a condition and in the drop-down lists
select
[Resource] [Department] [Any of] [Value] [Finance].
14. Click OK three times to complete the configuration of the global object access
audit policy setting.
15. In the navigation pane, click Object Access, and in the results pane, double-click
Audit Handle Manipulation. Click Configure the following audit events, Success,
and Failure, click OK, and then close the flexible access GPO.
Update Group Policy settings

In this step, you update the Group Policy settings after you have created the audit
policy.
To update Group Policy settings

1. Sign in to the file server, FILE1 as contoso\Administrator, with the password
pass@word1.
2. Press the Windows key+R, then type cmd to open a Command Prompt window.
７ Note
If the User Account Control dialog box appears, confirm that the action it
displays is what you want, and then click Yes.
3. Type gpupdate /force and then press ENTER.
Verify that the global object access policy has

been applied
After the Group Policy settings have been applied, you can verify that the audit policy
settings were applied correctly.
To verify that the global object access policy has been applied
1. Sign in to client computer, CLIENT1 as Contoso\MReid. Browse to the folder
HYPERLINK "file:///\\\\ID_AD_FILE1\\Finance" \\ FILE1\Finance Documents, and
modify Word Document 2.
2. Sign in to the file server, FILE1 as contoso\administrator. Open Event Viewer,

browse to Windows Logs, select Security, and confirm that your activities resulted
in audit events 4656 and 4663 (even though you did not set explicit auditing
SACLs on the files or folders that you created, modified, and deleted).
） Important
A new logon event is generated on the computer where the resource is located, on
behalf of the user for whom effective access is being checked. When analyzing
security audit logs for user sign-in activity, to differentiate between logon events
that are generated because of effective access and those generated because of an
interactive network user sign in, the Impersonation Level information is included.
When the logon event is generated because of effective access, the Impersonation
Level will be Identity. A network interactive user sign in typically generates a logon
event with the Impersonation Level = Impersonation or Delegation.
See also
Scenario: File Access Auditing

Scenario: Access-Denied Assistance
Article • 06/06/2023
Users will get an access-denied message when they try to access shared files and folders
on a file server for which they do not have permissions. Administrators often do not
have the appropriate context to troubleshoot the access issue, which makes it hard to
resolve the issue.
Scenario description
Access-denied assistance is a new feature in Windows Server 2012, which provides the
following ways to troubleshoot issues that are related to access to files and folders:
Self-assistance. If a user can determine the issue and remediate the problem so
that they can get the requested access, the impact to the business is low, and no
special exceptions are needed in the central access policy. Access-denied
assistance provides an access-denied message that file server administrators can
customize with information specific to their organizations. For example, an
administrator could set the message so that users can request access from a data
owner without involving the file server administrator.
Assistance by the data owner. You can define a distribution list for shared folders,
and configure it so that the folder owner receives an email notification when a user
needs access. If the data owner does not know how to help the user get access, the
owner can forward this information to the file server administrator.
Assistance by the file server administrator. This type of assistance is available

when the user cannot fix an issue and the data owner cannot help. Windows Server
2012 provides a user interface where file server administrators can view the
effective permissions for a user on a file or folder so that it is easier to
troubleshoot access issues.
Access-denied assistance in Windows Server 2012 provides file server administrators the
relevant access details so that they can determine the issue and appropriate tools so
that they can make configuration changes to satisfy the access request. For example, a
user might follow this process to access a file that they currently do not have access to:
The user attempts to read a file in the \\financeshares shared folder, but the server
displays an access-denied message.
Windows Server 2012 displays the access-denied assistance information to the

user with an option to request assistance.
If the user requests access to the resource, the server sends an email with the
access request information to the folder owner.
You can find planning information for configuring access-denied assistance in Plan for
Access-Denied Assistance.
You can find steps about configuring access-denied assistance in Deploy Access-Denied
Assistance (Demonstration Steps).
In this scenario
This scenario is part of the Dynamic Access Control scenario. For more information
about Dynamic Access Control, see:
Practical applications
Access-denied assistance in Windows Server 2012 contributes to Dynamic Access
Control by giving users the ability to request access to shared files and folders directly
from an access-denied message.
Features included in this scenario

The following table lists the features that are part of this scenario and describes how
they support it.
Feature How it supports this scenario
File Server Access-denied assistance can be configured by using the File Server Resource
Resource Manager console on the file server.
Manager
Overview
File and Storage File Server Resource Manager is a File and Storage Services role service, and it
Services is comprised of a set of features that can be used to administer the file servers
Overview on your network.
Deploy Access-Denied Assistance
Article • 06/06/2023
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

GenerateLog -Type DWORD -value 1

IncludeDeviceClaims -Type DWORD -value 1

IncludeUserClaims -Type DWORD -value 1

PutAdminOnTo -Type DWORD -value 1
PutDataOwnerOnTo -Type DWORD -value 1

ErrorMessage -Type MultiString -value "Type the text that the user will see
in the error message dialog box."
Enabled -Type DWORD -value 1
Alternatively, you can configure access-denied assistance individually on each file server
by using the File Server Resource Manager console.
To configure access-denied assistance by using File Server Resource

Manager
1. Open File Server Resource Manager. In Server Manager, click Tools, and then click
File Server Resource Manager.
2. Right-click File Server Resource Manager (Local), and then click Configure
Options.
3. Click the Access-Denied Assistance tab.
4. Select the Enable access-denied assistance check box.
5. In the Display the following message to users who are denied access to a folder
or file box, type a message that users will see when they are denied access to a file
or folder.
include:
[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.

"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
2. Expand File Server Resource Manager (Local), and then click Classification
Management.
3. Right-click Classification Properties, and then click Set Folder Management

Properties.
4. In the Property box, click Access-Denied Assistance Message, and then click Add.
5. Click Browse, and then choose the folder that should have the custom access-
denied message.
6. In the Value box, type the message that should be presented to the users when
they cannot access a resource within that folder.
include:
[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.
2. Right-click File Server Resource Manager (Local), and then click Configure
Options.
3. Click the Email Notifications tab.
4. Configure the following settings:
In the SMTP server name or IP address box, type the name of IP address of
the SMTP server in your organization.
In the Default administrator recipients and Default 'From' e-mail address

boxes, type the email address of the file server administrator.
5. Click Send Test E-mail to ensure that the email notifications are configured
correctly.
6. Click OK.

set-FSRMSetting -SMTPServer "server1" -AdminEmailAddress

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

configured correctly
You can verify that the access-denied assistance is configured correctly by having a user
who is running Windows 8 try to access a share or a file in that share that they do not
have access to. When the access-denied message appears, the user should see a
Request Assistance button. After clicking the Request Assistance button, the user can
specify a reason for access and then send an email to the folder owner or file server
administrator. The folder owner or file server administrator can verify for you that the
email arrived and contains the appropriate details.
） Important
If you want to verify access-denied assistance by having a user who is running

Windows Server 2012 , you must install the Desktop Experience before connecting
to the file share.
See also
Scenario: Access-Denied Assistance
Plan for Access-Denied Assistance

Scenario: Classification-Based
Encryption for Office Documents
Article • 07/29/2021
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 AD DS provides a distributed database that stores and manages information

Directory about network resources and application-specific data from directory-enabled
Domain applications. In this scenario, AD DS in Windows Server 2012 introduces a claims-
Services role based authorization platform that enables the creation of user claims and device
(AD DS) 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 File and Storage Services provides technologies to help you set up and manage
Storage one or more file servers that provide central locations on your network where you
Services role can store files and share them with users. If your network users need access to the
File Server same files and applications, or if centralized backup and file management are
Resource important to your organization, you should set up one or more computers as a
Manager 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 AD RMS enables individuals and administrators (through Information Rights

Directory Management (IRM) policies) to specify access permissions to documents,
Rights workbooks, and presentations. This helps prevent sensitive information from
Management being printed, forwarded, or copied by unauthorized people. After permission for
Services (AD a file has been restricted by using IRM, the access and usage restrictions are
RMS) role 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
Article • 07/29/2021
Contoso's Finance Department has a number of file servers that store their documents.
These documents can be general documentation or they can have a high-business
impact (HBI). For example, any document that contains confidential information is
deemed, by Contoso, to have a high-business impact. Contoso wants to ensure that all
their documentation has a minimum amount of protection and that their HBI
documentation is restricted to the appropriate people. To accomplish this, Contoso is
exploring using the File Classification Infrastructure (FCI) and AD RMS that is available in
Windows Server 2012 . By using FCI, Contoso will classify all of the documents on their
file server, based on the content, and then use AD RMS to apply the appropriate rights
policy.
In this scenario, you'll perform the following steps:
Task Description
Enable resource Enable the Impact and Personally Identifiable Information resource
properties properties.
Create classification Create the following classification rules: HBI Classification Rule and PII
rules Classification Rule.
Use file management Create a file management task that automatically used AD RMS to
tasks to automatically protect documents with high personally identifiable information (PII).
protect documents Only members of the FinanceAdmin group will have access to
with AD RMS 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 Verify that the document is protected with AD RMS.

protection
Step 1: Enable resource properties

To enable resource properties
1. In Hyper-V Manager, connect to server ID_AD_DC1. Sign in to the server by using
Contoso\Administrator with the password pass@word1.
2. Open Active Directory Administrative Center, and click Tree View.
3. Expand DYNAMIC ACCESS CONTROL, and select Resource Properties.
4. Scroll down to the Impact property in the Display name column. Right-click
Impact, and then click Enable.
5. Scroll down to the Personally Identifiable Information property in the Display

name column. Right-click Personally Identifiable Information, and then click
Enable.
6. To publish the resource properties in the Global Resource List, in the left pane,
click Resource Property Lists, and then double-click Global Resource Property
List.
7. Click Add, and then scroll down to and click Impact to add it to the list. Do the
same for Personally Identifiable Information. Click OK twice to finish.
Set-ADResourceProperty -Enabled:$true -Identity:"CN=Impact_MS,CN=Resource

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

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

2. You need to refresh the Global Resource Properties from Active Directory. Open
Windows PowerShell and type: Update-FSRMClassificationPropertyDefinition , and
then press ENTER. Close Windows PowerShell.
3. Open File Server Resource Manager. To open File Server Resource Manager, click
Start, type file server resource manager, and then click File Server Resource
Manager.
4. In the left pane of File Server Resource Manager, expand Classification

Management, and then select Classification Rules.
5. In the Actions pane, click Configure Classification Schedule. On the Automatic

Classification tab, select Enable fixed schedule, select a Day of the week, and then
select the Allow continuous classification for new files check box. Click OK.
6. In the Actions pane, click Create Classification Rule. This opens the Create
Classification Rule dialog box.
7. In the Rule name box, type High Business Impact.
8. In the Description box, type Determines if the document has a high business
impact based on the presence of the string "Contoso Confidential"
9. On the Scope tab, click Set Folder Management Properties, select Folder Usage,
click Add, then click Browse, browse to D:\Finance Documents as the path, click
OK, and then choose a property value named Group Files and click Close. Once
management properties are set, on the Rule Scope tab select Group Files.
10. Click the Classification tab. Under Choose a method to assign the property to
files, select Content Classifier from the drop-down list.
11. Under Choose a property to assign to files, select Impact from the drop-down list.
12. Under Specify a value, select High from the drop-down list.
13. Click Configure under Parameters. In the Classification Parameters dialog box, in
the Expression Type list, select String. In the Expression box, type: Contoso
Confidential, and then click OK.
14. Click the Evaluation Type tab. Click Re-evaluate existing property values, click
Overwritethe existing value, and then click OK to finish.
Update-FSRMClassificationPropertyDefinition
$date = Get-Date
$AutomaticClassificationScheduledTask = New-FsrmScheduledTask -Time $date -

Weekly @(3, 2, 4, 5,1,6,0) -RunDuration 0;
Set-FsrmClassification -Continuous -schedule

$AutomaticClassificationScheduledTask
New-FSRMClassificationRule -Name "High Business Impact" -Property

"Impact_MS" -Description "Determines if the document has a high business
impact based on the presence of the string 'Contoso Confidential'" -
PropertyValue "3000" -Namespace @("D:\Finance Documents") -
ClassificationMechanism "Content Classifier" -Parameters
@("StringEx=Min=1;Expr=Contoso Confidential") -ReevaluateProperty Overwrite
To create the high-PII classification rule

2. On the desktop, open the folder named Regular Expressions, and then open the
text document named RegEx-SSN. Highlight and copy the following regular
expression string: ^(?!000)([0-7]\d{2}|7([0-7]\d|7[012]))([ -]?)
(?!00)\d\d\3(?!0000)\d{4}$. This string will be used later in this step so keep it on
your clipboard.
Manager.
4. In the left pane of File Server Resource Manager, expand Classification

Management, and then select Classification Rules.
5. In the Actions pane, click Configure Classification Schedule. On the Automatic

Classification tab, select Enable fixed schedule, select a Day of the week, and then
select the Allow continuous classification for new files check box. Click OK.
6. In the Rule name box, type High PII. In the Description box, type Determines if
the document has a high PII based on the presence of a Social Security Number.
7. Click the Scope tab, select the Group Files check box.
8. Click the Classification tab. Under Choose a method to assign the property to
files, select Content Classifier from the drop-down list.
9. Under Choose a property to assign to files, select Personally Identifiable

Information from the drop-down list.
10. Under Specify a value, select High from the drop-down list.
11. Click Configure under Parameters.

In the Classification Parameterswindow, in the
Expression Type list, select Regular Expression. In the Expression box, paste the
text from your clipboard: ^(?!000)([0-7]\d{2}|7([0-7]\d|7[012]))([ -]?)
(?!00)\d\d\3(?!0000)\d{4}$, and then click OK.
７ Note
This expression will allow invalid Social Security numbers. This allows us to use
fictitious Social Security numbers in the demonstration.
12. Click the Evaluation Type tab. Select Re-evaluate existing property values,
Overwritethe existing value, and then click OK to finish.
New-FSRMClassificationRule -Name "High PII" -Description "Determines if the

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

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

automatically protect documents with AD RMS
Now that you've created rules to automatically classify documents based on content, the
next step is to create a file management task that uses AD RMS to automatically protect
certain documents based on their classification. In this step, you will create a file
management task that automatically protects any documents with a high PII. Only
members of the FinanceAdmin group will have access to documents that contain high
PII.
To protect documents with AD RMS

Manager.
3. In the left pane, select File Management Tasks. In the Actions pane, select Create
File Management Task.
4. In the Task name: field, type High PII. In the Description field, type Automatic
RMS protection for high PII documents.
5. Click the Scope tab, select the Group Files check box.
6. Click the Action tab. Under Type, select RMS Encryption. Click Browse to select a
template, and then select the Contoso Finance Admin Only template.
7. Click the Condition tab, and then click Add. Under Property, select Personally
Identifiable Information. Under Operator, select Equal. Under Value, select High.
Click OK.
8. Click the Schedule tab. In the Schedule section, click Weekly, and then select
Sunday. Running the task once-a-week will ensure that you catch any documents
that may have been missed due to a service outage or other disruptive event.
9. In the Continuous operation section, select Run task continuously on new files,
and then click OK. You should now have a file management task named High PII.
$fmjRmsEncryption = New-FSRMFmjAction -Type 'Rms' -RmsTemplate 'Contoso

Finance Admin Only'
$fmjCondition1 = New-FSRMFmjCondition -Property 'PII_MS' -Condition 'Equal'

-Value '5000'
$date = get-date
$schedule = New-FsrmScheduledTask -Time $date -Weekly @('Sunday')
$fmj1=New-FSRMFileManagementJob -Name "High PII" -Description "Automatic RMS

protection for high PII documents" -Namespace @('D:\Finance Documents') -
Action $fmjRmsEncryption -Schedule $schedule -Continuous -Condition
@($fmjCondition1)
Step 4: View the results

It's time to take a look at your new automatic classification and AD RMS protection rules
in action. In this step you will examine the classification of documents and observe how
they change as you change the content in the document.
To view the results

2. In Windows Explorer, navigate to D:\Finance Documents.
3. Right-click the Finance Memo document and click Properties.Click the

Classification tab, and notice that the Impact property currently has no value. Click
Cancel.
4. Right-click the Request for Approval to Hire document, and then select
Properties.
5. Click the Classification tab, and notice that the Personally Identifiable Information
property currently has no value. Click Cancel.
6. Switch to CLIENT1. Sign off any user who is signed in, and then sign in as
Contoso\MReid with the password pass@word1.
7. From the Desktop, open the Finance Documents shared folder.
8. Open the Finance Memo document. Near the bottom of the document, you will
see the word Confidential. Modify it to read: Contoso Confidential. Save the
document and close it.
9. Open the Request for Approval to Hire document. In the Social Security#: section,
type: 777-77-7777. Save the document and close it.
７ Note
You may need to wait 30 seconds for the classification to occur.
10. Switch back to ID_AD_FILE1. In Windows Explorer, navigate to D:\Finance

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

1. Switch back to ID_AD_CLIENT1.
2. Open the Request for approval to Hire document.
3. Click OK to allow the document to connect to your AD RMS server.
4. You can now see that the document has been protected by AD RMS because it
contains a Social Security number.
Scenario: Get Insight into Your Data by
Using Classification
Article • 07/29/2021
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
This scenario is part of the Dynamic Access Control scenario. For additional information
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.
Features included in this scenario

The following table lists the features that are part of this scenario and describes how
they support it.
Feature How it supports this scenario
File Server Resource File Classification Infrastructure is a feature that is included in File
Manager Overview Server Resource Manager.
File and Storage Services File Server Resource Manager is a feature that is included with the
Overview File Services server role.
Deploy Automatic File Classification
Article • 07/29/2021
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
This topic includes sample Windows PowerShell cmdlets that you can use to
automate some of the procedures described. For more information, see Using
Cmdlets .

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

Configuration,CN=Services,CN=Configuration,DC=contoso,DC=com'
Set-ADResourceProperty '"Enabled:$true '"Identity:'CN=PII_MS,CN=Resource

Configuration,CN=Services,CN=Configuration,DC=contoso,DC=com'
Step 2: Create a string content classification

rule
A string content classification rule scans a file for a specific string. If the string is found,
the value of a resource property can be configured. In this example, we will scan each
file on a network shared folder and look for the string 'Contoso Confidential.' If the
string is found, the associated file is classified as having high business impact.

To create a string content classification rule
1. Log on to the file server as a member of the Administrators security group.
2. From the Windows PowerShell command prompt, type Update-

FsrmClassificationPropertyDefinition and then press ENTER. This will synchronize
the property definitions created on the domain controller to the file server.
4. Expand Classification Management, right-click Classification Rules, and then click

Configure Classification Schedule.
5. Select the Enable fixed schedule check box, select the Allow continuous
classification for new files check box, choose a day of the week to run the
classification, and then click OK.
6. Right-click Classification Rules, and then click Create Classification Rule.
7. On the General tab, in the Rule name box, type a rule name such as Contoso
Confidential.
8. On the Scope tab, click Add, and choose the folders that should be included in this
rule, such as D:\Finance Documents.
７ Note
You can also choose a dynamic name space for the scope. For more
information about dynamic name spaces for classification rules, see What's
New in File Server Resource Manager in Windows Server 2012
[redirected] .
9. On the Classification tab, configure the following:
In the Choose a method to assign a property to files box, ensure that

Content Classifier is selected.
In the Choose a property to assign to files box, click Impact.
In the Specify a value box, click High.
10. Under the Parameters heading, click Configure.
11. In the Expression Type column, select String.

12. In the Expression column, type Contoso Confidential, and then click OK.
13. On the Evaluation Type tab, select the Re-evaluate existing property values check
box, click Overwrite the existing value, and then click OK.
$date = Get-Date
$AutomaticClassificationScheduledTask = New-FsrmScheduledTask -Time $date -

Weekly @(3, 2, 4, 5,1,6,0) -RunDuration
0;$AutomaticClassificationScheduledTask
Set-FsrmClassification -Continuous -schedule

$AutomaticClassificationScheduledTask
New-FSRMClassificationRule -Name 'Contoso Confidential' -Property

"Impact_MS" -PropertyValue "3000" -Namespace @('D:\Finance Documents') -
@("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.

FsrmClassificationPropertyDefinition, and then press ENTER. This will synchronize
the property definitions that are created on the domain controller to the file server.
4. Right-click Classification Rules, and then click Create Classification Rule.
5. On the General tab, in the Rule name box, type a name for the classification rule,
such as PII Rule.
6. On the Scope tab, click Add, and then choose the folders that should be included
in this rule, such as D:\Finance Documents.
7. On the Classification tab, configure the following:
In the Choose a method to assign a property to files box, ensure that

Content Classifier is selected.
In the Choose a property to assign to files box, click Personally Identifiable

Information.
In the Specify a value box, click High.
8. Under the Parameters heading, click Configure.
9. In the Expression Type column, select Regular expression.
10. In the Expression column, type ^(?!000)([0-7]\d{2}|7([0-7]\d|7[012]))([ -]?)

(?!00)\d\d\3(?!0000)\d{4}$
11. In the Minimum Occurrences column, type 10, and then click OK.
12. On the Evaluation Type tab, select the Re-evaluate existing property values check
box, click Overwrite the existing value, and then click OK.
New-FSRMClassificationRule -Name "PII Rule" -Property "PII_MS" -

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

correctly
You can verify that the files are properly classified by viewing the properties of a file that
was created in the folder specified in the classification rules.
To verify that the files are classified correctly
1. On the file server, run the classification rules by using File Server Resource
Manager.
a. Click Classification Management, right-click Classification Rules, and then click

Run Classification With All Rules Now.
b. Click the Wait for classification to complete option, and then click OK.
c. Close the Automatic Classification Report.
d. You can do this by using Windows PowerShell with the following command:
Start-FSRMClassification '"RunDuration 0 -Confirm:$false
2. Navigate to the folder that was specified in the classification rules, such as
D:\Finance Documents.
3. Right-click a file in that folder, and then click Properties.
4. Click the Classification tab, and verify that the file is classified correctly.
See also
Scenario: Get Insight into Your Data by Using Classification
Plan for Automatic File Classification

Scenario: Implement Retention of
Information on File Servers
Article • 04/01/2022
A retention period is the amount of time that a document should be kept before it's
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 time frame 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 won't 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 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
This scenario is part of the Dynamic Access Control scenario. For more information

Plan for retention of information on file
servers
Article • 04/01/2022
A data retention policy is important for any organization. You can use the following
information to plan how you retain information in your organization.
Determine the retention schedule

Determining how long data is stored on file servers in your network and developing a
data retention schedule offers the following advantages:
Limits the amount of data to store which lowers the overall cost of storage in your
organization
Reduces liability
Satisfies regulations
When you're determining your retention schedule, you should ensure that the retention
schedule meets the regulatory compliance of the industry your organization is in. For
example, if your company is a healthcare provider, you should understand the HIPAA
regulations.
Identify files to be retained

Before you can implement your data retention policy, you must first identify the data
that is stored on each file server. Once the data has been identified, you should mark
the folders with a retention period and retention start date. Also, you should remove the
Delete Child permission from any folders that could contain files that are being retained.
This will ensure that the files aren't accidentally deleted.
） Important
Classification properties should not be specified as a date. You should use the
retention period to classify the file. If the retention period should change, you can
update the retention period interval without having to classify every file again.
Considerations for multiple computers
There are several things to consider when you've more than one file server in your
organization:
Data retention policies are usually the same across the organization so you can
reuse the same set of rules on multiple computers.
The Data Classification Toolkit uses Windows PowerShell cmdlets to import and
export classification rules. You should use this to export the configuration from a
baseline computer and import to another computer to ensure that the
configuration is the same.
You should use dynamic name spaces when the source and destination servers use
the same drive letters for the storage on the server. When you create a new file
share by using Server Manager, you can specify the name space.
See also
Scenario: Implement Retention of Information on File Servers
Deploy Implementing Retention of Information on File Servers (Demonstration
Steps)
Deploy Implementing Retention of
Information on File Servers
Article • 04/01/2022
You can set retention periods for folders and put files on legal hold by using File
Classification Infrastructure and File Server Resource Manager.
Prerequisites
The steps in this article assume you have an SMTP server configured for file expiration
notifications.

In this step, you 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:
GUI
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, select Tools,

and then select Active Directory Administrative Center.
3. Expand Dynamic Access Control, and then select Resource Properties.
4. Right-click Retention Period, and then select Enable.
5. Right-click Discoverability, and then select Enable.

Step 2: Configure notifications
In this step, you 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:
GUI

FsrmClassificationPropertyDefinition, and then press ENTER. This will
synchronize the property definitions that are created on the domain controller
to the file server.
3. Open File Server Resource Manager. In Server Manager, select Tools, and then
select File Server Resource Manager.
4. Right-click File Server Resource Manager (local), and then select Configure
Options.
5. On the Email Notifications tab, configure the following parameters:
In the SMTP server name or IP address box, type the name of the SMTP
server on your network.
In the Default administrator recipients box, type the email address of

the administrator who should get the notification.
In the Default "From" e-mail address box, type the email address that
should be used to send the notifications.
6. Select OK.
Step 3: Create a file management task

In this step, you use the File Server Resource Manager console to create a file
management task that expires files with the following criteria:
The file isn't classified as being on legal hold.

The file is classified as having a long-term retention period.
The file hasn't been modified in the last 10 years.
The task will run on the last day of the month.
To create the file management task:
GUI
2. Open File Server Resource Manager. In Server Manager, select Tools, and then
select File Server Resource Manager.
3. Right-click File Management Tasks, and then select 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, select Add, and choose the folders that should be included
in this rule, such as D:\Finance Documents.
6. On the Action tab, in the Type box, select File expiration. In the Expiration
directory box, type a path to a folder on the local file server where the expired
files will be moved. This folder should have an access control list that grants
only file server administrators access.
7. On the Notification tab, select 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 select OK.
8. On the Condition tab, select Add, and add the following properties:
In the Property list, select Discoverability. In the Operator list, select Not
equal. In the Value list, select Hold.
In the Property list, select Retention Period. In the Operator list, select
Equal. In the Value list, select 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, select the Monthly option, and then select the Last
check box.
11. Select OK.
Step 4: Classify a file manually

In this step, you 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 select Properties.
4. On the Classification tab, select Retention Period, select Long-Term, and then
select OK.
5. Right-click a file within that folder, and then select Properties.
6. On the Classification tab, select Discoverability, select Hold, select Apply, and
then select 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 wasn't moved to the expiration directory.
8. Right-click the same file within that folder, and then select Properties.
9. On the Classification tab, select Discoverability, select Not Applicable, select

Apply, and then select 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

Deploy Claims Across Forests
Article • 07/29/2021
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)
Claims Transformation Rules Language

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

environment
The test configuration involves setting up two forests: Adatum Corporation and
Contoso, Ltd, and having a two-way trust between Contoso and Adatum. "adatum.com"
is the trusted forest and "contoso.com" is the trusting forest.
The claims transformation scenario demonstrates transformation of a claim in the

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

Adatum and Contoso Source attribute: company
Suggested values: Contoso, Adatum Important: You must set the ID on

the 'Company' claim type on both Contoso and Adatum to be the same
for the claims transformation to work.
Central access rule AdatumEmployeeAccessRule

on Contoso
Objects Details
Central access policy Adatum Only Access Policy

on Contoso
Claims DenyAllExcept Company

Transformation
policies on Adatum
and Contoso
File folder on D:\EARNINGS

Contoso
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 create a transformation policy Adatum to deny all claims

except 'Company'
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 apply the claims transformation policy
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 create a transformation policy Adatum to deny all except

'Company'
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 set the claims transformation policy
1. Sign in to the domain controller, contoso.com as Administrator with the password

pass@word1.
2. Open an elevated command prompt in Windows PowerShell and type the

following:
Set-ADClaimTransformLink
-Identity:"adatum.com" `
-Policy:"DenyAllClaimsExceptCompanyPolicy" `
-TrustRole:Trusting `
Validate the scenario

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

policies
Following is a list of additional common cases in claims transformation.
Scenario Policy
Allow all claims that come from Code -
Adatum to go through to Contoso New-ADClaimTransformPolicy `
Adatum -Description:"Claims transformation policy to allow all

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

claims" `
-Name:"DenyAllClaimsPolicy" `
-DenyAll `
-Policy:"DenyAllClaimsPolicy" `
-Server:"contoso.com"`
Scenario Policy
Allow all claims that come from Code
Adatum except "Company" and - New-ADClaimTransformationPolicy `
"Department" to go through to -Description:"Claims transformation policy to allow all claims

Contoso Adatum 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

Article • 06/09/2022
The across-forest claims transformation feature enables you to bridge claims for
Dynamic Access Control across forest boundaries by setting claims transformation
policies on across-forest trusts. The primary component of all policies is rules that are
written in claims transformation rules language. This topic provides details about this
language and provides guidance about authoring claims transformation rules.
The Windows PowerShell cmdlets for transformation policies on across-forest trusts

have options to set simple policies that are required in common scenarios. These
cmdlets translate the user input into policies and rules in the claims transformation rules
language, and then store them in Active Directory in the prescribed format. For more
information about cmdlets for claims transformation, see the AD DS Cmdlets for
Dynamic Access Control.
Depending on the claims configuration and the requirements placed on the across-
forest trust in your Active Directory forests, your claims transformation policies may
have to be more complex than the policies supported by the Windows PowerShell
cmdlets for Active Directory. To effectively author such policies, it is essential to
understand the claims transformation rules language syntax and semantics. This claims
transformation rules language ("the language") in Active Directory is a subset of the
language that is used by Active Directory Federation Services for similar purposes, and it
has a very similar syntax and semantics. However, there are fewer operations allowed,
and additional syntax restrictions are placed in the Active Directory version of the
language.
This topic briefly explains the syntax and semantics of the claims transformation rules
language in Active Directory and considerations to be made when authoring policies. It
provides several sets of example rules to get you started, and examples of incorrect
syntax and the messages they generate, to help you decipher error messages when you
author the rules.
Tools for authoring claims transformation

policies
Windows PowerShell cmdlets for Active Directory: This is the preferred and
recommended way to author and set claims transformation policies. These cmdlets
provide switches for simple policies and verify rules that are set for more complex
policies.
LDAP: Claims transformation policies can be edited in Active Directory through

Lightweight Directory Access Protocol (LDAP). However, this is not recommended
because the policies have several complex components, and the tools you use may not
validate the policy before writing it to Active Directory. This may subsequently require a
considerable amount of time to diagnose problems.
Active Directory claims transformation rules

language
Syntax overview
Here is a brief overview of the syntax and semantics of the language:
The claims transformation rule set consists of zero or more rules. Each rule has two
active parts: Select Condition List and Rule Action. If the Select Condition List
evaluates to TRUE, the corresponding rule action is executed.
Select Condition List has zero or more Select Conditions. All of the Select
Conditions must evaluate to TRUE for the Select Condition List to evaluate to
TRUE.
Each Select Condition has a set of zero or more Matching Conditions. All the
Matching Conditions must evaluate to TRUE for the Select Condition to evaluate
to TRUE. All of these conditions are evaluated against a single claim. A claim that
matches a Select Condition can be tagged by an Identifier and referred to in the
Rule Action.
Each Matching Condition specifies the condition to match the Type or Value or
ValueType of a claim by using different Condition Operators and String Literals.
When you specify a Matching Condition for a Value, you must also specify a
Matching Condition for a specific ValueType and vice versa. These conditions
must be next to each other in the syntax.
ValueType matching conditions must use specific ValueType literals only.

A Rule Action can copy one claim that is tagged with an Identifier or issue one
claim based on a claim that is tagged with an Identifier and/or given String Literals.
Example rule
This example shows a rule that can be used to translate the claims Type between two
forests, provided that they use the same claims ValueTypes and have the same
interpretations for claims Values for this type. The rule has one matching condition and
an Issue statement that uses String Literals and a matching claims reference.
C1: [TYPE=="EmployeeType"]
=> ISSUE (TYPE= "EmpType", VALUE = C1.VALUE, VALUETYPE =

C1.VALUETYPE);
[TYPE=="EmployeeType"] == Select Condition List with one Matching Condition

for claims Type.
ISSUE (TYPE= "EmpType", VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE) == Rule

Action that issues a claims using string literal and matching claim referred
with the Identifier.
Runtime operation
It is important to understand the runtime operation of claims transformations to author
the rules effectively. The runtime operation uses three sets of claims:
1. Input claims set: The input set of claims that are given to the claims
transformation operation.
2. Working claims set: Intermediate claims that are read from and written to during
the claims transformation.
3. Output claims set: Output of the claims transformation operation.
Here is a brief overview of the runtime claims transformation operation:
1. Input claims for claims transformation are used to initialize the working claims set.
a. When processing each rule, the working claims set is used for the input claims.
b. The Selection Condition List in a rule is matched against all possible sets of
claims from the working claims set.
c. Each set of matching claims is used to run the action in that rule.
d. Running a rule action results in one claim, which is appended to the output
claims set and the working claims set. Thus, the output from a rule is used as
input for subsequent rules in the rule set.
2. The rules in the rule set are processed in sequential order starting with the first
rule.
3. When the entire rule set is processed, the output claims set is processed to remove
duplicate claims and for other security issues.The resulting claims are the output of
the claims transformation process.
It is possible to write complex claims transformations based on the previous runtime

behavior.
Example: Runtime operation
This example shows the runtime operation of a claims transformation that uses two
rules.
C1:[Type=="EmpType", Value=="FullTime",ValueType=="string"] =>
Issue(Type=="EmployeeType",
Value=="FullTime",ValueType=="string");
[Type=="EmployeeType"] =>
Issue(Type=="AccessType", Value=="Privileged",
ValueType=="string");
Input claims and Initial Evaluation Context:
{(Type= "EmpType"),(Value="FullTime"),(ValueType="String")}
{(Type= "Organization"),(Value="Marketing"),(ValueType="String")}
After Processing Rule 1:
Evaluation Context:
{(Type= "Organization"), (Value="Marketing"),(ValueType="String")}
{(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
Output Context:
After Processing Rule 2:
Evaluation Context:
{(Type= "Organization"),(Value="Marketing"),(ValueType="String")}
{(Type= "AccessType"),(Value="Privileged"),(ValueType="String")}
Output Context:
Final Output:
Special rules semantics

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

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

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

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

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

Error message:
POLICY0002: Could not parse policy data.
Line number: 1, Column number: 2, Error
token: ;. Line: 'c1;[]=>Issue(claim=c1);'.
Parser error: 'POLICY0030: Syntax error,
unexpected ';', expecting one of the following: ':' .'
2. Example:
c1:[]=>Issue(claim=c2);
In this example, the Identifier tag in the copy issuance statement is undefined.
Error message:
POLICY0011: No conditions in the claim rule match the condition
tag specified in the CopyIssuanceStatement: 'c2'.
3. Example:
c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)
"bool" is not a Terminal in the language, and it is not a valid ValueType. Valid
terminals are listed in the following error message.
Error message:
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:
Line
number: 1, Column number: 23, Error token: 1. Line: 'c1:[type=="x1", value==1,
valuetype=="bool"]=>Issue(claim=c1);'.Parser error: 'POLICY0029: Unexpected
input.
5. Example:
c1:[type == "x1", value == "1", valuetype == "boolean"] =>
Issue(type = c1.type, value="0", valuetype == "boolean");
This example used a double equal sign (==) instead of a single equal sign (=).
Error message:
Line number: 1, Column
number: 91, Error token: ==. Line: 'c1:[type=="x1", value=="1",
valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype=="boolean");'.
Parser error: 'POLICY0030: Syntax error, unexpected '==', expecting one of the
following: '='
6. Example:
c1:[type=="x1", value=="boolean", valuetype=="string"] =>
Issue(type=c1.type, value=c1.value, valuetype = "string");
This example is syntactically and semantically correct. However, using "boolean" as

a string value is bound to cause confusion, and it should be avoided. As previously
mentioned, using language terminals as claims values should be avoided where
possible.
Language terminals
The following table lists the complete set of terminal strings and the associated
language terminals that are used in the claims transformation rules language. These
definitions use case-insensitive UTF-16 strings.
String Terminal
"=>" IMPLY
";" SEMICOLON
":" COLON
"," COMMA
"." DOT
"[" O_SQ_BRACKET
"]" C_SQ_BRACKET
"(" O_BRACKET
")" C_BRACKET
"==" EQ
"!=" NEQ
"=~" REGEXP_MATCH
"!~" REGEXP_NOT_MATCH
"=" ASSIGN
"&&" AND
"issue" ISSUE
"type" TYPE
"value" VALUE
"valuetype" VALUE_TYPE
"claim" CLAIM
"[_A-Za-z][_A-Za-z0-9]*" IDENTIFIER
"\"[^\"\n]*\"" STRING
"uint64" UINT64_TYPE
"int64" INT64_TYPE
"string" STRING_TYPE
"boolean" BOOLEAN_TYPE
Language syntax
The following claims transformation rules language is specified in ABNF form. This
definition uses the terminals that are specified in the previous table in addition to the
ABNF productions defined here. The rules must be encoded in UTF-16, and the string
comparisons must be treated as case insensitive.
Rule_set = ;/*Empty*/
/ Rules
Rules = Rule
/ Rule Rules
Rule = Rule_body
Rule_body = (Conditions IMPLY Rule_action SEMICOLON)
Conditions = ;/*Empty*/
/ Sel_condition_list
Sel_condition_list = Sel_condition
/ (Sel_condition_list AND Sel_condition)
Sel_condition = Sel_condition_body
/ (IDENTIFIER COLON Sel_condition_body)
Sel_condition_body = O_SQ_BRACKET Opt_cond_list C_SQ_BRACKET
Opt_cond_list = /*Empty*/
/ Cond_list
Cond_list = Cond
/ (Cond_list COMMA Cond)
Cond = Value_cond
/ Type_cond
Type_cond = TYPE Cond_oper Literal_expr
Value_cond = (Val_cond COMMA Val_type_cond)
/(Val_type_cond COMMA Val_cond)
Val_cond = VALUE Cond_oper Literal_expr
Val_type_cond = VALUE_TYPE Cond_oper Value_type_literal
claim_prop = TYPE
/ VALUE
Cond_oper = EQ
/ NEQ
/ REGEXP_MATCH
/ REGEXP_NOT_MATCH
Literal_expr = Literal
/ Value_type_literal
Expr = Literal
/ Value_type_expr
/ (IDENTIFIER DOT claim_prop)
Value_type_expr = Value_type_literal
/(IDENTIFIER DOT VALUE_TYPE)
Value_type_literal = INT64_TYPE
/ UINT64_TYPE
/ STRING_TYPE
/ BOOLEAN_TYPE
Literal = STRING
Rule_action = ISSUE O_BRACKET Issue_params C_BRACKET
Issue_params = claim_copy
/ claim_new
claim_copy = CLAIM ASSIGN IDENTIFIER
claim_new = claim_prop_assign_list
claim_prop_assign_list = (claim_value_assign COMMA claim_type_assign)
/(claim_type_assign COMMA claim_value_assign)
claim_value_assign = (claim_val_assign COMMA claim_val_type_assign)
/(claim_val_type_assign COMMA claim_val_assign)
claim_val_assign = VALUE ASSIGN Expr
claim_val_type_assign = VALUE_TYPE ASSIGN Value_type_expr
Claim_type_assign = TYPE ASSIGN Expr
Appendix A: Dynamic Access Control

Glossary
Article • 07/29/2021
Following are the list of terms and definitions that are included in the Dynamic Access
Control scenario.
Term Definition
Automatic Classification that occurs based on classification properties that are determined
classification 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 A rule that includes a condition and an access expression.

rule
Central access Policies that are authored and hosted in Active Directory.
policy
Claims-based A paradigm that utilizes claims to make access control decisions to resources.
access control
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 An access control list that identifies trustees who are allowed or denied access to
access control a securable resource. It can be modified at the discretion of the resource owner.
list (DACL)
Resource Properties (such as labels) that describe a file and are assigned to files by using
property automatic classification or manual classification. Examples include: Sensitivity,
Project, and Retention period.
Term Definition
File Server A feature in the Windows Server operating system that offers management of
Resource folder quotas, file screening, storage reports, file classification, and file
Manager management jobs on a file server.
Folder Properties and labels that describe a folder and are assigned manually by
properties and administrators and folder owners. These properties assign default property
labels 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 Automatic classification that is performed shortly after a file is created or
classification modified.
Near real-time File management tasks that are performed shortly after (a file is created or
file modified. These tasks are triggered by the Near real-time classification.
management
tasks
Organizational An Active Directory container that represents hierarchical, logical structures

Unit (OU) within an organization. It is the smallest scope to which Group Policy settings are
applied.
Secure A classification property that the authorization runtime can trust to be a valid
property 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 A data structure that contains security information associated with a securable
descriptor resource, such as access control lists.
Security A specification that describes the information in a security descriptor as a text

descriptor string.
definition
language
Staging policy A central access policy that is not yet in effect.
System access An access control list that specifies the types of access attempts by particular
control list trustees for which audit records need to be generated.
(SACL)
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.
Term Definition
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
Article • 07/29/2021
Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows
Server 2012 R2, Windows Server 2012
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 install the Hyper-V Role
1. Click Start, and then click Server Manager.
2. In the Roles Summary area of the Server Manager main window, click Add Roles.
3. On the Select Server Roles page, click Hyper-V.
4. On the Create Virtual Networks page, click one or more network adapters if you want to
make their network connection available to virtual machines.
5. On the Confirm Installation Selections page, click Install.
6. The computer must be restarted to complete the installation. Click Close to finish the
wizard, and then click Yes to restart the computer.
7. After you restart the computer, sign in with the same account you used to install the role.
After the Resume Configuration Wizard completes the installation, click Close to finish
the wizard.
Create an internal virtual network

Now you will create an internal virtual network called ID_AD_Network.
To create a virtual network
1. Open Hyper-V Manager.
2. From the Actions menu, click Virtual Network Manager.
3. Under Create virtual network, select the Internal.
4. Click Add. The New Virtual Network page appears.
5. Type ID_AD_Network as the name for the new network. Review the other properties and
modify them if necessary.
6. Click OK to create the virtual network and close Virtual Network Manager, or click Apply
to create the virtual network and continue using Virtual Network Manager.
Build the domain controller
Build a virtual machine to be used as the domain controller (DC1). Install the virtual machine
using Windows Server 2012 ISO, and name it DC1.
To install Active Directory Domain Services
1. Connect the virtual machine to the ID_AD_Network. Sign in to the DC1 as Administrator
with the password pass@word1.
2. In Server Manager, click Manage, and then click Add Roles and Features.
3. On the Before you begin page, click Next.
4. On the Select installation type page, click Role-based or Feature-based Install, and then
click Next.
5. On the Select destination server page, click Next.
6. On the Select server roles page, click Active Directory Domain Services. In the Add
Roles and Features Wizard dialog box, click Add Features, and then click Next.
7. On the Select features page, click Next.
8. On the Active Directory Domain Services page, review the information, and then click
Next.
9. On the Confirm installation selections page, click Install. The Feature installation
progress bar on the Results page indicates that the role is being installed.
10. On the Results page, verify that the installation succeeded, and click Close. In Server
Manager, click the warning icon with an exclamation mark on top right corner of the
screen, next to Manage. In the Tasks list, click the Promote this server to a domain
controller link.
11. On the Deployment Configuration page, click Add a new forest, type the name of the
root domain, contoso.com, and then click Next.
12. On the Domain Controller Options page, select the domain and forest functional levels
as Windows Server 2012, specify the DSRM password pass@word1, and then click Next.
13. On the DNS Options page, click Next.
14. On the Additional Options page, click Next.
15. On the Paths page, type the locations for the Active Directory database, log files, and
SYSVOL folder (or accept default locations), and then click Next.
16. On the Review Options page, confirm your selections, and then click Next.
17. On the Prerequisites Check page, confirm that the prerequisites validation is completed,
and then click Install.
18. On the Results page, verify that the server was successfully configured as a domain
controller, and then click Close.
19. Restart the server to complete the AD DS installation. (By default, this happens
automatically.)
Create the following users by using Active Directory Administrative Center.
Create users and groups on DC1
1. Sign in to contoso.com as Administrator. Launch Active Directory Administrative Center.
2. Create the following security groups:
Group Name Email Address
FinanceAdmin financeadmin@contoso.com
FinanceException financeexception@contoso.com
3. Create the following organizational unit (OU):
OU Name Computers
FileServerOU FILE1
4. Create the following users with the attributes indicated:
User Username Email address Department Group Country/Region
Myriam MDelesalle MDelesalle@contoso.com Finance US

Delesalle
Miles MReid MReid@contoso.com Finance FinanceAdmin US

Reid
Esther EValle EValle@contoso.com Operations FinanceException US

Valle
Maira MWenzel MWenzel@contoso.com HR US

Wenzel
Jeff Low JLow JLow@contoso.com HR US
RMS rms rms@contoso.com

Server
For more information about creating security groups, see Create a New Group on the
Windows Server website.
To create a Group Policy Object
1. Hover the cursor on the upper right corner of screen and click the search icon. In the
Search box, type group policy management, and click Group Policy Management.
2. Expand Forest: contoso.com, and then expand Domains, navigate to contoso.com,

expand (contoso.com), and then select FileServerOU. Right-click Create a GPO in this
domain and Link it here
3. Type a descriptive name for the GPO, such as FlexibleAccessGPO, and then click OK.
To enable Dynamic Access Control for contoso.com
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.
3. In the Group Policy Management Editor window, double-click Computer Configuration,

double-click Policies, double-click Administrative Templates, double-click System, and
then double-click KDC.
4. Double-click KDC support for claims, compound authentication, and Kerberos

armoring 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 install the File Services role and the File Server Resource Manager
1. In Server Manager, click Add Roles and Features.
3. On the Select installation type page, click Next.
4. On the Select destination server page, click Next.
5. On the Select Server Roles page, expand File and Storage Services, select the check-box
next to File and iSCSI Services, expand, and select File Server Resource Manager.
In the Add Roles and Features Wizard, click Add Features, and then click Next.
7. On the Confirm installation selections page, click Install.
8. On the Installation progress page, click Close.
Install the Microsoft Office Filter Packs on the file server
You should install the Microsoft Office Filter Packs on Windows Server 2012 to enable IFilters
for a wider array of Office files than are provided by default. Windows Server 2012 does not
have any IFilters for Microsoft Office Files installed by default, and the file classification
infrastructure uses IFilters to perform content analysis.
To download and install the IFilters, see Microsoft Office 2010 Filter Packs .
Configure email notifications on FILE1

When you create quotas and file screens, you have the option of sending email notifications
to users when their quota limit is approaching or after they have attempted to save files that
have been blocked. If you want to routinely notify certain administrators of quota and file
screening events, you can configure one or more default recipients. To send these
notifications, you must specify the SMTP server to be used for forwarding the email messages.
To configure email options in File Server Resource Manager
1. Open File Server Resource Manager. To open File Server Resource Manager, click Start,
type file server resource manager, and then click File Server Resource Manager.
2. In the File Server Resource Manager interface, right-click File Server Resource Manager,
and then click Configure options. The File Server Resource Manager Options dialog box
opens.
3. On the E-mail Notifications tab, under SMTP server name or IP address, type the host
name or the IP address of the SMTP server that will forward email notifications.
4. If you want to routinely notify certain administrators of quota or file screening events,
under Default administrator recipients, type each email address such as
fileadmin@contoso.com. Use the format account@domain, and use semicolons to
separate multiple accounts.
Create groups on FILE1
To create security groups on FILE1
1. Sign in to FILE1 as contoso\administrator, with the password: pass@word1.
2. Add NT AUTHORITY\Authenticated Users to the WinRMRemoteWMIUsers__ group.
Create files and folders on FILE1

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

Add the Active Directory Rights Management Services (AD RMS) and all required features
through Server Manager. Choose all the defaults.
To install Active Directory Rights Management Services
1. Sign in to the FILE1 as CONTOSO\Administrator or as a member of the Domain Admins

group.
） Important
In order to install the AD RMS server role the installer account (in this case,
CONTOSO\Administrator) will have to be given membership in both the local
Administrators group on the server computer where AD RMS is to be installed as
well as membership in the Enterprise Admins group in Active Directory.
2. In Server Manager, click Add Roles and Features. The Add Roles and Features Wizard
appears.
3. On the Before you Begin screen, click Next.
4. On the Select Installation Type screen, click Role/Feature Based Install, and then click
Next.
5. On the Select Server Targets screen, click Next.
6. On the Select Server Roles screen, select the box next to Active Directory Rights
Management Services, and then click Next.
7. In the Add features that are required for Active Directory Rights Management
Services? dialog box, click Add Features.
8. On the Select Server Roles screen, click Next.
9. On the Select Features to Install screen, click Next.
10. On the Active Directory Rights Management Services screen, click Next.
11. On the Select Role Services screen, click Next.
12. On the Web Server Role (IIS) screen, click Next.
13. On the Select Role Services screen, click Next.
14. On the Confirm Installation Selections screen, click Install.
15. After the installation has completed, on the Installation Progress screen, click Perform
additional configuration. The AD RMS Configuration Wizard appears.
16. On the AD RMS screen, click Next.
17. On the AD RMS Cluster screen, select Create a new AD RMS root cluster and then click
Next.
18. On the Configuration Database screen, click Use Windows Internal Database on this
server, and then click Next.
７ Note
Using the Windows Internal Database is recommended for test environments only
because it does not support more than one server in the AD RMS cluster.
Production deployments should use a separate database server.
19. On the Service Account screen, in Domain User Account, click Specify and then specify
the user name (contoso\rms), and Password (pass@word1) and click OK, and then click
Next.
20. On the Cryptographic Mode screen, click Cryptographic Mode 2.
21. On the Cluster Key Storage screen, click Next.
22. On the Cluster Key Password screen, in the Password and Confirm password boxes,
type pass@word1, and then click Next.
23. On the Cluster Web Site screen, make sure that Default Web Site is selected, and then
click Next.
24. On the Cluster Address screen, select the Use an unencrypted connection option, in the
Fully Qualified Domain Name box, type FILE1.contoso.com, and then click Next.
25. On the Licensor Certificate Name screen, accept the default name (FILE1) in the text box
and click Next.
26. On the SCP Registration screen, select Register SCP now, and then click Next.
27. On the Confirmation screen, click Install.
28. On the Results screen, click Close, and then click Close on Installation Progress screen.
When complete, log off and log on as contoso\rms using the password provided
(pass@word1).
29. Launch the AD RMS console and navigate to Rights Policy Templates.
To open the AD RMS console, in Server Manager, click Local Server in the console tree,
then click Tools, and then click Active Directory Rights Management Services.
30. Click the Create Distributed Rights Policy template located on the right panel, click Add,
and select the following information:
Language: US English
Name: Contoso Finance Admin Only
Description: Contoso Finance Admin Only
Click Add, and then click Next.
31. Under the Users and Rights section, click Users and rights, click Add, type
financeadmin@contoso.com, and click OK.
32. Select Full Control, and leave Grant owner (author) full control right with no expiration
selected.
33. Click though the remaining tabs with no changes, and then click Finish. Sign in as
CONTOSO\Administrator.
34. Browse to the folder, C:\inetpub\wwwroot\_wmcs\certification, select the

ServerCertification.asmx file, and add Authenticated Users to have Read and Write
permissions to the file.
35. Open Windows PowerShell and run Get-FsrmRmsTemplate . Verify that you are able to see
the RMS template you created in the previous steps in this procedure with this
command.
） Important
If you want your file servers to immediately change so you can test them, you need to do
the following:
1. On the file server, FILE1, open an elevated command prompt, and run the following
commands:
gpupdate /force.
NLTEST /SC_RESET:contoso.com
2. On the domain controller (DC1), replicate Active Directory.
For more information about steps to force the replication of Active Directory, see
Active Directory Replication
Optionally, instead of using the Add Roles and Features Wizard in Server Manager, you can
use Windows PowerShell to install and configure the AD RMS server role as show in the
following procedure.
To install and configure an AD RMS cluster in Windows Server 2012 using

Windows PowerShell
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
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
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 build the client virtual machine
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.
Enable Access-Denied assistance on the client virtual machine
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 install Active Directory Domain Services
1. Connect the virtual machine to the ID_AD_Network. Sign in to the DC2 as Administrator
with the password Pass@word1.
2. In Server Manager, click Manage, and then click Add Roles and Features.
4. On the Select Installation Type page, click Role-based or Feature-based Install, and
then click Next.
5. On the Select destination server page, click Select a server from the server pool, click
the names of the server where you want to install Active Directory Domain Services (AD
DS), and then click Next.
6. On the Select Server Roles page, click Active Directory Domain Services. In the Add
Roles and 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 server to a domain controller link.
） Important
If you close the installation wizard at this point rather than click Promote this server
to a domain controller, you can continue the AD DS installation by clicking Tasks in
Server Manager.
11. On the Deployment Configuration page, click Add a new forest, type the name of the
root domain, adatum.com, and then click Next.
12. On the Domain Controller Options page, select the domain and forest functional levels
as Windows Server 2012, specify the DSRM password pass@word1, and then click Next.
13. On the DNS Options page, click Next.
14. On the Additional Options page, click Next.
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,
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 set Contoso as a trusting forest to Adatum
1. Sign in to DC2 as administrator. On the Start screen, type domain.msc.
2. In the console tree, right-click adatum.com, and then click Properties.
3. On the Trusts tab, click New Trust, and then click Next.
4. On the Trust Name page, type contoso.com, in the Domain Name System (DNS) name
field, and then click Next.
5. On the Trust Type page, click Forest Trust, and then click Next.
6. On the Direction of Trust page, click Two-way.
7. On the Sides of Trust page, click Both this domain and the specified domain, and then
click Next.
8. Continue to follow the instructions in the wizard.
Create additional users in the Adatum forest

Create the user Jeff Low with the password pass@word1, and assign the company attribute
with the value Adatum.
To create a user with the Company attribute
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 create a claim type by using Windows PowerShell
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 enable the Company resource property on contoso.com
1. Sign in to contoso.com as an administrator.
2. In Server Manager, click Tools, and then click Active Directory Administrative Center.
3. In the left pane of Active Directory Administrative Center, click Tree View. In the left
pane, click Dynamic Access Control, and then double-click Resource Properties.
4. Select Company from the Resource Properties list, right-click and select Properties. In
the Suggested Values section, click Add to add the suggested values: Contoso and
Adatum, and then click OK twice.
5. Select Company from the Resource Properties list, right-click and select Enable.
Enable Dynamic Access Control on adatum.com
To enable Dynamic Access Control for adatum.com
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.
4. 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.
5. Double-click KDC support for claims, compound authentication, and Kerberos

armoring and select the option next to Enabled. You need to enable this setting to use
Central Access Policies.
6. Open an elevated command prompt, and run the following command:
gpupdate /force
Create the Company claim type on contoso.com
To create a claim type by using Windows PowerShell
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 create a central access rule
1. In the left pane of Active Directory Administrative Center, click Tree View. In the left
pane, click Dynamic Access Control, and then click Central Access Rules.
2. Right-click Central Access Rules, click New, and then Central Access Rule.
3. In the Name field, type AdatumEmployeeAccessRule.
4. In the Permissions section, select the Use following permissions as current permissions
option, click Edit, and then click Add. Click the Select a principal link, type Authenticated
Users, and then click OK.
5. In the Permission Entry for Permissions dialog box, click Add a condition, and enter the
following conditions: [User] [Company] [Equals] [Value] [Adatum]. Permissions should be
Modify, Read and Execute, Read, Write.
6. Click OK.
7. Click OK three times to finish and return to Active Directory Administrative Center.
New-ADCentralAccessRule `
-CurrentAcl:"O:SYG:SYD:AR(A;;FA;;;OW)(A;;FA;;;BA)(A;;FA;;;SY)
(XA;;0x1301bf;;;AU;(@USER.ad://ext/Company:ContosoAdatum == `"Adatum`"))" `
-Name:"AdatumEmployeeAccessRule" `
-ProposedAcl:$null `
-ProtectedFromAccidentalDeletion:$true `
Create the central access policy
To create a central access policy
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 apply the central access policy across file servers through Group
Policy
1. On the Start screen, type Administrative Tools, and in the Search bar, click Settings. In
the Settings results, click Administrative Tools. Open the Group Policy Management
Console from the Administrative Tools folder.
 Tip
If the Show Administrative tools setting is disabled, the Administrative Tools folder
and its contents will not appear in the Settings results.
2. Right-click the contoso.com domain, click Create a GPO in this domain and Link it here
3. Type a descriptive name for the GPO, such as AdatumAccessGPO, and then click OK.
To apply the central access policy to the file server through Group
Policy
1. On the Start screen, type Group Policy Management, in the Search box. Open Group
Policy Management from the Administrative Tools folder.
 Tip
If the Show Administrative tools setting is disabled, the Administrative Tools folder
and its contents will not appear in the Settings results.
2. Navigate to and select Contoso as follows: Group Policy Management\Forest:

contoso.com\Domains\contoso.com.
3. Right-click the AdatumAccessGPO policy, and select Edit.
4. In Group Policy Management Editor, click Computer Configuration, expand Policies,

expand Windows Settings, and then click Security Settings.
5. Expand File System, right-click Central Access Policy, and then click Manage Central
access policies.
6. In the Central Access Policies Configuration dialog box, click Add, select Adatum Only
Access Policy, and then click OK.
7. Close the Group Policy Management Editor. You have now added the central access
policy to Group Policy.
Create the Earnings folder on the file server

Create a new NTFS volume on FILE1, and create the following folder: D:\Earnings.
７ Note
Central access policies are not enabled by default on the system or boot volume C:.
Set classification and apply the central access policy on the

Earnings folder
To assign the central access policy on the file server
1. In Hyper-V Manager, connect to server FILE1. Sign in to the server by using

Contoso\Administrator, with the password pass@word1.
2. Open an elevated command prompt and type: gpupdate /force. This will ensure that
your Group Policy changes will take effect on your server.
3. You also need to refresh the Global Resource Properties from Active Directory. Open
Windows PowerShell, type Update-FSRMClassificationpropertyDefinition , and then
press ENTER. Close Windows PowerShell.
4. Open Windows Explorer, and navigate to D:\EARNINGS. Right-click the Earnings folder,
and click Properties.
5. Click the Classification tab. Select Company, and then select Adatum in the Value field.
6. Click Change, select Adatum Only Access Policy from the drop-down menu, and then
click Apply.
7. Click the Security tab, click Advanced, and then click the Central Policy tab. You should
see the AdatumEmployeeAccessRule listed. You can expand the item to view all of the
permissions that you set when you created the rule in Active Directory.
8. Click OK to return to Windows Explorer.

Configuring Certificate Enrollment Web
Service for certificate key-based renewal
on a custom port
Article • 01/29/2021
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 certificates for
autoenrollment renewal requests options are selected.
2. Switch to the Issuance Requirements tab, and then select the CA certificate
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 Server
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
Step 1: Install the instance
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:
PowerShell
Import-Module ServerManager
Add-WindowsFeature Adcs-Enroll-Web-Pol
Add-WindowsFeature Adcs-Enroll-Web-Svc
PowerShell
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, <SSLCertThumbPrint> is the thumbprint of the certificate that

will be used to bind IIS.
PowerShell
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.
Step 2 Check the Internet Information Services (IIS) Manager
console
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
Step 1: Install the CEP and CES for key-based renewal on the same
server.
Run the following command in PowerShell:
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.
PowerShell
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 certificate.
SSLCertThumbPrint 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.
Step 2 Check the IIS Manager console
After a successful installation, you expect to see the following display in the IIS Manager
console.
Select KeyBasedRenewal_ADPolicyProvider_CEP_Certificate 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.
Step 1: Create a computer account of the workgroup computer in

Active Directory
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.
Step 2: Configure the service account for Constrained Delegation

(S4U2Self )
Run the following PowerShell command to enable constrained delegation (S4U2Self or
any authentication protocol):
PowerShell
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.
Step 3: Configure a custom port on the IIS web server
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.
Step 4: Edit the CA enrollment services Object on Active Directory
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-Servers 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/C
ES1
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 Start > Run, and then enter gpedit.msc.

2. Go to Computer Configuration > Windows Settings > Security Settings, and then
click Public Key Policies.
3. Enable the Certificate Services Client - Auto-Enrollment policy to match the

settings in the following screenshot.
4. Enable Certificate Services Client - Certificate 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 Certificate Services Client – Certificate

Enrollment Policy, and then add the key-based renewal enrollment policy:
a. Click Add, enter the CEP URI with Certificate 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 Certificates
(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 certificates, and then click OK.
Method 1
Run the following command:
PowerShell
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
Article • 07/29/2021
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 Design and Planning
AD DS Deployment
AD DS Operations
Active Directory Domain Services Virtualization
AD DS Troubleshooting
What's new in Active Directory Domain
Services for Windows Server 2016
Article • 08/15/2022
Applies to: Windows Server 2022, Windows Server 2019, 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 Windows Hello for Business 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 for 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 logon 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 the SYSVOL folder. If
you created the domain at a lower functional level, you will need to migrate from using
FRS to DFS replication for the SYSVOL folder. 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. For more information, see the following resources:
Understanding Active Directory Domain Services (AD DS) Functional Levels

Raise the Domain Functional Level
Raise the Forest Functional Level
AD DS Getting Started
Article • 07/29/2021
Active Directory stores information about objects on the network and makes this
information easy for administrators and users to find and use. Active Directory uses a
structured data store as the basis for a logical, hierarchical organization of directory
information.
Topic Description
Active Provides information on basic AD DS features. Includes technical concepts, links

Directory to planning and deployment.
Domain
Services
Overview
Active Provides information about the Active Directory Administrative Center that
Directory includes enhanced management experience features. These features ease the
Administrative administrative burden for managing Active Directory Domain Services (AD DS).
Center
Active Provides overview and technical information on AD DS Virtualization.

Directory
Domain
Services
Virtualization
Windows Time Provides details on what is the Windows Time Service, the importance of Time
Service Protocols, and how the Windows Time Service works.
Overview
Article • 08/16/2022
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 Global catalog.
A query and index mechanism, so that objects and their properties can be
published and found by network users or applications. For more information about
querying the directory, see Searching in Active Directory Domain Services.
A replication service that distributes directory data across a network. All domain
controllers in a domain participate in replication and contain a complete copy of all
directory information for their domain. Any change to directory data is replicated
to all domain controllers in the domain. For more information about Active
Directory replication, see Active Directory Replication Concepts.
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.
Active Directory Administrative Center
Article • 07/29/2021
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)
Article • 07/29/2021
The Active Directory Administrative Center in Windows Server includes management

features for the following:
Active Directory Recycle Bin

Fine-Grained Password Policy
Windows PowerShell History Viewer
Active Directory Recycle Bin

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

Step 2: Enable Recycle Bin
Step 3: Create test users, group and organizational unit
Step 4: Restore deleted objects
７ Note
Membership in the Enterprise Admins group or equivalent permissions is required

to perform the following steps.
Step 1: Raise the forest functional level

In this step, you will raise the forest functional level. You must first raise the functional
level on the target forest to be Windows Server 2008 R2 at a minimum before you
enable Active Directory Recycle Bin.
To raise the functional level on the target forest

1. Right click the Windows PowerShell icon, click Run as Administrator and type
dsac.exe to open ADAC.
2. Click Manage, click Add Navigation Nodes and select the appropriate target
domain in the Add Navigation Nodes dialog box and then click OK.
3. Click the target domain in the left navigation pane and in the Tasks pane, click
Raise the forest functional level. Select a forest functional level that is at least
Windows Server 2008 R2 or higher and then click OK.
PowerShell
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.
PowerShell
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 Properties.
6. Click Members, click Add, type test1;test2, and then click OK.
PowerShell
Add-ADGroupMember -Identity group1 -Member test1
To create an organizational unit
domain in the Add Navigation Nodes dialog box and then click **OK
3. In the Tasks pane, click New and then click Organizational Unit.
4. Enter the following information under Organizational Unit and then click OK:
NameOU1
PowerShell
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.
PowerShell
Get-ADUser -Filter 'Name -Like "*test*"'|Remove-ADUser -Confirm:$false
4. Navigate to the Deleted Objects container, select test2 and test1 and then click
Restore in the Tasks pane.
5. To confirm the objects were restored to their original location, navigate to the
target domain and verify the user accounts are listed.
７ Note
If you navigate to the Properties of the user accounts test1 and test2 and
then click Member Of, you will see that their group membership was also
restored.
PowerShell
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.
PowerShell
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 raise the domain functional level
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.
PowerShell
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).

In the following procedure you will create a new fine-grained password policy using the
UI in ADAC.
To create a new fine grained password policy
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.
PowerShell
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 view a resultant set of policies for a user
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.
PowerShell
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
To edit a fine-grained password policy
3. In the ADAC Navigation Pane, expand System and then click Password Settings
Container.
4. Select the fine grained password policy you created in Step 3: Create a new fine-
grained password policy and click Properties in the Tasks pane.
5. Under Enforce password history, change the value of Number of passwords

remembered to 30.
6. Click OK.
PowerShell
Set-ADFineGrainedPasswordPolicy TestPswd -PasswordHistoryCount:"30"
Step 6: Delete a fine-grained password policy
To delete a fine-grained password policy
3. In the ADAC Navigation Pane, expand System and then click Password Settings
Container.
4. Select the fine grained password policy you created in Step 3: Create a new fine-
grained password policy and in the Tasks pane click Properties.
5. Clear the Protect from accidental deletion checkbox and click OK.
6. Select the fine grained password policy, and in the Tasks pane click Delete.
7. Click OK in the confirmation dialog.
PowerShell
Set-ADFineGrainedPasswordPolicy -Identity TestPswd -

ProtectedFromAccidentalDeletion $False
Remove-ADFineGrainedPasswordPolicy TestPswd -Confirm

ADAC is a user interface tool built on top of Windows PowerShell. In Windows Server
2012 and newer, IT administrators can leverage ADAC to learn Windows PowerShell for
Active Directory cmdlets by using the Windows PowerShell History Viewer. As actions
are executed in the user interface, the equivalent Windows PowerShell command is
shown to the user in Windows PowerShell History Viewer. This allows administrators to
create automated scripts and reduce repetitive tasks, thus increasing IT productivity.
Also, this feature reduces the time to learn Windows PowerShell for Active Directory and
increases the users' confidence in the correctness of their automation scripts.
When using the Windows PowerShell History Viewer in Windows Server 2012 or newer
consider the following:
To use Windows PowerShell Script Viewer, you must use the Windows Server 2012
or newer version of ADAC
７ Note
Have a basic understanding of Windows PowerShell. For example, you need to

know how piping in Windows PowerShell works. For more information about
piping in Windows PowerShell, see Piping and the Pipeline in Windows PowerShell.
Windows PowerShell History Viewer step-by-step

In the following procedure, you will use the Windows PowerShell History Viewer in
ADAC to construct a Windows PowerShell script. Before you begin this procedure,
remove user, test1 from the group, group1.
To construct a script using PowerShell History Viewer

3. Expand the Windows PowerShell History pane at the bottom of the ADAC screen.
4. Select user, test1.
5. Click Add to group... in the Tasks pane.
6. Navigate to group1 and click OK in the dialog box.
7. Navigate to the Windows PowerShell History pane and locate the command just
generated.
8. Copy the command and paste it into your desired editor to construct your script.
For example, you can modify the command to add a different user to group1, or
add test1 to a different group.
See Also
Advanced AD DS Management Using Active Directory Administrative Center (Level 200)
Advanced AD DS Management Using
(Level 200)
Article • 06/06/2022
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
Using the Active Directory Administrative Center Windows PowerShell History
Viewer
Troubleshooting AD DS Management

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
Capabilities
The Windows Server 2012 or newer Active Directory Administrative Center enables
you to configure and manage the Active Directory Recycle Bin for any domain
partition in a forest. There is no longer a requirement to use Windows PowerShell
or Ldp.exe to enable the Active Directory Recycle Bin or restore objects in domain
partitions.
The Active Directory Administrative Center has advanced filtering criteria, making
targeted restoration easier in large environments with many intentionally deleted
objects.
Limitations
Because the Active Directory Administrative Center can only manage domain
partitions, it cannot restore deleted objects from the Configuration, Domain DNS,
or Forest DNS partitions (you cannot delete objects from the Schema partition). To
restore objects from non-domain partitions, use Restore-ADObject.
The Active Directory Administrative Center cannot restore sub-trees of objects in a
single action. For example, if you delete an OU with nested OUs, users, groups, and
computers, restoring the base OU does not restore the child objects.
７ Note
The Active Directory Administrative Center batch restore operation does a

"best effort" sort of the deleted objects within the selection only so parents are
ordered before the children for the restore list. In simple test cases, sub-trees
of objects may be restored in a single action. But corner cases, such as a
selection that contains partial trees - trees with some of the deleted parent
nodes missing - or error cases, such as skipping the child objects when parent
restore fails, may not work as expected. For this reason, you should always
restore sub-trees of objects as a separate action after you restore the parent
objects.
The Active Directory Recycle Bin requires a Windows Server 2008 R2 Forest Functional
Level and you must be a member of the Enterprise Admins group. Once enabled, you
cannot disable Active Directory Recycle Bin. Active Directory Recycle Bin increases the
size of the Active Directory database (NTDS.DIT) on every domain controller in the
forest. Disk space used by the recycle bin continues to increase over time as it preserves
objects and all their attribute data.
Enabling Active Directory Recycle Bin using Active

Directory Administrative Center
To enable the Active Directory Recycle Bin, open the Active Directory Administrative
Center and click the name of your forest in the navigation pane. From the Tasks pane,
click Enable Recycle Bin.
The Active Directory Administrative Center shows the Enable Recycle Bin Confirmation
dialog. This dialog warns you that enabling the recycle bin is irreversible. Click OK to
enable the Active Directory Recycle Bin. The Active Directory Administrative Center
shows another dialog to remind you that the Active Directory Recycle Bin is not fully
functional until all domain controllers replicate the configuration change.
） Important
The option to enable the Active Directory Recycle Bin is unavailable if:
The forest functional level is less than Windows Server 2008 R2

It is already enabled
The equivalent Active Directory Windows PowerShell cmdlet is:
PowerShell
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
Filtering
Active Directory Administrative Center offers powerful criteria and filtering options that
you should become familiar with before you need to use them in a real-life restoration.
Domains intentionally delete many objects over their lifetime. With a likely deleted
object lifetime of 180 days, you cannot simply restore all objects when an accident
occurs.
Rather than writing complex LDAP filters and converting UTC values into dates and
times, use the basic and advanced Filter menu to list only the relevant objects. If you
know the day of deletion, the names of objects, or any other key data, use that to your
advantage when filtering. Toggle the advanced filter options by clicking the chevron to
the right of the search box.
The restore operation supports all the standard filter criteria options, the same as any
other search. Of the built-in filters, the important ones for restoring objects are typically:
ANR (ambiguous name resolution - not listed in the menu, but what is used when
you type in theFilterbox)
Last modified between given dates
Object is user/inetorgperson/computer/group/organization unit
Name
When deleted
Last known parent
Type
Description
City
Country /region
Department
Employee ID
First name
Job title
Last name
SAMaccountname
State/Province
Telephone number
UPN
ZIP/Postal code
You can add multiple criteria. For example, you can find all user objects deleted on
September 24, 2012 from Chicago, Illinois with a job title of Manager.
You can also add, modify, or reorder the column headers to provide more detail when
evaluating which objects to recover.
For more information about Ambiguous Name Resolution, see ANR Attributes.
Single Object
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.
Multiple Peer Objects
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.
Multiple Parent and Child Objects
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:
PowerShell
Restore-adobject
The Restore-ADObject cmdlet functionality did not change between Windows Server
2008 R2 and Windows Server 2012.
Server-side Filtering
It is possible that over time, the Deleted Objects container will accumulate over 20,000
(or even 100,000) objects in medium and large enterprises and have difficulty showing
all objects. Since the filter mechanism in Active Directory Administrative Center relies on
client-side filtering, it cannot show these additional objects. To work around this
limitation, use the following steps to perform a server-side search:
1. Right click the Deleted Objects container and click Search under this node.
2. Click the chevron to expose the +Add criteria menu, select and add Last modified
between given dates. The Last Modified time (the whenChanged attribute) is a
close approximation of the deletion time; in most environments, they are identical.
This query performs a server-side search.
3. Locate the deleted objects to restore by using further display filtering, sorting, and
so on in the results, and then restore them normally.
Configuring and Managing Fine-Grained

Password Policies Using Active Directory
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:
PowerShell
Add-ADFineGrainedPasswordPolicySubject
Get-ADFineGrainedPasswordPolicy
Get-ADFineGrainedPasswordPolicySubject
New-ADFineGrainedPasswordPolicy
Remove-ADFineGrainedPasswordPolicy
Remove-ADFineGrainedPasswordPolicySubject
Set-ADFineGrainedPasswordPolicy
Fine-Grained Password Policy cmdlet functionality did not change between the Windows
Server 2008 R2 and Windows Server 2012. As a convenience, the following diagram
illustrates the associated arguments for cmdlets:
The Active Directory Administrative Center also enables you to locate the resultant set of
applied FGPP for a specific user. Right click any user and click View resultant password
settings... to open the Password Settings page that applies to that user through implicit
or explicit assignment:
Examining the Properties of any user or group shows the Directly Associated Password
Settings, which are the explicitly assigned FGPPs:
Implicit FGPP assignment does not display here; for that, you must use the View
resultant password settings... option.
Using the Active Directory Administrative

Center Windows PowerShell History Viewer
The future of Windows management is Windows PowerShell. By layering graphical tools
on top of a task automation framework, management of the most complex distributed
systems becomes consistent and efficient. You need to understand how Windows
PowerShell works in order to reach your full potential and maximize your computing
investments.
The Active Directory Administrative Center now provides a complete history of all the
Windows PowerShell cmdlets it runs and their arguments and values. You can copy the
cmdlet history elsewhere for study or modification and re-use. You can create Task notes
to assist in isolating what your Active Directory Administrative Center commands
resulted in Windows PowerShell. You can also filter the history to find points of interest.
The Active Directory Administrative Center Windows PowerShell History Viewer's
purpose is for you to learn through practical experience.
Click the chevron (arrow) to show Windows PowerShell History Viewer.
Then, create a user or modify a group's membership. The history viewer continually
updates with a collapsed view of each cmdlet that the Active Directory Administrative
Center ran with the arguments specified.
Expand any line item of interest to see all values provided to the cmdlet's arguments:
Click the Start Task menu to create a manual notation before you use Active Directory
Administrative Center to create, modify, or delete an object. Type in what you were
doing. When done with your change, select End Task. The task note groups all of those
actions performed into a collapsible note you can use for better understanding.
For example, to see the Windows PowerShell commands used to change a user's
password and remove him from a group:
Selecting the Show All check box also shows the Get-* verb Windows PowerShell
cmdlets that only retrieve data.
The history viewer shows the literal commands run by the Active Directory
Administrative Center and you might note that some cmdlets appear to run
unnecessarily. For example, you can create a new user with:
PowerShell
new-aduser
and do not need to use:
PowerShell
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:
XML
<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)" -Server:"dc1.corp.contoso.com"
[12:42:49][TID 3][Info] 4, Output, Get-ADOptionalFeature, 2012-04-

16T12:42:49, 1

1

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)" -Server:"dc1.corp.contoso.com"
[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,lastKnownPa
rent,sAMAccountType,systemFlags,userAccountControl,displayName,descript
ion,whenChanged,location,managedBy,memberOf,primaryGroupID,objectSid,ms
DS-User-Account-Control-
Computed,sAMAccountName,lastLogonTimestamp,lastLogoff,mail,accountExpir
es,msDS-PhoneticCompanyName,msDS-PhoneticDepartment,msDS-
PhoneticDisplayName,msDS-PhoneticFirstName,msDS-
PhoneticLastName,pwdLastSet,operatingSystem,operatingSystemServicePack,
operatingSystemVersion,telephoneNumber,physicalDeliveryOfficeName,depar
tment,company,manager,dNSHostName,groupType,c,l,employeeID,givenName,sn
,title,st,postalCode,managedBy,userPrincipalName,isDeleted,msDS-
PasswordSettingsPrecedence
-ResultPageSize:"100"
-ResultSetSize:"20201"
-SearchBase:"DC=corp,DC=contoso,DC=com"
-SearchScope:"Base"
-Server:"dc1.corp.contoso.com"
Setting the Verbose level also shows the .NET stacks for each function, but these do not
include enough data to be particularly useful except when troubleshooting the Dsac.exe
suffering an access violation or crash. The two likely causes of this issue are:
The ADWS service is not running on any accessible domain controllers.

Network communications are blocked to the ADWS service from the computer
running the Active Directory Administrative Center.
） Important
There is also an out-of-band version of the service called the Active Directory
Management Gateway, which runs on Windows Server 2008 SP2 and Windows
Server 2003 SP2.
The errors shown when no Active Directory Web Services instances are available are:
Error Operation
"Cannot connect to any domain. Refresh or try again Shown at start of the Active Directory
when connection is available" Administrative Center application
"Cannot find an available server in the <NetBIOS Shown when trying to select a domain
domain name> domain that is running the Active node in the Active Directory
Directory Web Service (ADWS)" 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
Virtualization
Article • 07/29/2021
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)
Article • 05/17/2023
Applies to: Windows Server 2022, Windows Server 2019, 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 won't converge because other domain
controllers will believe they have already received the updates associated with the
reused 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 aren't inbound
replicated by destination domain controllers that have previously seen the USN.
Because these destination domain controllers believe they're 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 don't exist on one or more replication
partners. Or, the password updates that originated on the rollback domain controller
don't 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 can't change the password on a
domain controller that won't 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's 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're observed by an administrator.
If you suspect a USN rollback has occurred but don't 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 reuse. 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 shut down. 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 roll
back a virtual machine's state doesn't 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 isn't

recommended as an alternative mechanism to backing up a domain controller. It's
recommended that you continue to use Windows Server Backup or other VSS-writer
based backup solutions.
Ｕ Caution
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're 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 isn't 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)
Article • 07/29/2021
The virtualized domain controller (VDC) technical reference consists of the following
topics:
Virtualized Domain Controller Architecture
Virtualized Domain Controller Deployment and Configuration
Virtualized Domain Controller Troubleshooting
Virtualized Domain Controller Technical Reference Appendix
Virtualized Domain Controller Additional Resources

Virtualized Domain Controller
Architecture
Article • 05/17/2023
This article 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 reuse 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 repromoting using the
existing NTDS.DIT and SYSVOL contents copied from source media.
In a mixed environment where some hypervisors support VM-GenerationID and others

don't, it's possible for a clone media to be accidentally deployed on a hypervisor that
doesn't 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 isn't 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 isn't 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 won't 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 retry operation

The following steps explain the process in more detail:
1. An existing virtual machine domain controller boots up in a hypervisor that

supports VM-Generation ID.
a. This VM has no existing VM Generation-ID value set on its AD DS computer

object after promotion.
b. Even if it's null, the next computer creation will mean it still clones, as a new VM
Generation-ID won't match.
c. The VM Generation-ID is set after the next reboot of the DC, and doesn't
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 isn't a new virtual machine and cloning won't 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 don't match, this is a new virtual machine that contains an
NTDS.DIT from a previous domain controller (or it's 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 doesn't provide a VM-Generation ID for comparison but there's

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's 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 doesn't 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's already set to 0x1, this is a "retry" cloning attempt, where a previous
cloning operation failed. The VDC object duplication safety measures aren't
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 doesn't exist in any valid location, the guest checks the IP address for
duplication. If the IP address isn't duplicated, the server boots up normally. If
there's 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 aren't part of
the DefaultDCCloneAllowList.xml or CustomDCCloneAllowList.xml
a. If there are services or programs installed that's not in the default exclusion
allowlist or the custom exclusion allowlist, 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 doesn't 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's 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
nonauthoritative synchronization of SYSVOL when the service is next started. The
guest doesn't delete the file contents of SYSVOL, to preseed 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's no database, SYSVOL non-
authoritatively synchronizes inbound from a replication partner. This process
reuses 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
<SysprepInformation> 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 isn't 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 doesn't 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's 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 reuse 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 don't 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're 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's 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 isn't 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 nonauthoritatively 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 nonauthoritatively replicates inbound,
reusing 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\<database
GUID>). It then starts the DFSR service, which nonauthoritatively replicates
inbound, reusing 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
Deployment and Configuration
Article • 04/28/2023
This topic covers:
Installation Considerations
This includes platform requirements and other important constraints.
Virtualized Domain Controller Cloning
This explains in detail the entire virtualized domain controller cloning process.
Virtualized Domain Controller Safe Restore
This explains in detail the validations that are made during virtualized domain
controller safe restore.
Installation Considerations
There is no special role or feature installation for virtualized domain controllers; all
domain controllers automatically contain cloning and safe restore capabilities. You
cannot remove or disable these capabilities.
Use of Windows Server 2012 domain controllers requires a Windows Server 2012 AD DS
Schema version 56 or higher and forest functional level equal to Windows Server 2003
Native or higher.
Both writable and read-only domain controllers support all aspects of virtualized DC, as
do Global Catalogs and FSMO roles.
） Important
The PDC Emulator FSMO role holder must be online when cloning begins.
Platform Requirements
Virtualized Domain Controller cloning requires:
PDC emulator FSMO role hosted on a Windows Server 2012 DC
PDC emulator available during cloning operations
Both cloning and safe restore require:
Windows Server 2012 virtualized guests
Virtualization host platform supports VM-Generation ID (VMGID)
Review the table below for virtualization products and whether they support virtualized
domain controllers and VM-Generation ID.
Virtualization Product Supports virtualized domain controllers

and VMGID
Microsoft Windows Server 2012 server with Yes

Hyper-V Feature
Microsoft Windows Server 2012 Hyper-V Server Yes
Microsoft Windows 8 with Hyper-V Client Feature Yes
Windows Server 2008 R2 and Windows Server No

2008
Non-Microsoft virtualization solutions Contact vendor
Even though Microsoft supports Windows 7 Virtual PC, Virtual PC 2007, Virtual PC 2004,
and Virtual Server 2005, they cannot run 64-bit guests, nor do they support VM-
GenerationID.
For help with third party virtualization products and their support stance with virtualized
domain controllers, contact that vendor directly.
For more information, review Support policy for Microsoft software running in non-
Microsoft hardware virtualization software .
Critical Caveats
Virtualized domain controllers do not support safe restore of the following:
VHD and VHDX files manually copied over existing VHD files
VHD and VHDX files restored using file backup or full disk backup software
７ Note
VHDX files are new to Windows Server 2012 Hyper-V.
Neither of these operations is covered under VM-GenerationID semantics and therefore

do not change the VM-Generation ID. Restoring domain controllers using these
methods could either result in a USN rollback and either quarantine the domain
controller or introduce lingering objects and the need for forest wide cleanup
operations.
２ Warning
Virtualized domain controller safe restore is not a replacement for system state
backups and the AD DS Recycle Bin.
After restoring a snapshot, the deltas of previously un-replicated changes

originating from that domain controller after the snapshot are permanently lost.
Safe restore implements automated non-authoritative restoration to prevent
accidental domain controller quarantine only.
For more information about USN bubbles and lingering objects, see Troubleshooting
Active Directory operations that fail with error 8606: "Insufficient attributes were given
to create an object" .

There are a number of stages and steps to cloning a virtualized domain controller,
regardless of using graphical tools or Windows PowerShell. At a high level, the three
stages are:
Prepare the environment
Step 1: Validate that the hypervisor supports VM-Generation ID and therefore,

cloning
Step 2: Verify the PDC emulator role is hosted by a domain controller that runs
Windows Server 2012 and that it is online and reachable by the cloned domain
controller during cloning.
Prepare the source domain controller
Step 3: Authorize the source domain controller for cloning

Step 4: Remove incompatible services or programs or add them to the
CustomDCCloneAllowList.xml file.
Step 5: Create DCCloneConfig.xml
Step 6: Take the source domain controller offline
Create the cloned domain controller
Step 7: Copy or export the source VM and add the XML if not already copied
Step 8: Create a new virtual machine from the copy
Step 9: Start the new virtual machine to commence cloning
There are no procedural differences in the operation when using graphical tools such as
the Hyper-V Management Console or command-line tools such as Windows PowerShell,
so the steps are presented only once with both interfaces. This topic provides Windows
PowerShell samples for you to explore end-to-end automation of the cloning process;
they are not required for any steps. There is no graphical management tool for
virtualized domain controllers included in Windows Server 2012.
There are several points in the procedure where you have choices for how to create the
cloned computer and how you add the xml files; these steps are noted in the details
below. The process is otherwise unalterable.
The following diagram illustrates the virtualized domain controller cloning process,
where the domain already exists.
Step 1 - Validate the Hypervisor
Ensure the source domain controller is running on a supported hypervisor by reviewing
vendor documentation. Virtualized domain controllers are hypervisor-independent and
do not require Hyper-V.
If the hypervisor is Microsoft Hyper-V, ensure it is running on Windows Server 2012 .

You can validate this using Device Management
Open Devmgmt.msc and examine System Devices for installed Microsoft Hyper-V
devices and drivers. The specific system device required for a virtualized domain
controller is the Microsoft Hyper-V Generation Counter (driver: vmgencounter.sys).
Step 2 - Verify the PDCE FSMO role
Before you attempt to clone a DC, you must validate that the domain controller hosting
the Primary Domain Controller Emulator FSMO runs Windows Server 2012. The PDC
emulator (PDCE) is required for several reasons:
1. The PDCE creates the special Cloneable Domain Controllers group and sets its
permission on the root of the domain to allow a domain controller to clone itself.
2. The cloning domain controller contacts the PDCE directly using the DRSUAPI RPC
protocol, in order to create computer objects for the clone DC.
７ Note
Windows Server 2012 extends the existing Directory Replication Service (DRS)
Remote Protocol (UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2) to
include a new RPC method IDL_DRSAddCloneDC (Opnum 28). The
IDL_DRSAddCloneDC method creates a new domain controller object by
copying attributes from an existing domain controller object.
The states of a domain controller are composed of computer, server, NTDS
settings, FRS, DFSR, and connection objects maintained for each domain
controller. When duplicating an object, this RPC method replaces all
references to the original domain controller with corresponding objects of the
new domain controller. The caller must have the control access right DS-
Clone-Domain-Controller on the domain naming context.
Use of this new method always requires direct access to the PDC emulator
domain controller from the caller.
Because this RPC method is new, your network analysis software requires
updated parsers to include fields for the new Opnum 28 in the existing UUID
E3514235-4B06-11D1-AB04-00C04FC2DCD2. Otherwise, you cannot parse
this traffic.
For more information, see 4.1.29 IDL_DRSAddCloneDC (Opnum 28).
This also means when using non-fully routed networks, virtualized domain controller
cloning requires network segments with access to the PDCE. It is acceptable to move a
cloned domain controller to a different network after cloning - just like a physical
domain controller - as long as you are careful to update the AD DS logical site
information.
） Important
When cloning a domain that contains only a single domain controller, you must
ensure the source DC is back online before starting the clone copies. A production
domain should always contain at least two domain controllers.
Active Directory Users and Computers Method
1. Using the Dsa.msc snap-in, right click the domain and click Operations Masters.
Note the domain controller named on the PDC tab and close the dialog.
2. Right-click that DC's computer object and click Properties, and then validate the
Operating System info.
Windows PowerShell Method

You can combine the following Active Directory Windows PowerShell Module cmdlets to
return the version of the PDC emulator:
Get-adddomaincontroller
Get-adcomputer
If not provided the domain, these cmdlets assume the domain of the computer where
run.
The following command returns PDCE and Operating System info:
get-adcomputer(Get-ADDomainController -Discover -Service "PrimaryDC").name -

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

The source domain controller must have the control access right (CAR) Allow a DC to
create a clone of itself on the domain NC head. By default, the well-known group
Cloneable Domain Controllers has this permission and contains no members. The PDCE
creates this group when that FSMO role transfers to a Windows Server 2012 domain
controller.
Active Directory Administrative Center Method

1. Start Dsac.exe and navigate to the source DC, then open its detail page.
2. In the Member Of section, add the Cloneable Domain Controllers group for that
domain.

You can combine the following Active Directory Windows PowerShell Module cmdlets
get-adcomputer and add-adgroupmember to add a domain controller to the
Cloneable Domain Controllers group:
Get-adcomputer <dc name> | %{add-adgroupmember "cloneable domain

controllers" $_.samaccountname}
For instance, this adds server DC1 to the group, without the need to specify the
distinguished name of the group member:
Rebuilding Default Permissions

If you remove this permission from the domain head, cloning fails. You can recreate the
permission using the Active Directory Administrative Center or Windows PowerShell.
Active Directory Administrative Center Method
1. Open Active Directory Administrative Center, right-click the domain head, click
Properties, click the Extensions tab, click Security, and then click Advanced. Click
This Object Only.
2. Click Add, under Enter the object name to select, type the group name Cloneable
Domain Controllers.
3. Under Permissions, click Allow a DC to create a clone of itself, and then click OK.
７ Note
You can also remove the default permission and add individual domain controllers.
Doing so is likely to cause ongoing maintenance problems however, where new
administrators are unaware of this customization. Changing the default setting
does not increase security and is discouraged.

Use the following commands in an administrator-elevated Windows PowerShell console
prompt. These commands detect the domain name and add back in the default
permissions:
import-module activedirectory
cd ad:
$domainNC = get-addomain
$dcgroup = get-adgroup "Cloneable Domain Controllers"
$sid1 = (get-adgroup $dcgroup).sid
$acl = get-acl $domainNC
$objectguid = new-object Guid 3e0f7e18-2c7a-4c10-ba82-4d926db99a3e
$ace1 = new-object System.DirectoryServices.ActiveDirectoryAccessRule

$sid1,"ExtendedRight","Allow",$objectguid
$acl.AddAccessRule($ace1)
set-acl -aclobject $acl $domainNC

cd c:
Alternatively, run the sample FixVDCPermissions.ps1 in a Windows PowerShell console,

where the console starts as an elevated administrator on a domain controller in the
affected domain. It automatically set the permissions. The sample is located in the
appendix of this module.
Step 4 - Remove Incompatible applications or services (if

not using CustomDCCloneAllowList.xml)
Any programs or services previously returned by Get-
ADDCCloningExcludedApplicationList - and not added to the
CustomDCCloneAllowList.xml - must be removed prior to cloning. Uninstalling the
application or service is the recommended method.
２ Warning
Any incompatible program or service not uninstalled or added to the

CustomDCCloneAllowList.xml prevents cloning.
Use the Get-AdComputerServiceAccount cmdlet to locate any standalone Managed

Service Accounts (MSAs) in the domain and if this computer is using any of them. If any
MSA is installed, use the Uninstall-ADServiceAccount cmdlet to remove the locally
installed service account. Once you are done with taking the source domain controller
offline in step 6, you can re-add the MSA using Install-ADServiceAccount when the
server is back online. For more information, see Uninstall-ADServiceAccount.
） Important
Standalone MSAs - first released in Windows Server 2008 R2 - were replaced in

Windows Server 2012 with group MSAs. Group MSAs support cloning.
Step 5 - Create DCCloneConfig.xml

The DcCloneConfig.xml file is required for cloning Domain controllers. Its contents allow
you to specify unique details like the new computer name and IP address.
The CustomDCCloneAllowList.xml file is optional unless you install applications or

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

ADDCCloneConfigFile specified> DSA Working Directory (default:
%systemroot%\ntds)
- Specifies the clone DC computer name. String

CloneComputerName data type.
ActiveDirectory Arguments Explanation
Cmdlet
-Path Specifies the folder to create the

DcCloneConfig.xml. If not specified, writes to the
DSA Working Directory (default:
%systemroot%\ntds). String data type.
-SiteName Specifies the AD logical site name to join during

cloned computer account creation. String data
type.
-IPv4Address Specifies the static IPv4 address of the cloned

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

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

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

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

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

AlternateWINSServer 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
Hyper-V Manager Method
Use the Hyper-V Manager snap-in to determine which disks are associated with the
source domain controller. Use the Inspect option to validate if the domain controller
uses differencing disks (which requires that you copy the parent disk also)
To delete snapshots, select a VM and delete the snapshot subtree.
You can then manually copy the VHD or VHDX files using Windows Explorer, Xcopy.exe,
or Robocopy.exe. No special steps are required. It is a best practice to change the file
names even if moving to another folder.
７ Note
If copying between host computers on a LAN (1-Gbit or greater), the Xcopy.exe /J

option copies VHD/VHDX files considerably faster than any other tool, at the cost
of much greater bandwidth usage.
To determine the disks using Windows PowerShell, use the Hyper-V Modules:
Get-vmidecontroller
Get-vmscsicontroller
Get-vmfibrechannelhba
Get-vmharddiskdrive
For example, you can return all IDE hard drives from a VM named DC2 with the
following sample:
If the disk path points to an AVHD or AVHDX file, it is a snapshot. To delete the
snapshots associated with a disk and merge in the real VHD or VHDX, use cmdlets:
Get-VMSnapshot
Remove-VMSnapshot
For example, to delete all snapshots from a VM named DC2-SOURCECLONE:
To copy the files using Windows PowerShell, use the following cmdlet:
Copy-Item
Combine with VM cmdlets in pipelines to aid automation. The pipeline is a channel used
between multiple cmdlets to pass data. For example, to copy the drive of an offline
source domain controller named DC2-SOURCECLONE to a new disk called
c:\temp\copy.vhd without the need to know the exact path to its system drive:
Get-VMIdeController dc2-sourceclone | Get-VMHardDiskDrive | select-Object

{copy-item -path $_.path -destination c:\temp\copy.vhd}
） Important
You cannot use passthru disks with cloning, as they do not use a virtual disk file but
instead an actual hard disk.
７ Note
For more information about more Windows PowerShell operations with pipelines,
see Piping and the Pipeline in Windows PowerShell.
Exporting the VM
As an alternative to copying the disks, you can export the entire Hyper-V VM as a copy.
Exporting automatically creates a folder named for the VM and containing all disks and
configuration information.
To export a VM with Hyper-V Manager:
1. Right-click the source domain controller and click Export.
2. Select an existing folder as the export container.
3. Wait for the Status column to stop showing Exporting.
To export a VM using the Hyper-V Windows PowerShell module, use cmdlet:
Export-vm
For example, to export a VM named DC2-SOURCECLONE to a folder named C:\VM:
７ Note
Windows Server 2012 Hyper-V supports new export and import capabilities that are
outside the scope of this training. Review TechNet for more information.
Exporting merged disks, using Hyper-V
The final option is to use the disk merge and conversion options within Hyper-V. These
allow you to make a copy of an existing disk structure - even when including snapshot
AVHD/AVHDX files - into a single new disk. Like the manual disk copy scenario, this is
primarily intended for simpler virtual machines that only use a single drive, such as C:\.
Its lone advantage is that, unlike manually copying, it does not require you to first delete
snapshots. This operation is necessarily slower than simply deleting the snapshots and
copying disks.
To create a merged disk using Hyper-V Manager:
1. Click Edit Disk.
2. Browse for the lowest child disk. For example, if you are using a differencing disk,
the child disk is the lowest child. If the virtual machine has a snapshot (or multiple
ones), the currently selected snapshot is the lowest child disk.
3. Select the Merge option to create a single disk out of the entire parent-child
structure.
4. Select a new virtual hard disk and provide a path. This reconciles the existing
VHD/VHDX files into a single new portable unit that is not at risk of restoring
previous snapshots.
To create a merged disk from a complex set of parents using the Hyper-V Windows
PowerShell module, use cmdlet:
Convert-vm
For example, to export the entire chain of a VM's disk snapshots (this time not including
any differencing disks) and parent disk into a new single disk named DC4-
CLONED.VHDX:
Adding XML to the Offline System Disk
If you did copy the Dccloneconfig.xml to the running source DC, you must copy the
updated dccloneconfig.xml file to the offline copied/exported system disk now.
Depending on installed applications detected with Get-
ADDCCloningExcludedApplicationList earlier, you may also need to copy the
CustomDCCloneAllowList.xml file to the disk.
The following locations can contain the DcCloneConfig.xml file:
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
Windows Explorer Method
Windows Server 2012 now offers a graphical option for mounting VHD and VHDX files.
This requires installation of the Desktop Experience feature on Windows Server 2012.
1. Click the newly copied VHD/VHDX file that contains the source DC's system drive
or DSA Working Directory location folder, and then click Mount from the Disc
Image Tools menu.
2. In the now-mounted drive, copy the XML files to a valid location. You may be
prompted for permissions to the folder.
3. Click the mounted drive and click Eject from the Disk Tools menu.
Alternatively, you can mount the offline disk and copy the XML file using the Windows
PowerShell cmdlets:
mount-vhd
get-disk
get-partition
get-volume
Add-PartitionAccessPath
Copy-Item
This allows you complete control over the process. For instance, the drive can be
mounted with a specific drive letter, the file copied, and the drive dismounted.
mount-vhd <disk path> -passthru -nodriveletter | get-disk | get -partition |

get-volume | get-partition | where {$_.partition number -eq 2} | Add-
PartitionAccessPath -accesspath <drive letter>
copy-item <xml file path><destination path>\dccloneconfig.xml
dismount-vhd <disk path>
For example:
Alternatively, you can use the new Mount-DiskImage cmdlet to mount a VHD (or ISO)
file.
Step 8 - Create the New Virtual Machine

The final configuration step before starting the cloning process is creating a new VM
that uses the disks from the copied source domain controller. Depending on the
selection made in the copying disks phase, you have two options:
1. Associate a new VM with the copied disk
2. Import the exported VM
Associating a New VM with Copied Disks
If you copied the system disk manually, you must create a new virtual machine using the
copied disk. The hypervisor automatically sets the VM-Generation ID when a new VM is
created; no configuration changes are required in the VM or Hyper-V host.
1. Create a new virtual machine.
2. Specify the VM name, memory, and network.
3. On the Connect Virtual Hard Disk page, specify the copied system disk.
4. Complete the wizard to create the VM.
If there were multiple disks, network adapters, or other customizations, configure them
before starting the domain controller. The "Export-Import" method of copying disks is
recommended for complex VMs.
You can use the Hyper-V Windows PowerShell module to automate VM creation in
Windows Server 2012, using the following cmdlet:
New-VM
For example, here the DC4-CLONEDFROMDC2 VM is created, using 1GB of RAM,

booting from the c:\vm\dc4-systemdrive-clonedfromdc2.vhd file, and using the 10.0
virtual network:
Import VM
If you previously exported your VM, you now need to import it back in as a copy. This
uses the exported XML to recreate the computer using all the previous settings, drives,
networks, and memory settings.
If you intend to create additional copies from the same exported VM, make as many
copies of the exported VM as necessary. Then use Import for each copy.
） Important
It is important to use the Copy option, as export preserves all information from the
source; importing the server with Move or In Place causes information collision if
done on the same Hyper-V host server.
To import using the Hyper-V Manager snap-in:
1. Click Import Virtual Machine
2. On the Locate Folder page, select the exported VM definition file using the Browse
button
3. On the Select Virtual Machine page, click the source computer.
4. On the Choose Import Type page, click Copy the virtual machine (create a new
unique ID), then click Finish.
5. Rename the imported VM if importing on the same Hyper-V host; it will have the
same name as the exported source domain controller.
Remember to remove any imported snapshots, using the Hyper-V Management snap-in:
２ Warning
Deleting any imported snapshots is critically important; if applied, they would

return the cloned domain controller to the state of a previous - and possibly live -
DC, leading to replication failure, duplicate IP information, and other disruptions.
You can use the Hyper-V Windows PowerShell module to automate VM import in
Windows Server 2012, using the following cmdlets:
Import-VM
Rename-VM
For example, here the exported VM DC2-CLONED is imported using its automatically
determined XML file, then renamed immediately to its new VM name DC5-
CLONEDFROMDC2:
Remember to remove any imported snapshots, using the following cmdlets:
Get-VMSnapshot
Remove-VMSnapshot
For example:
２ Warning
Ensure that, when importing the computer, static MAC addresses were not assigned
to the source domain controller. If a source computer with a static MAC is cloned,
those copied computers will not correctly send or receive any network traffic. Set a
new unique static or dynamic MAC address if this is the case. You can see if a VM
uses static MAC addresses with the command:
Get-VM -VMName
test-vm | Get-VMNetworkAdapter | fl \*
Step 9 - Clone the New Virtual Machine

Optionally, before you begin cloning, restart the offline clone source domain controller.
Ensure that the PDC emulator is online, regardless.
To begin cloning, simply start the new virtual machine. The process initiates
automatically and the domain controller reboots automatically after cloning is complete.
） Important
Keeping domain controllers turned off for an extended period of time is not
recommended and if the clone is joining the same site as its source DC, the initial
intra and inter-site replication topology may take longer to build if the source
domain controller is offline.
If using Windows PowerShell to start a VM, the new Hyper-V Module cmdlet is:
Start-VM
For example:
Once the computer restarts after cloning completes, it is a domain controller and you
can logon on normally to confirm normal operation. If there are any errors, the server is
set to start in Directory Services Restore Mode for investigation.
Virtualization safeguards
Unlike virtualized domain controller cloning, Windows Server 2012 virtualization
safeguards have no configuration steps. The feature works without intervention as long
as you meet some simple conditions:
The hypervisor supports VM-Generation ID
There is a valid partner domain controller that a restored domain controller can
replicate changes from non-authoritatively.
Validate the Hypervisor

Ensure the source domain controller is running on a supported hypervisor by reviewing
vendor documentation. Virtualized domain controllers are hypervisor-independent and
do not require Hyper-V.
Review the previous Platform Requirements section for known VM-Generation ID

support.
If you are migrating VMs from a source hypervisor to a different target hypervisor,
virtualization safeguards may or may not be triggered depending on whether the
hypervisors support VM-Generation ID, as explained in the following table.
Source Target Result

hypervisor hypervisor
Source Target Result
hypervisor hypervisor
Supports VM- Does not Safeguards not triggered (if a DCCloneConfigFile.xml is

Generation ID support VM- present, DC will boot into DSRM)
Generation ID
Does not Supports VM- Safeguards triggered

support VM- Generation ID
Generation ID
Supports VM- Supports VM- Safeguards not triggered because VM definition has not
Generation ID Generation ID 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
Article • 06/28/2022
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.
Variable Name Purpose
AdminUsername Username to be configured on each VM as the local administrator.
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.

Variable Name Purpose
DomainController2 Name of second domain controller.
DC2IP IP address for second domain controller.
Azure CLI
#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. VMs continue to use their current
DNS settings until they are restarted. 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 Virtual 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:
Azure CLI
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 with
Hyper-V
Article • 06/30/2023
Applies to: Windows Server 2022, Microsoft Hyper-V Server 2019, Windows Server
2019, Microsoft Hyper-V Server 2016, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012
Windows Server 2012 and later support the implementation of virtualized domain
controllers (DCs) with safeguards to prevent update sequence number (USN) rollback on
virtual DCs and the ability to clone virtual DCs. Hyper-V consolidates different server
roles onto a single physical computer. For more information, see Safely virtualizing
This guide describes how to run DCs as 32-bit or 64-bit guest operating systems (OSs).
Planning for virtualization

The following sections outline planning considerations for virtualizing a DC. Review the
hardware requirements and learn how to avoid single points of failure. Explore how to
select the appropriate DC and VM configuration, and consider security and performance
decisions.
Hyper-V requirements
To install and use the Hyper-V role, you must have the following configuration:
An x64 processor. Hyper-V is available in x64-based versions of

Windows Server 2008 and later.
Hardware-assisted virtualization. This feature is available in processors that

include a virtualization option, specifically, Intel Virtualization Technology (Intel VT)
or AMD Virtualization (AMD-V).
Hardware Data Execution Protection (DEP). Hardware DEP must be available and
enabled. Specifically, you must enable Intel XD bit (execute disable bit) or
AMD NX bit (no execute bit).
Practices to avoid single point of failure

As you plan your virtual DC deployment, prepare a strategy to avoid creating single
points of failure. You can avoid introducing potential single points of failure by
implementing system redundancy.
Consider the following recommendations and also keep in mind the potential for
increases in the cost of administration:
Run at least two virtualized DCs per domain on different virtualization hosts. This
configuration reduces the risk of losing all DCs if a single virtualization host fails.
As recommended for other technologies, diversify the hardware that runs the DCs,
such as using different CPUs, motherboards, network adapters, or other hardware.
Hardware diversification limits damage caused by a malfunction due to vendor
configuration, driver, or hardware.
As possible, run DCs on hardware located in different regions of the world. This
approach helps to reduce the consequences of a disaster or failure that affects a
site at which the DCs are hosted.
Maintain physical DCs in each of your domains. This configuration mitigates the
risk of a virtualization platform malfunction that affects all host systems that use
the platform.
The host computer where virtual DCs run must be managed as carefully as a writeable
DC, even if the computer is only a domain-joined or workgroup computer. This
consideration is critical for security. A mismanaged host is vulnerable to an elevation-of-
privilege attack. This type of attack occurs when a malicious user gains access and
system privileges that are unauthorized or illegitimately assigned. A malicious user can
use this type of attack to compromise all the VMs, domains, and forests hosted by the
computer.
Keep the following security considerations in mind when you're planning to virtualize
DCs:
The local administrator of a computer that hosts virtual writeable DCs should be
considered equivalent in credentials to the default domain administrator of all the
domains and forests to which the DCs belong.
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. The limitation should
result in increased performance and fewer applications and services that can 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 can't be satisfactorily secured, a read-only

DC (RODC) is recommended. If a separate management network exists, we
recommend the host is connected to the management network only.
You can use BitLocker with your DCs. In Windows Server 2016 and later, 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 other controls to protect your DCs.
For information about RODCs, see Install a Windows Server 2012 Active Directory Read-
Only Domain Controller (RODC) (Level 200).
For more information about securing DCs, see the Best practice guide for securing
Active Directory installations.
Security boundaries for host and guest configurations

You can have many different configurations of DCs when you implement VMs. Careful
consideration must be given to the way VMs affect boundaries and trusts in your
Active Directory topology. Possible configurations for an Active Directory DC and host
(Hyper-V server) and its guest computers (VMs running on the Hyper-V server) are
described in the following table.
Machine Configuration 1 Configuration 2
Host Workgroup or member computer Workgroup or member computer
Guest Domain controller Workgroup or member computer
The following diagram demonstrates security boundaries a possible configuration of

three guest DC VMs hosted on a Hyper-V server:
Consider the configuration in the previous diagram, and review the following points
when planning for security boundaries:
Administrator access. The administrator on the host computer has the same
access as a domain administrator on the writable DC guests and must be treated
as such. For an RODC guest, the administrator of the host computer has the same
access as a local administrator on the guest RODC.
DC administrative rights on host. A DC in a VM has administrative rights on the

host if the host is joined to the same domain. There's an opportunity for a
malicious user to compromise all VMs if the malicious user first gains access to VM
1. This scenario is known as an attack vector. If there are DCs for multiple domains
or forests, these domains should have centralized administration in which the
administrator of one domain is trusted on all domains.
Strategy to avoid attacks. The opportunity for attack from VM 1 exists even if VM
1 is installed as an RODC. Although an administrator of an RODC doesn't 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 VMs on the host computer.
Review these extra security considerations:
Security of VHD files. A VHD file of a virtual DC is equivalent to the physical hard
drive of a physical DC. As such, it should be protected with the same amount of
care that goes into securing the hard drive of a physical DC. Make sure that only
reliable and trusted administrators are allowed access to the VHD files for the DCs.
RODCs. One benefit of RODCs is the ability to place them at locations where
physical security can't 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 considerations
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 shouldn't
have server roles other than Hyper-V installed.
Performance of VMs 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 DCs, 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 DC with
ADTest.exe and then on a VM hosted on a server identical to the physical DC. Only one
logical processor was used for the physical computer, and only one virtual processor
was used for the VM 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 DC performance was 88 to 98 percent of the
physical DC performance.
Measurement Test Physical Virtual Delta
Searches/sec Search for common name in base scope (L1) 11508 10276 -10.71%
Searches/sec Search for a set of attributes in base scope 10123 9005 -11.04%
(L2)
Searches/sec Search for all attributes in base scope (L3) 1284 1242 -3.27%
Searches/sec Search for common name in subtree scope 8613 7904 -8.23%
(L6)
Successful Perform fast binds (B1) 1438 1374 -4.45%

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

binds/sec
Measurement Test Physical Virtual Delta
Successful Use NTLM to perform binds (B5) 1068 1056 -1.12%

binds/sec
Writes/sec Write multiple attributes (W2) 6467 5885 -9.00%
To ensure satisfactory performance, integration components (IC) were installed to allow

the guest OS to use hypervisor-aware synthetic drivers. During the installation process, it
can 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.
Review the following performance recommendations:
When you monitor performance of VMs with Reliability and Performance Manager
(Perfmon.msc), the CPU information within the VM isn't entirely accurate as a result
of the way the virtual CPU is scheduled on the physical processor. To obtain CPU
information for a VM 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.
Don't plan to use a differencing disk VHD on a VM that's configured as a DC

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 more information regarding AD DS in virtual hosting environments, see Things
to consider when you host Active Directory DCs in virtual hosting environments in
the Microsoft Knowledge Base.
Deployment considerations
The following sections describe common VM practices to avoid when deploying DCs,
and special considerations for time synchronization and storage.
Deployment practices to avoid

Virtualization platforms, such as Hyper-V, offer many convenience features that make
managing, maintaining, backing up, and migrating computers easier. However, the
following common deployment practices and features should be avoided for virtual DCs:
Don't deploy virtual DC database files on virtual IDE disks. To ensure durability of
Active Directory writes, don't deploy a virtual DC'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 the database,
logs, and SYSVOL are placed on the VM's SCSI disk during DC installation.
Don't implement differencing disk VHDs on a DC VM. Don't implement

differencing disk virtual hard disks (VHDs) on a VM that you're configuring as a DC.
This approach 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.
Don't deploy Active Directory domains and forests that aren't prepared with
Sysprep. Don't deploy new Active Directory domains and forests on a copy of a
Windows Server OS without first preparing them by using System Preparation tool
(Sysprep). For more information about running the Sysprep, see Sysprep (System
Preparation) Overview.
２ Warning
Running Sysprep on an already promoted DC isn't supported.
Don't use copies of a VHD file for an already deployed DC to deploy other DCs.
To help prevent a potential update sequence number (USN) rollback situation,
don't use copies of a VHD file that represents an already deployed DC to deploy
more DCs. For more information about USN rollback, see the USN and USN
rollback section.
In Windows Server 2012 and later, administrators can clone DC images to deploy
more DCs, when the images are properly prepared.
Don't use the Hyper-V Export feature to export a VM running a DC.
In Windows Server 2012 and later, an export and import of a DC virtual guest is
handled like a nonauthoritative restore. The process detects a change of the
Generation ID and it isn't configured for cloning.
Ensure the exported guest is no longer used. You can use Hyper-V Replication to
keep a second inactive copy of a DC. 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 VM Manager (VMM) 2008 provides unified management of physical
machines and VMs and the ability to migrate a physical machine to a VM. This process is
known as physical-to-VM conversion (P2V conversion). During the P2V conversion
process, the new VM and the physical DC that's being migrated must not run at the
same time. Ensuring the VM and DC don't run at the same time helps to avoid a USN
rollback situation as described in the USN and USN rollback section.
You should perform P2V conversion by using offline mode to ensure the directory data
is consistent when the DC 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: Convert physical computers to VMs in
VMM. During P2V conversion, the VM shouldn't be connected to the network. The
network adapter of the VM should be enabled only after the P2V conversion process is
complete and verified. At this point, the physical source machine should be off. Don't
bring the physical source machine back onto the network again before you reformat the
hard disk.
Practices to avoid risk of USN rollback

There are safer options to create virtual DCs that don't run the risks of creating a USN
rollback. You can set up a new virtual DC by regular promotion, promotion from Install
from Media (IfM), and also by using Domain Controller cloning, if you already have at
least one virtual DC. This approach also helps to avoid problems with hardware or
platform-related problems P2V-converted virtual guests might encounter.
２ Warning
To prevent issues with Active Directory replication, ensure that only one instance
(physical or virtual) of a given DC exists on a given network at any point in time.
You can lower the likelihood of the old clone being a problem by using one of the
following methods:
When the new virtual DC is running, change the computer account password
twice by using the following command:
netdom resetpwd /Server:\<domain-
controller\> ...
Export and import the new virtual guest to force it to become a new
Generation ID and a database invocation ID.
Test environments and P2V migration
You can use P2V migration through the VMM to create test environments. You can
migrate production DCs from physical machines to VMs to create a test environment
without permanently bringing down the production DCs. However, the test environment
must be on a different network from the production environment to enable two
instances of the same DC 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.
Practices to create a test environment

You can use the following approach to create test environments with P2V.
Migrate one in-production DC from each domain to a test VM by using P2V

according to the guidelines stated in the Physical-to-virtual migration section.
Be sure to locate the physical production machines and test VMs in different
networks when they're brought back online.
To avoid USN rollbacks in the test environment, take all DCs to be migrated from
physical machines to VMs offline. You can take the DCs offline by stopping the
ntds service or by restarting the computer in Directory Services Restore Mode
(DSRM).
After the DCs are offline, no new updates should be introduced to the
environment.
All of the computers must remain offline during the P2V migration. No computers
should be brought back online until all computers are fully migrated.
Subsequent test DCs should be promoted as replicas in the test environment.
To learn more about USN rollback, see the USN and USN rollback section.
Time service and synchronization

For VMs that are configured as DCs, it's recommended that you disable time
synchronization between the host system and guest OS that's acting as a DC. This
practice enables your guest DC 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
The time service guidance has been recently updated to reflect the current
recommendation: synchronize time for the guest DC from only the domain
hierarchy. The previous recommendation was to partially disable time
synchronization between the host system and guest DC.
Storage and optimization

To optimize the performance of the DC VM and ensure durability of Active Directory
writes, follow these recommended practices for storing OSs, 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 OS files. Create a second VHD
attached to a virtual SCSI controller and store the database, logs, and SYSVOL on
the VM'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 OS writes and reads data directly from the media bypassing all caching
mechanisms.
７ Note
To use BitLocker for the virtual DC guest, make sure the extra volumes are
configured for "auto unlock." For more information about configuring auto
unlock, see the PowerShell reference topic for the Enable-
BitLockerAutoUnlock cmdlet.
Host storage of VHD files. Host storage recommendations address storage of

VHD files. For maximum performance, don't store VHD files on a disk frequently
used by other services or applications, such as the system disk where the host
Windows OS is installed. Store each VHD file on a separate partition from the host
OS 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 ensures the disks are connected to a battery-backed caching host
bus adapter (HBA).
The system uses a storage controller like a RAID system as the storage device.
The system ensures power to the disk is protected by an uninterruptible power

supply (UPS).
The system ensures the disk's write-caching feature is disabled.
Fixed VHD versus pass-through disks. There are many ways to configure storage
for VMs. 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're created.
Pass-through disks, which VMs can use to access physical storage media, are even
more optimized for performance. Pass-through disks are physical disks or logical
unit numbers (LUNs) that are attached to a VM. Pass-through disks don't support
the snapshot feature. Therefore, pass-through disks are the preferred hard disk
configuration because the use of snapshots with DCs isn't recommended.
Use virtual SCSI controllers. 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 DCs. If you can't use SCSI drives, ensure write caching is disabled on
the ATA/IDE drives that host virtual DCs. 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 OS writes and
reads data directly from the media bypassing all caching mechanisms.
Operational practices to avoid

Domain controllers running on VMs have operational restrictions that don't apply to
DCs running on physical machines. When you use a virtualized DC, avoid the following
virtualization software features and practices:
Don't pause, stop, or store the saved state longer than the tombstone lifetime.
Don't pause, stop, or store the saved state of a DC in a VM longer than the forest's
tombstone lifetime, and resume from the paused or saved state. These types of
operations can interfere with replication. To learn how to determine the tombstone
lifetime for the forest, see Determine the tombstone lifetime for the forest.
Don't 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.
Don't take or use a snapshot of a virtual DC. This practice is technically supported
in Windows Server 2012 and later, but it isn't a replacement for a good backup
strategy. There are few reasons for taking DC snapshots or restoring the snapshots.
Don't use a differencing disk VHD on a VM configured as a DC. This practice

makes reverting to a previous version too easy, and also decreases performance.
Don't use the Export feature on a VM running a DC.
Don't restore or roll back by any means other than a supported backup. Don't
restore a DC or attempt to roll back the contents of an Active Directory database
by any means other than a supported backup.
These recommendations can help you avoid the possibility of an update sequence
number (USN) rollback. For more information about USN rollback, see the USN and USN
rollback section.
Back up and restore considerations

Backing up DCs is a critical requirement for any environment. Backups protect against
data loss for DC failures or administrative errors. If such an event occurs, it's necessary to
roll back the system state of the DC to a point in time before the failure or error. The
supported method of restoring a DC to a healthy state is to use a backup application to
restore a system state backup that originated from the current installation of the DC.
The back application should be compatible with Active Directory, such as Windows
Server Backup. For more information about Windows Server Backup and
Active Directory Domain Services (AD DS), see the AD DS backup and recovery step-by-
step guide.
With VM technology, certain requirements of Active Directory restore operations take

on added significance. If you restore a DC by using a copy of the VHD file, you bypass
the critical step of updating the database version of a DC after it's restored. Replication
proceeds with inaccurate tracking numbers that cause an inconsistent database among
DC replicas. In most cases, this problem is undetected by the replication system and no
errors are reported, despite inconsistencies between DCs.
Windows Server Backup and guest OS

There's one supported way to perform backup and restore of a virtualized DC and that's
to run Windows Server Backup in the guest OS.
In Hyper-V hosts and guests in Windows Server 2012 and later, you can take supported
backups of DCs by using snapshots, guest VM export and import, and also Hyper-V
Replication. However, none of these approaches are a good fit for creating a proper
backup history with the slight exception of guest VM export.
Windows Server 2016 Hyper-V and later support "production snapshots." The Hyper-V
server triggers a VSS-based backup of the guest. When the guest is done with the
snapshot, the host fetches the VHDs and stores them in the backup location. This
approach works in Windows Server 2012 and later, but there's an incompatibility with
BitLocker:
When doing a VSS snapshot, Active Directory wants to perform a post-snapshot

task. The task can mark the database as coming from a backup, or when preparing
an IFM source for RODC, remove credentials from the database.
When Hyper-V mounts the snapshot volume for this task, no facility unlocks the
Volume for unencrypted access. The Active Directory database engine fails in the
attempt to access the database and eventually fails the snapshot.
７ Note
The shielded VM project mentioned earlier has a Hyper-V host driven backup as a
non-goal for maximum data protection of the guest VM.
Back up and restore practices to avoid

As mentioned, DCs running in VMs have restrictions that don't apply to DCs running in
physical machines. When you back up or restore a virtual DC, avoid the following
virtualization software features and practices:
Don't copy or clone VHD files of DCs instead of performing regular backups. If
the VHD file is copied or cloned, the file becomes stale. If the VHD is started in
normal mode, a USN rollback occurs. You should perform proper backup
operations supported by AD DS, such as working with the Windows Server Backup
feature.
Don't use the Snapshot feature as a backup to restore a VM configured as a DC.

Problems can occur with replication when you revert the VM to an earlier state
with Windows Server 2008 R2 and later. For more information, see the USN and
USN rollback section. You can use a snapshot to restore a read-only DC (RODC)
and not encounter replication issues, but this restore method isn't recommended.
Restoration of virtual DC
To restore a DC when it fails, you must regularly back up system state. System state
includes Active Directory data and log files, the registry, the system volume (SYSVOL
folder), and various elements of the OS. This requirement is the same for physical and
virtual DCs. System state restoration procedures performed by Active Directory–
compatible backup applications 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. Virtual hosting environments and disk or
OS imaging applications allow administrators to bypass the standard checks and
validations that occur during DC system state restore.
When a DC VM fails and a USN rollback hasn't occurred, there are two supported
situations for restoring the VM:
If there's a valid system state data backup that predates the failure, you can restore
system state with the restore option of the backup utility used to create the
backup. To do so, the system state data backup must be created with an
Active Directory–compatible backup utility within the span of the tombstone
lifetime. The default tombstone lifetime is no more than 180 days. You should back
up your DCs 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 VM. Restore the existing VM by using a
previous copy of the VHD. Be sure to start the VM in DSRM and configure the
registry properly as described in the following section. Then, restart the DC in
normal mode.
Use the process in the following diagram to determine the best way to restore your
virtualized DC.
The restoration process and decisions are simpler for RODCs, as shown in the next
diagram.
Restoration of system state backup
If a valid system state backup exists for the DC VM, 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 DC, you must start the DC in DSRM. You must not allow the
DC to start in normal mode. If you miss the opportunity to enter DSRM during
system startup, turn off the DC's VM before it can fully start in normal mode. It's
important to start the DC in DSRM because starting a DC in normal mode
increments the USNs, even if the DC is disconnected from the network. For more
information about USN rollback, see the USN and USN rollback section.
Restore the system state backup of virtual DC

Follow these steps to restore the system state data backup of a virtual DC:
1. Start the DC's VM, and press F5 to access Windows Boot Manager.
If you're prompted to enter connection credentials, follow these steps:

a. Immediately select the Pause button on the VM to pause the process.
b. Enter your connection credentials.
c. Select the Play button on the VM.
d. Select inside the VM window, and press F5.
If Windows Boot Manager doesn't open, and the DC begins to start in normal
mode, turn off the VM to pause the process. Repeat this step as many times as
necessary until you're able to access Windows Boot Manager. You can't access
DSRM from the Windows Error Recovery menu. Therefore, turn off the VM and try
again if the Windows Error Recovery menu appears.
2. In Windows Boot Manager, press F8 to access advanced boot options.
3. Under Advanced Boot Options, select Directory Services Restore Mode, and then
press ENTER to start the DC 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.
Restoration of virtual DC without system state backup

If you don't have a system state data backup that predates the VM failure, you can use a
previous VHD file to restore a DC that's running on a VM. As possible, make a copy of
the VHD. If you encounter an issue during the procedure or miss a step, you can try
again with the copied VHD.
Restore previous version of virtual DC VHD without system state

backup
You can use the following steps to restore to a previous version of a virtual DC VHD
without a system state data backup.
２ Warning
The following procedure shouldn't be used as a substitute for regularly planned

and scheduled backups. Restores performed with this procedure aren't supported
by Microsoft. Use this procedure only when there's no alternative.
Don't use this procedure if the copy of the VHD to restore has been started in
normal mode by any VM.
1. Using the previous VHD, start the virtual DC in DSRM, as described in the previous
section. Don't allow the DC to start in normal mode. If you miss the Windows Boot
Manager screen and the DC begins to start in normal mode, turn off the VM to
prevent it from completing startup. See the previous section for detailed
instructions for entering DSRM.
2. Open Registry Editor. You can open the editor by selecting Start > Run, then enter
regedit, and select OK.
a. If the User Account Control dialog displays, confirm the displayed action is as
expected, and select Yes.
b. In Registry Editor, expand the path

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
c. Look for a value named DSA Previous Restore Count. If the value is present,
make a note of the setting. Otherwise, the setting value is the default (0). If no
value is shown, don't manually set the value.
3. Right-click the Parameters key, select New, and then select DWORD (32-bit)
Value.
4. Enter the new name Database restored from backup, and then press ENTER.
5. Double-click the value you just created to open the Edit DWORD (32-bit) Value
dialog, and enter 1 in the Value data box.
The Database restored from backup entry option is available on the following DCs
running Windows Server:
Windows 2000 Server with Service Pack 4 (SP4)

Windows Server 2003 with specified updates installed (For details, see A
Windows Server domain controller logs Directory Services event 2095 when it
encounters a USN rollback in the Microsoft Knowledge Base.)
Windows Server 2008
6. Restart the DC in normal mode.
7. When the DC restarts, open Event Viewer. To open Event Viewer, select Start >
Control Panel. Double-click Administrative Tools, and then double-click Event
Viewer.
8. Expand Application and Services Logs, and then select the Directory Services log.
Ensure the events appear in the details pane.
9. Right-click the Directory Services log, and then select Find. In Find what, enter
1109, and then select Find Next.
10. You should see at least one entry for Event ID 1109. If you don't see this entry,
proceed to the next step. Otherwise, double-click the entry, and review the text.
Confirm the text shows that the update was made to the InvocationID:
Output
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 the value for the DSA Previous Restore Count setting
is equal to the previous value plus one. If the correct value isn't shown, and you
can't find an entry for Event ID 1109 in Event Viewer, verify that the DC's service
packs are current.
７ Note
You can't try this procedure again on the same VHD. You can try again on a
copy of the VHD or a different VHD that hasn't been started in normal mode
by starting again from 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 VM. For more
information about the Active Directory replication process, see Active Directory
replication concepts.
How AD DS and DCs use USNs

AD DS uses USNs to keep track of replication of data between DCs. Each time a change
is made to data in the directory, the USN is incremented to indicate a new change.
For each directory partition stored by a destination DC, USNs are used to track the latest
originating update that a DC introduced to its database. The USN also tracks the status
of every other DC that stores a replica of the directory partition. When DCs 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 DC received from each partner.
Two replication metadata tables contain USNs: up-to-dateness vector and high water
mark. Source and destination DCs use the USNs in these tables to filter updates that the
destination DC requires.
The up-to-dateness vector table is maintained by the destination DC to track

originating updates received from all source DCs. When a destination DC requests
changes for a directory partition, it provides its up-to-dateness vector to the source DC.
The source DC then uses this value to filter the updates that it sends to the destination
DC. The source DC sends its up-to-dateness vector to the destination at the completion
of a successful replication cycle. The USN is used to ensure the destination DC knows
that it has synchronized with every DC's originating updates and the updates are at the
same level as the source.
The high water mark table is maintained by the destination DC to track the most recent
changes received from a specific source DC for a specific partition. The high water mark
prevents the source DC from sending out changes that the destination DC has already
received from it.
Directory database identity

In addition to USNs, DCs 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 DC is stored in the invocationID attribute of the NTDS Settings object, which is
located under the 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 under certain circumstances:
When a system state restore procedure occurs on the server
When an application directory partition is added, then removed, and later readded
from the server
When a Hyper-V instance triggers its VSS writers on a partition containing a virtual
DC's VHD
In this scenario, the guest triggers its own VSS writers. This action is the same
mechanism used by the backup/restore process mentioned earlier. This method
results in another means by which the invocationID is reset.
So, the invocationID attribute effectively relates a set of originating updates on a DC

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 the DCs recognize
the copy of the Active Directory database from where the replication information is
coming.
The invocationID attribute is a globally unique identifier (GUID) value that's visible near
the top of the output after you run the command repadmin /showrepl . The following
text represents example output from the command:
Output
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 DC, the invocationID attribute is reset. This
change causes an increase in replication traffic, where the duration is relative to the size
of the partition being replicated.
Consider a scenario where VDC1 and DC2 are two DCs in the same domain. The
following diagram 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 DC
tries to use a USN that's lower than its latest update. In most cases, USN rollback is
detected and replication is stopped before divergence in the forest is created.
USN rollback can be caused in many ways. Some examples include 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.
Practices to prevent USN rollback

Take the following precautions to ensure USN rollback doesn't occur:
When not running Windows Server 2012 or later, don't take or use a snapshot of a
DC VM.
Don't copy the DC VHD file.
When not running Windows Server 2012 or later, don't export the VM that's
running a DC.
Don't restore a DC 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.
Sometimes, USN rollback can go undetected, and at other time, USN rollback might
cause replication errors. It can be necessary to identify the extent of the problem and
address it in a timely manner. For more information about how to remove lingering
objects that can occur as a result of USN rollback, see Active Directory replication Event
ID 1388 or 1988: A lingering object is detected in the Microsoft Knowledge Base.
USN rollback detection

In most cases, USN rollbacks without a corresponding reset of the invocationID
attribute caused by improper restore procedures are detected. Windows Server 2008
provides protections against inappropriate replication after an improper DC restore
operation. These protections trigger when an improper restore operation causes lower
USNs that represent originating changes already received by the replication partners.
In Windows Server 2008 and Windows Server 2003 SP1, when a destination DC requests

changes by using a previously used USN, the response by its source replication partner
is interpreted by the destination DC to mean its replication metadata is outdated. This
outcome indicates the Active Directory database on the source DC has been rolled back
to a previous state. An example is when the VHD file of a VM has been rolled back to a
previous version. In this case, the destination DC initiates the following quarantine
measures on the DC 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 diagram shows the sequence of events that occur when USN rollback is
detected on VDC2, the destination DC that's running on a VM. 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 previously seen by the destination DC. This
condition indicates that VDC2's database has rolled back in time improperly.
Resolve Event ID 2095 issues
If the Directory Service event log reports Event ID 2095, complete the following
procedure immediately:
1. Isolate the VM that recorded the error from the network.
2. Attempt to determine whether any changes originated from this DC and

propagated to other DCs. If the event was a result of a snapshot or copy of a VM
being started, try to determine the time the USN rollback occurred. You can then
check the replication partners of that DC to determine whether replication
occurred in the time since the rollback.
You can use the Repadmin tool to make this determination. For information about
how to use Repadmin, see Monitoring and troubleshooting Active Directory
replication with Repadmin. If you're unable to make a determination, contact
Microsoft Support for assistance.
3. Forcefully demote the DC. This operation involves cleaning up the DC'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 A Windows Server domain controller logs Directory Services event 2095
when it encounters a USN rollback in the Microsoft Knowledge Base.
4. Delete all former VHD files for the DC.
Undetected USN rollback

USN rollback might not be detected in two scenarios:
The VHD file is attached to different VMs running in multiple locations

simultaneously.
The USN on the restored DC has increased past the last USN received by the other
DC.
In the first scenario, other DCs might replicate with either one of the VMs, and changes
might occur on either VM without being replicated to the other. This divergence of the
forest is difficult to detect, and it causes unpredictable directory responses. This
situation can occur after a P2V migration if both the physical DC and VM are run on the
same network. This situation can also happen if multiple virtual DCs are created from the
same physical DC and then run on the same network.
In the second scenario, a range of USNs applies to two different sets of changes. This
scenario can continue for extended periods without being detected. Whenever an object
that's created during that time is modified, a lingering object is detected and reported
as Event ID 1988 in Event Viewer. The following diagram shows how USN rollback might
not be detected in such a circumstance.
Read-only DCs
RODCs are DCs that host read-only copies of the partitions in an Active Directory
database. RODCs avoid most USN rollback issues because they don't replicate any
changes to the other DCs. However, if an RODC replicates from a writeable DC affected
by USN rollback, the RODC is also affected.
Restoring an RODC by using a snapshot isn't recommended. Restore an RODC by using

an Active Directory–compatible backup application. Also, as with writeable DCs, care
must be taken to not allow an RODC to be offline for more than the tombstone lifetime.
This condition can result in lingering objects on the RODC.
For more information about implementing RODCs, see the Read-Only Domain
Controllers step-by-step guide.
Troubleshooting
Article • 05/17/2023
This article 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 to build a test lab and
rigorously examine normal, working scenarios. If you encounter errors, they're 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 article, but the third can be explained
in some detail. Virtualized domain controller troubleshooting requires a logical and
linear method. The key is to approach the issue using the data provided and only resort
to complex tools and analysis when you have exhausted the provided output and
logging.
Troubleshooting virtualized domain controller

cloning
This sections covers:
Tools for Troubleshooting
Logging Options
General Methodology for Troubleshooting Domain Controller Cloning
Server Core and the Event Log
Troubleshooting Specific Problems
The troubleshooting strategy for virtualized domain controller cloning follows this
general format:
Logging Options
The built-in logs are the most important tool for troubleshooting issues with domain
controller cloning. All of these logs are enabled and configured for maximum verbosity,
by default.
Operation Log
Cloning - Event viewer\Windows logs\System
- Event viewer\Applications and services logs\Directory Service
- %systemroot%\debug\dcpromo.log
Promotion - %systemroot%\debug\dcpromo.log
- Event viewer\Applications and services logs\Directory 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.
i. Did initial cloning steps succeed but domain controller promotion fail?
ii. 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
i. Does an incompatible application need to be in the
CustomDCCloneAllowList.xml allowlist?
ii. Is the IP address or computer name either duplicated or invalid in the

dccloneconfig.xml?
iii. Is the Active Directory site invalid in the dccloneconfig.xml?
iv. Is the IP address not set in the dccloningconfig.xml and there's no DHCP
server available?
v. Is the PDC emulator online and available through the RPC protocol?
vi. 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?
vii. Does the Dccloneconfig.xml file contain syntax errors that prevent correct
parsing?
viii. Is the hypervisor supported?
ix. Did domain controller promotion fail after cloning began successfully?
x. Was the maximum number of autogenerated domain controller names

(9999) exceeded?
xi. 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 isn't 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 isn't 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 doesn't indicate that cloning can't be retried, fix the cause for failure and
reset the DSRM flag. A failed clone doesn't 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.
Removing DSRM with Msconfig.exe
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, deselect Safe boot (it's already selected
with the option Active Directory repair enabled)
3. Select OK and restart when prompted
Removing DSRM with Bcdedit.exe
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's 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.
Directory Services Event Log
Events Description
Event ID 2160
Source Microsoft-Windows-ActiveDirectory_DomainService
Severity Informational
Message The local <COMPUTERNAME> 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
<COMPUTERNAME> will start to clone itself.
Notes This is a success event and only an issue if unexpected. Examine the DSA Working
and Directory, %systemroot%\ntds, and root of any local or removable disks for the
resolution dcclconeconfig.xml file.
Events Description
Event ID 2161
Message The local <COMPUTERNAME> didn't find the virtual domain controller cloning
configuration file. The local machine isn't a cloned DC.
Events Description
Events Description
Event ID 2162
Severity Error
Message Virtual domain controller cloning failed.

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 Follow message instructions, this error is a catchall.

and
resolution
Events Description
Event ID 2163
Message DsRoleSvc service was started to clone the local virtual domain controller.
Events Description
Event ID 2164
Severity Error
Message <COMPUTERNAME> failed to start the DsRoleSvc service to clone the local virtual
domain controller.
Notes Examine the service settings for the DS Role Server service (DsRoleSvc) and ensure its
and start type is set to manual. Validate that no third party program is preventing the
resolution start of this service.
Events Description
Events Description
Event ID 2165
Severity Error
Message <COMPUTERNAME> 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 Contact Microsoft Product Support

resolution
Events Description
Event ID 2166
Severity Error
Message <COMPUTERNAME> needs RPCSS service to initiate rebooting into DSRM. Waiting
for RPCSS to initialize into a running state failed.
Error code:%1
Notes and Examine the System event log and service settings for the RPC Server service
resolution (Rpcss)
Events Description
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

Events Description
Notes and This is a success event and only an issue if unexpected.

resolution
Events Description
Event ID 2169
Message There's no VM Generation ID detected. The DC is hosted on a physical machine, a

down-level version of Hyper-V, or a hypervisor that doesn't support the VM
Generation ID.
Additional Data
Failure code returned when checking VM Generation ID:%1
Notes This is a success event if not intending to clone. Otherwise, examine the System
and event log and review hypervisor product support documentation.
resolution
Events Description
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.
<COMPUTERNAME> will create a new invocation ID to recover the domain
controller. Virtualized domain controllers shouldn't be restored using virtual machine
snapshots. The supported method to restore or roll back 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 This is a success event if intending to clone. Otherwise, examine the System event
and log.
resolution
Events Description
Events Description
Event ID 2171
Message No Generation ID change has been detected.

Notes and This is a success event if not intending to clone, and should be seen at every reboot
resolution of a virtualized DC. Otherwise, examine the System event log.
Events Description
Event ID 2172
Message Read the msDS-GenerationId attribute of the Domain Controller's computer

object.
msDS-GenerationId attribute value:%1
Notes and This is a success event if intending to clone. Otherwise, examine the System
resolution event log.
Events Description
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
doesn't exist in the local database. The msDS-GenerationId doesn't exist during the
first reboot after dcpromo or the DC isn't a virtual domain controller.
Additional Data
Failure code:%1
Notes This is a success event if intending to clone and it's the first VM reboot after cloning
and has completed. It can also be ignored on nonvirtual Domain controllers. Otherwise,
resolution examine the System event log.
Events Description
Event ID 2174
Message The DC is neither a virtual domain controller clone nor a restored virtual
domain controller snapshot.
Notes and This is a success event if not intending to clone. Otherwise, examine the
resolution System event log.
Events Description
Event ID 2175
Severity Error
Message Virtual domain controller clone configuration file exists on an unsupported platform.
Notes This occurs when a dccloneconfig.xml is found but a VM Generation-ID couldn't be

and found, such as when a dccloneconfig.xml file is found on a physical computer or on a
resolution hypervisor that doesn't support VM Generation-ID.
Events Description
Event ID 2176
Message Renamed virtual domain controller clone configuration file.

Additional Data
Old file name:%1
New file name:%2
Notes Rename expected when booting a source VM back up, because the VM Generation
and ID hasn't changed. This prevents the source domain controller from trying to clone.
resolution
Events Description
Event ID 2177
Events Description
Severity Error
Message Renaming virtual domain controller clone configuration file failed.

Additional Data
File name:%1
Failure code:%2 %3
Notes Rename attempt expected when booting a source VM back up, because the VM
and Generation ID hasn't changed. This prevents the source domain controller from
resolution trying to clone. Manually rename the file and investigate installed third party
products that may be preventing the file rename.
Events Description
Event ID 2178
Message Detected virtual domain controller clone configuration file, but VM Generation ID
hasn't been changed. The local DC is the clone source DC. Rename the clone
configuration file.
Notes Expected when booting a source VM back up, because the VM Generation ID hasn't
and changed. This prevents the source domain controller from trying to clone.
resolution
Events Description
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

resolution
Events Description
Events Description
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 Examine the System event log and Dcpromo.log. Lookup the specific error in MS
and TechNet, MS Knowledgebase, and MS blogs to determine its usual meaning, and
resolution then troubleshoot based on those results.
Events Description
Event ID 2182
Message Internal event: The Directory Service has been asked to clone a remote
DSA:

resolution
Events Description
Event ID 2183
Events Description
Message Internal event: <COMPUTERNAME> 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

resolution
Events Description
Event ID 2184
Severity Error
Message <COMPUTERNAME> 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 <COMPUTERNAME>was exceeded.
Notes A single source domain controller name can only automatically generate 9999 times
and if domain controllers aren't demoted, based on the naming convention. Use the
resolution <computername> element in the XML to generate a new unique name or clone from
a differently named DC.
Events Description
Event ID 2191
Events Description
Message <COMPUTERNAME> 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 can't send requests to the local machine
undergoing cloning. The cloning process will enable DNS updates again after cloning
is completed.
Notes This is a success event and only an issue if unexpected.

and
resolution
Events Description
Event ID 2192
Severity Error
Message <COMPUTERNAME> failed to set the following registry value to disable DNS
updates.
Registry Key:%1
Registry Value: %2
Error code:%4
Error message:%5
undergoing cloning.
Notes Examine Application and System event logs. Investigate third party application that
and may be blocking registry updates.
resolution
Events Description
Events Description
Event ID 2193
Message <COMPUTERNAME> set the following registry value to enable DNS updates.
Registry Key:%1
Registry Value: %2
undergoing cloning.

and
resolution
Events Description
Event ID 2194
-- --
Severity Error
Message <COMPUTERNAME> failed to set the following registry value to enable DNS updates.
Registry Key:%1
Registry Value: %2
Error code:%4
Error message:%5
undergoing cloning.
Events Description
resolution
Events Description
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 nonsupported hypervisor, the local machine will
reboot into DSRM for troubleshooting. Setting DSRM boot failed.
resolution
Events Description
Event ID 2196
Severity Error
Message Failed to enable shutdown privilege.

Error code:%1
Error message:%2
reboot into DSRM for troubleshooting. Enabling shutdown privilege failed.
and may be blocking privilege usage.
resolution
Events Description
Events Description
Event ID 2197
Severity Error
Message Failed to initiate system shutdown.

Error code:%1
Error message:%2
reboot into DSRM for troubleshooting. Initiating system shutdown failed.
and may be blocking privilege usage.
resolution
Events Description
Event ID 2198
Severity Error
Message <COMPUTERNAME> failed to create or modify the following cloned DC object.
Additional data:
Object:
%1
Error value: %2
%3
Notes and Lookup the specific error in MS TechNet, MS Knowledgebase, and MS blogs to
resolution determine its usual meaning, and then troubleshoot based on those results.
Events Description
Event ID 2199
Severity Error
Events Description
Message <COMPUTERNAME> failed to create the following cloned DC object because the
object already exists.
Additional data:
Source DC:
%1
Object:
%2
Notes Validate the dccloneconfig.xml didn't specify an existing domain controller or that
and copies of the dccloneconfig.xml have been used on multiple clones without editing
resolution 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.
Events Description
Event ID 2203
Severity Error
Message Last virtual domain controller cloning failed. This is the first reboot since then so this
should be a retry 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 Expected if cloning failed previously, due to missing or invalid dccloneconfig.xml

and
resolution
Events Description
Event ID 2210
Severity Error
Events Description
Message <COMPUTERNAME> 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 Review the System and Directory Services event logs and the dcpromo.log for
resolution further details on why cloning failed.
Events Description
Event ID 2211
Message <COMPUTERNAME> has created objects for clone domain controller.

Additional data:
Clone Id: %3
Retry loop: %2
Notes and resolution This is a success event and only an issue if unexpected.
Events Description
Event ID 2212
Events Description
Message <COMPUTERNAME> started to create objects for the clone domain

controller.
Additional data:
Clone Id: %1
Clone name: %2
Clone site: %3
Clone RODC: %4

resolution
Events Description
Event ID 2213
Message <COMPUTERNAME> created a new KrbTgt object for Read-Only domain

controller cloning.
Additional data:
Clone Id: %1
New KrbTgt Object Guid: %2

resolution
Events Description
Event ID 2214
Events Description
Message <COMPUTERNAME> will create a computer object for the clone domain
controller.
Additional data:
Clone Id: %1
Original domain controller: %2
Clone domain controller: %3

resolution
Events Description
Event ID 2215
Message <COMPUTERNAME> will add the clone domain controller in the following
site.
Additional data:
Clone Id: %1
Site: %2

resolution
Events Description
Event ID 2216
Message <COMPUTERNAME> will create a servers container for the clone domain
controller.
Additional data:
Clone Id: %1
Servers Container: %2
Events Description

resolution
Events Description
Event ID 2217
Message <COMPUTERNAME> will create a server object for the clone domain
controller.
Additional data:
Clone Id: %1
Server Object: %2

resolution
Events Description
Event ID 2218
Message <COMPUTERNAME> will create a NTDS Settings object for the clone domain
controller.
Additional data:
Clone Id: %1
Object: %2

resolution
Events Description
Event ID 2219
Events Description
Message <COMPUTERNAME> will create connection objects for the clone Read-Only
domain controller.
Additional data:
Clone Id: %1

resolution
Events Description
Event ID 2220
Message <COMPUTERNAME> will create SYSVOL objects for the clone Read-Only
domain controller.
Additional data:
Clone Id: %1

resolution
Events Description
Event ID 2221
Severity Error
Message <COMPUTERNAME> failed to generate a random password for the cloned

domain controller.
Additional data:
Clone Id: %1
Error: %3%4
Notes and Examine the system event log for further details on why the machine account
resolution password couldn't be created.
Events Description
Events Description
Event ID 2222
Severity Error
Message <COMPUTERNAME> failed to set password for the cloned domain controller.
Additional data:
Clone Id: %1
Error: %3%4
Notes and Examine the system event log for further details on why the machine account
resolution password couldn't be set.
Events Description
Event ID 2223
Message <COMPUTERNAME> successfully set machine account password for the

cloned domain controller.
Additional data:
Clone Id: %1
Total retry times: %3

resolution
Events Description
Event ID 2224
Severity Error
Events Description
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 Expected when using standalone MSAs (not group MSA). Don't* follow the event
and advice to remove the account - it's incorrectly written. Use Uninstall-
resolution 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.
Events Description
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 that were previously cached on
the cloning source read-only domain controller will be removed on the cloned
domain controller.

and
resolution
Events Description
Event ID 2226
Severity Error
Events Description
Message Failed to remove cached secrets of the following security principal from local domain
controller:
%1
Error: %2 (%3)
the cloning source 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 Examine the System and Directory Services event logs for further information.
and
resolution
Events Description
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
the cloning source 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 Examine the System and Directory Services event logs for further information.
and
resolution
Events Description
Events Description
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) couldn't be located
so domain controller cloning wasn't 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 This protection mechanism stops duplicate domain controllers when possible (it will
and not when using DHCP, for example). Add a valid DcCloneConfig.xml file, remove the
resolution DSRM flag, and reattempt cloning
Events Description
Event ID 29218
Source Microsoft-Windows-DirectoryServices-DSROLE-Server
Severity Error
Message Virtual domain controller cloning failed. The cloning operation couldn't be completed
and the cloned domain controller was rebooted into Directory Services Restore Mode
(DSRM).
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 can't 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 Review the System and Directory Services event logs and the dcpromo.log for further
and details on why cloning failed.
resolution
Events Description
Event ID 29219
Events Description
Message Virtual domain controller cloning succeeded.
Notes and resolution This is a success event and only an issue if unexpected.
Events Description
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 Contact Microsoft Product Support

and
resolution
Events Description
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
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 Examine the dclconeconfig.xml file for syntax errors using an XML editor and the
resolution DCCloneConfigSchema.xsd schema file.
Events Description
Events Description
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 aren't 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 can't be completed if there are noncloneable applications installed.
Run Active Directory PowerShell Cmdlet Get-ADDCCloningExcludedApplicationList to check

which applications are installed on the cloned machine, but not included in the allowlist,
and add them to the allowlist if they're compatible with virtual domain controller cloning. If
any of these applications aren't compatible with virtual domain controller cloning, please
uninstall them before retrying 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 Follow the message instructions

and
resolution
Events Description
Event ID 29251
Severity Error
Events Description
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.
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 Verify the IP information set in the dccloneconfig.xml is valid and doesn't duplicate
and the original source machine.
resolution
Events Description
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.
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 Validate the cloned domain controller IP and DNS information is set. Use Dcdiag.exe
and /test:locatorcheck to validate if the PDCE is online, use Nltest.exe /server:<PDCE>
resolution /dclist:<domain> to valid RPC, obtain a network capture from the PDCE while cloning
fails and analyze the traffic.
Events Description
Event ID 29254
Severity Error
Events Description
Message Virtual domain controller cloning failed to bind to the primary domain controller %1.
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 Validate the cloned domain controller IP and DNS information is set. Use Dcdiag.exe
and /test:locatorcheck to validate if the PDCE is online, use Nltest.exe /server:<PDCE>
resolution /dclist:<domain> to valid RPC, obtain a network capture from the PDCE while cloning
fails and analyze the traffic.
Events Description
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).
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 Lookup the specific error in MS TechNet, MS Knowledgebase, and MS blogs to

and determine its typical meaning, and then troubleshoot based on those results.
resolution
Events Description
Event ID 29256
Severity Error
Message An attempt to set the Boot into Directory Services Restore Mode flag failed with error
code %1.
See %systemroot%\debug\dcpromo.log for more information about errors.
Notes Examine the Directory Services log and dcpromo.log for details. Examine Application
and and System event logs. Investigate third party application that may be blocking
resolution privilege usage.
Events Description
Events Description
Event ID 29257
Severity Error
Message Virtual domain controller cloning has done. An attempt to reboot the machine
failed with error code %1.
Reboot the machine to finish the cloning operation.
Notes and Examine Application and System event logs. Investigate third party application
resolution that may be blocking privilege usage.
Events Description
Event ID 29264
Severity Error
Message An attempt to clear the Boot into Directory Services Restore Mode flag failed with
error code %1.
See %systemroot%\debug\dcpromo.log for more information about errors.
Notes Examine the Directory Services log and dcpromo.log for details. Examine Application
and and System event logs. Investigate third party application that may be blocking
resolution privilege usage.
Events Description
Event ID 29265
Message Virtual domain controller cloning succeeded. The virtual domain controller cloning
configuration file %1 has been renamed to %2.
Notes and N/A, this is a success event.

resolution
Events Description
Event ID 29266
Events Description
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 Manually rename the dccloneconfig.xml file.

resolution
Events Description
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 allowlist file (The file
currently being checked is: %3). For more information about this error, please see
%systemroot%\debug\dcpromo.log.
Notes Follow the event instructions

and
resolution
Error Messages
There are no direct interactive errors for failed virtualized domain controller cloning; all
cloning information logs in the System and Directory Services logs and the domain
controller promotion logs in dcpromo.log. However, if the server boots into DS Restore
Mode, investigate immediately, as promotion or cloning failed.
The dcpromo.log is the first place to check for cloning failure. Depending on the failure
listed, it may be necessary to subsequently review Directory Services and System logs for
further diagnosis.
Known Issues and Support Scenarios

The following are common issues seen during the Windows Server 2012 development
process. All of these issues are "by design" and have either a valid workaround or more
appropriate technique to avoid them in the first place. Some may be resolved in later
releases of Windows Server 2012.
Issue Cloning fails, DSRM
Symptoms Clone boots into Directory Services Restore Mode
Resolution Validate all steps followed from sections Deploying Virtualized Domain Controller
and Notes section and General Methodology for Troubleshooting Domain Controller Cloning
Described in KB 2742844.
Issue Extra IP leases when using DHCP to clone
Symptoms After successfully cloning a DC and using DHCP, the first boot of the clone takes a
DHCP lease. Then when the server is renamed and restarted as a DC, it takes a
second DHCP lease. The first IP address isn't released and you end up with a
"phantom" lease
Resolution Manually delete the unused address lease in DHCP or allow it to expire normally.
and Notes Described in KB 2742836.
Issue Cloning fails into DSRM after very long delay
Symptoms Cloning appears to pause at "Domain controller cloning is at X% completion" for

between 8 and 15 minutes. After this, the cloning fails and boots into DSRM.
Resolution The cloned computer can't get a dynamic IP address from DHCP or SLAAC, or is
and Notes using a duplicate IP address, or can't find the PDC. Multiple retry attempts
performed by cloning lead to the delay. Resolve the networking issue to allow
cloning.
Issue Cloning does not recreate all service principal names

Issue Cloning does not recreate all service principal names
Symptoms If a set of three-part service principal names (SPN) includes both a NetBIOS name
with a port and an otherwise identical NetBIOS name without a port, the non-port
entry isn't 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 isn't 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 This is a limitation of the domain controller rename process in Windows, not just in
and Notes cloning. Three-part SPNS aren't handled by the renaming logic in any scenario. Most
included Windows services are unaffected by this, as they recreate any missing SPNs
as needed. Other applications may require manually entering the SPN to resolve the
issue.
Issue Cloning fails, boots into DSRM, general networking errors
Symptoms Clone boots into Directory Services Repair Mode. There are general networking
errors.
Resolution Ensure that the new clone doesn't have a duplicate static MAC address assigned
and Notes from the source domain controller; you can see if a VM uses static MAC addresses
by running this command on the hypervisor host for both the source and clone
virtual machines:
Get-VM -VMName test-vm | Get-VMNetworkAdapter | fl *
Change the MAC address to a unique static address or switch to using dynamic MAC
addresses.
Described in KB 2742844
Issue Cloning fails, boots into DSRM as a duplicate of the source DC

Issue Cloning fails, boots into DSRM as a duplicate of the source DC
Symptoms A new clone boots up without cloning. The dccloneconfig.xml isn't renamed and the
server starts in DS Restore Mode. The Directory Services event log shows Error 2164
<COMPUTERNAME> failed to start the DsRoleSvc service to clone the local virtual
domain controller.
Resolution Examine the service settings for the DS Role Server service (DsRoleSvc) and ensure
and Notes its start type is set to Manual. Validate that no third party program is preventing the
start of this service.
For more information about how to reclaim this secondary DC while ensuring that
updates get replicated outbound, see Microsoft KB article 2742970.
Issue Cloning fails, boots into DSRM, error 8610
Symptoms Clone boots into Directory Services Restore Mode. Dcpromo .log shows 8610 error
(which is ERROR_DS_ROLE_NOT_VERIFIED 8610 or 0x21A2)
Resolution Will happen if the PDC can be discoverable but it hasn't performed sufficient
and Notes replication to allow itself to assume the role. For example, if cloning is started and
another administrator moves the PDCE FSMO role to a new DC.
Issue Cloning fails, boots into DSRM, general networking errors
Symptoms Clone boots into Directory Services Restore Mode. There are general networking
errors.
Resolution Ensure that the new clone doesn't have a duplicate static MAC address assigned
and Notes from the source domain controller; you can see if a VM uses static MAC addresses
by running this command on the Hyper-V host for both the source and clone virtual
machines:
Get-VM -VMName test-vm | Get-VMNetworkAdapter | fl *
Change the MAC address to a unique static address or switch to using dynamic MAC
addresses.
Issue Cloning fails, boots into DSRM
Symptoms Clone boots into Directory Services Repair Mode
Resolution and Ensure that the dccloneconfig.xml contains the schema definition (see
Notes sampledccloneconfig.xml, line 2):
<d3c:DCCloneConfig
xmlns:d3c="uri:microsoft.com:schemas:DCCloneConfig">
Issue No logon servers are available error logging into DSRM
Symptoms Clone boots into Directory Services Repair Mode. You attempt to log on and
receive error:
There are currently no logon servers are available to service the logon request
Resolution Ensure that you log on with the DSRM administrator account, and not the domain
and Notes account. Use the left arrow and type a user name of:
.\administrator
Issue Clone Source fails into DSRM, error
Symptoms During cloning, fails 8437 "Create clone DC objects on PDC failed" (0x20f5)
Resolution Duplicate computer name was set in DCCloneConfig.xml as the source DC or an

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

Index was out of range. Must be non-negative and less than the size of the
collection.
Resolution You must run the cmdlet in an administrator-elevated Windows PowerShell console.
and Notes This error is caused by lack of local administrator group membership on the
computer.
Issue Cloning fails, duplicate DC
Symptoms Clone boots without cloning, duplicates existing source DC
Resolution The computer was copied and started but doesn't contain a DcCloneConfig.xml file
and Notes in any of the supported locations, and didn't have a duplicate IP address with the
source domain controller. The DC must be correctly removed in order to avoid data
loss.
Issue New-ADDCCloneConfigFile fails with The server is not operational error when it
checks if the source domain controller is a member of the Cloneable Domain
controllers group if a GC is not available.
Issue New-ADDCCloneConfigFile fails with The server is not operational error when it
checks if the source domain controller is a member of the Cloneable Domain
controllers group if a GC is not available.
Symptoms When running New-ADDCCloneConfigFile to create a dccloneconfig.xml file, you

receive error:
Code - The server isn't operational
Resolution Verify connectivity to a GC from the server where you run New-
and Notes 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're 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 most 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 nonauthoritative sync inbound.
The USN high watermark is adjusted.
Event Source Message

ID
ID
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:
<path>\DCCloneConfig.xml
The existence of the virtual domain controller cloning

configuration file indicates that the local virtual domain
controller is a clone of another virtual domain controller.
The Active Directory Domain Services will start to clone
itself.
2191 ActiveDirectory_DomainService Active Directory Domain Services set the following

registry value to disable DNS updates.
Registry Key:
SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registry Value:
UseDynamicDns
Registry Value data:
During the cloning process, the local machine may have

the same computer name as the clone source machine for
a short time. DNS A and AAAA record registration are
disabled during this period so clients can't send requests
to the local machine undergoing cloning. The cloning
process will enable DNS updates again after cloning is
completed.
ID
2191 ActiveDirectory_DomainService Active Directory Domain Services set the following

registry value to disable DNS updates.
Registry Key:
SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Registry Value:
RegistrationEnabled

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

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

completed.
ID
2172 ActiveDirectory_DomainService Read the msDS-GenerationId attribute of the Domain

Controller's computer object.
msDS-GenerationId attribute value:
<Number>
2170 ActiveDirectory_DomainService A Generation ID change has been detected.

Generation ID cached in DS (old value):
<Number>
Generation ID currently in VM (new value):
<Number>
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 shouldn't be restored using virtual machine
snapshots. The supported method to restore or roll back
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.
ID
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):
<GUID>
InvocationID attribute (new value):
<GUID>
Update sequence number:
<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. Virtualized domain controllers
shouldn't be restored using virtual machine snapshots.
The supported method to restore or roll back 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.
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
ID
103 NTDS ISAM NTDS (536) NTDSA: The database engine stopped the
instance (0).
Dirty Shutdown: 0
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.
102 NTDS ISAM NTDS (536) NTDSA: The database engine (6.02.8225.0000)
is starting a new instance (0).
105 NTDS ISAM NTDS (536) NTDSA: The database engine started a new
instance (0). (Time=0 seconds)
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.
102 NTDS ISAM NTDS (536) NTDSA: The database engine (6.02.8225.0000)
is starting a new instance (0).
326 NTDS ISAM NTDS (536) NTDSA: The database engine attached a
database (1, C:\Windows\NTDS\ntds.dit). (Time=0
seconds)
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
105 NTDS ISAM NTDS (536) NTDSA: The database engine started a new
instance (0). (Time=1 seconds)
0.391, [5] 0.000, [6] 0.000, [7] 0.000, [8] 0.000, [9] 0.031,
[10] 0.000, [11] 0.000.
ID
<GUID>
<GUID>
<Number>

applied, after a virtual machine import operation, or after
a live migration operation. Virtualized domain controllers
shouldn't be restored using virtual machine snapshots.
The supported method to restore or roll back 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.
1168 ActiveDirectory_DomainService Internal error: An Active Directory Domain Services error

has occurred.
Additional Data
Error value (decimal):
Error value (hexadecimal):
Internal ID:
7011658
ID
1110 ActiveDirectory_DomainService Promotion of this domain controller to a global catalog

will be delayed for the following interval.
Interval (minutes):
This delay is necessary so that the required directory

partitions can be prepared before the global catalog is
advertised. In the registry, you can specify the number of
seconds that the directory system agent will wait before
promoting the local domain controller to a global catalog.
For more information about the Global Catalog Delay
Advertisement registry value, see the Resource Kit
Distributed Systems Guide
103 NTDS ISAM NTDS (536) NTDSA: The database engine stopped the
instance (0).
Dirty Shutdown: 0
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 couldn't 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:
<Number>
ID
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
doesn't exist in the local database. The msDS-
GenerationId doesn't exist during the first reboot after
dcpromo or the DC isn't a virtual domain controller.
Additional Data
Failure code:
1000 ActiveDirectory_DomainService Microsoft Active Directory Domain Services startup

complete, version 6.2.8225.0
1394 ActiveDirectory_DomainService All problems preventing updates to the 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,<Domain Controller DN>
Local directory service:
CN=NTDS Settings, <Domain Controller DN>
Additional Data
Reason Code:
0x2
Creation Point Internal ID:
f0a025d
ID
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:
<GUID> (<FQDN>)
Common directory service ID:
<GUID>
Common property USN:
<Number>
As a result, the up-to-dateness vector of the destination

directory service has been configured with the following
settings.
Previous object USN:
Previous property USN:
Database GUID:
<GUID>
Object USN:
<Number>
Property USN:
<Number>
System Event Log
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.

ID
16654 Directory- A pool of account-identifiers (RIDs) has been invalidated. This may
Services-SAM 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 The Active Directory Domain Services service entered the running
Manager state.
7036 Service Control The Kerberos Key Distribution Center service entered the running
Manager state.
3096 Netlogon The primary Domain Controller for this domain couldn't be located.
7036 Service Control The Security Accounts Manager service entered the running state.
Manager
7036 Service Control The Server service entered the running state.
Manager
7036 Service Control The Netlogon service entered the running state.
Manager
7036 Service Control The Active Directory Web Services service entered the running state.
Manager
7036 Service Control The DFS Replication service entered the running state.
Manager
7036 Service Control The File Replication Service service entered the running state.
Manager
14533 Microsoft- DFS has finished building all namespaces.

Windows-DfsSvc
14531 Microsoft- DFS server has finished initializing.

Windows-DfsSvc
7036 Service Control The DFS Namespace service entered the running state.
Manager
ID
7023 Service Control The Intersite Messaging service terminated with the following error:
Manager The specified server can't perform the requested operation.
7036 Service Control The Intersite Messaging service entered the stopped state.
Manager
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- The request for a new account-identifier pool failed. The operation
Services-SAM will be retried until the request succeeds. The error is
The requested FSMO operation failed. The current FSMO holder
couldn't be contacted.
7036 Service Control The DNS Server service entered the running state.
Manager
7036 Service Control The DS Role Server service entered the running state.
Manager
7036 Service Control The Netlogon service entered the stopped state.
Manager
7036 Service Control The File Replication Service service entered the stopped state.
Manager
7036 Service Control The Kerberos Key Distribution Center service entered the stopped
Manager state.
7036 Service Control The DNS Server service entered the stopped state.
Manager
7036 Service Control The Active Directory Domain Services service entered the stopped
Manager state.
7036 Service Control The Netlogon service entered the running state.
Manager
7040 Service Control The start type of the Active Directory Domain Services service was
Manager changed from auto start to disabled.
7036 Service Control The Netlogon service entered the stopped state.
Manager
ID
7036 Service Control The File Replication Service service entered the running state.
Manager
29219 DirectoryServices- Virtual domain controller cloning succeeded.

DSROLE-Server
29223 DirectoryServices- This server is now a Domain Controller.

DSROLE-Server
29265 DirectoryServices- Virtual domain controller cloning succeeded. The virtual domain
DSROLE-Server controller cloning configuration file
C:\Windows\NTDS\DCCloneConfig.xml has been renamed to
C:\Windows\NTDS\DCCloneConfig.20120207-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: "
DCPROMO.LOG
The Dcpromo.log contains the actual promotion portion of cloning that the Directory
Services event log doesn't describe. Since the log doesn't 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 repromoted 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 doesn't 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 doesn't 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's 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 aren't 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 wasn't specified by the
administrator
15:14:03 [INFO] vDC Cloning: Enable DHCP:
15:14:03 [INFO] WMI Instance: Win32_NetworkAdapterConfiguration.Index=12
15:14:03 [INFO] Method: EnableDHCP
15:14:03 [INFO] HRESULT code: 0x0 (0)
15:14:03 [INFO] Return Value: 0x0 (0)
Locate the PDC emulator
Set the clone's site (automatically generated in this case)
Set the clone's name (automatically generated in this case)
15:14:03 [INFO] vDC Cloning: Found PDC. Name: DC1.root.fabrikam.com
15:14:04 [INFO] vDC Cloning: Winlogon UI Notification #1: Domain Controller

cloning is at 5% completion...

15:14:05 [INFO] Site of the cloned DC: Default-First-Site-Name
Create the new clone computer object
Rename the clone to match the new name

15:14:05 [INFO] vDC Cloning: Clone DC objects are created on PDC.
15:14:05 [INFO] Name of the cloned DC: DC2-CL0001
15:14:05 [INFO] DsRolepSetRegStringValue on

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

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


15:14:05 [INFO] Validate supplied paths
15:14:05 [INFO] Validating path C:\Windows\NTDS.
15:14:05 [INFO] Path is a directory
15:14:05 [INFO] Path is on a fixed disk drive.
15:14:05 [INFO] Validating path C:\Windows\NTDS.
15:14:05 [INFO] Path is a directory
15:14:05 [INFO] Validating path C:\Windows\SYSVOL.
15:14:05 [INFO] Path is on an NTFS volume

15:14:05 [INFO] Start the worker task

15:14:05 [INFO] Request for promotion returning 0

Stop and configure all of the AD DS-related services (NTDS, NTFRS/DFSR, KDC,
DNS)
７ Note
The DNS service taking a long time to shutdown is expected in this scenario, as it is
using AD-integrated zones that were no longer available even before the NTDS
service stopped - see the DNS events described later in this section of the module.
15:14:15 [INFO] Stopping service NTDS
15:14:15 [INFO] Stopping service NtFrs
15:14:15 [INFO] ControlService(STOP) on NtFrs returned 1(gle=0)
15:14:15 [INFO] DsRolepWaitForService: waiting for NtFrs to enter one of 7

states
15:14:15 [INFO] DsRolepWaitForService: QueryServiceStatus on NtFrs returned

1 (gle=0), SvcStatus.dwCS=3
15:14:16 [INFO] DsRolepWaitForService: QueryServiceStatus on NtFrs returned

1 (gle=0), SvcStatus.dwCS=1
15:14:16 [INFO] DsRolepWaitForService: exiting because NtFrs entered STOPPED

state
15:14:16 [INFO] DsRolepWaitForService(for any end state) on NtFrs service

returned 0
15:14:16 [INFO] ControlService(STOP) on NtFrs returned 0(gle=1062)
15:14:16 [INFO] Exiting service-stop loop after service NtFrs entered

STOPPED state
15:14:16 [INFO] StopService on NtFrs returned 0
15:14:16 [INFO] Configuring service NtFrs to 1 returned 0
15:14:16 [INFO] Stopping service Kdc
15:14:16 [INFO] ControlService(STOP) on Kdc returned 1(gle=0)
15:14:16 [INFO] DsRolepWaitForService: waiting for Kdc to enter one of 7

states
15:14:16 [INFO] DsRolepWaitForService: QueryServiceStatus on Kdc returned 1

(gle=0), SvcStatus.dwCS=3
15:14:17 [INFO] DsRolepWaitForService: QueryServiceStatus on Kdc returned 1

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












































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

15:15:01 [INFO] DsRolepWaitForService: QueryServiceStatus on NTDS returned 1

15:15:01 [INFO] DsRolepWaitForService: exiting because NTDS entered STOPPED

state
15:15:01 [INFO] DsRolepWaitForService(for any end state) on NTDS service

returned 0
15:15:01 [INFO] ControlService(STOP) on NTDS returned 0(gle=1062)
15:15:01 [INFO] Exiting service-stop loop after service NTDS entered STOPPED
state
15:15:01 [INFO] StopService on NTDS returned 0
15:15:01 [INFO] Configuring service NTDS to 1 returned 0
15:15:01 [INFO] Configuring service NTDS


Force NT5DS (NTP) time synchronization with another domain controller (typically
the PDCE)
15:15:02 [INFO] Forcing time sync
Contact a domain controller that holds the source domain controller account of
the clone
Flush any existing Kerberos tickets
15:15:02 [INFO] Searching for a domain controller for the domain

root.fabrikam.com that contains the account DC2$
15:15:02 [INFO] Located domain controller DC1.root.fabrikam.com for domain

root.fabrikam.com

15:15:02 [INFO] Directing kerberos authentication to DC1.root.fabrikam.com

returns 0
15:15:02 [INFO] DsRolepFlushKerberosTicketCache() successfully flushed the

Kerberos ticket cache

15:15:02 [INFO] Using site Default-First-Site-Name for server

\\DC1.root.fabrikam.com
Stop the NetLogon service and set its start type

15:15:02 [INFO] DsRolepWaitForService: waiting for NETLOGON to enter one of

7 states


15:15:03 [INFO] DsRolepWaitForService: exiting because NETLOGON entered

STOPPED state
15:15:03 [INFO] DsRolepWaitForService(for any end state) on NETLOGON service

returned 0
15:15:03 [INFO] Exiting service-stop loop after service NETLOGON entered

STOPPED state
15:15:03 [INFO] StopService on NETLOGON returned 0
15:15:03 [INFO] Configuring service NETLOGON to 1 returned 0
15:15:03 [INFO] Stopped NETLOGON

Configure the DFSR/NTFRS services to run automatically
Delete their existing database files to force nonauthoritative 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:
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):
Error value (hexadecimal):
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):
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

<SysprepInformation> 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 isn't 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
Active Directory Web Services Event Log
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 isn't 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.

ID
1202 ADWS This computer is now hosting the specified directory instance, but Active
Instance Directory Web Services couldn't service it. Active Directory Web Services will
Events retry this operation periodically.
Directory instance: NTDS
Directory instance LDAP port: 389
Directory instance SSL port: 636
1000 ADWS Active Directory Web Services is starting

Instance
Events
1008 ADWS Active Directory Web Services has successfully reduced its security privileges
Instance
Events
ID
1100 ADWS The values specified in the <appsettings> section of the configuration file for
Instance Active Directory Web Services have been loaded without errors.
Events
1400 ADWS ADWS Certificate Events"Active Directory Web Services couldn't find a server
Instance certificate with the specified certificate name. A certificate is required to use
Events 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: <Server FQDN>
1100 ADWS The values specified in the <appsettings> section of the configuration file for
Instance Active Directory Web Services have been loaded without errors.
Events
1200 ADWS Active Directory Web Services is now servicing the specified directory instance.
Instance Directory instance: NTDS
Events
Directory instance LDAP port: 389
Directory instance SSL port: 636
DNS Server Event Log
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.

ID
4013 DNS- The DNS server is waiting for Active Directory Domain Services (AD DS) to
Server- signal that the initial synchronization of the directory has been completed. The
Service DNS server service can't 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's 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- The DNS server has encountered a critical error from the Active Directory. Check
Server- that the Active Directory is functioning properly. The extended error debug
Service information (which may be empty) is """". The event data contains the error.
ID
4000 DNS- The DNS server was unable to open Active Directory. This DNS server is
Server- configured to obtain and use information from the directory for this zone and is
Service 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- The DNS server is waiting for Active Directory Domain Services (AD DS) to
Server- signal that the initial synchronization of the directory has been completed. The
Service DNS server service can't 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's 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- The DNS server has started.

Server-
Service
4 DNS- The DNS server has finished the background loading of zones. All zones are
Server- now available for DNS updates and zone transfers, as allowed by their individual
Service zone configuration.
File Replication Service Event Log
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.

ID
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.
Couldn't bind to a Domain Controller. Will try again at next polling cycle
13502 NtFrs The File Replication Service is stopping.

ID
13565 NtFrs File Replication Service is initializing the system volume with data from another
domain controller. Computer DC2 can't 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 system volume with data from another
net share
share will appear.
controllers.
13501 NtFrs The File Replication Service is starting.

ID
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 <Domain Controller FQDN>
Replica set member name is <Domain Controller>
Replica set root path is <path>
Replica staging directory path is <path>
Replica working directory path is <path>
13520 NtFrs The File Replication Service moved the preexisting files in <path> to
<path>\NtFrs_PreExisting___See_EventLog.
The File Replication Service may delete the files in

<path>\NtFrs_PreExisting___See_EventLog at any time. Files can be saved from
deletion by copying them out of <path>\NtFrs_PreExisting___See_EventLog.
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
<path>\NtFrs_PreExisting___See_EventLog into <path> instead of replicating
the file from some other replicating partner.
Space can be recovered at any time by deleting the files in

<path>\NtFrs_PreExisting___See_EventLog."
13508 NtFrs The File Replication Service is having trouble enabling replication from
<Domain Controller FQDN> to <Domain Controller> for <path> using the
DNS name <Domain Controller FQDN>. FRS will keep retrying.
Following are some of the reasons you would see this warning.
[1] FRS can't correctly resolve the DNS name <Domain Controller FQDN> from
this computer.
[2] FRS isn't running on <Domain Controller FQDN>.
[3] The topology information in the Active Directory Domain Services for this
replica hasn't yet replicated to all the Domain Controllers.
This event log message will appear once per connection, After the problem is
fixed you'll see another event log message indicating that the connection has
been established.
ID
13509 NtFrs The File Replication Service has enabled replication from <Domain Controller
FQDN> to <Domain Controller> for <Path> after repeated retries.
13516 NtFrs The File Replication Service is no longer preventing the computer <Domain
Controller> 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."
DFS Replication Event Log
The DFSR services synchronizes nonauthoritatively from a partner during cloning.

Cloning accomplishes this by deleting the DFSR database files and leaving the contents
of SYSVOL untouched, for use as preseeded data. The two attempts to synchronize are
expected.

ID
1004 DFSR The DFS Replication service has started.
1314 DFSR The DFS Replication service successfully configured the debug log files.
Additional Information:
Debug Log File Path: C:\Windows\debug
6102 DFSR The DFS Replication service has successfully registered the WMI provider
1206 DFSR The DFS Replication service successfully contacted domain controller
DC2.corp.contoso.com to access configuration information.
1210 DFSR The DFS Replication service successfully set up an RPC listener for incoming
replication requests.
Port: 0"
ID
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 won't 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 won't 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: <GUID>
Replication Group Name: Domain System Volume
Replication Group ID: <GUID>
Member ID: <GUID>
Read-Only: 0
4604 DFSR The DFS Replication service successfully 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"".
Member ID: <GUID>
Sync partner: <domain controller FQDN>
Troubleshooting virtualized domain controller

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

creation Worker
Snapshot - Event viewer\Applications and services logs\Directory Service
restore - Event viewer\Windows logs\System
- 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
Tools and Commands for Troubleshooting Domain Controller

Configuration
point:
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
i. Are there snapshot restore errors?
ii. Are there AD replication errors?

b. Examine the System event log
i. Are there communication errors?
ii. 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.
Events Description
Event ID 2170
Severity Warning
Events Description
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.
<COMPUTERNAME> will create a new invocation ID to recover the domain
controller. Virtualized domain controllers shouldn't be restored using virtual machine
snapshots. The supported method to restore or roll back 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 This is a success event if the snapshot was expected. If not, examine the Hyper-V-
and Worker event log or contact the hypervisor administrator.
resolution
Events Description
Event ID 2174
Message The DC is neither a virtual domain controller clone nor a restored virtual domain
controller snapshot.
Notes and Expected event when starting physical domain controllers or virtualized domain
resolution controllers not restored from snapshot
Events Description
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 Expected when restoring a snapshot. Transactions track the VM Generation ID

and changing
resolution
Event Description
Event Description
Event ID 2185
Message <COMPUTERNAME> 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. <COMPUTERNAME> must initialize a
nonauthoritative 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 Expected when restoring a snapshot. All SYSVOL data on this domain controller is
and replaced with a partner DC's copy.
resolution
Event Description
Event ID 2186
Severity Error
Message <COMPUTERNAME> failed to stop the FRS or DFSR service used to replicate the
SYSVOL folder.
Service name:%1
Error code:%2
Error message:%3
was reverted to a previous state. <COMPUTERNAME> must initialize a
nonauthoritative 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.
<COMPUTERNAME> failed to stop the current running service and can't complete
the nonauthoritative restore. Perform a nonauthoritative restore manually.
Event Description
Notes Examine the System, FRS and DFSR event logs for further information.
and
resolution
Event Description
Event ID 2187
Message <COMPUTERNAME> started the FRS or DFSR service used to replicate the SYSVOL
folder.
Service name:%1
was reverted to a previous state. <COMPUTERNAME> needed to initialize a
nonauthoritative 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.
resolution
Event Description
Event ID 2188
Severity Error
Event Description
Message <COMPUTERNAME> failed to start the FRS or DFSR service used to replicate the
SYSVOL folder.
Service name:%1
Error code:%2
Error message:%3
was reverted to a previous state. <COMPUTERNAME> needs to initialize a
FRS or DFSR service used to replicate the SYSVOL and starting it with appropriate
registry keys and values to trigger the restore. <COMPUTERNAME> failed to start the
FRS or DFSR service used to replicate the SYSVOL folder and can't complete the
nonauthoritative restore. Perform a nonauthoritative restore manually and restart the
service.
Notes Examine the System, FRS and DFSR event logs for further information.
and
resolution
Event Description
Event ID 2189
Message <COMPUTERNAME> set the following registry values to initialize SYSVOL replica
during a nonauthoritative restore:
Registry Key:%1
Registry Value: %2
appropriate registry keys and values to trigger the restore.
resolution
Event Description
Event ID 2190
Severity Error
Message <COMPUTERNAME> failed to set the following registry values to initialize the
SYSVOL replica during a nonauthoritative restore:
Registry Key:%1
Registry Value: %2
Error code:%4
Error message:%5
role was reverted to a previous state. <COMPUTERNAME> needs to initialize a
appropriate registry keys and values to trigger the restore. <COMPUTERNAME>
failed to set the above registry values and can't complete the nonauthoritative
restore. Perform a nonauthoritative restore manually.
Notes Examine Application and System event logs. Investigate third party applications that
resolution
Event Description
Event ID 2200
Message Active Directory detected that the virtual machine that hosts the domain controller
was reverted to a previous state. <COMPUTERNAME> initializes replication to bring
the domain controller current. Event 2201 will be logged when the replication is
finished.
Notes Expected when restoring a snapshot. Marks the beginning of inbound AD replication.
and
resolution
Event Description
Event Description
Event ID 2201
was reverted to a previous state. <COMPUTERNAME> has finished replication to
bring the domain controller current.
Notes Expected when restoring a snapshot. Marks the end of inbound AD replication.
and
resolution
Event Description
Event ID 2202
Severity Error
was reverted to a previous state. <COMPUTERNAME> failed replication to bring the
domain controller up-to-date. The domain controller will be updated after next
periodic replication.
Notes Examine the Directory Services and System event logs. Use repadmin.exe to attempt
and forcing replication and note any failures.
resolution
Event Description
Event ID 2204
Event Description
Message <COMPUTERNAME> has detected a change of virtual machine generation ID. The
change means that the virtual domain controller has been reverted to a previous
state. <COMPUTERNAME> 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 Expected when restoring a snapshot. This explains all the various reset operations
and that will occur as part of the safe restore process.
resolution
Event Description
Event ID 2205
Message <COMPUTERNAME> invalidated current RID pool after virtual domain controller was
reverted to previous state.
Notes Expected when restoring a snapshot. The local RID pool must be destroyed as the
and domain controller has time travelled and they may have already been issued.
resolution
Event Description
Event ID 2206
Severity ERROR
Event Description
Message <COMPUTERNAME> failed to invalidate current RID pool after virtual domain
controller was reverted to previous state.
Additional data:
Error code: %1
Error value: %2
Notes Examine the Directory Services and System event logs. Validate that the RID Master is
and online can be reached from this server using Dcdiag.exe /test:ridmanager
resolution
Event Description
Event ID 2207
Severity ERROR
Message <COMPUTERNAME> 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 Examine the Directory Services and System event logs.

and
resolution
Event Description
Event ID 2208
Message <COMPUTERNAME> deleted DFSR databases to initialize SYSVOL replica during a

nonauthoritative restore.
Notes Expected when restoring a snapshot. This guarantees DFSR non-authoritatively

and synchronizes SYSVOL from a partner DC. Note that any other DFSR Replicated
resolution Folders on the same volume as SYSVOL will also non-authoritatively sync (domain
controllers aren't recommended to host custom DFSR sets on the same volume as
SYSVOL).
Event Description
Event Description
Event ID 2209
Severity Error
Message <COMPUTERNAME> failed to delete DFSR databases.
Additional data:
Error code: %1
Error value: %2
nonauthoritative restore on the local SYSVOL replica. For DFSR, this is done by
stopping the DFSR service, deleting DFSR databases, and restarting the service. Upon
restarting DFSR will rebuild the databases and start the initial sync.
Notes Examine the DFSR event log.

and
resolution
Error Messages
There are no direct interactive errors for failed virtualized domain controller safe
snapshot restore; all cloning information logs in the Directory Services event logs.
Naturally, any critical replication or server advertising errors manifest themselves as
symptoms elsewhere.
Known Issues and Support Scenarios
The General Methodology for Troubleshooting Domain Controller Safe Restore are
usually adequate to troubleshoot most issues.
Issue Cannot create new security principals on recently safe restored domain controller
Symptoms After restoring a snapshot, attempts to create a new security principal (user,
computer, group) on that domain controller fail with:
Error 0x2010
The directory service was unable to allocate a relative identifier.

Issue Cannot create new security principals on recently safe restored domain controller
Resolution This issue is caused by the restored computer's stale knowledge of the RID Master
and Notes 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 won't have
knowledge of the RID master until initial replication has completed.
To resolve the issue, allow AD replication to complete inbound to the restored
domain controller. If still not working, validate that all domain controllers have the
same correct knowledge of which DC hosts the RID Master.
Issue Restored domain controllers do not share SYSVOL, advertise
Symptoms After restoring a snapshot, one or more DCs don't advertise, don't share sysvol, and
don't have up to date SYSVOL contents
Resolution The DC's upstream partners don't have a working SYSVOL replica that is correctly
and Notes 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 unrestored 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 most 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 nonauthoritative sync inbound. The
USN high watermark is adjusted.

ID
ID
2170 ActiveDirectory_DomainService A Generation ID change has been detected.

Generation ID cached in DS (old value):
<number>
Generation ID currently in VM (new value):
<number>
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 shouldn't be restored
using virtual machine snapshots. The supported method
to restore or roll back 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."
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.
ID
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.
ID
<GUID>
<GUID>
<number>

applied, after a virtual machine import operation, or
after a live migration operation. Virtualized domain
controllers shouldn't be restored using virtual machine
snapshots. The supported method to restore or roll
back 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."
2179 ActiveDirectory_DomainService The msDS-GenerationId attribute of the Domain

Controller's computer object has been set to the
following parameter:
GenerationID attribute:
<number>
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
state. Active Directory Domain Services has finished
replication to bring the domain controller current.
ID
2185 ActiveDirectory_DomainService Active Directory Domain Services stopped the FRS or

DFSR service used to replicate the SYSVOL folder.
Service name:
DFSR
Active Directory detected that the virtual machine that

state. Active Directory Domain Services must initialize a
nonauthoritative 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."
2208 ActiveDirectory_DomainService Active Directory Domain Services deleted DFSR

databases to initialize SYSVOL replica during a
nonauthoritative restore.
state. Active Directory Domain Services needs to
initialize a nonauthoritative restore on the local SYSVOL
replica. For DFSR, this is done by stopping the DFSR
service, deleting DFSR databases, and restarting the
service. Upon restarting DFSR will rebuild the databases
and start the initial sync. "
2187 ActiveDirectory_DomainService Active Directory Domain Services started the FRS or

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

state. Active Directory Domain Services needed to
initialize a nonauthoritative 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. "
ID
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:
<GUID> (<FQDN of partner domain controller>)
USN at the time of restore:
<number>
As a result, the up-to-dateness vector of the destination

directory service has been configured with the following
settings.
Previous database GUID:
<GUID>
Previous object USN:
<number>
Previous property USN:
<number>
New database GUID:
<GUID>
New object USN:
<number>
New property USN:
<number>
System Event Log

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.

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

time.
16654 Directory- A pool of account-identifiers (RIDs) has been invalidated. This may
Services-SAM occur in the following expected cases:
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.
7036 Service Control The DFS Replication service entered the stopped state.
Manager
7036 Service Control The DFS Replication service entered the running state.
Manager
Application Event Log
The Application event log notes the DFSR database stopping and starting.

ID
103 ESENT DFSRs (1360) \\.\C:\System Volume

Information\DFSR\database_<GUID>\dfsr.db: The database engine stopped the
instance (0).
Dirty Shutdown: 0
Internal Timing Sequence: [1] 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.
102 ESENT DFSRs (532) \\.\C:\System Volume Information\DFSR\database_<GUID>\dfsr.db:

The database engine (6.02.8189.0000) is starting a new instance (0).
ID
105 ESENT DFSRs (532) \\.\C:\System Volume Information\DFSR\database_<GUID>\dfsr.db:

The database engine started a new instance (0). (Time=0 seconds)
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<GUID>\dfsr.db:

The database engine created a new database (1, \\.\C:\System Volume
Information\DFSR\database<GUID>\dfsr.db). (Time=0 seconds)
0.016, [7] 0.000, [8] 0.000, [9] 0.015, [10] 0.000, [11] 0.000.
DFS Replication Event Log
The DFSR service is stopped and the database that contains SYSVOL is deleted, forcing a
nonauthoritative synchronization inbound.

ID
1006 DFSR The DFS Replication service is stopping.
1008 DFSR The DFS Replication service has stopped.
1002 DFSR The DFS Replication service is starting.
1004 DFSR The DFS Replication service has started.
1314 DFSR The DFS Replication service successfully configured the debug log files.
Debug Log File Path: C:\Windows\debug
6102 DFSR The DFS Replication service has successfully registered the WMI provider.
1206 DFSR The DFS Replication service successfully contacted domain controller <domain
controller FQDN> to access configuration information.
1210 DFSR The DFS Replication service successfully set up an RPC listener for incoming
replication requests.
Port: 0
ID
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 won't 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 won't 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.
Member ID: <GUID>
Read-Only: 0
4604 DFSR The DFS Replication service successfully 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".
Member ID: <GUID>
Sync partner: <partner domain controller FQDN>
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.
File Replication Service Event Log
The FRS service is stopped and restarted with a D2 BURFLAGS value to

nonauthoritatively synchronize SYSVOL.

ID
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 system volume with data from another
net share
share will appear.
controllers."
ID
13520 NTFRS The File Replication Service moved the pre-existing files in <path> to
The File Replication Service may delete the files in

<path>\NtFrs_PreExisting___See_EventLog at any time. Files can be saved from
deletion by copying them out of <path>\NtFrs_PreExisting___See_EventLog.
Copying the files into <path> 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
<path>\NtFrs_PreExisting___See_EventLog into <path> 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:
Information related to this event is shown below:
Computer DNS name is "<domain controller FQDN>"
Replica set member name is "<domain controller name>"
Replica set root path is "<path>"
Replica staging directory path is "<path> "
Replica working directory path is "<path>"
13554 NTFRS The File Replication Service successfully added the connections shown below to
the replica set:
Inbound from "<partner domain controller FQDN>"
Outbound to "<partner domain controller FQDN>"
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.
Application Event Log
The FRS database stops and starts, and is purged due to the D2 BURFLAGS operation.

ID
327 ESENT ntfrs (1424) The database engine detached a database (1,
c:\windows\ntfrs\jet\ntfrs.jdb). (Time=0 seconds)
0.516, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000, [11] 0.063, [12] 0.000.
Revived Cache: 0
103 ESENT ntfrs (1424) The database engine stopped the instance (0).
Dirty Shutdown: 0
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.
102 ESENT ntfrs (3000) The database engine (6.02.8189.0000) is starting a new instance (0).
105 ESENT ntfrs (3000) The database engine started a new instance (0). (Time=0 seconds)
0.000, [7] 0.000, [8] 0.000, [9] 0.062, [10] 0.000, [11] 0.141.
Dirty Shutdown: 0
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.
0.000, [7] 0.000, [8] 0.000, [9] 0.078, [10] 0.000, [11] 0.109.
325 ESENT ntfrs (3000) The database engine created a new database (1,
0.015, [7] 0.000, [8] 0.000, [9] 0.078, [10] 0.016, [11] 0.000.
Dirty Shutdown: 0
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.
ID
0.000, [7] 0.000, [8] 0.000, [9] 0.032, [10] 0.000, [11] 0.000.
326 ESENT ntfrs (3000) The database engine attached a database (1,
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
Article • 04/28/2023
This topic covers:
Terminology
FixVDCPermissions.ps1
Terminology
Snapshot - The state of a virtual machine at a particular point in time. It is
dependent on the chain of previous snapshots taken, on the hardware, and on the
virtualization platform.
Clone - A complete and separate copy of a virtual machine. It is dependent on the

virtual hardware (hypervisor).
Full Clone - A full clone is an independent copy of a virtual machine that shares no
resources with the parent virtual machine after the cloning operation. Ongoing
operation of a full clone is entirely separate from the parent virtual machine.
Differencing disk - A copy of a virtual machine that shares virtual disks with the
parent virtual machine in an ongoing manner. This usually conserves disk space
and allows multiple virtual machines to use the same software installation.
VM Copy- A file system copy of all the related files and folders of a virtual
machine.
VHD File Copy - A copy of a virtual machine's VHD
VM Generation ID - a 128-bit integer given to the virtual machine by the

hypervisor. This ID is stored in memory and reset every time a snapshot is applied.
The design uses a hypervisor-agnostic mechanism for surfacing the VM-
Generation ID in the virtual machine. The Hyper-V implementation exposes the ID
in the ACPI table of the virtual machine.
Import/Export - A Hyper-V feature that allows the user to save the entire virtual
machine (VM files, VHD and the machine configuration). It then allows users to
using that set of files to bring the machine back on the same machine as the same
VM (Restore), on a different machine as the same VM (Move), or a new VM (copy)
FixVDCPermissions.ps1
# Unsigned script, requires use of set-executionpolicy remotesigned -force
# You must run the Windows PowerShell console as an elevated administrator
# Load Active Directory Windows PowerShell Module and switch to AD DS drive
cd ad:
## Get Domain NC
$domainNC = get-addomain
## Get groups and obtain their SIDs
$dcgroup = get-adgroup "Cloneable Domain Controllers"
$sid1 = (get-adgroup $dcgroup).sid
## Get the DACL of the domain
$acl = get-acl $domainNC
## The following object specific ACE grants extended right 'Allow a DC to

create a clone of itself' for the CDC group to the Domain NC
## 3e0f7e18-2c7a-4c10-ba82-4d926db99a3e is the schemaIDGuid for 'DS-Clone-

Domain-Controller"
$objectguid = new-object Guid 3e0f7e18-2c7a-4c10-ba82-4d926db99a3e
$ace1 = new-object System.DirectoryServices.ActiveDirectoryAccessRule

$sid1,"ExtendedRight","Allow",$objectguid
## Add the ACE in the ACL and set the ACL on the object
set-acl -aclobject $acl $domainNC

write-host "Done writing new VDC permissions."
cd c:

Additional Resources
Article • 06/08/2022
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)
Test Guidance for Application Vendors
Article • 03/30/2022
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
Article • 07/29/2021
This topic explains the supportability of using Hyper-V Replica to replicate a virtual
machine (VM) that runs as a domain controller (DC). Hyper-V Replica is a new capability
of Hyper-V beginning with Windows Server 2012 that provides a built-in replication
mechanism at a VM level.
Hyper-V Replica asynchronously replicates selected VMs from a primary Hyper-V host to
a replica Hyper-V host across either LAN or WAN links. After initial replication is
complete, subsequent changes are replicated at an interval defined by the administrator.
Failover can be either planned or unplanned. A planned failover is initiated by an

administrator on the primary VM, and any un-replicated changes are copied over to the
replica VM to prevent any data loss. An unplanned failover is initiated on the replica VM
in response to an unexpected failure of the primary VM. Data loss is possible because
there is no opportunity to transmit changes on the primary VM that might not have
been replicated yet.
For more information about Hyper-V Replica, see Hyper-V Replica Overview and Deploy
Hyper-V Replica.
７ Note
Hyper-V Replica can be run only on Windows Server Hyper-V, not the version of
Hyper-V that runs on Windows 8.
Windows Server 2012 or newer domain

controllers required
Windows Server 2012 Hyper-V introduced VM-GenerationID (VMGenID). VMGenID
provides a way for the hypervisor to communicate to the guest OS when significant
changes have occurred. For example, the hypervisor can communicate to a virtualized
DC that a restore from snapshot has occurred (Hyper-V snapshot restore technology,
not backup restore). AD DS in Windows Server 2012 and newer is aware of VMGenID
VM technology and uses it to detect when hypervisor operations are performed, such as
snapshot restore, which allows it to better protect itself.
７ Note
Only AD DS on Windows Server 2012 DCs or newer provide these safety measures
resulting from VMGenID; DCs that run all previous releases of Windows Server are
subject to problems such as USN rollback that can occur when a virtualized DC is
restored using an unsupported mechanism, such as snapshot restore. For more
information about these safeguards and when they are triggered, see Virtualized
Domain Controller Architecture.
When a Hyper-V replica failover occurs (planned or unplanned), the virtualized DC

detects a VMGenID reset, triggering the aforementioned safety features. Active
Directory operations then proceed as normal. The replica VM runs in place of the
primary VM.
７ Note
Given that now there are now two instances of the same DC identity, there is a
potential for both the primary instance and the replicated instance to run. While
Hyper-V Replica has control mechanisms in place to ensure the primary and replica
VMs do not run simultaneously, it is possible for them to run at the same time in
the event the link between them fails after replication of the VM. In the event of
this unlikely occurrence, virtualized DCs that run Windows Server 2012 have
safeguards to help protect AD DS, whereas virtualized DCs that run earlier versions
of Windows Server do not.
When using Hyper-V Replica, ensure that you follow best practices for running virtual
domain controllers on Hyper-V. This discusses, for example, recommendations for
storing Active Directory files on virtual SCSI disks, which provides stronger guarantees of
data durability.
Supported and unsupported scenarios

Only VMs that run Windows Server 2012 or newer are supported for unplanned failover
and for testing failover. Even for planned failover, Windows Server 2012 or newer is
recommended for the virtualized DC in order to mitigate risks in the event that an
administrator inadvertently starts both the primary VM and the replicated VM at the
same time.
VMs that run earlier versions of Windows Server are supported for planned failover but
unsupported for unplanned failover because of the potential for USN rollback. For more
information about USN rollback, see USN and USN Rollback.
７ Note
There are no functional level requirements for the domain or forest; there are only
operating system requirements for the DCs that run as VMs that are replicated
using Hyper-V Replica. The VMs can be deployed in a forest that contains other
physical or virtual DCs that run earlier versions of Windows Server and may or may
not also be replicated using Hyper-V Replica.
This support statement is based on tests that were performed in a single domain-forest,
though multi-domain forest configurations are also supported. For these tests,
virtualized domain controllers DC1 and DC2 are Active Directory replication partners in
the same site, hosted on a server that runs Hyper-V on Windows Server 2012. The VM
guest that runs DC2 has Hyper-V Replica enabled. The Replica server is hosted in
another geographically distant datacenter. To help explain the test case processes
outlined below, the VM running on the replica server is referred to as DC2-Rec
(although in practice it retains the same name as the original VM).
Windows Server 2012

The following table explains support for virtualized DCs that run Windows Server 2012
and test cases.
Planned Failover Unplanned Failover
Supported Supported
Test case: The test case is the same as for

- DC1 and DC2 are running Windows Server 2012. a planned failover, with these
exceptions:
- DC2 is shut down and a failover is performed on DC2-Rec. - Any AD updates received on
The failover can be either planned or unplanned. DC2 but not yet replicated by
AD to a replication partner
- After DC2-Rec starts, it checks whether the value of VMGenID
before the failover event will be
that it has in its database is the same as the value from the
lost.
virtual machine driver saved by the Hyper-V Replica server.
- AD updates received on DC2
- As a result, DC2-Rec triggers virtualization safeguards; in
after the time of the recovery
other words, it resets its InvocationID, discards its RID pool, and
point that were replicated by
sets an initial synchronization requirement before it will assume
AD to DC1 will be replicated
an operations master role. For more information about initial
from DC1 back to DC2-Rec.
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 Note: Unplanned failover would be
VMGenID or use associated virtualization safeguards. This supported where USN rollback is
places them at risk for USN rollback. For more information, not a risk, such as a single DC in the
see USN and USN Rollback. forest (a configuration that is not
recommended).
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
Article • 06/09/2022
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
AD DS Design and Planning
Article • 05/18/2023
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 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
Understanding AD DS Design
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
Enabling Advanced Features for AD DS
Evaluating AD DS Deployment Strategy Examples
Appendix A: Reviewing Key AD DS Terms

Understanding AD DS Design
Article • 07/29/2021
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
Article • 07/29/2021
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.
AD DS Design Requirements
AD DS Deployment Requirements
AD DS Design Requirements
Article • 07/29/2021
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.

AD DS Deployment Requirements
Article • 07/29/2021
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
Article • 07/29/2021
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 New Organization
Deploying AD DS in a Windows Server 2003 Organization
Deploying AD DS in a Windows 2000 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.
AD DS Deploying AD DS in a New Deploying AD DS in Deploying AD DS in

design and Organization a Windows Server a Windows 2000
deployment 2003 Organization Organization
requirements
Designing the Yes Yes Yes

Logical
Structure for
Windows
Server 2008
AD DS
requirements
Designing the Yes Yes Yes

Site Topology
for Windows
Server 2008
AD DS
Planning Yes Yes Yes

Domain
Controller
Capacity
Deploying a Yes No No
Windows
Server 2008
Forest Root
Domain
Deploying Yes Yes Yes

Windows
Server 2008
Regional
Domains
Enabling Yes Yes, but all domain Yes, but all domain
Advanced controllers in the controllers in the
Features for environment must run environment must run
AD DS Windows Server 2008 Windows Server 2008
before you set the before you set the
domain or forest domain or forest
functional level to functional level to
Windows Server 2008. Windows Server 2008.
Upgrading No Yes Yes

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

Migrating and reduce the number of reduce the number of
Restructuring domains, reduce domains, reduce
Active replication traffic and replication traffic and
Directory the amount of the amount of
Domains required user and required user and
group administration, group administration,
or simplify the or simplify the
administration of administration of
Group Policy. Group Policy.
Deploying AD DS in a New Organization
Article • 07/29/2021
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
Article • 07/29/2021
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.
Deploying AD DS in a Windows 2000
Organization
Article • 07/29/2021
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
Article • 07/29/2021
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
Identifying the Deployment Project Participants
Creating a Forest Design
Creating a Domain Design
Creating a DNS Infrastructure Design
Creating an Organizational Unit Design
Appendix A: DNS Inventory

Understanding the Active Directory
Logical Model
Article • 07/29/2021
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.
Identifying the Deployment Project
Participants
Article • 07/29/2021
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
Article • 07/29/2021
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
for Windows Server 2003 Deployment Kit and open "Forest Design" (DSSLOGI_3.doc).
In this section
Identifying Forest Design Requirements
Determining the Number of Forests Required

Identifying Forest Design Requirements
Article • 07/29/2021
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
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
Article • 07/29/2021
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
Article • 05/17/2023
You can design your Active Directory logical structure to achieve either of the following:
Autonomy. Involves independent but not exclusive control of a resource. When

you achieve autonomy, administrators have the authority to manage resources
independently; however, administrators with greater authority exist who also have
control over those resources and can take control away if necessary. You can
design your Active Directory logical structure to achieve the following types of
autonomy:
Service autonomy. This type of autonomy involves control over all or part of
service management.
Data autonomy. This type of autonomy involves control over all or part of the
data stored in the directory or on member computers joined to the directory.
Isolation. Involves independent and exclusive control of a resource. When you

achieve isolation, administrators have the authority to manage a resource
independently, and no other administrator can take away control of the resource.
You can design your Active Directory logical structure to achieve the following
types of isolation:
Service isolation. Prevents administrators (other than those administrators who

are specifically designated to control service management) from controlling or
interfering with service management.
Data isolation. Prevents administrators (other than those administrators who

are specifically designated to control or view data) from controlling or viewing a
subset of data in the directory or on member computers joined to the directory.
Administrators who require only autonomy accept that other administrators who have
equal or greater administrative authority have equal or greater control over service or
data management. Administrators who require isolation have exclusive control over
service or data management. Creating a design to achieve autonomy is generally less
expensive than creating a design to achieve isolation.
In Active Directory Domain Services (AD DS), administrators can delegate both service
administration and data administration to achieve either autonomy or isolation between
organizations. The combination of service management, data management, autonomy,
and isolation requirements of an organization impact the Active Directory containers
that are used to delegate administration.
Isolation and autonomy requirements

The number of forests that you need to deploy is based on the autonomy and isolation
requirements of each group within your organization. To identify your forest design
requirements, you must identify the autonomy and isolation requirements for all groups
in your organization. Specifically, you must identify the need for data isolation, data
autonomy, service isolation, and service autonomy. You must also identify areas of
limited connectivity in your organization.
Data isolation
Data isolation involves exclusive control over data by the group or organization that
owns the data. It's important to note that service administrators have the ability to take
control of a resource away from data administrators. And data administrators don't have
the ability to prevent service administrators from accessing the resources that they
control. Therefore, you can't 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 can't 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 isn't 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 doesn't 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 can't 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 doesn't 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.
Determining the Number of Forests
Required
Article • 07/29/2021
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
Article • 07/29/2021
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
Article • 07/29/2021
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.
Scenario Limited Data Data Service Service

connectivity isolation autonomy isolation autonomy
Scenario 1: Join an existing No No Yes No No

forest for data autonomy
Scenario Limited Data Data Service Service
connectivity isolation autonomy isolation autonomy
Scenario 2: Use an No No N/A No Yes

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

organizational forest or
resource forest for service
isolation
Scenario 4: Use an N/A Yes N/A N/A N/A

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

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

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

forest, and reconfigure the
firewall for service isolation
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.

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.

restricted access forest for data isolation
You can achieve data isolation by doing one of the following:
Using an organizational forest. Place the users, groups, and computers for the
group that requires data isolation into a separate organizational forest. Assign an
individual from that group to be the forest owner. If the group needs to access or
share resources with other forests in the organization, establish a trust between
the organizational forest and the other forests. Only the users who require access
to the classified information exist in the new organizational forest. Users have one
account that they use to access both classified data in their own forest and
unclassified data in other forests by means of trust relationships.
Using a restricted access forest. This is a separate forest that contains the restricted
data and the user accounts that are used to access that data. Separate user
accounts are maintained in the existing organizational forests that are used to
access the unrestricted resources on the network. No trusts are created between
the restricted access forest and other forests in the enterprise. You can further
restrict the forest by deploying the forest on a separate physical network, so that it
cannot connect to other forests. If you deploy the forest on a separate network,
users must have two workstations: one for accessing the restricted forest and one
for accessing the 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 .

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:
that requires service autonomy into a separate organizational forest. Assign an
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
If limited connectivity is an issue, and you have a requirement for service isolation, you
that requires service isolation into a separate organizational forest. Assign an
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.
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
Article • 07/29/2021
In the organizational domain forest model, several autonomous groups each own a
domain within a forest. Each group controls domain-level service administration, which
enables them to manage certain aspects of service management autonomously while
the forest owner controls forest-level service management.
The following illustration shows an organizational domain forest model.
Domain-level service autonomy

The organizational domain forest model enables the delegation of authority for domain-
level service management. The following table lists the types of service management
that can be controlled at the domain level.
Type of service Associated tasks
management
Management of domain - Creating and removing domain controllers
controller operations - Monitoring the functioning of domain controllers
- Managing services that are running on domain controllers
- Backing up and restoring the directory
Configuration of domain- - Creating domain and domain user account policies, such as
wide settings password, Kerberos, and account lockout policies
- Creating and applying domain-wide Group Policy
Delegation of data-level - Creating organizational units (OUs) and delegating administration
administration - Repairing problems in the OU structure that OU owners do not

have sufficient access rights to fix
Management of external - Establishing trust relationships with domains outside the forest
trusts
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.
Creating a Domain Design
Article • 07/29/2021
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 the Number of Domains Required
Determining Whether to Upgrade Existing Domains or Deploy New Domains
Assigning Domain Names
Selecting the Forest Root Domain

Reviewing the Domain Models
Article • 07/29/2021
The following factors impact the domain design model that you select:
Amount of available capacity on your network that you are willing to allocate to
Active Directory Domain Services (AD DS). The goal is to select a model that
provides efficient replication of information with minimal impact on available
network bandwidth.
Number of users in your organization. If your organization includes a large number

of users, deploying more than one domain enables you to partition your data and
gives you more control over the amount of replication traffic that will pass through
a given network connection. This makes it possible for you to control where data is
replicated and reduce the load created by replication traffic on slow links in your
network.
The simplest domain design is a single domain. In a single domain design, all
information is replicated to all of the domain controllers. If necessary, however, you can
deploy additional regional domains. This might occur if portions of the network
infrastructure are connected by slow links, and the forest owner wants to be sure that
replication traffic does not exceed the capacity that has been allocated to AD DS.
It is best to minimize the number of domains that you deploy in your forest. This
reduces the overall complexity of the deployment and, as a result, reduces total cost of
ownership. The following table lists the administrative costs associated with adding
regional domains.
Cost Implications
Management of multiple service Each domain has its own service administrator groups that
administrator groups need to be managed independently. The membership of
these service administrator groups must be carefully
controlled.
Maintaining consistency among Group Policy settings that need to be applied forest-wide
Group Policy settings that are must be applied separately to each individual domain in the
common to multiple domains forest.
Cost Implications
Maintaining consistency among Access control and auditing settings that need to be applied
access control and auditing across the forest must be applied separately to each
settings that are common to individual domain in the forest.
multiple domains
Increased likelihood of objects The greater the number of domains, the greater the
moving between domains 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.
Determining the Number of Domains
Required
Article • 07/29/2021
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.
Slowest link Maximum number of Maximum number of Maximum number of

connecting a users if 1-percent users if 5-percent users if 10-percent
domain bandwidth is bandwidth is bandwidth is available
controller (Kbps) available available
28.8 10,000 25,000 40,000
32 10,000 25,000 50,000
56 10,000 50,000 100,000
64 10,000 50,000 100,000
128 25,000 100,000 100,000
256 50,000 100,000 100,000
512 80,000 100,000 100,000
1,500 100,000 100,000 100,000
To use this table:
1. In the Slowest link connecting a domain controller column, locate the value that
matches the speed of the slowest link across which AD DS will replicate in your
domain.
2. In the row that corresponds to your slowest link speed, locate the column that
represents the percentage bandwidth you want to allocate to AD DS. The value at
that location is the maximum number of users that the domain in a single domain
forest can contain.
If you determine that the total number of users in your forest is less than the maximum
number of users that your domain can contain, you can use a single domain. Be sure to
accommodate for planned future growth when you make this determination. If you
determine that the total number of users in your forest is greater than the maximum
number of users that your domain can contain, you need to reserve a higher percentage
of bandwidth for replication, increase your link speed, or divide your organization into
regional domains.
Dividing the organization into regional

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

Users are members of five global groups and five universal groups.
Active Directory-integrated DNS is used.
７ Note

28.8 10,000 50,000 75,000

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

Users are members of five global groups and five universal groups.
Active Directory-integrated DNS is used.
７ Note

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

region.
represents the percentage 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
for Windows Server 2003 Deployment Kit and open "Identifying Regions"
(DSSLOGI_4.doc).
Determining Whether to Upgrade
Existing Domains or Deploy New
Domains
Article • 07/29/2021
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
for Windows Server 2003 Deployment Kit and open "Domain Planning"
(DSSLOGI_5.doc).
Assigning Domain Names
Article • 07/29/2021
You must assign a name to every domain in your plan. Active Directory Domain Services
(AD DS) domains have two types of names: Domain Name System (DNS) names and
NetBIOS names. In general, both names are visible to end users. The DNS names of
Active Directory domains include two parts, a prefix and a suffix. When creating domain
names, first determine the DNS prefix. This is the first label in the DNS name of the
domain. The suffix is determined when you select the name of the forest root domain.
The following table lists the prefix naming rules for DNS names.
Rule Explanation
Select a prefix that is not Avoid names such as a product line or operating system that
likely to become outdated. might change in the future. We recommend using geographical
names.
Select a prefix that includes A-Z, a-z, 0-9, and (-), but not entirely numerical.
Internet standard characters
only.
Include 15 characters or less If you choose a prefix length of 15 characters or less, the NetBIOS
in the prefix. 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
for Windows Server 2003 Deployment Kit and open "Domain Planning"
(DSSLOGI_5.doc).
Selecting the Forest Root Domain
Article • 05/19/2023
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.
Ｕ Caution
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.
Rule Explanation
Select a prefix that is not Avoid names such as a product line or operating system that might
likely to become outdated. change in the future. We recommend using generic names such as
corp or ds.
Select a prefix that includes A-Z, a-z, 0-9, and (-), but not entirely numerical.
Internet standard
characters only.
Include 15 characters or If you choose a prefix length of 15 characters or less, the NetBIOS
fewer in the prefix. 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).
Creating a DNS Infrastructure Design
Article • 12/17/2021
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
for Windows Server 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
Reviewing DNS Concepts
DNS and AD DS
DNS for AD DS Owner Role
Integrating AD DS into an Existing DNS Infrastructure
Reviewing DNS Concepts
Article • 07/29/2021
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
Article • 07/29/2021
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
Article • 07/29/2021
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
Article • 07/29/2021
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
Article • 07/29/2021
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
Article • 06/08/2022
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 you to manually edit the msDS-
AllowedToDelegateTo attribute in Active Directory. For more information, see
the ms-DS-Allowed-To-Delegate-To attribute.
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.
DNS for AD DS Owner Role
Article • 12/17/2021
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 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 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
Article • 06/27/2023
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 don't 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
７ 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 don't 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 locate DNS servers. The following table
lists our recommended configurations for these design elements.
Design Configuration
element
Computer Use default naming. When a computer using a Windows operating system joins a
naming 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 Configure client computers to point to any DNS server on the network.
resolver
configuration
７ 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're
joined is upgraded to Windows Server 2008 AD DS, they'll 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 with dynamic update. They're cleaned up automatically with 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.
Appendix A: DNS Inventory
Article • 07/29/2021
You can use the following tables to assist you in documenting the recursive name
resolution method of your current Domain Name System (DNS) structure as part of the
logical structure design for Windows Server Active Directory Domain Services (AD DS).
Root hints
Name IPv4 address IPv6 address
Forwarding
Name IPv4 address IPv6 address Physical location
Creating an Organizational Unit Design
Article • 07/29/2021
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

for Windows Server 2003 Deployment Kit and open "Identifying OUs for Each
Domain" (DSSLOGI_9.doc).
In this section
Reviewing OU Design Concepts
Delegating Administration by Using OU Objects

Reviewing OU Design Concepts
Article • 07/29/2021
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.
Delegating Administration by Using OU
Objects
Article • 07/29/2021
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
Article • 07/29/2021
Every Active Directory domain contains a standard set of containers and organizational
units (OUs) that are created during the installation of Active Directory Domain Services
(AD DS). These include the following:
Domain container, which serves as the root container to the hierarchy
Built-in container, which holds the default service administrator accounts
Users container, which is the default location for new user accounts and groups
created in the domain
Computers container, which is the default location for new computer accounts
created in the domain
Domain Controllers OU, which is the default location for the computer accounts for
domain controllers computer accounts
The forest owner controls these default containers and OUs.
Domain container
The domain container is the root container of the hierarchy of a domain. Changes to the
policies or the access control list (ACL) on this container can potentially have domain-
wide impact. Do not delegate control of this container; it must be controlled by the
service administrators.
Users and computers containers

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

accounts
By default, several well-known users and groups and built-in accounts are created in a
new domain. We recommend that management of these accounts remains under the
control of the service administrators. Do not delegate management of these accounts to
an individual who is not a service administrator. The following table lists the well-known
users and groups and built-in accounts that need to remain under the control of the
service administrators.
Well-known users and groups Built-in accounts

Well-known users and groups Built-in accounts
Cert Publishers Administrator

Domain Controllers Guest
Group Policy Creator Owners Guests
KRBTGT Account Operators
Domain Guests Administrators
Administrator Backup Operators
Domain Admins Incoming Forest Trust Builders
Schema Admins (forest root domain only) Print Operators
Enterprise Admins (forest root domain only) Pre-Windows 2000 Compatible Access
Domain Users Server Operators
Users
Domain Controller OU
When domain controllers are added to the domain, their computer objects are
automatically added to the Domain Controller OU. This OU has a default set of policies
applied to it. To ensure that these policies are applied uniformly to all domain
controllers, we recommend that you not move the computer objects of the domain
controllers out of this OU. Failure to apply the default policies can cause a domain
controller to fail to function properly.
By default, the service administrators control this OU. Do not delegate control of this OU
to individuals other than the service administrators.
Delegating Administration of Account
OUs and Resource OUs
Article • 07/29/2021
Account organizational units (OUs) contain user, group, and computer objects. Resource
OUs contain resources and the accounts that are responsible for managing those
resources. The forest owner is responsible for creating an OU structure to manage these
objects and resources and for delegating control of that structure to the OU owner.
Delegating administration of account OUs

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

The following table lists and describes the possible child OUs that you can create in an
account OU structure.
OU Purpose
Users Contains user accounts for nonadministrative personnel.
Service Some services that require access to network resources run as user accounts. This
Accounts 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
Article • 06/06/2022
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
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
Article • 07/29/2021
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
Understanding Active Directory Site Topology
Collecting Network Information
Planning Domain Controller Placement
Creating a Site Design
Creating a Site Link Design
Creating a Site Link Bridge Design
Finding Additional Resources for Windows Server 2008 Active Directory Site
Topology Design
Understanding Active Directory Site
Topology
Article • 07/29/2021
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 Topology Owner Role
Active Directory Replication Concepts

Site functions
Article • 05/17/2023
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 doesn't 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 doesn't
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's hosting the requested
data within the site. If DFSN doesn't 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.
Site Topology Owner Role
Article • 07/29/2021
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.
Active Directory Replication Concepts
Article • 10/08/2021
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 <automatically generated> 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 <automatically generated> 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\Services\NTDS\Parameters
"Random BH Loadbalancing Allowed"

1 = Enabled (default), 0 = Disabled
For more information about how these KCC improvements work, see Planning and
Deploying Active Directory Domain Services for Branch Offices
(https://go.microsoft.com/fwlink/?LinkId=107114).
Failover functionality
Sites ensure that replication is routed around network failures and offline domain
controllers. The KCC runs at specified intervals to adjust the replication topology for
changes that occur in AD DS, such as when new domain controllers are added and new
sites are created. The KCC reviews the replication status of existing connections to
determine if any connections are not working. If a connection is not working due to a
failed domain controller, the KCC automatically builds temporary connections to other
replication partners (if available) to ensure that replication occurs. If all the domain
controllers in a site are unavailable, the KCC automatically creates replication
connections between domain controllers from another site.
Subnet
A subnet is a segment of a TCP/IP network to which a set of logical IP addresses are
assigned. Subnets group computers in a way that identifies their physical proximity on
the network. Subnet objects in AD DS identify the network addresses that are used to
map computers to sites.
Site
Sites are Active Directory objects that represent one or more TCP/IP subnets with highly
reliable and fast network connections. Site information allows administrators to
configure Active Directory access and replication to optimize usage of the physical
network. Site objects are associated with a set of subnets, and each domain controller in
a forest is associated with an Active Directory site according to its IP address. Sites can
host domain controllers from more than one domain, and a domain can be represented
in more than one site.
Site link
Site links are Active Directory objects that represent logical paths that the KCC uses to
establish a connection for Active Directory replication. A site link object represents a set
of sites that can communicate at uniform cost through a specified intersite transport.
All sites contained within the site link are considered to be connected by means of the
same network type. Sites must be manually linked to other sites by using site links so
that domain controllers in one site can replicate directory changes from domain
controllers in another site. Because site links do not correspond to the actual path taken
by network packets on the physical network during replication, you do not need to
create redundant site links to improve Active Directory replication efficiency.
When two sites are connected by a site link, the replication system automatically creates
connections between specific domain controllers in each site that are called bridgehead
servers. In Windows Server 2008, all domain controllers in a site that host the same
directory partition are candidates for being selected as bridgehead servers. The
replication connections created by the KCC are randomly distributed among all
candidate bridgehead servers in a site to share the replication workload. By default, the
randomized selection process takes place only once, when connection objects are first
added to the site.
Site link bridge

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

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

creating site links objects in the SMTP container is not recommended.
Global catalog server

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

Universal group membership caching allows the domain controller to cache universal
group membership information for users. You can enable domain controllers that are
running Windows Server 2008 to cache universal group memberships by using the
Active Directory Sites and Services snap-in.
Enabling universal group membership caching eliminates the need for a global catalog
server at every site in a domain, which minimizes network bandwidth usage because a
domain controller does not need to replicate all of the objects located in the forest. It
also reduces logon times because the authenticating domain controllers do not always
need to access a global catalog to obtain universal group membership information. For
more information about when to use universal group membership caching, see Planning
Global Catalog Server Placement.
Collecting Network Information
Article • 07/29/2021
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
"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
"Domains and Users in Each Location" (DSSTOPO_3.doc).
Planning Domain Controller Placement
Article • 05/17/2023
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 can't 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 Forest Root Domain Controller Placement
Planning Regional Domain Controller Placement
Planning Global Catalog Server Placement

Planning Operations Master Role Placement
Planning Forest Root Domain Controller
Placement
Article • 07/29/2021
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
"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
Article • 05/17/2023
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 can't access them. Don't place writable domain
controllers in hub and satellite locations in which you can't 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 can't 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
can't 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 doesn't include a domain controller that can authenticate the users.
If your WAN link availability isn't 100 percent and your remote sites can't 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 isn't 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 don't need to
place a domain controller in a location that contains only a few users who don't
frequently access network resources.
Logon network traffic vs. replication traffic

If a domain controller isn't 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 don't 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
"Domain Controller Placement" (DSSTOPO_4.doc).
You'll 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.
Planning Global Catalog Server
Placement
Article • 05/17/2023
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 doesn't 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 don't 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's 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: Don't 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 don't 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 don't 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 don't need to place a global catalog at a location that doesn't 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 don't 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 aren't 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
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.
Planning Operations Master Role
Placement
Article • 07/29/2021
Active Directory Domain Services (AD DS) supports multimaster replication of directory
data, which means any domain controller can accept directory changes and replicate the
changes to all other domain controllers. However, certain changes, such as schema
modifications, are impractical to perform in a multimaster fashion. For this reason
certain domain controllers, known as operations masters, hold roles responsible for
accepting requests for certain specific changes.
７ Note
Operations master role holders must be able to write some information to the
Active Directory database. Because of the read-only nature of the Active Directory
database on a read-only domain controller (RODC), RODCs cannot act as
operations master role holders.
Three operations master roles (also known as flexible single master operations or FSMO)
exist in each domain:
The primary domain controller (PDC) emulator operations master processes all
password updates.
The relative ID (RID) operations master maintains the global RID pool for the
domain and allocates local RIDs pools to all domain controllers to ensure that all
security principals created in the domain have a unique identifier.
The infrastructure operations master for a given domain maintains a list of the
security principals from other domains that are members of groups within its
domain.
In addition to the three domain-level operations master roles, two operations master
roles exist in each forest:
The schema operations master governs changes to the schema.

The domain naming operations master adds and removes domains and other
directory partitions (for example, Domain Name System (DNS) application
partitions) to and from the forest.
Place the domain controllers hosting these operations master roles in areas where
network reliability is high, and ensure that the PDC emulator and the RID master are
consistently available.
Operations master role holders are assigned automatically when the first domain
controller in a given domain is created. The two forest-level roles (schema master and
domain naming master) are assigned to the first domain controller created in a forest. In
addition, the three domain-level roles (RID master, infrastructure master, and PDC
emulator) are assigned to the first domain controller created in a domain.
７ Note
Automatic operations master role holder assignments are made only when a new
domain is created and when a current role holder is demoted. All other changes to
role owners have to be initiated by an administrator.
These automatic operations master role assignments can cause very high CPU usage on
the first domain controller created in the forest or the domain. To avoid this, assign
(transfer) operations master roles to various domain controllers in your forest or
domain. Place the domain controllers that host operations master roles in areas where
the network is reliable and where the operations masters can be accessed by all other
domain controllers in the forest.
You should also designate standby (alternate) operations masters for all operations
master roles. The standby operations masters are domain controllers to which you could
transfer the operations master roles in case the original role holders fail. Ensure that the
standby operations masters are direct replication partners of the actual operations
masters.
Planning the PDC emulator placement

The PDC emulator processes client password changes. Only one domain controller acts
as the PDC emulator in each domain in the forest.
Even if all the domain controllers are upgraded to Windows 2000, Windows Server 2003,
and Windows Server 2008 , and the domain is operating at the Windows 2000 native
functional level, the PDC emulator receives preferential replication of password changes
performed by other domain controllers in the domain. If a password was recently
changed, that change takes time to replicate to every domain controller in the domain.
If logon authentication fails at another domain controller due to a bad password, that
domain controller forwards the authentication request to the PDC emulator before
deciding whether to accept or reject the logon attempt.
Place the PDC emulator in a location that contains a large number of users from that
domain for password forwarding operations if needed. In addition, ensure that the
location is well connected to other locations to minimize replication latency.
For a worksheet to assist you in documenting the information about where you plan to
place PDC emulators and the number of users for each domain that is represented in
each location, see Job Aids for Windows Server 2003 Deployment Kit , download
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

Be aware that if your environment does have a central location or hub site in which you
can place operations master role holders, certain domain controller operations that
depend on the availability of those operations master role holders might be affected.
For example, suppose that an organization creates sites A, B, C, and D. Site links exist
between A and B, between B and C, and between C and D. Network connectivity exactly
mirrors the network connectivity of the sites links. In this example, all operations master
roles are placed in site A and the option to Bridge all site links is not selected.
Although this configuration results in successful replication between all of the sites, the
operations master role functions have the following limitations:
Domain controllers in sites C and D cannot access the PDC emulator in site A to
update a password or to check it for a password that has been recently updated.
Domain controllers in sites C and D cannot access the RID master in site A to
obtain an initial RID pool after the Active Directory installation and to refresh RID
pools as they become depleted.
Domain controllers in sites C and D cannot add or remove directory, DNS, or
custom application partitions.
Domain controllers in sites C and D cannot make schema changes.
For a worksheet to assist you in planning operations master role placement, see Job
Aids for Windows Server 2003 Deployment Kit , download
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
Article • 10/08/2021
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
"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 <IP address>/<prefix length>. 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.
Creating a Site Link Design
Article • 07/29/2021
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
"Sites and Associated Site Links" (DSSTOPO_5.doc).
In this guide
Setting Site Link Properties
Setting Site Link Properties
Article • 07/29/2021
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
Article • 05/17/2023
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 doesn't exist at that site. The client contacts the domain controller by using the
site link that has the lowest cost assigned to it.
We recommend that the cost value be defined on a site-wide basis. Cost is usually based
not only on the total bandwidth of the link but also on the availability, latency, and
monetary cost of the link.
To determine the costs to place on site links, document the connection speed for each
site link. Refer to the "Geographic Locations and Communication Links"
(DSSTOPO_1.doc) worksheet in Collecting Network Information for information about
the connection speed that you identified.
The following table lists the speeds for different types of networks.
Network type Speed
Very slow 56 kilobits per second (Kbps)
Slow 64 Kbps
Integrated Services Digital 64 Kbps or 128 Kbps

Network (ISDN)
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 Variable rate, commonly between 155 Mbps and 622 Mbps
(ATM)
Network type Speed
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 isn't 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.
Available bandwidth (Kbps) Cost
9.6 1,042
19.2 798
38.4 644
56 586
64 567
128 486
256 425
512 378
1,024 340
2,048 309
4,096 283
These costs don't reflect differences in reliability between network links. Set higher costs
on any failure-prone network links so that you don't 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
Article • 07/29/2021
If you have a domain controller that runs Windows Server 2008 or newer, you can make
it possible for client computers that run Windows Vista or newer or Windows Server
2008 or newer to locate domain controllers more efficiently by enabling the Try Next
Closest Site Group Policy setting. This setting improves the Domain Controller Locator
(DC Locator) by helping to streamline network traffic, especially in large enterprises that
have many branch offices and sites.
This new setting can affect how you configure site link costs because it affects the order
in which domain controllers are located. For enterprises that have many hub sites and
branch offices, you can significantly reduce Active Directory traffic on the network by
ensuring that clients fail over to the next closest hub site when they cannot find a
domain controller in the closest hub site.
As a general best practice, you should simplify your site topology and site link costs as
much as possible if you enable the Try Next Closest Site setting. In enterprises with
many hub sites, this can simplify any plans that you make for handling situations in
which clients in one site need to fail over to a domain controller in another site.
By default, the Try Next Closest Site setting is not enabled. When the setting is not
enabled, DC Locator uses the following algorithm to locate a domain controller:
Try to find a domain controller in the same site.

If no domain controller is available in the same site, try to find any domain
controller in the domain.
７ Note
This is the same algorithm that DC Locator used in previous versions of Active
Directory. For more information, see the article How DNS Support for Active
Directory Works.
If you enable the Try Next Closest Site setting, DC Locator uses the following algorithm
to locate a domain controller:
Try to find a domain controller in the same site.
If no domain controller is available in the same site, try to find a domain controller
in the next closest site. A site is closer if it has a lower site-link cost than another
site with a higher site-link cost.
If no domain controller is available in the next closest site, try to find any domain
The Try Next Closest Site setting works in coordination with automatic site coverage.
For example, if the next closest site has no domain controller, DC Locator tries to find
the domain controller that performs automatic site coverage for that site.
By default, DC Locator does not consider any site that contains a read-only domain
controller (RODC) when it determines the next closest site. In addition, when the client
gets a response from a domain controller that runs a version earlier than Windows
Server 2008, the DC Locator behavior is the same as when then setting is not enabled.
For example, assume that a site topology has four sites with the site link values in the
following illustration. In this example, all the domain controllers are writable domain
controllers that run Windows Server 2008 or newer.
When the Try Next Closest Site Group Policy setting is enabled in this example, if a
client computer in Site_B tries to locate a domain controller, it first tries to find a domain
controller in its own Site_B. If none is available in Site_B, it tries to find a domain
controller in Site_A.
If the setting is not enabled, the client tries to find a domain controller in Site_A, Site_C,
or Site_D if no domain controller is available in Site_B.
７ Note
The Try Next Closest Site setting works in coordination with automatic site
coverage. For example, if the next closest site has no domain controller, DC Locator
tries to find the domain controller that performs automatic site coverage for that
site.
To apply the Try Next Closest Site setting, you can create a Group Policy object (GPO)
and link it to the appropriate object for your organization, or you can modify the Default
Domain Policy to have it affect all clients that run Windows Vista or newer and Windows
Server 2008 or newer in the domain. For more information about how to set the Try
Next Closest Site setting, see Enable Clients to Locate a Domain Controller in the Next
Closest Site.
Determining the Schedule
Article • 07/29/2021
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
Article • 07/29/2021
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:
Sites Seattle Boston Los Angeles New York Washington, D.C.
Seattle 0.25
Boston 0.25
Los Angeles 0.25
New York 0.25
Washington, D.C. 0.25
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.
Sites Seattle Boston Los Angeles New York Washington, 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, D.C. 0.25

Creating a Site Link Bridge Design
Article • 02/15/2023
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.
Finding Additional Resources for
Windows Server 2008 Active Directory
Site Topology Design
Article • 07/29/2021
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
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
Article • 07/29/2021
Use the following table to assist in listing the IP version 6 (IPv6) subnet prefixes when
you design the site topology for Windows Server 2008 Active Directory Domain Services
(AD DS).
Location Network subnet prefix

Enabling Advanced Features for AD DS
Article • 07/29/2021
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
Article • 06/16/2023
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, 2019, or
2022. As with any server, domain controllers (DCs) running on an unsupported version
of Windows Server should be removed from the domain and replaced with a version of
Windows Server that is supported. For more information, see Windows Server release
information.
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 Migration of FRS to DFSR SYSVOL blog .
Windows Server 2016 is the last Windows Server release that includes FRS.
７ Note
There have been no new forest or domain functional levels added since Windows
Server 2016. Later operating system versions can and should be used for domain
controllers, however they use Windows Server 2016 as the most recent functional
levels.
Windows Server 2016 functional levels

Supported domain controller operating systems:
Windows Server 2022

Windows Server 2019
Windows Server 2016
The minimum requirement to add one a domain controller of one of these versions of
Windows Server is a Windows Server 2008 functional level. The domain also has to use
DFS-R as the engine to replicate SYSVOL.
Windows Server 2016 forest functional level features

All of the features that are available at the Windows Server 2012 R2 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 2012 R2
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 2012 R2 functional levels

Windows Server 2022

Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012 R2 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 2012 R2 domain functional level features

All default Active Directory features, all features from the Windows Server 2012
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 that 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 2022

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 2008 R2
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 2008 R2 functional levels

Windows Server 2022

Windows Server 2019
Windows Server 2016
Windows Server 2012
Windows Server 2008 R2 forest functional level features

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 2008 R2 domain functional level features

All default Active Directory features, all features from the Windows Server 2008
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 2022

Windows Server 2019
Windows Server 2016
Windows Server 2012
Windows Server 2008

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 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,<domain root> and cn=Users,
<domain root>. 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 with Kerberos-based
authentication.
You can restrict delegation to specific destination services only.
Selective authentication
Selective authentication makes it 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 functional levels

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
Article • 07/29/2021
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 Windows Server 2008 R2
Use of a version-specific program that does not run on Windows Server 2008 or
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 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 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 .
Domain.
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.
Domain.
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.
Domain.
７ 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
Article • 07/29/2021
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 Upgrading Active Directory Domains to Windows Server 2008 and
Windows Server 2008 R2 AD DS 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.
Evaluating AD DS Deployment Strategy
Examples
Article • 07/29/2021
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.
Appendix A: Reviewing Key AD DS
Terms
Article • 07/29/2021
The following terms are relevant to the deployment process for Windows Server 2008
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.

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
Article • 07/29/2021
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.
What's New in Active Directory Domain Services Installation and Removal
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
Troubleshooting Domain Controller Deployment

What's New in Active Directory Domain
Services Installation and Removal
Article • 05/17/2023
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's 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's functional parity between
command-line and GUI installation options.
The new AD DS installation includes prerequisite validation. Any potential errors

are identified before the installation begins. You can correct error conditions
before they occur without the concerns resulting from a partially complete
upgrade. For example, if adprep /domainprep needs to be run, the installation
wizard verifies that the user has sufficient rights to execute the operation.
Configuration pages are grouped in a sequence that mirrors the requirements of

the most common promotion options with related options grouped in fewer
wizard pages. This provides better context for making installation choices.
You can export a Windows PowerShell script that contains all the options that
were specified during the graphical installation. At the end of an installation or
removal, you can export the settings to a Windows PowerShell script for use with
automating the same operation.
Only critical replication occurs before reboot. New switch to allow replication of
noncritical 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's only one version of Adprep.exe (there's 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 isn't 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're 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 doesn't 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 doesn't impose the
same requirements as by adprep.exe. Using Windows PowerShell or Server Manager, it's
possible to pass a value for /user but not /userdomain to adprep.dll. If /user is specified
but /userdomain isn't specified, the local machine's domain is used to perform the
check. If the machine isn't domain joined, group membership can't be checked.
When group membership can't 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 isn't a
domain account, Adprep.exe can't perform the group membership check. Adprep.exe
also can't perform the group membership check if smartcard credentials are used, even
if you do specify both /user and /userdomain.
If Adprep finishes successfully, there's 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's no easy way to specify the smart card credential through the command line.
One way to do it's 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 isn't run

automatically
The adprep /domainprep /gpprep command isn't 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 doesn't 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 won't
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 doesn't currently
exist.
NetBIOS name verification: Checks that provided NetBIOS name is valid and
doesn't conflict with existing names.
Component path verification: Verifies that paths for the Active Directory database,
logs, and SYSVOL are valid and that there's enough disk space available for them.
Child domain name verification: Ensures that the parent and new child domain
names are valid and that they don't conflict with existing domains.
Tree domain name verification: Ensures that the specified tree name is valid and
that it doesn't 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 isn't returned to
Windows PowerShell, and the cmdlet can hang indefinitely.
Installation of an additional domain controller using smart card credentials fails

if the target server is not joined to the domain before installation.
The error message returned in this case is:
Unable to connect to the replication source domain controller source domain

controller name. (Exception: Logonfailure: unknown user name or bad password)
If you join the target server to the domain and then perform the installation using
a smart card, the installation succeeds.
The ADDSDeployment module does not run under 32-bit processes. If you're
automating deployment and configuration of Windows Server 2012 using a script
that includes an ADDSDeployment cmdlet and any other cmdlet that doesn't
support native 64-bit processes, the script can fail with an error that indicates the
ADDSDeployment cmdlet can't be found.
In this case, you need to run the ADDSDeployment cmdlet separately from the
cmdlet that doesn't support native 64-bit processes.
There's a new file system in Windows Server 2012 named Resilient File System.
Don't 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 won't proceed.
If you're installing using Server Manager, you may see the installation progress page
remain open, but there's no error reported on screen, and the progress may not change
for about 15 minutes. If you're using Windows PowerShell, the progress shown in the
Windows PowerShell window won't 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're 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 won't correct this error condition because the server will
indicate that AD DS is installed even though the installation didn't 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 aren't 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 isn't 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're 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 a newer
version of Windows Server
Article • 01/05/2022
This article provides background information about Active Directory Domain Services in
Windows Server and explains the process for upgrading domain controllers (DCs) from
an earlier version of Windows Server.
Prerequisites
The recommended way to upgrade a domain is to promote new servers to DCs that run
a newer version of Windows Server and demote the older DCs as needed. This method
is preferable to upgrading the operating system of an existing DC, which is also known
as an in-place upgrade.
Follow these general steps before you promote a server to a DC that runs a newer
version of Windows Server:
1. Verify the target server meets the system requirements.
2. Verify application compatibility.
3. Review recommendations for moving to a newer version of Windows Server.
4. Verify security settings.
5. Check connectivity to the target server from the computer where you plan to run
the installation.
6. Check for availability of the necessary Flexible Single Master Operation (FSMO)
roles in Active Directory. This step is required for the following scenarios:
To install the first DC that runs the latest Windows Server version in an
existing domain and forest, the machine where you run the installation needs
connectivity to:
The schema master to run adprep /forestprep .
The infrastructure master 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 DC installation also requires connectivity to the RID master.
If you're installing the first read-only DC in an existing forest, you need
connectivity to the infrastructure master for each application directory
partition, which is also known as a non-domain naming context.
To find out which server or servers hold which FSMO role, run the following
commands in an elevated PowerShell session by using an account that's a member
of the Domain Admins group:
PowerShell
Get-ADDomain | FL InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | FL DomainNamingMaster, SchemaMaster
Installation actions and required administrative levels

The following table provides a summary of the installation actions and the permissions
requirements to accomplish these steps.
Installation action Credential requirements
Install a new forest. Local admin on the target server
Install a new domain in an existing Enterprise admins

forest.
Install another 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
Supported in-place upgrade paths

Only 64-bit version upgrades are supported. For more information about supported
upgrade paths, see Supported upgrade paths.
Adprep - forestprep and domainprep
For an in-place upgrade of an existing DC, you must run adprep /forestprep and adprep
/domainprep manually. You need to run Adprep /forestprep only once in the forest for
each newer version of Windows Server. Run Adprep /domainprep once in each domain in
which you have DCs that you're upgrading for each newer version of Windows Server.
If you're promoting a new server to a DC, you don't need to run these command-line
tools manually. They're integrated into the PowerShell and Server Manager experiences.
For more information on running adprep, see Running Adprep.
Functional-level features and requirements

Windows Server 2019 or later requires a Windows Server 2008 forest functional level as
a minimum. Windows Server 2016 requires a Windows Server 2003 forest functional
level as a minimum. If the forest contains DCs running an older forest functional level
than the operating system supports, the installation is blocked. Those DCs must be
removed and the forest functional level raised to a version that's supported before you
add newer Windows Server DCs to your forest. For more information about supported
functional levels, see Forest and domain functional levels.
７ Note
No new forest or domain functional levels have been added since Windows Server
2016. Later operating system versions can and should be used for domain
controllers. They use Windows Server 2016 as the most recent functional levels.
Roll back functional levels

After you set the forest functional level to a certain value, you can't roll back or lower
the forest functional level, with the following exceptions:
If you're upgrading from Windows Server 2012 R2 forest functional level, you can
roll back to Windows Server 2012 R2.
If you're upgrading from Windows Server 2008 R2 forest functional level, you can
roll back to Windows Server 2008 R2.
After you set the domain functional level to a certain value, you can't 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 available at each of the functional levels, see Forest
and domain functional levels.

interoperability
Active Directory Domain Services isn't supported on the following Windows operating
systems:
Windows MultiPoint Server

Windows Server Essentials
Active Directory Domain Services can't be installed on a server that also runs the
following server roles or role services:
Microsoft Hyper-V Server

Remote Desktop Connection Broker
Administration of Windows Server

Use the Remote Server Administration Tools for Windows 10 or later to manage domain
controllers and other servers that run Windows Server. You can run the Windows Server
Remote Server Administration Tools on a computer that runs Windows 10 or later.
Add a new domain controller with a newer

version of Windows Server
The following example shows how to upgrade the Contoso forest from a previous
version of Windows Server to a later version.
1. Join the new Windows Server to your forest. Restart when you're prompted.
2. Sign in to the new Windows Server with a domain admin account.
3. In Server Manager, under Add Roles and Features, install Active Directory
Domain Services on the new Windows Server. This action automatically runs
adprep on the earlier version forest and domain.
4. In Server Manager, select the yellow triangle. From the drop-down, select
Promote the server to a domain controller.
5. On the Deployment Configuration screen, select Add a new domain to an
existing forest and select Next.
6. On the Domain Controller options screen, enter the Directory Services Restore
Mode (DSRM) password and select Next.
7. For the rest of the screens, select Next.
8. On the Prerequisite Check screen, select Install. After the restart has completed,
sign in again.
9. On the earlier version of Windows Server, in Server Manager, under Tools, select
Active Directory Module for Windows PowerShell.
10. In the PowerShell window, use the Move-ADDirectoryServerOperationMasterRole

cmdlet to move the FSMO roles. You can enter the name of each Operation Master
Role or use numbers to specify the roles. For more information, see Move-
ADDirectoryServerOperationMasterRole.
PowerShell
Move-ADDirectoryServerOperationMasterRole -Identity "DC-W2K16" -

OperationMasterRole 0,1,2,3,4
11. To verify the roles were moved, go to the new Windows Server. In Server Manager,
under Tools, select Active Directory Module for Windows PowerShell. Use the
Get-ADDomain and Get-ADForest cmdlets to view the FSMO role holders.
12. Demote and remove the earlier Windows Server DC. For information on how to
demote a DC, see Demoting domain controllers and domains.
13. After the server is demoted and removed, you can raise the forest functional and
domain functional levels to the latest version of Windows Server.
Next steps
What's new in Active Directory Domain Services installation and removal
Windows Server functional levels
Upgrade Domain Controllers to
Windows Server 2012 R2 and Windows
Server 2012
Article • 05/17/2023
This article 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're 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 nondomain naming context or NDNC.
6. Be sure to supply the necessary credentials to run the AD DS installation.
Installation action Credential requirements
Install a new forest Local Administrator on the target server
Install a new domain in an existing Enterprise Admins

forest
Install an additional DC in an existing Domain Admins

domain
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 enables 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 as 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's available. For a more detailed
explanation of some features, including their requirements, see What's New in Active
Directory in Windows Server 2012 R2.
Feature Description
Workplace Allows information workers to join their personal devices with their company to
Join access company resources and services.
Web Provides access to web application using a new Remote Access role service.
Application
Proxy
Feature Description
Active AD FS has simplified deployment and improvements to enable users to access

Directory resources from personal devices and help IT departments manage access control.
Federation
Services
SPN and UPN Domain Controllers running Windows Server 2012 R2 block the creation of
uniqueness duplicate service principal names (SPNs) and user principal names (UPNs).
Winlogon Enables lock screen applications to be restarted and available on Windows 8.1
Automatic devices.
Restart Sign-
On (ARSO)
TPM Key Enables CAs to cryptographically attest in an issued certificate that the certificate
Attestation requester private key is actually protected by a Trusted Platform Module (TPM).
Credentials New credential protection and domain authentication controls to reduce

Protection credential theft.
and
Management
Deprecation The Windows Server 2003 domain functional level is also deprecated because at
of File the functional level, FRS is used to replicate SYSVOL. That means when you
Replication create a new domain on a server that runs Windows Server 2012 R2, the domain
Service (FRS) 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 There are new functional levels for Windows Server 2012 R2. New features are
and forest available at Windows Server 2012 R2 DFL.
functional
levels
LDAP query Performance improvement in LDAP search efficiency and LDAP search time of
optimizer complex queries.
changes
1644 Event LDAP search result statistics were added to event ID 1644 to aid in
improvements troubleshooting.
Active Adjusts the maximum AD Replication throughput from 40Mbps to around 600
Directory Mbps
replication
throughput
improvement
What's new in AD DS in Windows Server 2012?
The following table summarizes the new features for AD DS in Windows Server 2012,
with a link to more detailed information where it is available. For a more detailed
explanation of some features, including their requirements, see What's New in Active
Directory Domain Services (AD DS).
Feature Description
Active Directory-Based Simplifies the task of configuring the distribution and management of
Activation (AD BA) see volume software licenses.
Volume Activation
Overview
Active Directory Adds role install via Server Manager, simplified trust-setup, automatic
Federation Services (AD trust management, SAML-protocol support, and more.
FS)
Active Directory lost NTDS ISAM event 530 with jet error -1119 is logged to detect lost
page flush events page flush events to Active Directory databases.
Active Directory Recycle Active Directory Administrative Center (ADAC) adds GUI management
Bin User Interface of recycle bin feature originally introduced in Windows Server 2008
R2.
Active Directory Supports the creation and management of Active Directory sites, site-
Replication and links, connection objects, and more using Windows PowerShell.
Topology Windows
PowerShell cmdlets
Dynamic Access Control New claims-based authorization platform that enhances the legacy
access control model.
Fine-Grained Password ADAC adds GUI support for the creating, editing and assignment of
Policy User Interface PSOs originally added in Windows Server 2008.
Group Managed Service A new security principal type known as a gMSA. Services running on
Accounts (gMSA) multiple hosts can run under the same gMSA account.
DirectAccess Offline Extends offline domain-join by including DirectAccess prerequisites.

Domain Join
Rapid deployment via Virtualized DCs can be rapidly deployed by cloning existing virtual
virtual domain controller domain controllers using Windows PowerShell cmdlets.
(DC) cloning
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.
Feature Description
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 Accidentally restoring snapshot backups of virtualized DCs no longer
for virtualized DCs causes USN rollback.
Windows PowerShell Allow administrators to view the Windows PowerShell commands

History Viewer 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
Components|Windows Update|No auto-restart with logged on users
Components|Maintenance Scheduler|Maintenance Random Delay
The following table lists some examples of how to configure these settings to provide
desired restart behavior.
Scenario Recommended configuration(s)
WSUS managed Set machines to autoinstall, prevent autoreboot until desired time
Policy: Configure Automatic Updates (Enabled)
- Install updates once per
week
Configure automatic updating: 4 - Auto download and schedule
- Reboot Fridays at 11PM the install
Policy: No autorestart with logged-on users (Disabled)
WSUS deadlines: set to Fridays at 11PM
WSUS managed Set target groups for different groups of machines that should be
updated together
- Stagger installs across Use above steps for previous scenario
different hours/days
Set different deadlines for different target groups
Not WSUS-managed - no Policy: Configure Automatic Updates (Enabled)

support for deadlines
Configure automatic updating: 4 - Auto download and schedule
- Stagger installs at different the install
times
Registry key: Enable the registry key discussed in Microsoft KB
article 2835627
Policy: Automatic Maintenance Random Delay (Enabled)
Set Regular maintenance random delay to PT6H for 6-hour

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

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

machines
For more information about why the Windows engineering team implemented these
changes, see 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're 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's 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:
Encryption Windows Windows Comment

type or policy Server Server
2008 2012 and
default Windows
Server
2008 R2
default
AllowNT4Crypto Disabled Disabled Third-party Server Message Block (SMB) clients may
be incompatible with the secure default settings on
domain controllers. In all cases, these settings can be
relaxed to allow interoperability, but only at the
expense of security. For more information, see
Disable the AllowNT4Crypto setting on all affected
domain controllers in the Microsoft Knowledge Base
(/services-hub/unified/health/remediation-steps-
ad/disable-the-allownt4crypto-setting-on-all-
affected-domain-controllers).
DES Enabled Disabled Article 977321 in the Microsoft Knowledge Base

(https://go.microsoft.com/fwlink/?LinkId=177717 )
CBT/Extended N/A Enabled See Microsoft Security Advisory (937811)

Protection for (https://go.microsoft.com/fwlink/?LinkId=164559 )
Integrated and article 976918 in the Microsoft Knowledge Base
Authentication (https://go.microsoft.com/fwlink/?LinkId=178251 ).
Review and install the hotfix in Install Service Packs

and Hotfixes - Windows Client
(/troubleshoot/windows-client/deployment/install-
service-packs-hotfixes) in the Microsoft Knowledge
Base as required.
LMv2 Enabled Disabled Article 976918 in the Microsoft Knowledge Base

(https://go.microsoft.com/fwlink/?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.
Requirement Value
Processor 1.4 Ghz 64-bit processor
RAM 512 MB
Free disk space requirements 32 GB
Screen resolution 800 x 600 or higher
Miscellaneous DVD drive, keyboard, Internet access
Disk space requirements for upgrading domain

controllers
This section covers disk space requirements only for upgrading domain controllers from
Windows Server 2008 or Windows Server 2008 R2 . For more information about disk
space requirements for upgrading domain controllers to earlier versions of Windows
Server, see Disk space requirements for upgrading to Windows Server 2008 or Disk
space requirements for upgrading to Windows Server 2008 R2.
Size the disk that hosts the Active Directory database and log files in order to
accommodate the custom and application-driven schema extensions, application and
administrator-initiated indexes, plus space for the objects and attributes that you'll 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's 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 can't upgrade domain
controllers that run Windows Server 2003 or 32-bit versions of Windows Server 2008. To
replace them, install domain controllers that run a later version of Windows Server in the
domain, and then remove the domain controllers that Windows Server 2003.
If you're running these editions You can upgrade to these editions

If you're running these editions You can upgrade to these editions
Windows Server 2008 Standard with SP2 Windows Server 2012 Standard
OR OR
Windows Server 2008 Enterprise with SP2 Windows Server 2012 Datacenter
Windows Server 2008 Datacenter with SP2 Windows Server 2012 Datacenter
Windows Web Server 2008 Windows Server 2012 Standard
Windows Server 2008 R2 Standard with SP1 Windows Server 2012 Standard
OR OR
Windows Server 2008 R2 Enterprise with SP1 Windows Server 2012 Datacenter
Windows Server 2008 R2 Datacenter with SP1 Windows Server 2012 Datacenter
Windows Web Server 2008 R2 Windows Server 2012 Standard
For more information about supported upgrade paths, see Evaluation Versions and
Upgrade Options for Windows Server 2012. Note that you can't 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 can't 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's 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 aren't supported and will block installation of
a domain controller that runs Windows Server 2012. If the forest contains domain
controllers running Windows Server 2003 or later but the forest functional level is still
Windows 2000, the installation is also blocked.
Windows 2000 domain controllers must be removed prior to adding Windows Server
2012 domain controllers to your forest. In this case, consider the following workflow:
1. Install domain controllers that run Windows Server 2003 or later. These domain
controllers can be deployed on an evaluation version of Windows Server. This step
also requires running adprep.exe for that operating system release as a
prerequisite.
2. Remove the Windows 2000 domain controllers. Specifically, gracefully demote or
forcibly remove Windows Server 2000 domain controllers from the domain and
used Active Directory Users and Computers to remove the domain controller
accounts for all removed domain controllers.
3. Raise the forest functional level to Windows Server 2003 or higher.
4. Install domain controllers that run Windows Server 2012.
5. Remove domain controllers that run earlier versions of Windows Server.
The new Windows Server 2012 domain functional level enables one new feature: the
KDC support for claims, compound authentication, and Kerberos armoring KDC
administrative template policy has two settings (Always provide claims and Fail
unarmored authentication requests) that require Windows Server 2012 domain
functional level.
The Windows Server 2012 forest functional level doesn't 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 doesn't 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 can't 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 hasn't 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 can't be rolled back, for
example, to Windows Server 2003.
After you set the domain functional level to a certain value, you can't 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 can't 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 can't. But virtual domain controller cloning
and virtual domain controller safeguards in Windows Server 2012 don't 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 isn't supported on the following Windows operating systems:
Windows MultiPoint Server

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

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

Use the Remote Server Administration Tools for Windows 8 to manage domain
controllers and other servers that run Windows Server 2012 . You can run the Windows
Server 2012 Remote Server Administration Tools on a computer that runs Windows 8.
Application compatibility
The following table covers common Active Directory-integrated Microsoft applications.
The table covers what versions of Windows Server that the applications can be installed
on and whether the introduction of Windows Server 2012 DCs affects application
compatibility.
Product Notes
Microsoft SharePoint 2010 Service Pack 2 is required to install and operate
SharePoint SharePoint 2010 on Windows Server 2012 Servers

2010
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) can't be installed on Windows
Server 2012."
Microsoft Minimum requirements for a database server in a farm

SharePoint The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard,
2013 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:
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 front-end web servers and application servers 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.
Product Notes
Configuration Configuration Manager 2012 Service Pack 1:

Manager Microsoft will add the following operating systems to our client support matrix
2012 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 Supported operating systems for Configuration Manager site system servers.
Endpoint
Configuration
Manager
(current
branch)
Microsoft Lync Server 2013 requires with Windows Server 2008 R2 or Windows Server 2012.
Lync Server It can't be run on a Server Core installation. It can be run on virtual servers.
2013
Lync Server Lync Server 2010 can be installed on a new (not upgraded) installation Windows
2010 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 isn't supported. Microsoft Lync Server 2010 Group
Chat Server is also not supported on Windows Server 2012.
System System Center 2012 Endpoint Protection Service Pack 1 will update the client
Center 2012 support matrix to include the following operating systems
Endpoint - Windows 8 Pro
Protection - Windows 8 Enterprise
System FEP 2010 with Update Rollup 1 will update the client support matrix to include
Center 2012 the following operating systems:
Forefront - Windows 8 Pro
Endpoint - Windows 8 Enterprise
Protection - Windows Server 2012 Standard

Product Notes
Forefront TMG is supported to run only on Windows Server 2008 and Windows Server 2008
Threat R2. For more information, see System requirements for Forefront TMG.
Management
Gateway
(TMG)
Windows This release of WSUS already supports Windows 8-based computers or Windows
Server Server 2012-based computers as clients.
Update
Services
Windows Update KB article 2734608 lets servers that are running Windows Server
Server Update Services (WSUS) 3.0 SP2 provide updates to computers that are running
Update Windows 8 or Windows Server 2012: Note: Customers with standalone WSUS 3.0
Services 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 Windows Server 2012 Standard and Datacenter are supported for the following
2013 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 Source: Exchange 2010 Service Pack 3

2010
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 Source: KB 2681562

2012
SQL Server 2012 RTM is supported on Windows Server 2012.

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

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

2005
Not supported to install on Windows Server 2012.
Known issues
The following table lists known issues related to AD DS installation:
KB article number and Technology area Issue/description

title impacted
2830145 : SID S-1-18-1 AD DS Applications that map SID S-1-18-1 and SID S-
and SID S-1-18-2 can't be Management/App 1-18-2, which are new in Windows Server 2012,
mapped on Windows 7 or compat may fail because the SIDs can't be resolved on
Windows Server 2008 R2- Windows 7-based or Windows Server 2008 R2-
based computers in a based computers. To resolve this issue, install
domain environment the hotfix on the Windows 7-based and
Windows Server 2008 R2-based computers in
the domain.
2737129 : Group Policy AD DS Installation Adprep /domainprep /gpprep isn't

preparation isn't automatically run as part of installing the first
performed when you DC that runs Windows Server 2012 in a domain.
automatically prepare an If it has never been run previously in the
existing domain for domain, it must be run manually.
Windows Server 2012
2737416: Windows AD DS Installation Warnings can appear during prerequisite

PowerShell-based domain validation and then reappear during the
controller deployment installation.
repeats warnings
2737424: "Format of the AD DS Installation This error appears if you're removing the last
specified domain name is DC in a domain where pre-created RODC
invalid" error when you accounts still exist. This affects Windows Server
try to remove Active 2012, Windows Server 2008 R2, and Windows
Directory Domain Server 2008.
Services from a domain
controller
2737463 : Domain AD DS Installation A DC doesn't start because an administrator

controller doesn't start, used Dism.exe, Pkgmgr.exe, or Ocsetup.exe to
c00002e2 error occurs, or remove the DirectoryServices-DomainController
"Choose an option" is role.
displayed
title impacted
2737535: Install- AD DS Installation You can receive an error when you try to attach
AddsDomainController a server to an RODC account if you specify
cmdlet returns parameter arguments that are already populated on the
set error for RODC pre-created RODC account.
2737560: "Unable to AD DS Installation Prerequisite check fails when you configure the
perform Exchange first Windows Server 2012 DC in an existing
schema conflict check" domain because DCs are missing the
error, and prerequisites SeServiceLogonRight for Network Service or
check fails because WMI or DCOM protocols are blocked.
2737797: AD DS Installation The -WhatIf parameter shows DNS server won't

AddsDeployment module be installed but it will be.
with the -Whatif
argument shows incorrect
DNS results
2737807: The Next button AD DS Installation The Next button is disabled on the Domain
isn't available on the Controller Options page because the IP address
Domain Controller of the target DC doesn't map to an existing
Options page subnet or site, or because the DSRM password
isn't typed and confirmed correctly.
2737935 : Active AD DS Installation The installation hangs because the local

Directory installation stalls Administrator password matches the domain
at the "Creating the NTDS Administrator password, or because networking
settings object" stage problems prevent critical replication from
completing.
2738060: "Access is AD DS Installation You receive the error when you run Install-
denied" error message ADDSDomain with the Invoke-Command
when you create a child cmdlet if the DNSDelegationCredential has a
domain remotely by using bad password.
Install-AddsDomain
2738697 : "The server AD DS Installation You receive this error when you try to install AD
isn't operational" domain DS on a workgroup computer because NTLM
controller configuration authentication is disabled.
error when you configure
a server by using Server
Manager
2738746 : You receive AD DS Installation When you log on using a local Administrator
access denied errors after account rather than the built-in Administrator
you log on to a local account and then create a new domain, the
administrator domain account isn't added to the Domain Admins
account group.
title impacted
2743345 : "The system AD DS Installation You receive this error when you run adprep
can't find the file /gpprep because the infrastructure master is
specified" Adprep implements a disjoint namespace
/gpprep error, or tool
crashes
2753560: ADMT 3.2 and ADMT ADMT 3.2 can't be installed on Windows Server
PES 3.1 installation errors 2012 by design.
on Windows Server 2012
2750857 : DFS DFS Replication DFS Replication diagnostic report doesn't

Replication diagnostic display correctly because of changes in Internet
reports don't display Explorer 10.
correctly in Internet
Explorer 10
2741537: Remote Group Group Policy This is due to scheduled tasks run in the context
Policy updates are visible of each user who is logged on. The Windows
to users Task Scheduler design requires an interactive
prompt in this scenario.
2741591: ADM files aren't Group Policy GP replication can report "replication in
present in SYSVOL in the progress" because GPMC Infrastructure Status
GPMC Infrastructure doesn't follow customized filtering rules.
Status option
2737880 : "The service Virtual DC cloning You receive this error while installing or
can't be started" error removing AD DS, or cloning, because the DS
during AD DS Role Server service is disabled.
configuration
2742836: Two DHCP Virtual DC cloning This happens because the cloned domain
leases are created for controller received a lease before cloning and
each domain controller again when cloning was complete.
when you use the VDC
cloning feature
2742844: Domain Virtual DC cloning The cloned DC starts in DSRM because cloning
controller cloning fails failed for any of a variety of reasons listed in the
and the server restarts in KB article.
DSRM in Windows Server
2012
2742874: Domain Virtual DC cloning Some three-part SPNs aren't recreated on the
controller cloning doesn't cloned DC because of a limitation of the
re-create all service domain rename process.
principal names
title impacted
2742908 : "No logon Virtual DC cloning You receive this error when you try to log on
servers are available" after cloning a virtualized DC because cloning
error after cloning failed and the DC is started in DSRM. Log on as
domain controller .\administrator to troubleshoot the cloning
failure.
2742916: Domain Virtual DC cloning Cloning fails because the PDC emulator hasn't
controller cloning fails performed inbound replication of the domain
with error 8610 in partition, likely because the role was transferred.
dcpromo.log
2742927: "Index was out Virtual DC cloning You receive the error after you run New-
of range" New- ADDCCloneConfigFile cmdlet while cloning
AdDcCloneConfig error virtual DCs, either because the cmdlet wasn't
run from an elevated command prompt or
because your access token doesn't contain the
Administrators group.
2742959: Domain Virtual DC cloning Cloning failed because an invalid clone name or
controller cloning fails a duplicate NetBIOS name was specified.
with error 8437: "invalid
parameter was specified
for this replication
operation"
2742970: DC Cloning fails Virtual DC cloning The cloned virtual DC boots in Directory
with no DSRM, duplicate Services Repair Mode (DSRM), using a duplicate
source and clone name as the source DC because the
computer DCCloneConfig.xml file wasn't created in the
correct location or because the source DC was
rebooted before cloning.
2743278: Domain Virtual DC cloning The cloned DC boots into DSRM because only
controller cloning error one WINS server was specified. If any WINS
0x80041005 server is specified, both Preferred and Alternate
WINS servers must be specified.
2745013: "Server is not Virtual DC cloning You receive this error after you run the New-
operational" error ADDCCloneConfigFile cmdlet because the
message if you run New- server can't contact a global catalog server.
AdDcCloneConfigFile in
Windows Server 2012
2747974: Domain Virtual DC cloning Event ID 2224 incorrectly states that managed
controller cloning event service accounts must be removed before
2224 provides incorrect cloning. Standalone MSAs must be removed but
guidance Group MSAs don't block cloning.
title impacted
2748266: You can't unlock BitLocker You receive an "Application not found" error
a BitLocker-encrypted when you try to unlock a drive on a computer
drive after you upgrade that was upgraded from Windows 7.
to Windows 8
See Also
Windows Server 2012 Evaluation Resources
Windows Server 2012 Evaluation Guide
Install and Deploy Windows Server 2012
AD DS Simplified Administration
Article • 06/08/2022
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).

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

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

Windows 2000 Active Directory introduced the RID Master, which issues pools of relative
identifiers to domain controllers, in order to create security identifiers (SIDs) of security
trustees like users, groups, and computers. By default, this global RID space is limited to
230 (or 1,073,741,823) total SIDs created in a domain. SIDs cannot return to the pool or
reissue. Over time, a large domain may begin to run low on RIDs, or accidents may lead
to unnecessary RID depletion and eventual exhaustion.
Windows Server 2012 addresses a number of RID issuance and management issues
uncovered by customers and Microsoft Customer Support as AD DS matured since the
creation of the first Active Directory domains in 1999. These include:
Periodic RID consumption warnings are written to the event log

Events log when an administrator invalidates a RID pool
A maximum cap on the RID policy RID Block Size is now enforced
Artificial RID ceilings are now enforced and logged when the global RID space is
low, allowing an administrator to take action before the global space is exhausted
The global RID space can now be increased by one bit, doubling the size to 231
(2,147,483,648 SIDs)
For more information about RIDs and the RID Master, review How Security Identifiers
Work.
AD DS Role Deployment and Management

Architecture
Server Manager and ADDSDeployment Windows PowerShell rely on the following core
assemblies for functionality when deploying or managing the AD DS role:
Microsoft.ADroles.Aspects.dll
Microsoft.ADroles.Instrumentation.dll
Microsoft.ADRoles.ServerManager.Common.dll
Microsoft.ADRoles.UI.Common.dll
Microsoft.DirectoryServices.Deployment.Types.dll
Microsoft.DirectoryServices.ServerManager.dll
Addsdeployment.psm1
Addsdeployment.psd1
Both rely on Windows PowerShell and its remote invoke-command for remote role
installation and configuration.
Windows Server 2012 also refactors a number of previous promotion operations out of
LSASS.EXE, as part of:
DS Role Server Service (DsRoleSvc)

DSRoleSvc.dll (loaded by DsRoleSvc service)
This service must be present and running in order to promote, demote, or clone virtual
domain controllers. AD DS role installation adds this service and sets a start type of
Manual, by default. Do not disable this service.
ADPrep and Prerequisite Checking Architecture

Adprep no longer requires running on the schema master. It can be run remotely from a
computer that runs Windows Server 2008 x64 or later.
７ Note
Adprep uses LDAP to import Schxx.ldf files and does not automatically reconnect if
the connection to the schema master is lost during import. As part of the import
process, the schema master is set in a specific mode and automatic reconnection is
disabled because if LDAP reconnects after the connection is lost, the re-established
connection would not be in the specific mode. In that case, the schema would not
be updated correctly.
Prerequisite checking ensures that certain conditions are true. These conditions are
required for successful AD DS installation. If some required conditions are not true, they
can be resolved before continuing the installation. It also detects that a forest or domain
are not yet prepared, so that the Adprep deployment code runs automatically.
ADPrep Executables, DLLs, LDFs, files

ADprep.dll
Ldifde.dll
Csvde.dll
Sch14.ldf - Sch56.ldf
Schupgrade.cat
*dcpromo.csv
The AD Preparation code formerly housed in ADprep.exe is refactored into adprep.dll.

This allows both ADPrep.exe and the ADDSDeployment Windows PowerShell module to
use the library for the same tasks and have the same capabilities. Adprep.exe is included
with the installation media but automated processes do not call it directly - only an
Administrator runs it manually. It can only run on Windows Server 2008 x64 and later
operating systems. Ldifde.exe and csvde.exe also have refactored versions as DLLs that
are loaded by the preparation process. Schema extension still uses the signature-verified
LDF files, like in previous operating system versions.
） Important
There is no 32-bit Adprep32.exe tool for Windows Server 2012. You must have at
least one Windows Server 2008 x64, Windows Server 2008 R2, or Windows Server
2012 computer, running as a domain controller, member server, or in a workgroup,
to prepare the forest and domain. Adprep.exe does not run on Windows Server
2003 x64.
Prerequisite Checking
The prerequisite checking system built into ADDSDeployment Windows PowerShell
managed code works in different modes, based on the operation. The tables below
describe each test, when it is used, and an explanation of how and what it validates.
These tables may be useful if there are issues where the validation fails and the error is
not sufficient to troubleshoot the problem.
These tests log in the DirectoryServices-Deployment operational event log channel

under the Task Category Core, always as Event ID 103.
Prerequisite Windows PowerShell

There are ADDSDeployment Windows PowerShell cmdlets for all of the domain
controller deployment cmdlets. They have approximately the same arguments as their
associated cmdlets.
Test-ADDSDomainControllerInstallation
Test-ADDSDomainControllerUninstallation
Test-ADDSDomainInstallation
Test-ADDSForestInstallation
Test-ADDSReadOnlyDomainControllerAccountCreation
There is no need to run these cmdlets, ordinarily; they already automatically execute
with the deployment cmdlets by default.
Prerequisite Tests
Test Name Protocols Explanation and notes

used
VerifyAdminTrusted LDAP Validates that you have the "Enable computer and user
ForDelegationProvider 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
VerifyADPrep LDAP Discovers and contacts the Schema Master using the
Prerequisites (forest) 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 Infrastructure Master using

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

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

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

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

GroupMembership RPC over group and has the Manage Audit and Security Event Logs
SMB (SesScurityPrivilege) privilege on the existing domain
(LSARPC) controllers
VerifyInitSync LDAP Validate that the Schema Master has replicated at least
AfterReboot once since it restarted by setting a dummy value on
rootDSE attribute becomeSchemaMaster
VerifySFUHotFix LDAP Validate the existing forest schema does not contain
Applied known problem SFU2 extension for the UID attribute with
OID 1.2.840.113556.1.4.7000.187.102
(Impact of Schema Changes - Win32 apps)
VerifyExchange LDAP, Validate the existing forest schema does not still contain
SchemaFixed WMI, problem Exchange 2000 extensions ms-Exch-Assistant-
DCOM, Name, ms-Exch-LabeledURI, and ms-Exch-House-
RPC Identifier (About schema extensions - Configuration
Manager)
VerifyWin2KSchema LDAP Validate the existing forest schema has consistent (not
Consistency incorrectly modified by a third party) core attributes and
classes.
DCPromo DRSR Validate the command-line syntax passed to the

over RPC, promotion code and test promotion. Validate the forest
LDAP, or domain does not already exist if creating new.
DNS
RPC over
SMB
(SAMR)
VerifyOutbound LDAP, Validate the existing domain controller specified as the

ReplicationEnabled DRSR replication partner has outbound replication enabled by
over SMB, checking the NTDS Settings object's options attribute for
RPC over NTDSDSA_OPT_DISABLE_OUTBOUND_REPL (0x00000004)
SMB
(LSARPC)
used
VerifyMachineAdmin DRSR Validate the safe mode password set for DSRM meets
Password over RPC, domain complexity requirements.
LDAP,
DNS
RPC over
SMB
(SAMR)
VerifySafeModePassword N/A Validate the local Administrator password set meets

computer security policy complexity requirements.
Simplified Administration Appendix
Article • 05/17/2023
Server Manager Add Servers Dialog (Active Directory)
Server Manager Remote Server Status
Windows PowerShell Module Loading
RID Issuance Hotfixes for Previous Operating Systems
Ntdsutil.exe Install from Media Changes
Server Manager Add Servers Dialog (Active

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

Server Manager tests remote server accessibility using Address Routing Protocol. Any
servers not responding to ARP requests aren't 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 can't fully
manage the server.
Windows PowerShell Module Loading

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

Systems
See An update is available to detect and prevent too much consumption of the global
RID pool on a domain controller that is running Windows Server 2008 R2 .
Ntdsutil.exe Install from Media Changes
Windows Server 2012 adds two additional options to the Ntdsutil.exe command-line
tool for the IFM (IFM Media Creation) menu. These allow you to create IFM stores
without first performing an offline defrag of the exported NTDS.DIT database file. When
disk space isn't a premium, this saves time creating the IFM.
The following table describes the two new menu items:
Menu Item Explanation
Create Full NoDefrag Create IFM media without defragmenting for a full AD DC or an AD/LDS
%s instance into folder %s
Create Sysvol Full Create IFM media with SYSVOL and without defragmenting for a full AD
NoDefrag %s DC into folder %s
Install Active Directory Domain Services
(Level 100)
Article • 04/28/2023
This topic explains how to install AD DS in Windows Server 2012 by using any of the
following methods:
Credential requirements to run Adprep.exe and install Active Directory Domain

Services
Installing AD DS by Using Windows PowerShell
Installing AD DS by using Server Manager
Performing a Staged RODC Installation using the Graphical User Interface
Credential requirements to run Adprep.exe and

install Active Directory Domain Services
The following credentials are required to run Adprep.exe and install AD DS.
To install a new forest, you must be logged on as the local Administrator for the
computer.
To install a new child domain or new domain tree, you must be logged on as a
member of the Enterprise Admins group.
To install an additional domain controller in an existing domain, you must be a

member of the Domain Admins group.
７ Note
If you do not run adprep.exe command separately and you are installing the
first domain controller that runs Windows Server 2012 in an existing domain
or forest, you will be prompted to supply credentials to run Adprep
commands. The credential requirements are as follows:
To introduce the first Windows Server 2012 domain controller in the forest,
you need to supply credentials for a member of Enterprise Admins group,
the Schema Admins group, and the Domain Admins group in the domain
that hosts the schema master.
To introduce the first Windows Server 2012 domain controller in a domain,

you need to supply credentials for a member of the Domain Admins group.
To introduce the first read-only domain controller (RODC) in the forest, you
need to supply credentials for a member of the Enterprise Admins group.
７ Note
If you have already run adprep /rodcprep in Windows Server 2008 or

Windows Server 2008 R2, you do not need to run it again for Windows
Server 2012.
Installing AD DS by Using Windows PowerShell

Beginning with Windows Server 2012, you can install AD DS using Windows PowerShell.
Dcpromo.exe is deprecated beginning with Windows Server 2012, but you can still run
dcpromo.exe by using an answer file (dcpromo /unattend:<answerfile> or dcpromo
/answer:<answerfile>). The ability to continue running dcpromo.exe with an answer file
provides organizations that have resources invested in existing automation time to
convert the automation from dcpromo.exe to Windows PowerShell. For more
information about running dcpromo.exe with an answer file, see
https://support.microsoft.com/kb/947034 .
For more information about removing AD DS using Windows PowerShell, see Remove
AD DS using Windows PowerShell .
Start with adding the role using Windows PowerShell. This command installs the AD DS
server role and installs the AD DS and AD LDS server administration tools, including
GUI-based tools such as Active Directory Users and Computers and command-line tools
such as dcdia.exe. Server administration tools are not installed by default when you use
Windows PowerShell. You need to specify "IncludeManagementTools to manage the
local server or install Remote Server Administration Tools to manage a remote server.
Install-WindowsFeature -name AD-Domain-Services -IncludeManagementTools
<<Windows PowerShell cmdlet and arguments>>
There is no reboot required until after the AD DS installation is complete.
You can then run this command to see the available cmdlets in the ADDSDeployment
module.
Get-Command -Module ADDSDeployment
To see the list of arguments that can be specified for a cmdlets and syntax:
Get-Help <cmdlet name>
For example, to see the arguments for creating an unoccupied read-only domain
controller (RODC) account, type
Get-Help Add-ADDSReadOnlyDomainControllerAccount
Optional arguments appear in square brackets.
You can also download the latest Help examples and concepts for Windows PowerShell
cmdlets. For more information, see about_Updatable_Help.
You can run Windows PowerShell cmdlets against remote servers:
In Windows PowerShell, use Invoke-Command with the ADDSDeployment cmdlet.

For example, to install AD DS on a remote server named ConDC3 in the
contoso.com domain, type:
Invoke-Command { Install-ADDSDomainController -DomainName contoso.com -

Credential (Get-Credential) } -ComputerName ConDC3
-or-
In Server Manager, create a server group that includes the remote server. Right-
click the name of the remote server and click Windows PowerShell.
The next sections explain how to run ADDSDeployment module cmdlets to install AD
DS.
ADDSDeployment cmdlet arguments
Specifying Windows PowerShell Credentials
Using test cmdlets
Installing a new forest root domain using Windows PowerShell
Installing a new child or tree domain using Windows PowerShell
Installing an additional (replica) domain controller using Windows PowerShell
ADDSDeployment cmdlet arguments

The following table lists arguments for the ADDSDeployment cmdlets in Windows
PowerShell. Arguments in bold are required. Equivalent arguments for dcpromo.exe are
listed in parentheses if they are named different in Windows PowerShell.
Windows PowerShell switches accept $TRUE or $FALSE arguments. Arguments that are
$TRUE by default do not need to be specified.
To override default values, you can specify the argument with a $False value. For
example, because -InstallDNS is automatically run for a new forest installation if it is not
specified, the only way to prevent DNS installation when you install a new forest is to
use:
-InstallDNS:$False
Similarly, because -InstallDNS has a default value of $False if you install a domain
controller in an environment that does not host Windows Server DNS server, you need
to specify the following argument in order to install DNS server:
-InstallDNS:$True
Argument Description
ADPrepCredential <PS Credential> Note: Required Specifies the account with Enterprise
if you are installing the first Windows Server 2012 Admins and Schema Admins group
domain controller in a domain or forest and the membership that can prepare the forest,
credentials of the current user are insufficient to according to the rules of Get-Credential
perform the operation. and a PSCredential object.
If no value is specified, the value of the

credential argument is used.
AllowDomainControllerReinstall Specifies whether to continue installing this

writable domain controller, although
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: Specifies the application directory

There is no equivalent option in the UI. If you install partitions to replicate. This argument is
using the UI, or using IFM, then all application applied only when you specify the -
partitions will be replicated. InstallationMediaPath argument to install
from media (IFM). By default, all application
partitions will replicate based on their own
scopes.

example:
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
argument when you run the Add- delegation that references the new DNS
ADDSReadOnlyDomainController cmdlet. server that you are installing along with the
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 <PS Credential> Note: Required only if Specifies the domain account that can
the credentials of the current user are insufficient to logon to the domain, according to the rules
perform the operation. 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 <string> Specifies the fully qualified, non"Universal

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

Important: While you can store the AD DS
database and log files on volume formatted
with Resilient File System (ReFS), there are
no specific benefits for hosting AD DS on
ReFS, other than the normal benefits of
resiliency you get for hosting any data on
ReFS.
DelegatedAdministratorAccountName <string> 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.
example:
Code -
-DenyPasswordReplicationAccountName
"RegionalAdmins","AdminPCs"
DnsDelegationCredential <PS Credential> Note: Specifies the user name and password for
You cannot specify this argument when you run the creating DNS delegation, according to the
Add-ADDSReadOnlyDomainController cmdlet. rules of Get-Credential and a PSCredential
object.
DomainMode <DomainMode> {Win2003 | Specifies the domain functional level

Win2008 | Win2008R2 | Win2012 | Win2012R2} during the creation of a new domain.
Or The domain functional level cannot be
lower than the forest functional level, but it
DomainMode <DomainMode> {2 | 3 | 4 | 5 | 6} can be higher.
The default value is automatically

computed and set to the existing forest
functional level or the value that is set for -
ForestMode.
DomainName Specifies the FQDN of the domain in which

you want to install an additional domain
Required for Install-ADDSForest and Install- controller.
ADDSDomainController cmdlets.
DomainNetbiosName <string> Use with Install-ADDSForest. Assigns a

NetBIOS name to the new forest root
Required for Install-ADDSForest if FQDN prefix domain.
name is longer than 15 characters.
DomainType <DomainType> {ChildDomain | Indicates the type of domain that you want
TreeDomain} or {child | tree} 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 <ForestMode> {Win2003 | Win2008 | Specifies the forest functional level when
Win2008R2 | Win2012 | Win2012R2} you create a new forest.
Or The default value is Win2012.
ForestMode <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 <string> Specifies the fully qualified, non-UNC path

to a directory on a fixed disk of the local
computer that contains the domain log
files, for example, C:\Windows\Logs.
The default is %SYSTEMROOT%\NTDS.

Important: Do not store the Active
Directory log files on a data volume
formatted with Resilient File System (ReFS).
MoveInfrastructureOperationMasterRoleIfNecessary Specifies whether to transfer the

infrastructure master operations master
role (also known as flexible single master
operations or FSMO) to the domain
controller that you are creating "in case it is
currently hosted on a global catalog server"
and you do not plan to make the domain
controller that you are creating a global
catalog server. Specify this parameter to
transfer the infrastructure master role to
the domain controller that you are creating
in case the transfer is needed; in this case,
specify the NoGlobalCatalog option if you
want the infrastructure master role to
remain where it currently is.
NewDomainName <string> Note: Required only Specifies the single domain name for the
for Install-ADDSDomain. new domain.
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 <string> Use with Install-ADDSDomain. Assigns a

NetBIOS name to the new domain. The
Required for Install-ADDSDomain if FQDN prefix default value is derived from the value of
name is longer than 15 characters. "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 <string> Note: Required for Specifies the FQDN of an existing parent
Install-ADDSDomain cmdlet domain. You use 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 <string> Indicates the FQDN of the partner domain

controller from which you replicate the
domain information. The default is
automatically computed.
SafeModeAdministratorPassword <securestring> 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 <string> Specifies the site where the domain

controller will be installed. There is no
Required for the Add- sitename argument when you run Install-
addsreadonlydomaincontrolleraccount cmdlet 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 <string> 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 <string> Specifies the fully qualified, non-UNC path

to a directory on a fixed disk of the local
computer, for example,
C:\Windows\SYSVOL.
The default is %SYSTEMROOT%\SYSVOL.

Important: SYSVOL cannot be stored on a
data volume formatted with Resilient File
System (ReFS).
SkipPreChecks Does not run the prerequisite checks

before starting installation. It is not
advisable to use this setting.
WhatIf Shows what would happen if the cmdlet

runs. The cmdlet is not run.
Specifying Windows PowerShell Credentials

You can specify credentials without revealing them in plain text on screen by using Get-
credential.
The operation for the -SafeModeAdministratorPassword and
LocalAdministratorPassword arguments is special:
If not specified as an argument, the cmdlet prompts you to enter and confirm a
masked password. This is the preferred usage when running the cmdlet
interactively.
If specified with a value, the value must be a secure string. This is not the preferred
usage when running the cmdlet interactively.
For example, you can manually prompt for a password by using the Read-Host cmdlet
to prompt the user for a secure string
-SafeModeAdministratorPassword (Read-Host -Prompt "DSRM Password:" -

AsSecureString)
２ Warning
As the previous option does not confirm the password, use extreme caution: the
password is not visible.
You can also provide a secure string as a converted clear-text variable, although this is
highly discouraged:
-SafeModeAdministratorPassword (ConvertTo-SecureString "Password1" -

AsPlainText -Force)
２ Warning
Providing or storing a clear text password is not recommended. Anyone running

this command in a script or looking over your shoulder knows the DSRM password
of that domain controller. With that knowledge, they can impersonate the domain
controller itself and elevate their privilege to the highest level in an Active Directory
forest.
Using test cmdlets

Each ADDSDeployment cmdlet has a corresponding test cmdlet. The test cmdlets runs
only the prerequisite checks for the installation operation; no installation settings are
configured. The arguments for each test cmdlet are the same as for the corresponding
installation cmdlet, but "SkipPreChecks is not available for test cmdlets.
Test cmdlet Description
Test-ADDSForestInstallation Runs the prerequisites for installing a new

Active Directory forest.
Test-ADDSDomainInstallation Runs the prerequisites for installing a new

domain in Active Directory.
Test-ADDSDomainControllerInstallation Runs the prerequisites for installing a domain

controller in Active Directory.
Test- Runs the prerequisites for adding a read-only

ADDSReadOnlyDomainControllerAccountCreation 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 AdminUser
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\AdminUser) -
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 install AD DS by using Server Manager
1. In Server Manager, click Manage and click Add Roles and Features to start the
Add Roles Wizard.
3. On the Select installation type page, click Role-based or feature-based

installation and then click Next.
4. On the Select destination server page, click Select a server from the server pool,
click the name of the server where you want to install AD DS and then click Next.
To select remote servers, first create a server pool and add the remote servers to it.
For more information about creating server pools, see Add Servers to Server
Manager.
5. On the Select server roles page, click Active Directory Domain Services, then on
the Add Roles and 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 Directory Domain Services page, review the information and then
click Next.
9. On the Results page, verify that the installation succeeded, and click Promote this
server to a domain controller to start the Active Directory Domain Services
Configuration Wizard.
） Important
If you close Add Roles Wizard at this point without starting the Active
Directory Domain Services Configuration Wizard, you can restart it by clicking
Tasks in Server Manager.
10. On the Deployment Configuration page, choose one of the following options:
If you are installing an additional domain controller in an existing domain,

click Add a domain controller to an existing domain, and type the name of
the domain (for example, emea.corp.contoso.com) or click Select... to choose
a domain, and credentials (for example, specify an account that is a member
of the Domain Admins group) and then click Next.
７ Note
The name of the domain and current user credentials are supplied by
default only if the machine is domain-joined and you are performing a
local installation. If you are installing AD DS on a remote server, you
need to specify the credentials, by design. If current user credentials are
not sufficient to perform the installation, click Change... in order to
specify different credentials.
For more information, see Install a Replica Windows Server 2012 Domain
Controller in an Existing Domain (Level 200).
If you are installing a new child domain, click Add a new domain to an
existing forest, for Select domain type, select Child Domain, type or browse
to the name of the parent domain DNS name (for example,
corp.contoso.com), type the relative name of the new child domain (for
example emea), type credentials to use to create the new domain, and then
click Next.
For more information, see Install a New Windows Server 2012 Active
Directory Child or Tree Domain (Level 200).
If you are installing a new domain tree, click Add new domain to an existing
forest, for Select domain type, choose Tree Domain, type the name of the
root domain (for example, corp.contoso.com), type the DNS name of the new
domain (for example, fabrikam.com), type credentials to use to create the
new domain, and then click Next.
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).
Directory Forest (Level 200).
11. On the Domain Controller Options page, choose one of the following options:
If you are creating a new forest or domain, select the domain and forest
functional levels, click Domain Name System (DNS) server, specify the DSRM
password, and then click Next.
If you are adding a domain controller to an existing domain, click Domain

Name System (DNS) server, Global Catalog (GC), or Read Only Domain
Controller (RODC) as needed, choose the site name, and type the DSRM
password and then click Next.
For more information about which options on this page are available or not
available under different conditions, see Domain Controller Options.
12. On the DNS Options page (which appears only if you install a DNS server), click
Update DNS delegation as needed. If you do, provide credentials that have
permission to create DNS delegation records in the parent DNS zone.
If a DNS server that hosts the parent zone cannot be contacted, the Update DNS
Delegation option is not available.
For more information about whether you need to update the DNS delegation, see
Understanding Zone Delegation. If you attempt to update the DNS delegation and
encounter an error, see DNS Options.
13. On the RODC Options page (which appears only if you install an RODC), specify
the name of a group or user who will manage the RODC, add accounts to or
remove accounts from the Allowed or Denied password replication groups, and
then click Next.
For more information, see Password Replication Policy.
14. On the Additional Options page, choose one of the following options:
If you are creating a new domain, type a new NetBIOS name or verify the
default NetBIOS name of the domain, and then click Next.
If you are adding a domain controller to an existing domain, select the

domain controller that you want to replicate the AD DS installation data from
(or allow the wizard to select any domain controller). If you are installing from
media, click Install from media path type and verify the path to the
installation source files, and then click Next.
You cannot use install from media (IFM) to install the first domain controller
in a domain. IFM does not work across different operating system versions. In
other words, in order to install an additional domain controller that runs
Windows Server 2012 by using IFM, you must create the backup media on a
Windows Server 2012 domain controller. For more information about IFM,
see Installing an Additional Domain Controller by Using IFM.
15. On the Paths page, type the locations for the Active Directory database, log files,
and SYSVOL folder (or 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
controller. The server will be restarted automatically to complete the AD DS
installation.
Performing a Staged RODC Installation using

the Graphical User Interface
A staged RODC installation allows you to create an RODC in two stages. In the first
stage, a member of the Domain Admins group creates an RODC account. In the second
stage, a server is attached to the RODC account. The second stage can be completed by
a member of the Domain Admins group or a delegated domain user or group.
To create an RODC account by using the Active Directory

management tools
1. You can create the RODC account using Active Directory Administrative Center or
Active Directory Users and Computers.
a. Click Start, click Administrative Tools, and then click Active Directory
Administrative Center.
b. In the navigation pane (left pane), click the name of the domain.
c. In the Management list (center pane), click the Domain Controllers OU.
d. In the Tasks Pane (right pane), click Pre-create a read-only domain controller
account.
-Or-
a. Click Start, click Administrative Tools, and then click Active Directory Users and
Computers.
b. Either right-click the Domain Controllers organizational unit (OU) or click the
Domain Controllers OU, and then click Action.
c. Click Pre-create Read-only Domain Controller account.
2. On the Welcome to the Active Directory Domain Services Installation Wizard

page, if you want to modify the default the Password Replication Policy (PRP),
select Use advanced mode installation, and then click Next.
3. On the Network Credentials page, under Specify the account credentials to use
to perform the installation, click My current logged on credentials or click
Alternate credentials, and then click Set. In the Windows Security dialog box,
provide the user name and password for an account that can install the additional
domain controller. To install an additional domain controller, you must be a
member of the Enterprise Admins group or the Domain Admins group. When you
are finished providing credentials, click Next.
4. On the Specify the Computer Name page, type the computer name of the server
that will be the RODC.
5. On the Select a Site page, select a site from the list or select the option to install
the domain controller in the site that corresponds to the IP address of the
computer on which you are running the wizard, and then click Next.
6. On the Additional Domain Controller Options page, make the following

selections, and then click Next:
DNS server: This option is selected by default so that your domain controller
can function as a Domain Name System (DNS) server. If you do not want the
domain controller to be a DNS server, clear this option. However, if you do
not install the DNS server role on the RODC and the RODC is the only domain
controller in the branch office, users in the branch office will not be able to
perform name resolution when the wide area network (WAN) to the hub site
is offline.
Global catalog: This option is selected by default. It adds the global catalog,
read-only directory partitions to the domain controller, and it enables global
catalog search functionality. If you do not want the domain controller to be a
global catalog server, clear this option. However, if you do not install a global
catalog server in the branch office or enable universal group membership
caching for the site that includes the RODC, users in the branch office will not
be able to log on to the domain when the WAN to the hub site is offline.
Read-only domain controller. When you create an RODC account, this

option is selected by default and you cannot clear it.
7. If you selected the Use advanced mode installation check box on the Welcome
page, the Specify the Password Replication Policy page appears. By default, no
account passwords are replicated to the RODC, and security-sensitive accounts
(such as members of the Domain Admins group) are explicitly denied from ever
having their passwords replicated to the RODC.
To add other accounts to policy, click Add, then click Allow passwords for the
account to replicate to this RODC or click Deny passwords for the account from
replicating to this RODC and then select the accounts.
When complete (or to accept the default setting), click Next.
8. On the Delegation of RODC Installation and Administration page, type the name
of the user or the group who will attach the server to the RODC account that you
are creating. You can type the name of only one security principal.
To search the directory for a specific user or group, click Set. In Select User or
Group, type the name of the user or group. We recommend that you delegate
RODC installation and administration to a group.
This user or group will also have local administrative rights on the RODC after the
installation. If you do not specify a user or group, only members of the Domain
Admins group or the Enterprise Admins group will be able to attach the server to
the account.
When you are finished, click Next.
9. On the Summary page, review your selections. Click Back to change any selections,
if necessary.
To save the settings that you selected to an answer file that you can use to
automate subsequent AD DS operations, click Export settings. Type a name for
your answer file, and then click Save.
When you are sure that your selections are accurate, click Next to create the RODC
account.
10. On the Completing the Active Directory Domain Services Installation Wizard
page, click Finish.
After an RODC account is created, you can attach a server to account to complete the
RODC installation. This second stage can be completed in the branch office where the
RODC will be located. The server where you perform this procedure must not be joined
to the domain. Beginning in Windows Server 2012, you use the Add Roles Wizard in
Server Manager to attach a server to an RODC account.
To attach a server to an RODC account using Server Manager

1. Log on as local Administrator.
2. In Server Manager, click Add roles and features.

installation and then click Next.
click the name of the server where you want to install AD DS and then click Next.
6. On the Select server roles page, click Active Directory Domain Services, click Add
Features and then click Next.
7. On the Select features page, select any additional features that you want to install
and click Next.
8. On the Active Directory Domain Services page, review the information and then
click Next.

10. On the Results page, verify Installation succeeded, and click Promote this server
to a domain controller to start the Active Directory Domain Services Configuration
Wizard.
） Important
If you close Add Roles Wizard at this point without starting the Active
Directory Domain Services Configuration Wizard, you can restart it by clicking
Tasks in Server Manager.
(media/Install-Active-Directory-Domain-Services--Level-100-/ADDS_SMI_Tasks.gif)
11. On the Deployment Configuration page, click Add a domain controller to an

existing domain, type the name of the domain (for example, emea.contoso.com)
and credentials (for example, specify an account that is delegated to manage and
install the RODC), and then click Next.
12. On the Domain Controller Options page, click Use existing RODC account, type
and confirm the Directory Services Restore Mode password, and then click Next.
13. On the Additional Options page, if you are installing from media, click Install from
media path type and verify the path to the installation source files, select the
domain controller that you want to replicate the AD DS installation data from (or
allow the wizard to select any domain controller) and then click Next.
14. On the Paths page, type the locations for the Active Directory database, log files,
and SYSVOL folder, or accept default locations, and then click Next.
15. On the Review Options page, confirm your selections, click View Script to export
the settings to a Windows PowerShell script, and then click Next.
16. On the Prerequisites Check page, confirm that prerequisite validation completed
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)
Active Directory Forest (Level 200)
Article • 04/21/2023
This topic explains the new Windows Server 2012 Active Directory Domain Services
domain controller promotion feature at an introductory level. In Windows Server 2012,
AD DS replaces the Dcpromo tool with a Server Manager and Windows PowerShell-
based deployment system.
Active Directory Domain Services Simplified Administration
Technical Overview
Deploying a Forest with Windows PowerShell
Active Directory Domain Services Simplified

Administration
Windows Server 2012 introduces the next generation of Active Directory Domain
Services Simplified Administration, and is the most radical domain re-envisioning since
Windows 2000 Server. AD DS Simplified Administration takes lessons learned from
twelve years of Active Directory and makes a more supportable, more flexible, more
intuitive administrative experience for architects and administrators. This meant creating
new versions of existing technologies as well as extending the capabilities of
components released in Windows Server 2008 R2.
What Is AD DS Simplified Administration?

AD DS Simplified Administration is a reimagining of domain deployment. Some of those
features include:
AD DS role deployment is now part of the new Server Manager architecture and
allows remote installation.
The AD DS deployment and configuration engine is now Windows PowerShell,
even when using a graphical setup.
Promotion now includes prerequisite checking that validates forest and domain
readiness for the new domain controller, lowering the chance of failed promotions.
The Windows Server 2012 forest functional level does not implement new features
and domain functional level is required only for a subset of new Kerberos features,
relieving administrators of the frequent need for a homogenous domain controller
environment.
Purpose and Benefits

These changes may appear more complex, not simpler. In redesigning the AD DS
deployment process though, there was opportunity to coalesce many steps and best
practices into fewer, easier actions. This means, for example, that the graphical
configuration of a new replica domain controller is now eight dialogs rather than the
previous twelve. Creating a new Active Directory forest requires a single Windows
PowerShell command with only one argument: the name of the domain.
Why is there such an emphasis on Windows PowerShell in Windows Server 2012? As

distributed computing evolves, Windows PowerShell allows a single engine for
configuration and maintenance from both graphical and command-line interfaces. It
permits fully featured scripting of any component with the same first class citizenship
for an IT Professional that an API grants to developers. As cloud-based computing
becomes ubiquitous, Windows PowerShell also finally brings the ability to remotely
administer a server, where a computer with no graphical interface has the same
management capabilities as one with a monitor and mouse.
A veteran AD DS administrator should find their previous knowledge highly relevant. A

beginning administrator will find a far shallower learning curve.
Technical Overview
What You Should Know Before You Begin

This topic assumes familiarity with previous releases of Active Directory Domain
Services, and does not provide foundational detail around their purpose and
functionality. For more information about AD DS, see the TechNet Portal pages linked
below:
Active Directory Domain Services for Windows Server 2008 R2
Active Directory Domain Services for Windows Server 2008
Windows Server Technical Reference
Functional Descriptions
AD DS Role Installation
Active Directory Domain Services installation uses Server Manager and Windows
PowerShell, like all other server roles and features in Windows Server 2012. The
Dcpromo.exe program no longer provides GUI configuration options.
You use a graphical wizard in Server Manager or the ServerManager module for
Windows PowerShell in both local and remote installations. By running multiple
instances of those wizards or cmdlets and targeting different servers, you can deploy AD
DS to multiple domain controllers simultaneously, all from one single console. Although
these new features are not backwards compatible with Windows Server 2008 R2 or
earlier operating systems, you can also still use the Dism.exe application introduced in
Windows Server 2008 R2 for local role installation from the classic command-line.
AD DS Role Configuration
Active Directory Domain Services configuration " previously known as DCPROMO " is a
now a discrete operation from role installation. After installing the AD DS role, an
administrator configures the server as a domain controller using a separate wizard
within Server Manager or using the ADDSDeployment Windows PowerShell module.
AD DS role configuration builds on twelve years of field experience and now configures
domain controllers based on the most recent Microsoft best practices. For example,
Domain Name System and Global Catalogs install by default on every domain controller.
The Server Manager AD DS configuration wizard merges many individual dialogs into
fewer prompts and no longer hides settings in an "advanced" mode. The entire
promotion process is in one expanding dialog box during installation. The wizard and
the ADDSDeployment Windows PowerShell module show you notable changes and
security concerns, with links to further information.
The Dcpromo.exe remains in Windows Server 2012 for command-line unattended

installations only, and no longer runs the graphical installation wizard. It is highly
recommended that you discontinue use of Dcpromo.exe for unattended installs and
replace it with the ADDSDeployment module, as the now-deprecated executable will not
be included in the next version of Windows.
These new features are not backwards compatible to Windows Server 2008 R2 or older
operating systems.
） Important
Dcpromo.exe no longer contains a graphical wizard and no longer installs role or

feature binaries. Attempting to run Dcpromo.exe from the Explorer shell returns:
"The Active Directory Domain Services Installation Wizard is relocated in Server

Manager. For more information, see https://go.microsoft.com/fwlink/?
LinkId=220921 ."
Attempting to run Dcpromo.exe /unattend still installs the binaries, as in previous

operating systems, but warns:
"The dcpromo unattended operation is replaced by the ADDSDeployment module

for Windows PowerShell. For more information, see
https://go.microsoft.com/fwlink/?LinkId=220924 ."
Windows Server 2012 deprecates dcpromo.exe and it will not be included with
future versions of Windows, nor will it receive further enhancements in this
operating system. Administrators should discontinue its use and switch to the
supported Windows PowerShell modules if they wish to create domain controllers
from the command-line.
Prerequisite Checking
Domain controller configuration also implements a prerequisite checking phase that
evaluates the forest and domain prior to continuing with domain controller promotion.
This includes FSMO role availability, user privileges, extended schema compatibility and
other requirements. This new design alleviates issues where domain controller
promotion starts and then halts midway with a fatal configuration error. This lessens the
chance of orphaned domain controller metadata in the forest or a server that incorrectly
believes it is a domain controller.

This section explains how to install the first domain controller in a forest root domain
using Server Manager on a graphical Windows Server 2012 computer.
Server Manager AD DS Role Installation Process

The diagram below illustrates the Active Directory Domain Services role installation
process, beginning with you running ServerManager.exe and ending right before the
promotion of the domain controller.
Server Pool and Add Roles

Any Windows Server 2012 computers accessible from the computer running Server
Manager are eligible for pooling. Once pooled, you select those servers for remote
installation of AD DS or any other configuration options possible within Server Manager.
To add servers, choose one of the following:

Click Add Other Servers to Manage on the dashboard welcome tile
Click the Manage menu and select Add Servers
Right-click All Servers and choose Add Servers
This brings up the Add Servers dialog:
This gives you three ways to add servers to the pool for use or grouping:
Active Directory search (uses LDAP, requires that the computers belong to a
domain, allows operating system filtering and supports wildcards)
DNS search (uses DNS alias or IP address via ARP or NetBIOS broadcast or WINS
lookup, does not allow operating system filtering or support wildcards)
Import (uses a text file list of servers separated by CR/LF)
Click Find Now to return a list of servers from that same Active Directory domain that
the computer is joined to, Click one or more server names from the list of servers. Click
the right arrow to add the servers to the Selected list. Use the Add Servers dialog to
add selected servers to dashboard role groups. Or Click Manage, and then click Create
Server Group, or click Create Server Group on the dashboard Welcome to Server
Manager tile to create custom server groups.
７ Note
The Add Servers procedure does not validate that a server is online or accessible.
However, any unreachable servers flag in the Manageability view in Server Manager
at the next refresh
You can install roles remotely on any Windows Server 2012 computers added the pool,
as shown:
You cannot fully manage servers running operating systems older than Windows Server
2012. The Add Roles and Features selection is running ServerManager Windows
PowerShell Module Install-WindowsFeature.
You can also use the Server Manager Dashboard on an existing domain controller to
select remote server AD DS installation with the role already preselected by right
clicking the AD DS dashboard tile and selecting Add AD DS to Another Server. This is
invoking Install-WindowsFeature AD-Domain-Services.
The computer you are running Server Manager on pools itself automatically. To install
the AD DS role here, simply click the Manage menu and click Add Roles and Features.
Installation Type
The Installation Type dialog provides an option that does not support Active Directory
Domain Services: the Remote Desktop Services scenario based-installation. That option
only allows Remote Desktop Service in a multi-server distributed workload. If you select
it, AD DS cannot install.
Always leave the default selection in place when installing AD DS: Role-based or
Feature-based Installation.
Server Selection
The Server Selection dialog enables you to choose from one of the servers previously
added to the pool, as long as it is accessible. The local server running Server Manager is
automatically available.
In addition, you can select offline Hyper-V VHD files with the Windows Server 2012
operating system and Server Manager adds the role to them directly through
component servicing. This allows you to provision virtual servers with the necessary
components before further configuring them.
Server Roles and Features

Select the Active Directory Domain Services role if you intend to promote a domain
controller. All Active Directory administration features and required services install
automatically, even if they are ostensibly part of another role or do not appear selected
in the Server Manager interface.
Server Manager also presents an informational dialog that shows which management
features this role implicitly installs; this is equivalent to the -IncludeManagementTools
argument.
Additional Features can be added here as desired.
The Active Directory Domain Services dialog provides limited information on

requirements and best practices. It mainly acts as a confirmation that you chose the AD
DS role " if this screen does not appear, you did not select AD DS.
Confirmation
The Confirmation dialog is the final checkpoint before role installation starts. It offers an
option to restart the computer as needed after role installation, but AD DS installation
does not require a reboot.
By clicking Install, you confirm you are ready to begin role installation. You cannot
cancel a role installation once it begins.
Results
The Results dialog shows the current installation progress and current installation status.
Role installation continues regardless of whether Server Manager is closed.
Verifying the installation results is still a best practice. If you close the Results dialog
before installation completes, you can check the results using the Server Manager
notification flag. Server Manager also shows a warning message for any servers that
have installed the AD DS role but not been further configured as domain controllers.
Task Notifications
AD DS Details
Task Details
Promote to Domain Controller

At the end of the AD DS role installation, you can continue with configuration by using
the Promote this server to a domain controller link. This is required to make the server
a domain controller, but is not necessary to run the configuration wizard immediately.
For example, you may only want to provision servers with the AD DS binaries before
sending them to another branch office for later configuration. By adding the AD DS role
before shipping, you save time when it reaches its destination. You also follow the best
practice of not keeping a domain controller offline for days or weeks. Finally, this
enables you to update components before domain controller promotion, saving you at
least one subsequent reboot.
Selecting this link later invokes the ADDSDeployment cmdlets: install-addsforest,

install-addsdomain, or install-addsdomaincontroller.
Uninstalling/Disabling
You remove the AD DS role like any other role, regardless of whether you promoted the
server to a domain controller. However, removing the AD DS role requires a restart on
completion.
Active Directory Domain Services role removal is different from installation, in that it
requires domain controller demotion before it can complete. This is necessary to
prevent a domain controller from having its role binaries uninstalled without proper
metadata cleanup in the forest. For more information, see Demoting Domain Controllers
and Domains (Level 200).
２ Warning
Removing the AD DS roles with Dism.exe or the Windows PowerShell DISM module
after promotion to a Domain Controller is not supported and will prevent the server
from booting normally.
Unlike Server Manager or the AD DS Deployment module for Windows PowerShell,

DISM is a native servicing system that has no inherent knowledge of AD DS or its
configuration. Do not use Dism.exe or the Windows PowerShell DISM module to
uninstall the AD DS role unless the server is no longer a domain controller.
Create an AD DS Forest Root Domain with Server

Manager
The following diagram illustrates the Active Directory Domain Services configuration
process, in the case where you have previously installed the AD DS role and started the
Active Directory Domain Services Configuration Wizard using Server Manager.
Deployment Configuration
Server Manager begins every domain controller promotion with the Deployment
Configuration page. The remaining options and required fields change on this page and
subsequent pages, depending on which deployment operation you select.
To create a new Active Directory forest, click Add a new forest. You must provide a valid
root domain name; the name cannot be single-labeled (for example, the name must be
contoso.com or similar and not just contoso) and must use allowed DNS domain naming
requirements.
For more information on valid domain names, see KB article Naming conventions in
Active Directory for computers, domains, sites, and OUs .
２ Warning
Do not create new Active Directory forests with the same name as an external DNS
name. For example, if your Internet DNS URL is https://contoso.com , you must
choose a different name for your internal forest to avoid future compatibility issues.
That name should be unique and unlikely for web traffic. For example:
corp.contoso.com.
A new forest does not need new credentials for the domain's Administrator account. The
domain controller promotion process uses the credentials of the built-in Administrator
account from the first domain controller used to create the forest root. There is no way
(by default) to disable or lock out the built-in Administrator account and it may be the
only entry point into a forest if the other administrative domain accounts are unusable.
It is critical to know the password before deploying a new forest.
DomainName requires a valid fully qualified domain DNS name and is required.
Domain Controller Options
The Domain Controller Options enables you to configure the forest functional level
and domain functional level for the new forest root domain. By default, these settings
are Windows Server 2012 in a new forest root domain. The Windows Server 2012 forest
functional level does not provide any new functionality over the Windows Server 2008
R2 forest functional level. The Windows Server 2012 domain functional level is required
only in order to implement the new Kerberos settings "always provide claims" and "Fail
unarmored authentication requests." A primary use for functional levels in Windows
Server 2012 is to restrict participation in the domain to domain controllers that meet
minimum-allowed operating system requirements. In other words, you can specify
Windows Server 2012 domain functional level only domain controllers that run Windows
Server 2012 can host the domain. Windows Server 2012 implements a new domain
controller flag called DS_WIN8_REQUIRED in the DSGetDcName function of NetLogon
that exclusively locates Windows Server 2012 domain controllers. This allows you the
flexibility of a more homogeneous or heterogeneous forest in terms of which operating
systems are permitted to be run on domain controllers.
For more information about domain controller Location, review Directory Service
Functions.
The only configurable domain controller capability is the DNS server option. Microsoft
recommends that all domain controllers provide DNS services for high availability in
distributed environments, which is why this option is selected by default when installing
a domain controller in any mode or domain. The Global Catalog and read only domain
controller options are unavailable when creating a new forest root domain; the first
domain controller must be a GC, and cannot be a read only domain controller (RODC).
The specified Directory Services Restore Mode Password must adhere to the password
policy applied to the server, which by default does not require a strong password; only a
non-blank one. Always choose a strong, complex password or preferably, a passphrase.
DNS Options and DNS Delegation Credentials
The DNS Options page enables you to configure DNS delegation and provide alternate
DNS administrative credentials.
You cannot configure DNS options or delegation in the Active Directory Domain
Services Configuration Wizard when installing a new Active Directory Forest Root
Domain where you selected the DNS server on the Domain Controller Options page.
The Create DNS delegation option is available when creating a new forest root DNS
zone in an existing DNS server infrastructure. This option enables you to provide
alternate DNS administrative credentials that have the rights to update DNS zone.
For more information about whether you need to create a DNS delegation, see
Understanding Zone Delegation.
Additional Options
The Additional Options page shows the NetBIOS name of the domain and enables you
to override it. By default, the NetBIOS domain name matches the left-most label of the
fully qualified domain name provided on the Deployment Configuration page. For
example, if you provided the fully qualified domain name of corp.contoso.com, the
default NetBIOS domain name is CORP.
If the name is 15 characters or less and does not conflict with another NetBIOS name, it
is unaltered. If it does conflict with another NetBIOS name, a number is appended to the
name. If the name is more than 15 characters, the wizard provides a unique, truncated
suggestion. In either case, the wizard first validates the name is not already in use via a
WINS lookup and NetBIOS broadcast.
For more information on valid domain names, see KB article Naming conventions in
Active Directory for computers, domains, sites, and OUs .
Paths
The Paths page enables you to override the default folder locations of the AD DS
database, the database transaction logs, and the SYSVOL share. The default locations are
always in subdirectories of %systemroot% (i.e. C:\Windows).
Review Options and View Script
The Review Options page enables you to validate your settings and ensure they meet
your requirements before you start the installation. This is not the last opportunity to
stop the installation when using Server Manager. This is simply an option to confirm
your settings before continuing the configuration
The Review Options page in Server Manager also offers an optional View Script button
to create a Unicode text file that contains the current ADDSDeployment configuration as
a single Windows PowerShell script. This enables you to use the Server Manager
graphical interface as a Windows PowerShell deployment studio. Use the Active
Directory Domain Services Configuration Wizard to configure options, export the
configuration, and then cancel the wizard. This process creates a valid and syntactically
correct sample for further modification or direct use. For example:
PowerShell
# Windows PowerShell Script for AD DS Deployment
Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDNSDelegation `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "Win2012" `
-DomainName "corp.contoso.com" `
-DomainNetBIOSName "CORP" `
-ForestMode "Win2012" `
-InstallDNS:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SYSVOLPath "C:\Windows\SYSVOL"
-Force:$true
７ Note
Server Manager generally fills in all arguments with values when promoting and
does not rely on defaults (as they may change between future versions of Windows
or service packs). The one exception to this is the -
safemodeadministratorpassword argument (which is deliberately omitted from the
script). To force a confirmation prompt, omit the value when running cmdlet
interactively.
Prerequisites Check
The Prerequisites Check is a new feature in AD DS domain configuration. This new
phase validates that the server configuration is capable of supporting a new AD DS
forest.
When installing a new forest root domain, the Server Manager Active Directory Domain
Services Configuration Wizard invokes a series of modular tests. These tests alert you
with suggested repair options. You can run the tests as many times as required. The
domain controller process cannot continue until all prerequisite tests pass.
The Prerequisites Check also surfaces relevant information such as security changes that
affect older operating systems.
For more information on the specific prerequisite checks, see Prerequisite Checking.
Installation
When the Installation page displays, the domain controller configuration begins and
cannot be halted or canceled. Detailed operations display on this page and are written
to logs:
%systemroot%\debug\dcpromo.log
%systemroot%\debug\dcpromoui.log
７ Note
You can run multiple role installation and AD DS configuration wizards from the
same Server Manager console simultaneously.
Results
The Results page shows the success or failure of the promotion and any important
administrative information. The domain controller will automatically reboot after 10
seconds.
Deploying a Forest with Windows PowerShell

This section explains how to install the first domain controller in a forest root domain
using Windows PowerShell on a Core Windows Server 2012 computer.
Windows PowerShell AD DS Role Installation Process

By implementing a few straightforward ServerManager deployment cmdlets into your
deployment processes, you further realize the vision of AD DS simplified administration.
The next figure illustrates the Active Directory Domain Services role installation process,
beginning with you running PowerShell.exe and ending right before the promotion of
the domain controller.
ServerManager Arguments (Bold arguments are required. Italicized arguments can
Cmdlet be specified by using Windows PowerShell or the AD DS
Configuration Wizard.)
Install- -Name
WindowsFeature/Add-
WindowsFeature -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.
PowerShell
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.
PowerShell
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:
PowerShell
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.
PowerShell
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.
PowerShell
Get-WindowsFeature | where-object <options>
For example, to find all features containing "Active Dir" in their Display Name property,
use:
PowerShell
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:
PowerShell
Get-WindowsFeature | where {$_.displayname - like "*active dir*"}
By using the Windows PowerShell pipeline, you can create readable results. For example:
PowerShell
Install-WindowsFeature | Format-List
Install-WindowsFeature | select-object | Format-List
Note how using the Select-Object cmdlet with the -expandproperty argument returns
interesting data:
７ Note
The Select-Object -expandproperty argument slows down overall installation

performance slightly.
Create an AD DS Forest Root Domain with Windows
PowerShell
To install a new Active Directory forest using the ADDSDeployment module, use the
following cmdlet:
PowerShell
Install-addsforest
The Install-AddsForest cmdlet only has two phases (prerequisite checking and
installation). The two figures below show the installation phase with the minimum
required argument of -domainname.
ADDSDeployment Arguments (Bold arguments are required. Italicized arguments can be

Cmdlet specified by using Windows PowerShell or the AD DS Configuration
Wizard.)
Wizard.)
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:
PowerShell
Install-ADDSForest
-DomainName <string>
The equivalent Server Manager Domain Controller Options ADDSDeployment cmdlet

arguments are:
PowerShell
-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:
interactively.
For example, to create a new forest named corp.contoso.com and be prompted to

enter and confirm a masked password:
PowerShell
Install-ADDSForest "DomainName corp.contoso.com
to prompt the user for a secure string:
PowerShell
-safemodeadministratorpassword (read-host -prompt "Password:" -

assecurestring)
２ Warning
highly discouraged.
PowerShell
-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:
PowerShell
$file = "c:\pw.txt"
$pw = read-host -prompt "Password:" -assecurestring
$pw | ConvertFrom-SecureString | Set-Content $file
-safemodeadministratorpassword (Get-Content $File | ConvertTo-SecureString)
２ Warning
Providing or storing a clear or obfuscated text password is not recommended.

Anyone running this command in a script or looking over your shoulder knows the
DSRM password of that domain controller. Anyone with access to the file could
reverse that obfuscated password. With that knowledge, they can logon to a DC
started in DSRM and eventually impersonate the domain controller itself, elevating
their privileges to the highest level in an Active Directory forest. An additional set of
steps using System.Security.Cryptography to encrypt the text file data is advisable
but out of scope. The best practice is to totally avoid password storage.
The ADDSDeployment cmdlet offers an additional option to skip automatic

configuration of DNS client settings, forwarders, and root hints. You cannot skip this
configuration option when using Server Manager. This argument matters only if you
installed the DNS Server role prior to configuring the domain controller:
PowerShell
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:
PowerShell
-domainnetbiosname <string>
The equivalent Server Manager Paths ADDSDeployment cmdlet arguments are:
PowerShell
-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:
PowerShell
-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
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)
Article • 07/29/2021
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

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

ADDSDeployment Arguments (Bold arguments are required. Italicized arguments can
Install- -SkipPreChecks
AddsDomainController -DomainName
-SiteName
-ADPrepCredential
-AllowDomainControllerReinstall
-Confirm
-Credential
-CriticalReplicationOnly
-DatabasePath
-Force
-InstallationMediaPath
-InstallDNS
-LogPath
-MoveInfrastructureOperationMasterRoleIfNecessary
-NoDnsOnNetwork
-NoGlobalCatalog
-Norebootoncompletion
-ReplicationSourceDC
-SiteName
-SystemKey
-SYSVOLPath
-UseExistingAccount
-Whatif
７ Note
The -credential argument is only required if you are not already logged on as a
member of the Enterprise Admins and Schema Admins groups (if you are
upgrading the forest) or the Domain Admins group (if you are adding a new DC to
an existing domain).
Deployment
To upgrade an existing forest or add a writable domain controller to an existing domain,
click Add a domain controller to an existing domain and click Select to Specify the
domain information for this domain. Server Manager prompts you for valid credentials
if needed.
Upgrading the forest requires credentials that include group memberships in both the
Enterprise Admins and Schema Admins groups in Windows Server 2012. The Active
Directory Domain Services Configuration Wizard prompts you later if your current
credentials do not have adequate permissions or group memberships.
The automatic Adprep process is the only operational difference between adding a
domain controller to an existing Windows Server 2012 domain and a domain where
domain controllers run an earlier version of Windows Server.
The Deployment Configuration ADDSDeployment cmdlet and arguments are:
Install-AddsDomainController
-domainname <string>
-credential <pscredential>
Certain tests perform at each page, some of which repeat later as discrete prerequisite
checks. For instance, if the selected domain does not meet the minimal functional levels,
you do not have to go all the way through promotion to the prerequisite check to find
out:
The Domain Controller Options page specifies the domain controller capabilities for the
new domain controller. The configurable domain controller capabilities are DNS server,
Global Catalog, and Read-only domain controller. Microsoft recommends that all
domain controllers provide DNS and GC services for high availability in distributed
environments. GC is always selected by default and DNS server is selected by default if
the current domain hosts DNS already on its DCs based on Start of Authority query. The
Domain Controller Options page also enables you to choose the appropriate Active
Directory logical site name from the forest configuration. By default, it selects the site
with the most correct subnet. If there is only one site, it selects automatically.
７ Note
If the server does not belong to an Active Directory subnet and there is more than
one Active Directory site, nothing is selected and the Next button is unavailable
until you choose a site from the list.
policy applied to 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.
interactively.
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)

assecurestring)
２ Warning
highly discouraged.

asplaintext -force)
$file = "c:\pw.txt"
２ Warning
their privileges to the highest level in an Active Directory forest. An additional set of
steps using System.Security.Cryptography to encrypt the text file data is advisable
but out of scope. The best practice is to totally avoid password storage.
The ADDSDeployment cmdlet offers an additional option to skip automatic

configuration of DNS client settings, forwarders, and root hints. You cannot skip this
configuration option when using Server Manager. This argument matters only if you
installed the DNS Server role prior to configuring the domain controller:
The Domain Controller Options page warns that you cannot create read only domain
controllers if your existing domain controllers run Windows Server 2003. This is
expected, and you can dismiss the warning.
The DNS Options page enables you to configure DNS delegation if you selected the
DNS server option on the Domain Controller Options page and if pointing to a zone
where DNS delegations are allowed. You may need to provide alternate credentials of a
user that is a member of the DNS Admins group.
The DNS Options ADDSDeployment cmdlet arguments are:
-creatednsdelegation
-dnsdelegationcredential <pscredential>
For more information about whether you need to create a DNS delegation, see
Understanding Zone Delegation.
Additional Options
The Additional Options page provides the configuration option to name a domain
controller as the replication source, or you can use any domain controller as the
replication source.
You can also choose to install the domain controller using backed up media using the
Install from media (IFM) option. The Install from media checkbox provides a browse
option once selected and you must click Verify to ensure the provided path is valid
media. Media used by the IFM option is created with Windows Server Backup or
Ntdsutil.exe from another existing Windows Server 2012 computer only; you cannot use
a Windows Server 2008 R2 or previous operating system to create media for a Windows
Server 2012 domain controller. For more information about changes in IFM, see
Simplified Administration Appendix. If using media protected with a SYSKEY, Server
Manager prompts for the image's password during verification.
The Additional Options ADDSDeployment cmdlet arguments are:
-replicationsourcedc <string>
-installationmediapath <string>
-syskey <secure string>
Paths
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.
correct sample for further modification or direct use.
For example:
Install-ADDSDomainController `
-Credential (Get-Credential) `
-CriticalReplicationOnly:$false `
-DomainName "root.fabrikam.com" `
-InstallDNS:$true `
-SiteName "Default-First-Site-Name" `
-Force:$true
７ Note
safemodeadministratorpassword argument. To force a confirmation prompt omit
the value when running cmdlet interactively
Use the optional Whatif argument with the Install-ADDSDomainController cmdlet

to review configuration information. This enables you to see the explicit and
implicit values of the arguments for a cmdlet.
Prerequisites Check
phase validates that the 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.
For more information about the specific prerequisite checks, see Prerequisite Checking.
-skipprechecks
２ Warning

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
to logs:
%systemroot%\debug\adprep\logs
%systemroot%\debug\netsetup.log (if server is in a workgroup)
following cmdlet:
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
function correctly.
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
administrative information. If successful, the domain controller will automatically reboot
after 10 seconds.
As with previous versions of Windows Server, automated domain preparation for

domain controllers that run Windows server 2012 does not run GPPREP. Run adprep.exe
/gpprep manually for all domains that were not previously prepared for Windows Server
2003, Windows Server 2008, or Windows Server 2008 R2. You should run GPPrep only
once in the history of a domain, not with every upgrade. Adprep.exe does not run
/gpprep automatically because its operation can cause all files and folders in the
SYSVOL folder to re-replicate on all domain controllers.
Active Directory Child or Tree Domain
(Level 200)
Article • 07/29/2021
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

process when you previously installed the AD DS role and you have started the Active
domain in an existing forest.
Child and Tree Domain Windows PowerShell

Wizard.)
AddsDomain -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
The Server Manager Active Directory Domain Services Configuration Wizard prompts
you for domain credentials if your current credentials are not from the domain. Click
Change to provide domain credentials for the promotion operation.
The Deployment Configuration ADDSDeployment cmdlet and arguments are:
Install-AddsDomain
-domaintype <{childdomain | treedomain}>
-parentdomainname <string>
-newdomainname <string>
The Domain Controller Options page specifies the domain controller options for the
new domain controller. The configurable domain controller options include DNS server
and Global Catalog; you cannot configure read-only domain controller as the first
domain controller in a new domain.
Microsoft recommends that all domain controllers provide DNS and GC services for high
availability in distributed environments. GC is always selected by default and DNS is
selected by default if the current domain hosts DNS already on its DCs, based on a
Start-of-Authority query. You must also specify a Domain functional level. The default
functional level is Windows Server 2012, and you can choose any other value that is
equal to or greater than the current forest functional level.
The Domain Controller Options page also enables you to choose the appropriate Active
Directory logical site name from the forest configuration. By default, the site with the
most correct subnet is selected. If there is only one site, it is selected automatically.
） Important
passphrase.
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.
interactively.
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

assecurestring)
２ Warning
highly discouraged.

asplaintext -force)
$file = "c:\pw.txt"
２ Warning

their privileges to the highest level in an AD forest. An additional set of steps using
System.Security.Cryptography to encrypt the text file data is advisable but out of
scope. The best practice is to totally avoid password storage.
The ADDSDeployment module offers an additional option to skip automatic

configuration of DNS client settings, forwarders, and root hints. This is not configurable
when using Server Manager. This argument matters only if you already installed the DNS
Server service prior to configuring the domain controller:
The DNS Options page enables you to provide alternate DNS Admin credentials for
delegation.
When installing a new domain in an existing forest - where you selected DNS installation
on the Domain Controller Options page - you cannot configure any options; the
delegation happens automatically and irrevocably. You have the option to provide
alternate DNS administrative credentials with rights to update that structure.
The DNS Options ADDSDeployment Windows PowerShell arguments are:
-creatednsdelegation
-dnsdelegationcredential <pscredential>
For more information about DNS delegation, see Understanding Zone Delegation.
Additional Options
The Additional Options page shows the NetBIOS name of the domain and enables you
to override it. By default, the NetBIOS domain name matches the left-most label of the
fully qualified domain name provided on the Deployment Configuration page. For
example, if you provided the fully qualified domain name of corp.contoso.com, the
default NetBIOS domain name is CORP.
If the name is 15 characters or less and does not conflict with another NetBIOS name, it
is unaltered. If it does conflict with another NetBIOS name, a number is appended to the
name. If the name is more than 15 characters, the wizard provides a unique, truncated
suggestion. In either case, the wizard first validates the name is not already in use via a
WINS lookup and NetBIOS broadcast.
For more information about DNS names, see Naming conventions in Active Directory for
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
database, the data base transaction logs, and the SYSVOL share. The default locations
are always in subdirectories of %systemroot%.
The Paths ADDSDeployment cmdlet arguments are:
-logpath <string>

The Review Options page enables you to validate your settings and ensure they meet
your requirements before you start the installation. This is not the last opportunity to
stop the installation when using Server Manager. This is simply an option to confirm
your settings before continuing the configuration
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
domain.
The domain controller process cannot continue until all prerequisite tests pass.
For more information on the specific prerequisite checks, see Prerequisite Checking.
-skipprechecks
２ Warning
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
promotion results.
Installation
to logs:
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
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.
argument.
２ Warning
Overriding the reboot is not recommended. The domain controller must reboot to
function correctly
Results
seconds.
Install a Windows Server 2012 Active
Directory Read-Only Domain Controller
(RODC) (Level 200)
Article • 05/17/2023
This article explains how to create a staged RODC account and then attach a server to
that account during RODC installation. This article 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
ADDSDeployment Cmdlet Arguments (Bold arguments are required. Italicized
arguments can be specified by using Windows
PowerShell or the AD DS Configuration Wizard.)
Add- -SkipPreChecks
addsreadonlydomaincontrolleraccount -DomainControllerAccountName
-DomainName
-SiteName
-AllowPasswordReplicationAccountName
-Credential
-DelegatedAdministratorAccountName
-NoGlobalCatalog
-InstallDNS
７ Note
Attach RODC Workflow

The diagram below illustrates the Active Directory Domain Services configuration
process, where you already installed the AD DS role, you staged the RODC account, and
started Promote this Server to a Domain Controller using Server Manager to create a
new RODC in an existing domain, attaching it to the staged computer account.
Attach RODC Windows PowerShell

AddsDomaincontroller -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). Select the name of
the domain in the navigation pane. Double-click Domain Controllers in the
management list. Select 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'll 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 doesn't use the cmdlet for its operation. The
following sections display the equivalent cmdlet and arguments in order to make the
information associated with each easier to understand.
The Pre-create a Read-only domain controller account link in the Active Directory
Administrative Center's task pane is equivalent to the ADDSDeployment Windows
PowerShell cmdlet:
Add-addsreadonlydomaincontrolleraccount
Welcome
The Welcome to the Active Directory Domain Services Installation Wizard dialog has
one option named Use advanced mode installation. Select this option and select 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 don't include membership in the Domain Admins
group, select Alternate Credentials, and select 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
doesn't provide the new Adprep functionality. If you plan to deploy staged RODC
accounts, you must either first deploy an unstaged RODC in that domain so that the
automatic rodcprep operation runs, or manually run adprep.exe /rodcprep first.
Otherwise, you'll receive error. You won't be able to install a read-only domain controller
in this domain because adprep /rodcprep wasn't 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 doesn't exist. The domain controller you
configure and attach to this account later must have the same name, or the promotion
operation won't detect the staged account.
-domaincontrolleraccountname <string>
Select a Site
The Select a Site dialog shows a list of Active Directory sites for the current forest. The
staged read-only domain controller operation requires you to select a single site from
the list. The RODC uses this information to create its NTDS Settings object in the
Configuration partition and join itself to the correct site when it starts for the first time
after being deployed.
-sitename <string>
Additional Domain Controller Options

The Additional Domain Controller Options dialog enables you to specify that a domain
controller include running as a DNS Server and a Global Catalog. Microsoft
recommends that read-only domain controllers provide DNS and GC services, so both
are installed by default; one intention of the RODC role is branch office scenarios where
the wide area network may not be available and without those DNS and global catalog
services, computers in the branch won't 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)
don't cache their password. Accounts that aren't allowed to cache passwords on the
RODC and can't connect and authenticate to a writable domain controller can't 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. Select 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 aren't*
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 isn't required.
-delegatedadministratoraccountname <string>
Summary
The Summary dialog enables you to confirm your settings. This is the last opportunity
to stop the installation before the wizard creates the staged account. Select Next when
you're ready to create the staged RODC computer account. Select Export Settings to
save an answer file in the obsolete dcpromo unattend file format.
Creation
The Active Directory Domain Services Installation Wizard creates the staged read-only
domain controller in Active Directory. You can't 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 select the Select button to Specify the domain
information for this domain. Server Manager automatically prompts you for valid
credentials, or you can select 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 don't have adequate permissions or group memberships.
The Deployment Configuration ADDSDeployment Windows PowerShell cmdlet and

arguments are:
The Domain Controller Options page shows the domain controller options for the new
domain controller. When this page loads, the Active Directory Domain Services
Configuration Wizard sends an LDAP query to an existing domain controller to check for
unoccupied accounts. If the query finds an unoccupied domain controller computer
account that shares the same name as the current computer, then the wizard displays an
informational message at the top of the page that reads A Pre-created RODC account
that matches the name of the target server exists in the directory. Choose whether to
use this existing RODC account or reinstall this domain controller. The wizard uses the
Use existing RODC account as the default configuration.
） Important
You can use the Reinstall this domain controller option when a domain controller
has suffered a physical problem and cannot return to functionality. This saves time
when configuring the replacement domain controller, by leaving the domain
controller computer account and object metadata in Active Directory. Install the
new computer with the same name, and promote it as a domain controller in the
domain. The Reinstall this domain controller option is unavailable if you removed
the domain controller object's metadata from Active Directory (metadata cleanup).
You can't configure domain controller options when you're attaching a server to an
RODC computer account. You configure domain controller options when you create the
staged RODC computer account.
passphrase.
The Domain Controller Options ADDSDeployment Windows PowerShell arguments are:
-UseExistingAccount <{$true | $false}>
） Important
install-AddsDomainController 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.
interactively.
For example, to create a new RODC in the corp.contoso.com and be prompted to

Install-ADDSDomainController -DomainName corp.contoso.com -credential
(get-credential)
If specified with a value, the value must be a secure string. This isn't the preferred
-safemodeadministratorpassword (read-host -prompt Password: -assecurestring)
２ Warning
highly discouraged.
-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

replication source.
option once selected and you must select Verify to 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 can't 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 isn't 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
always in subdirectories of %systemroot%. The Paths ADDSDeployment cmdlet
arguments are:
-logpath <string>

meet your requirements before you start the installation. This isn't the last opportunity
and confirm your settings before continuing the configuration. The Review Options
page in Server Manager also offers an optional View Script button to create a Unicode
text file that contains the current ADDSDeployment configuration as a single Windows
PowerShell script. This enables you to use the Server Manager graphical interface as a
Windows PowerShell deployment studio. Use the Active Directory Domain Services
Configuration Wizard to configure options, export the configuration, and then cancel
the wizard. This process creates a valid and syntactically correct sample for further
modification or direct use. For example:
-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
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
forest.
The domain controller installation process can't continue until all prerequisite tests pass.
affect older operating systems. For more information about the prerequisite checks, see
Prerequisite Checking.
You can't bypass the Prerequisite Check when using Server Manager, but you can skip
-skipprechecks
２ Warning

Select Install to begin the domain controller promotion process. This is last opportunity
to cancel the installation. You can't cancel the promotion process once it begins. The
promotion results.
Installation
can't be halted or canceled. Detailed operations display on this page and are written to
logs:
following cmdlet:
See Attach RODC Windows PowerShell for required and optional arguments.
The Install-addsdomaincontroller cmdlet only has two phases (prerequisite checking

required arguments of -domainname, -useexistingaccount, and -credential. Note how,
just like Server Manager, Install-ADDSDomainController reminds you that promotion
will reboot the server automatically:
argument.
２ Warning

function correctly.
Results
seconds.
RODC without Staging Workflow

process, when you previously installed the AD DS role and you have started the Active
nonstaged read-only domain controller in an existing Windows Server 2012 domain.
RODC without Staging Windows PowerShell
AddsDomainController -DomainName
-SiteName
-Credential
-DatabasePath
-DNSOnNetwork
-InstallDNS
-LogPath
-MoveInfrastructureOperationMasterRoleIfNecessary
-NoGlobalCatalog
-SystemKey
-SYSVOLPath
-AllowPasswordReplicationAccountName
-DelegatedAdministratorAccountName
-ReadOnlyReplica
７ Note
RODC without Staging Deployment
To add an unstaged read-only domain controller to an existing Windows Server 2012

domain, select Add a domain controller to an existing domain and select the Select
button to Specify the domain information for this domain. Server Manager
automatically prompts you for valid credentials, or you can select 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 don't have adequate permissions or group memberships.
The Deployment Configuration ADDSDeployment Windows PowerShell cmdlet and

arguments are:
The Domain Controller Options page specifies the domain controller capabilities for the
new domain controller. The configurable domain controller capabilities are DNS server,
Global Catalog, and Read-only domain controller. Microsoft recommends that all
domain controllers provide DNS and GC services for high availability in distributed
environments. GC is always selected by default and DNS server is selected by default if
the current domain hosts DNS already on its DCs based on Start of Authority query.
The Domain Controller Options page also enables you to choose the appropriate Active
Directory logical site name from the forest configuration. By default, it selects the site
with the most correct subnet. If there's only one site, it selects that site automatically.
） Important
passphrase.The Domain Controller Options ADDSDeployment Windows PowerShell
arguments are:
-UseExistingAccount <{$true | $false}>
） Important
install-AddsDomainController 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.
interactively.
For example, to create a new RODC in the corp.contoso.com and be prompted to

Install-ADDSDomainController -DomainName corp.contoso.com -credential

(get-credential)
If specified with a value, the value must be a secure string. This isn't the preferred
-safemodeadministratorpassword (read-host -prompt Password: -assecurestring)
２ Warning
highly discouraged.
-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 aren't 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 isn't required.
-delegatedadministratoraccountname <string>
Accounts that aren't allowed to cache passwords on the RODC and can't connect and
authenticate to a writable domain controller can't 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
replication source.
option once selected and you must select Verify to 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 can't 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 isn't 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
always in subdirectories of %systemroot%. The Paths ADDSDeployment cmdlet
arguments are:
-logpath <string>
Preparation Options
The Preparation Options page alerts you that the AD DS configuration includes
extending the Schema (forestprep) and updating the domain (domainprep). You only
see this page when the forest or domain hasn't 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 don't occur when you select 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. Select Change to provide the adequate user
credentials if the page informs you that the current credentials don't 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.

meet your requirements before you start the installation. This isn't the last opportunity
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.
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
forest.
The domain controller process can't continue until all prerequisite tests pass.
You can't bypass the Prerequisite Check when using Server Manager, but you can skip
-skipprechecks
Select Install to begin the domain controller promotion process. This is last opportunity
to cancel the installation. You can't cancel the promotion process once it begins. The
promotion results.
Installation
can't be halted or canceled. Detailed operations display on this page and are written to
logs:
following cmdlet:
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

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:
argument.
２ 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
seconds.
Demoting Domain Controllers and
Domains
Article • 05/17/2023
This article explains how to remove AD DS, using Server Manager or Windows
PowerShell.
AD DS removal workflow
Ｕ Caution
Removing the AD DS roles with Dism.exe or the Windows PowerShell DISM module
after promotion to a Domain Controller is not supported and will prevent the server
from booting normally.
Unlike Server Manager or the ADDSDeployment module for Windows PowerShell,

DISM is a native servicing system that has no inherent knowledge of AD DS or its
configuration. Do not use Dism.exe or the Windows PowerShell DISM module to
uninstall the AD DS role unless the server is no longer a domain controller.
Demotion and role removal with PowerShell
ADDSDeployment and Arguments (Bold arguments are required. Italicized arguments
ServerManager Cmdlets can be specified by using Windows PowerShell or the AD DS
Uninstall- -SkipPreChecks
ADDSDomainController -LocalAdministratorPassword
-Confirm
-Credential
-DemoteOperationMasterRole
-DNSDelegationRemovalCredential
-Force
-ForceRemoval
-IgnoreLastDCInDomainMismatch
-IgnoreLastDNSServerForZone
-LastDomainControllerInDomain
-RemoveApplicationPartitions
-RemoveDNSDelegation
-RetainDCMetadata
Uninstall- -Name
WindowsFeature/Remove-
WindowsFeature -IncludeManagementTools
-Restart
-Remove
-Force
-ComputerName
-Credential
-LogPath
-Vhd
７ Note
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
Select AD DS or All Servers on the navigation pane. Scroll down to the Roles and
Features section. Right-click Active Directory Domain Services in the Roles and
Features list and select Remove Role or Feature. This interface skips the Server
Selection page.
The ServerManager cmdlets Uninstall-WindowsFeature and Remove-WindowsFeature
will prevent you from removing the AD DS role until you demote the domain controller.
Server Selection
The Server Selection dialog enables you to choose from one of the servers previously
added to the pool, as long as it's accessible. The local server running Server Manager is
always automatically available.
Server Roles and Features

Clear the Active Directory Domain Services check box to demote a domain controller; if
the server is currently a domain controller, this doesn't 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.
Don't 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 doesn't have an equivalent ADDSDeployment Windows PowerShell argument.
Removal Options
The Removal Options page appears depending on previously selecting Last domain
controller in the domain on the Credentials page. This page enables you to configure
additional removal options. Select Ignore last DNS server for zone, Remove application
partitions, and Remove DNS Delegation to enable the Next button.
The options only appear if applicable to this domain controller. For instance, if there's
no DNS delegation for this server then that checkbox won't display.
Select Change to specify alternate DNS administrative credentials. Select View Partitions
to view additional partitions the wizard removes during the demotion. By default, the
only additional partitions are Domain DNS and Forest DNS Zones. All other partitions
are non-Windows partitions.
The equivalent ADDSDeployment cmdlet arguments are:
-ignorelastdnsserverforzone <{ $true | false }>
-removeapplicationpartitions <{ $true | false }>
-removednsdelegation <{ $true | false }>
-dnsdelegationremovalcredential <pscredential>
New Administrator Password

The New Administrator Password page requires you to provide a password for the
built-in local computer's Administrator account, once the demotion completes and the
computer becomes a domain member server or workgroup computer.
The Uninstall-ADDSDomainController cmdlet and arguments follow the same defaults

as Server Manager if not specified.
The LocalAdministratorPassword argument is special:
If not specified as an argument, then the cmdlet prompts you to enter and confirm
a masked password. This is the preferred usage when running the cmdlet
interactively.
If specified with a value, then the value must be a secure string. This isn't the
preferred usage when running the cmdlet interactively.
to prompt the user for a secure string.
-localadministratorpassword (read-host -prompt "Password:" -assecurestring)
２ Warning
As the previous two options do not confirm the password, use extreme caution: the
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 doesn't 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.
Select 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
can't 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're shown here in the Confirmation phase with the minimum required
arguments. Pressing ENTER starts the irrevocable demotion process and restarts the
computer.
automatically rebooting at the end of promotion, use the -
norebootoncompletion:$false argument.
２ Warning
Overriding the reboot is discouraged. The member server must reboot to function
correctly.
Here's an example of forcibly demoting with its minimal required arguments of -

forceremoval and -demoteoperationmasterrole. The -credential argument isn't
required because the user logged on as a member of the Enterprise Admins group:
Here's an example of removing the last domain controller in the domain with its minimal
required arguments of -lastdomaincontrollerindomain and -
removeapplicationpartitions:
If you attempt to remove the AD DS role before demoting the server, Windows
PowerShell blocks you with an error:
） Important
You must restart the computer after demoting the server before you can remove
the AD-Domain-Services role binaries.
Results
seconds.
Clean up Active Directory Domain
Controller server metadata
Article • 01/11/2022
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 two options to clean up server metadata:
Clean up server metadata by using GUI tools.

Clean up server metadata using the command line.
７ Note
If you receive an "Access is denied" error when you use any of these methods to
perform metadata cleanup, make sure that the computer object and the NTDS
Settings object for the domain controller are not protected against accidental
deletion. To verify this right-click the computer object or the NTDS Settings object,
click Properties, click Object, and clear the Protect object from accidental deletion
check box. In Active Directory Users and Computers, the Object tab of an object
appears if you click View and then click Advanced Features.
Clean up server metadata using GUI tools

When you use Remote Server Administration Tools (RSAT) or the Active Directory Users
and Computers console (Dsa.msc) that is included with Windows Server to delete a
domain controller computer account from the Domain Controllers organizational unit
(OU), the cleanup of server metadata is performed automatically. 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 Directory Users and Computers.
2. If you have identified replication partners in preparation for this procedure and if
you are not connected to a replication partner of the removed domain controller
whose metadata you are cleaning up, right-click Active Directory Users and
Computers node, and then click Change Domain Controller. Click the name of the
domain controller from which you want to remove the metadata, and then click
OK.
3. Expand the domain of the domain controller that was forcibly removed, and then
click Domain Controllers.
4. In the details pane, right-click the computer object of the domain controller whose
metadata you want to clean up, and then click Delete.
5. In the Active Directory Domain Services dialog box, confirm the name of the
domain controller you wish to delete is shown, and click Yes to confirm the
computer object deletion.
6. In the Deleting Domain Controller dialog box, select This Domain Controller is
permanently offline and can no longer be demoted using the Active Directory
Domain Services Installation Wizard (DCPROMO), and then click Delete.
7. If the domain controller is a global catalog server, in the Delete Domain Controller
dialog box, click Yes to continue with the deletion.
8. If the domain controller currently holds one or more operations master roles, click
OK to move the role or roles to the domain controller that is shown. You cannot
change this domain controller. If you want to move the role to a different domain
controller, you must move the role after you complete the server metadata
cleanup procedure.
Clean up server metadata using Active Directory Sites
and Services
1. Open Active Directory Sites and Services.
2. If you have identified replication partners in preparation for this procedure and if
you are not connected to a replication partner of the removed domain controller
whose metadata you are cleaning up, right-click Active Directory Sites and
Services, and then click Change Domain Controller. Click the name of the domain
controller from which you want to remove the metadata, and then click OK.
3. Expand the site of the domain controller that was forcibly removed, expand
Servers, expand the name of the domain controller, right-click the NTDS Settings
object, and then click Delete.
4. In the Active Directory Sites and Services dialog box, click Yes to confirm the
NTDS Settings deletion.
5. In the Deleting Domain Controller dialog box, select This Domain Controller is
permanently offline and can no longer be demoted using the Active Directory
Domain Services Installation Wizard (DCPROMO), and then click Delete.
6. If the domain controller is a global catalog server, in the Delete Domain Controller
dialog box, click Yes to continue with the deletion.
7. If the domain controller currently holds one or more operations master roles, click
OK to move the role or roles to the domain controller that is shown.
8. Right-click the domain controller that was forcibly removed, and then click Delete.
9. In the Active Directory Domain Services dialog box, click Yes to confirm the
domain controller deletion.
Clean up server metadata using the command

line
As an alternative, you can clean up metadata by using ntdsutil.exe, a command-line tool
that is installed automatically on all domain controllers and servers that have Active
Directory Lightweight Directory Services (AD LDS) installed. ntdsutil.exe is also available
on computers that have RSAT installed. To clean up server metadata by using ntdsutil do
the following:
1. Open a command prompt as an administrator: On the Start menu, right-click

Command Prompt, and then click Run as administrator. If the User Account
Control dialog box appears, provide credentials of an Enterprise Administrator if
required, and then click Continue.
2. At the command prompt, type the following command, and then press Enter:
ntdsutil
3. At the ntdsutil: prompt, type the following command, and then press Enter:
metadata cleanup
4. At the metadata cleanup: prompt, type the following command, and then press
Enter:
remove selected server <ServerName>
5. In Server Remove Configuration Dialog, review the information and warning, and
then click Yes to remove the server object and metadata.
At this point, Ntdsutil confirms that the domain controller was removed
successfully. If you receive an error message that indicates that the object cannot
be found, the domain controller might have been removed earlier.
6. At the metadata cleanup: and ntdsutil: prompts, type quit , and then press
Enter.
7. To confirm removal of the domain controller:
Open Active Directory Users and Computers. In the domain of the removed
domain controller, click Domain Controllers. In the details pane, an object for the
domain controller that you removed should not appear.
Open Active Directory Sites and Services. Navigate to the Servers container and
confirm that the server object for the domain controller that you removed does
not contain an NTDS Settings object. If no child objects appear below the server
object, you can delete the server object. If a child object appears, do not delete the
server object because another application is using the object.
See Also
Demoting Domain Controllers
Ntdsutil command reference
AD DS Installation and Removal Wizard
Page Descriptions
Article • 04/28/2023
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
subsequent pages, depending on which 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 server and Global
Catalog; you cannot configure read-only domain controller as the first domain
controller in a new domain.
Microsoft recommends that all domain controllers provide DNS and global catalog
services for high availability in distributed environments, which is why the wizard
enables these options by default when creating a new domain.
The Domain Controller Options page also enables you to choose the appropriate
Active Directory logical site name from the forest configuration. By default, it
selects the site with the most correct subnet. If there is only one site, it selects that
site automatically.
） Important
If the server does not belong to an Active Directory subnet and there is more
than one site, nothing is selected and the Next button is unavailable until you
choose a site from the list.
2012 Active Directory Child or Tree Domain (Level 200).
If you are adding a domain controller to a domain, the Domain Controller Options page
has these options:
The configurable domain controller options include DNS server and Global
Catalog, and Read-only domain controller.
Microsoft recommends that all domain controllers provide DNS and global catalog
services for high availability in distributed environments, which is why the wizard
enables these options by default. For more information about deploying RODCs,
see Read-Only Domain Controller Planning and Deployment Guide.
For more information about how to add a domain controller to an existing domain, see
Install a Replica Windows Server 2012 Domain Controller in an Existing Domain (Level
200).
DNS Options
If you install DNS server, the following DNS Options page appears:
When you install DNS server, delegation records that point to the DNS server as
authoritative for the zone should be created in the parent Domain Name System (DNS)
zone. Delegation records transfer name resolution authority and provide correct referral
to other DNS servers and clients of the new servers that are being made authoritative
for the new zone. These resource records include the following:
A name server (NS) resource record to effect the delegation. This resource record
advertises that the server named ns1.na.example.microsoft.com is an authoritative
server for the delegated subdomain.
A host (A or AAAA) resource record also known as a glue record must be present
to resolve the name of the server that is specified in the name server (NS) resource
record to its IP address. The process of resolving the host name in this resource
record to the delegated DNS server in the name server (NS) resource record is
sometimes referred to as "glue chasing."
You can have the Active Directory Domain Services Configuration Wizard create them
automatically. The wizard verifies that the appropriate records exist in the parent DNS
zone after you click Next on the Domain Controller Options page. If the wizard cannot
verify that the records exist in the parent domain, the wizard provides you with the
option to create a new DNS delegation for a new domain (or update the existing
delegation) automatically and continue with the new domain controller installation.
Alternatively, you can create these DNS delegation records before you install DNS
server. To create a zone delegation, open DNS Manager, right-click the parent domain,
and then click New Delegation. Follow the steps in the New Delegation Wizard to create
the delegation.
The installation process tries to create the delegation to ensure that computers in other
domains can resolve DNS queries for hosts, including domain controllers and member
computers, in the DNS subdomain. Note that the delegation records can be
automatically created only on Microsoft DNS servers. If the parent DNS domain zone
resides on third party DNS servers such as BIND, a warning about the failure to create
DNS delegation records appears on the Prerequisites check page. For more information
about the warning, see Known issues for installing AD DS.
Delegations between the parent domain and the subdomain being promoted can be
created and validated before or after the installation. There is no reason to delay the
installation of a new domain controller because you cannot create or update the DNS
delegation.
For more information about delegation, see Understanding Zone Delegation

(https://go.microsoft.com/fwlink/?LinkId=164773 ). If zone delegation is not possible
in your situation, you might consider other methods for providing name resolution from
other domains to the hosts in your domain. For example, the DNS administrator of
another domain could configure conditional forwarding, stub-zones, or secondary zones
in order to resolve names in your domain. For more information, see the following
topics:
Understanding zone types (https://go.microsoft.com/fwlink/?LinkID=157399 )
Understanding stub zones (https://go.microsoft.com/fwlink/?LinkId=164776 )
Understanding forwarders (https://go.microsoft.com/fwlink/?LinkId=164778 )
RODC Options
The following options appear when you install a read-only domain controller (RODC).
Delegated administrator accounts gain local administrative permissions to the
RODC. These users can operate with privileges equivalent to the local computer's
Administrators group. They are not members of the Domain Admins or the domain
built-in Administrators groups. This option is useful for delegating branch office
administration without giving out domain administrative permissions. Configuring
delegation of administration is not required. For more information, see
Administrator Role Separation.
The Password Replication Policy acts as an access control list (ACL). It determines if
an RODC should be permitted to cache a password. After the RODC receives an
authenticated user or computer logon request, it refers to the Password
Replication Policy to determine if the password for the account should be cached.
The same account can then perform subsequent logons more efficiently.
The Password Replication Policy (PRP) lists the accounts whose passwords are
allowed to be cached, and accounts whose passwords are explicitly denied from
being cached. The list of user and computer accounts that are permitted to be
cached does not imply that the RODC has necessarily cached the passwords for
those accounts. An administrator can, for example, specify in advance any accounts
that an RODC will cache. This way, the RODC can authenticate those accounts,
even if the WAN link to the hub site is offline.
Any users or computers who are not allowed (including implicit) or denied do not
cache their password. If those users or computers do not have access to a writable
domain controller, they cannot access AD DS-provided resources or functionality.
For more information about the PRP, see Password Replication Policy. For more
information about managing the PRP, see Administering the Password Replication
Policy.
For more information about installing RODCs, see Install a Windows Server 2012 Active
Directory Read-Only Domain Controller (RODC) (Level 200).
Additional Options
The following option appears on the Additional Options page if you are creating a new
domain:
The following options appear on the Additional Options page if you install an
additional domain controller in an existing domain:
You can either specify a domain controller as the replication source, or allow the
wizard to choose any domain controller as the replication source.
You can also choose to install the domain controller using backed up media using
the Install from media (IFM) option. If the installation media is stored locally, the
Install from media Path option allows you to browse to the file location. The
browse option is not available for a remote installation. You can click Verify to
ensure the provided path is valid media. Media used by the IFM option must be
created with Windows Server Backup or Ntdsutil.exe from another existing
Windows Server 2012 computer only; you cannot use a Windows Server 2008 R2
or previous operating system to create media for a Windows Server 2012 domain
controller. If the media is protected with a SYSKEY, Server Manager prompts for
the image's password during verification.
2012 Active Directory 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.
database, the database 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 Disable the
AllowNT4Crypto setting on all affected domain controllers.
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
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
Article • 07/29/2021
This topic describes the changes that Adprep.exe makes in Windows Server 2012 R2 and
Windows Server 2012.
Forest-Wide Updates
Domain-Wide Updates
Read-Only Domain Controller 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
Article • 07/29/2021
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
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;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(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

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: CN=ms-DS-Key-Approximate-Last-Logon-Time-
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
NT,CN=Services,CN=Configuration,DC=X
# 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;;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
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
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
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
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)
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
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
(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
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-
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-
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
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
dn:
changetype: modify
schemaUpdateNow: 1
objectVersion: 63
Sch64.ldf
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
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-
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-
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
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

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

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

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

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

AuthNPolicySiloMembers.
attributeId: 1.2.840.113556.1.4.2288
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: x8v8EeT7UUm0t63fb579RA==
systemFlags: 16
instanceType: 4
linkID: 2205
dn: CN=ms-DS-User-AuthN-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAuthNPolicy
adminDisplayName: User Authentication Policy
adminDescription: This attribute specifies which AuthNPolicy should be

applied to users assigned to this silo object.
attributeId: 1.2.840.113556.1.4.2289
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 87kmzRXUKkSPeHxhUj7pWw==
systemFlags: 16
instanceType: 4
linkID: 2206
dn: CN=ms-DS-User-AuthN-Policy-BL,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-UserAuthNPolicyBL
adminDisplayName: User Authentication Policy Backlink
adminDescription: This attribute is the backlink for msDS-UserAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2290
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

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

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

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

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

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

AssignedAuthNPolicy.
attributeId: 1.2.840.113556.1.4.2296
omSyntax: 127
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: PBsTLZ/T7kqBXo20vBznrA==
systemFlags: 16
instanceType: 4
linkID: 2213
dn: CN=ms-DS-AuthN-Policy-Enforced,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicyEnforced
adminDisplayName: Authentication Policy Enforced
adminDescription: This attribute specifies whether the authentication policy

is enforced.
attributeId: 1.2.840.113556.1.4.2297
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: wgxWekXsukSy1yEjatWf1Q==
instanceType: 4
systemFlags: 16
dn: CN=ms-DS-AuthN-Policy-Silo-Enforced,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySiloEnforced
adminDisplayName: Authentication Policy Silo Enforced
adminDescription: This attribute specifies whether the authentication policy

silo is enforced.
attributeId: 1.2.840.113556.1.4.2298
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: AhH18uBrPUmHJhVGzbyHcQ==
instanceType: 4
systemFlags: 16
dn: CN=ms-DS-AuthN-Policy-Silos,CN=Schema,CN=Configuration,DC=X
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==
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==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-AuthN-
Policies,CN=Schema,CN=Configuration,DC=X
instanceType: 4
systemFlags: 16
subClassOf: top
dn:
changetype: modify
schemaUpdateNow: 1
dn: CN=ms-DS-AuthN-Policy-Silo,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AuthNPolicySilo
adminDisplayName: Authentication Policy Silo
adminDescription: An instance of this class defines authentication policies

and related behaviors for assigned users, computers, and services.
governsId: 1.2.840.113556.1.5.292
rdnAttId: cn
schemaIdGuid:: Hkbw+X1piUaSmTfmHWF7DQ==
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==
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-
ldapDisplayName: msDS-MembersOfResourcePropertyListBL
adminDisplayName: ms-DS-Members-Of-Resource-Property-List-BL
adminDescription: Backlink for ms-DS-Members-Of-Resource-Property-List. For

a resource property object, this attribute references the resource property
list object that it is a member of.
attributeId: 1.2.840.113556.1.4.2104
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BLdpdLDtaEWlpVn0hix1pw==
linkID: 2181
systemFlags: 17
dn: CN=ms-DS-Claim-Value-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimValueType
adminDisplayName: ms-DS-Claim-Value-Type
adminDescription: For a claim type object, specifies the value type of the
claims issued.
attributeId: 1.2.840.113556.1.4.2098
omSyntax: 65
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: uRdixo7k90e31WVSuK/WGQ==
systemFlags: 16
dn: CN=ms-DS-Claim-Possible-Values,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimPossibleValues
adminDisplayName: ms-DS-Claim-Possible-Values
adminDescription: For a claim type or resource property object, this

attribute describes the values suggested to a user when the he/she use the
claim type or resource property in applications.
attributeId: 1.2.840.113556.1.4.2097
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1048576
schemaIdGuid:: 7u0oLnztP0Wv5JO9hvIXTw==
systemFlags: 16
dn: CN=ms-DS-Claim-Attribute-Source,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimAttributeSource
adminDisplayName: ms-DS-Claim-Attribute-Source
adminDescription: For a claim type object, this attribute points to the

attribute that will be used as the source for the claim type.
attributeId: 1.2.840.113556.1.4.2099
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: PhK87ua6ZkGeWymISot2sA==
systemFlags: 16
dn: CN=ms-DS-Claim-Type-Applies-To-Class,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimTypeAppliesToClass
adminDisplayName: ms-DS-Claim-Type-Applies-To-Class
adminDescription: For a claim type object, this linked attribute points to

the AD security principal classes that for which claims should be issued.
(For example, a link to the user class).
attributeId: 1.2.840.113556.1.4.2100
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: TA77anbYfEOutsPkFFTCcg==
linkID: 2176
systemFlags: 16
dn: CN=ms-DS-Claim-Shares-Possible-Values-
With,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimSharesPossibleValuesWith
adminDisplayName: ms-DS-Claim-Shares-Possible-Values-With
adminDescription: For a resource property object, this attribute indicates

that the suggested values of the claims issued are defined on the object
that this linked attribute points to. Overrides ms-DS-Claim-Possible-Values
on itself, if populated.
attributeId: 1.2.840.113556.1.4.2101
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: OtHIUgvOV0+JKxj1pDokAA==
linkID: 2178
systemFlags: 16
dn: CN=ms-DS-Claim-Shares-Possible-Values-With-
ldapDisplayName: msDS-ClaimSharesPossibleValuesWithBL
adminDisplayName: ms-DS-Claim-Shares-Possible-Values-With-BL
adminDescription: For a claim type object, this attribute indicates that the
possible values described in ms-DS-Claim-Possible-Values are being
referenced by other claim type objects.
attributeId: 1.2.840.113556.1.4.2102
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: 2yLVVJXs9UibvRiA67shgA==
linkID: 2179
systemFlags: 17
dn: CN=ms-DS-Is-Used-As-Resource-Security-
Attribute,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsUsedAsResourceSecurityAttribute
adminDisplayName: ms-DS-Is-Used-As-Resource-Security-Attribute
adminDescription: For a resource property, this attribute indicates whether

it is being used as a secure attribute.
attributeId: 1.2.840.113556.1.4.2095
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: nfjJUTBHjUaitR1JMhLRfg==
systemFlags: 16
dn: CN=ms-SPP-KMS-Ids,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-KMSIds
adminDisplayName: ms-SPP-KMS-Ids
adminDescription: KMS IDs enabled by the Activation Object
attributeId: 1.2.840.113556.1.4.2082
omSyntax: 4
systemOnly: FALSE
searchFlags: 1
rangeLower: 16
rangeUpper: 16
schemaIdGuid:: 2j5mm0I11kad8DFAJa8rrA==
systemFlags: 16
dn: CN=ms-SPP-CSVLK-Pid,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-CSVLKPid
adminDisplayName: ms-SPP-CSVLK-Pid
adminDescription: ID of CSVLK product-key used to create the Activation

Object
attributeId: 1.2.840.113556.1.4.2105
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 512
schemaIdGuid:: DVF/tFBr4Ue1VncseeT/xA==
systemFlags: 16
dn: CN=ms-SPP-CSVLK-Sku-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-CSVLKSkuId
adminDisplayName: ms-SPP-CSVLK-Sku-Id
adminDescription: SKU ID of CSVLK product-key used to create the Activation

Object
attributeId: 1.2.840.113556.1.4.2081
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeLower: 16
rangeUpper: 16
schemaIdGuid:: OfeElnh7bUeNdDGtdpLu9A==
systemFlags: 16
dn: CN=ms-SPP-Phone-License,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-PhoneLicense
adminDisplayName: ms-SPP-Phone-License
adminDescription: License used during phone activation of the Active

Directory forest
attributeId: 1.2.840.113556.1.4.2086
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 5242880
schemaIdGuid:: EtnkZ2LzUkCMeUL0W6eyIQ==
systemFlags: 16
dn: CN=ms-SPP-Config-License,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-ConfigLicense
adminDisplayName: ms-SPP-Config-License
adminDescription: Product-key configuration license used during online/phone

activation of the Active Directory forest
attributeId: 1.2.840.113556.1.4.2087
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 5242880
schemaIdGuid:: tcRTA5nRsECzxd6zL9nsBg==
systemFlags: 16
dn: CN=ms-SPP-Online-License,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-OnlineLicense
adminDisplayName: ms-SPP-Online-License
adminDescription: License used during online activation of the Active

Directory forest
attributeId: 1.2.840.113556.1.4.2085
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 5242880
schemaIdGuid:: jjaPCRJIzUivt6E2uWgH7Q==
systemFlags: 16
dn: CN=ms-SPP-Confirmation-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-ConfirmationId
adminDisplayName: ms-SPP-Confirmation-Id
adminDescription: Confirmation ID (CID) used for phone activation of the

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

attributeId: 1.2.840.113556.1.4.2083
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 512
schemaIdGuid:: FLG/aXtAOUeiE8ZjgCs+Nw==
systemFlags: 16
dn: CN=ms-SPP-Issuance-License,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-IssuanceLicense
adminDisplayName: ms-SPP-Issuance-License
adminDescription: Issuance license used during online/phone activation of

the Active Directory forest
attributeId: 1.2.840.113556.1.4.2088
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 5242880
schemaIdGuid:: obN1EK+70kmujcTyXIIzAw==
systemFlags: 16
dn: CN=ms-SPP-CSVLK-Partial-Product-Key,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msSPP-CSVLKPartialProductKey
adminDisplayName: ms-SPP-CSVLK-Partial-Product-Key
adminDescription: Last 5 characters of CSVLK product-key used to create the

Activation Object
attributeId: 1.2.840.113556.1.4.2106
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeLower: 5
rangeUpper: 5
schemaIdGuid:: kbABplKGOkWzhoetI5t8CA==
systemFlags: 16
dn: CN=ms-TPM-Srk-Pub-Thumbprint,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-SrkPubThumbprint
adminDisplayName: TPM-SrkPubThumbprint
adminDescription: This attribute contains the thumbprint of the SrkPub

corresponding to a particular TPM. This helps to index the TPM devices in
the directory.
attributeId: 1.2.840.113556.1.4.2107
omSyntax: 4
systemOnly: FALSE
searchFlags: 11
rangeUpper: 20
schemaIdGuid:: 6wbXGXZNokSF1hw0K+O+Nw==
systemFlags: 16
dn: CN=ms-TPM-Owner-Information-Temp,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-OwnerInformationTemp
adminDisplayName: TPM-OwnerInformationTemp
adminDescription: This attribute contains temporary owner information for a

particular TPM.
attributeId: 1.2.840.113556.1.4.2108
omSyntax: 64
systemOnly: FALSE
searchFlags: 640
rangeUpper: 128
schemaIdGuid:: nYCUyBO1+E+IEfT0P1rHvA==
systemFlags: 16
dn: CN=ms-TPM-Tpm-Information-For-Computer,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msTPM-TpmInformationForComputer
adminDisplayName: TPM-TpmInformationForComputer
adminDescription: This attribute links a Computer object to a TPM object.
attributeId: 1.2.840.113556.1.4.2109
omSyntax: 127
systemOnly: FALSE
searchFlags: 16
schemaIdGuid:: k3sb6khe1Ua8bE30/aeKNQ==
linkID: 2182
systemFlags: 16
dn: CN=ms-TPM-Tpm-Information-For-Computer-
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==
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
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==
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==
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==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Claim-Type-Property-
Base,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-DS-Resource-Property,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ResourceProperty
adminDisplayName: ms-DS-Resource-Property
adminDescription: An instance of this class holds the definition of a

property on resources.
governsId: 1.2.840.113556.1.5.273
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.5.269
schemaIdGuid:: Xj0oWwSElUGTOYRQGIxQGg==
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==
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-
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==
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;LOLCCCRP;;;DC)
systemOnly: FALSE
defaultObjectCategory: CN=ms-TPM-Information-Objects-
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;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(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==
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
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-
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-
ldapDisplayName: msAuthz-MemberRulesInCentralAccessPolicyBL
adminDisplayName: ms-Authz-Member-Rules-In-Central-Access-Policy-BL
adminDescription: Backlink for ms-Authz-Member-Rules-In-Central-Access-

Policy. For a central access rule object, this attribute references one or
more central access policies that point to it.
attributeId: 1.2.840.113556.1.4.2156
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: z2duUd3+lES7OrxQapSIkQ==
linkID: 2185
systemFlags: 17
dn: CN=ms-DS-Claim-Source,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimSource
adminDisplayName: ms-DS-Claim-Source
adminDescription: For a claim type, this attribute indicates the source of

the claim type. For example, the source can be certificate.
attributeId: 1.2.840.113556.1.4.2157
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: pvIy+ovy0Ee/kWY+j5EKcg==
systemFlags: 16
dn: CN=ms-Authz-Proposed-Security-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-ProposedSecurityPolicy
adminDisplayName: ms-Authz-Proposed-Security-Policy
adminDescription: For a Central Access Policy Entry, defines the proposed

security policy of the objects the CAPE is applied to.
attributeId: 1.2.840.113556.1.4.2151
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: zr5GubUJakuyWktjozDoDg==
systemFlags: 16
dn: CN=ms-DS-Claim-Source-Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimSourceType
adminDisplayName: ms-DS-Claim-Source-Type
adminDescription: For a security principal claim type, lists the type of

store the issued claim is sourced from
attributeId: 1.2.840.113556.1.4.2158
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: BZzxkvqNIkK70SxPAUh3VA==
systemFlags: 16
dn: CN=ms-Authz-Effective-Security-Policy,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-EffectiveSecurityPolicy
adminDisplayName: ms-Authz-Security-Policy
adminDescription: For a central access rule, this attribute defines the

permission that is applying to the target resources on the central access
rule.
attributeId: 1.2.840.113556.1.4.2150
omSyntax: 64
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-
ldapDisplayName: msAuthz-LastEffectiveSecurityPolicy
adminDisplayName: ms-Authz-Last-Effective-Security-Policy
adminDescription: For a Central Access Policy Entry, defines the security

policy that was last applied to the objects the CAPE is applied to.
attributeId: 1.2.840.113556.1.4.2152
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: xoUWji8+okiljVrw6nifoA==
systemFlags: 16
dn: CN=ms-Authz-Resource-Condition,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-ResourceCondition
adminDisplayName: ms-Authz-Resource-Condition
adminDescription: For a central access rule, this attribute is an expression

that identifies the scope of the target resource to which the policy
applies.
attributeId: 1.2.840.113556.1.4.2153
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: d3iZgHT4aEyGTW5QioO9vQ==
systemFlags: 16
dn: CN=ms-DS-Claim-Is-Value-Space-Restricted,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimIsValueSpaceRestricted
adminDisplayName: ms-DS-Claim-Is-Value-Space-Restricted
adminDescription: For a claim type, this attribute identifies whether a user

can input values other than those described in the msDS-ClaimPossibleValues
in applications.
attributeId: 1.2.840.113556.1.4.2159
omSyntax: 1
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: x+QsDMPxgkSFeMYNS7dEIg==
systemFlags: 16
dn: CN=ms-Authz-Central-Access-Policy-ID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msAuthz-CentralAccessPolicyID
adminDisplayName: ms-Authz-Central-Access-Policy-ID
adminDescription: For a Central Access Policy, this attribute defines a GUID

that can be used to identify the set of policies when applied to a resource.
attributeId: 1.2.840.113556.1.4.2154
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: YJvyYnS+MEaUVi9mkZk6hg==
systemFlags: 16
dn: CN=ms-DS-Generation-Id,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-GenerationId
adminDisplayName: ms-DS-Generation-Id
adminDescription: For virtual machine snapshot resuming detection. This

attribute represents the VM Generation ID.
attributeId: 1.2.840.113556.1.4.2166
omSyntax: 4
rangeLower: 16
rangeUpper: 16
systemOnly: TRUE
searchFlags: 0
schemaIdGuid:: PTldHreMT0uECpc7NswJww==
systemFlags: 17
dn: CN=ms-DS-Claim-Shares-Possible-Values-
With,CN=Schema,CN=Configuration,DC=X
replace: adminDescription
adminDescription: For a claim type object, indicates that the possible

values of the claims issued are defined on the object this linked attribute
points to; overrides msDS-ClaimPossibleValues, msDS-ClaimValueType, and
msDS-ClaimIsValueSpaceRestricted, if populated.
dn: CN=ms-DNS-Server-Settings,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDNS-ServerSettings
adminDisplayName: ms-DNS-Server-Settings
adminDescription: A container for storing DNS server settings.
governsId: 1.2.840.113556.1.4.2129
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: 7cMv7xhuW0GZ5DEUqMsSSw==
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)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Authz-Central-Access-
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==
systemOnly: FALSE
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==
systemOnly: FALSE
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==
systemOnly: FALSE
systemFlags: 16
dn: CN=ms-DS-Claim-Types,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DS-Resource-Properties,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DS-List-Of-Claim-Types,CN=Schema,CN=Configuration,DC=X
dn: CN=ms-DS-Claim-Type,CN=Schema,CN=Configuration,DC=X
dn: CN=Dns-Zone,CN=Schema,CN=Configuration,DC=X
dn:
changetype: modify
schemaUpdateNow: 1
dn: CN=DS-Clone-Domain-Controller,CN=Extended-Rights,CN=Configuration,DC=X
displayName: Allow a DC to create a clone of itself
rightsGuid: 3e0f7e18-2c7a-4c10-ba82-4d926db99a3e
appliesTo: 19195a5b-6da0-11d0-afd3-00c04fd930c9
validAccesses: 256
localizationDisplayId: 80
objectVersion: 49
Sch50.ldf
dn: CN=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-
Identity,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-AllowedToActOnBehalfOfOtherIdentity
adminDisplayName: ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity
adminDescription: This attribute is used for access checks to determine if a

requester has permission to act on the behalf of other identities to
services running as this account.
attributeId: 1.2.840.113556.1.4.2182
omSyntax: 66
systemOnly: TRUE
searchFlags: 0
rangeLower: 0
rangeUpper: 132096
schemaIdGuid:: 5cN4P5r3vUaguJ0YEW3ceQ==
systemFlags: 16
dn: CN=ms-Kds-Version,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-Version
adminDisplayName: ms-Kds-Version
adminDescription: Version number of this root key.
attributeId: 1.2.840.113556.1.4.2176
omSyntax: 2
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: QHPw1bDmSh6Xvg0zGL2dsQ==
systemFlags: 16
dn: CN=ms-Kds-DomainID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-DomainID
adminDisplayName: ms-Kds-DomainID
adminDescription: Distinguished name of the Domain Controller which
generated this root key.
attributeId: 1.2.840.113556.1.4.2177
omSyntax: 127
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: ggRAlgfPTOmQ6PLvxPBJXg==
systemFlags: 16
dn: CN=ms-Kds-KDF-Param,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-KDFParam
adminDisplayName: ms-Kds-KDF-Param
adminDescription: Parameters for the key derivation algorithm.
attributeId: 1.2.840.113556.1.4.2170
omSyntax: 4
systemOnly: FALSE
searchFlags: 640
rangeUpper: 2000
schemaIdGuid:: cgeAirj0TxW0HC5Cce/3pw==
systemFlags: 16
dn: CN=ms-Kds-CreateTime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-CreateTime
adminDisplayName: ms-Kds-CreateTime
adminDescription: The time when this root key was created.
attributeId: 1.2.840.113556.1.4.2179
omSyntax: 65
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: nxEYrpBjRQCzLZfbxwGu9w==
systemFlags: 16
dn: CN=ms-Kds-RootKeyData,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-RootKeyData
adminDisplayName: ms-Kds-RootKeyData
adminDescription: Root key.
attributeId: 1.2.840.113556.1.4.2175
omSyntax: 4
systemOnly: FALSE
searchFlags: 640
rangeUpper: 128
schemaIdGuid:: J3xiJqIIQAqhsY3OhbQpkw==
systemFlags: 16
dn: CN=ms-DS-Primary-Computer,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-PrimaryComputer
adminDisplayName: ms-DS-Primary-Computer
adminDescription: For a user or group object, identifies the primary

computers.
attributeId: 1.2.840.113556.1.4.2167
omSyntax: 127
systemOnly: FALSE
searchFlags: 1
schemaIdGuid:: 4vQ9obDb60yCi4suFD6egQ==
linkID: 2186
systemFlags: 16
dn: CN=ms-Kds-UseStartTime,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-UseStartTime
adminDisplayName: ms-Kds-UseStartTime
adminDescription: The time after which this root key may be used.
attributeId: 1.2.840.113556.1.4.2178
omSyntax: 65
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: fwTcbCL1SreanNlayM39og==
systemFlags: 16
dn: CN=ms-Imaging-Hash-Algorithm,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msImaging-HashAlgorithm
adminDisplayName: ms-Imaging-Hash-Algorithm
adminDescription: Contains the name of the hash algorithm used to create the
Thumbprint Hash for the Scan Repository/Secure Print Device.
attributeId: 1.2.840.113556.1.4.2181
omSyntax: 64
systemOnly: FALSE
searchFlags: 0
rangeUpper: 64
schemaIdGuid:: tQ3nigZklkGS/vO7VXUgpw==
systemFlags: 16
dn: CN=ms-Kds-KDF-AlgorithmID,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-KDFAlgorithmID
adminDisplayName: ms-Kds-KDF-AlgorithmID
adminDescription: The algorithm name of the key derivation function used to

compute keys.
attributeId: 1.2.840.113556.1.4.2169
omSyntax: 64
systemOnly: FALSE
searchFlags: 640
rangeUpper: 200
schemaIdGuid:: skgs203RTuyfWK1XnYtEDg==
systemFlags: 16
dn: CN=ms-Imaging-Thumbprint-Hash,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msImaging-ThumbprintHash
adminDisplayName: ms-Imaging-Thumbprint-Hash
adminDescription: Contains a hash of the security certificate for the Scan

Repository/Secure Print Device.
attributeId: 1.2.840.113556.1.4.2180
omSyntax: 4
systemOnly: FALSE
searchFlags: 0
rangeUpper: 1024
schemaIdGuid:: xdvfnAQDaUWV9sT2Y/5a5g==
systemFlags: 16
dn: CN=ms-Kds-PublicKey-Length,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-PublicKeyLength
adminDisplayName: ms-Kds-PublicKey-Length
adminDescription: The length of the secret agreement public key.
attributeId: 1.2.840.113556.1.4.2173
omSyntax: 2
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: cPQ44805SUWrW/afnlg/4A==
systemFlags: 16
dn: CN=ms-Kds-PrivateKey-Length,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-PrivateKeyLength
adminDisplayName: ms-Kds-PrivateKey-Length
adminDescription: The length of the secret agreement private key.
attributeId: 1.2.840.113556.1.4.2174
omSyntax: 2
systemOnly: FALSE
searchFlags: 640
schemaIdGuid:: oUJfYec3SBGg3TAH4Jz8gQ==
systemFlags: 16
dn: CN=ms-DS-Is-Primary-Computer-For,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-IsPrimaryComputerFor
adminDisplayName: ms-DS-Is-Primary-Computer-For
adminDescription: Backlink 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;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
systemOnly: FALSE
defaultObjectCategory: CN=ms-Kds-Prov-
RootKey,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=ms-Kds-Prov-ServerConfiguration,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msKds-ProvServerConfiguration
adminDisplayName: ms-Kds-Prov-ServerConfiguration
adminDescription: Configuration for the Group Key Distribution Service.
governsId: 1.2.840.113556.1.5.277
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: qEPyXiUqpkWLcwinGuZ3zg==
systemOnly: FALSE
defaultObjectCategory: CN=ms-Kds-Prov-
ServerConfiguration,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=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-
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
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-
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-
ldapDisplayName: msDS-IngressClaimsTransformationPolicy
adminDisplayName: ms-DS-Ingress-Claims-Transformation-Policy
adminDescription: This is a link to a Claims Transformation Policy Object

for the ingress claims (claims entering this forest) from the Trusted
Domain. This is applicable only for an outgoing or bidirectional Across-
Forest Trust. If this link is absent, all the ingress claims are dropped.
attributeId: 1.2.840.113556.1.4.2191
omSyntax: 127
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: CEwohm4MQBWLFXUUfSPSDQ==
linkID: 2190
systemFlags: 16
dn: CN=ms-DS-TDO-Egress-BL,CN=Schema,CN=Configuration,DC=X
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
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-
systemFlags: 16
dn: CN=ms-DS-Claims-Transformation-Policy-
Type,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-ClaimsTransformationPolicyType
adminDisplayName: ms-DS-Claims-Transformation-Policy-Type
adminDescription: An object of this class holds the one set of Claims

Transformation Policy for Across-Forest Claims Transformation.
governsId: 1.2.840.113556.1.5.280
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: s2LrLnMTRf6BATh/Fnbtxw==
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Claims-Transformation-Policy-
Type,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=X
add: mayContain
mayContain: 1.2.840.113556.1.4.2183
mayContain: 1.2.840.113556.1.4.2184
mayContain: 1.2.840.113556.1.4.2185
dn: CN=ms-DS-Group-Managed-Service-Account,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-GroupManagedServiceAccount
adminDisplayName: msDS-Group-Managed-Service-Account
adminDescription: The group managed service account class is used to create

an account which can be shared by different computers to run Windows
services.
governsId: 1.2.840.113556.1.5.282
rdnAttId: 2.5.4.3
subClassOf: 1.2.840.113556.1.3.30
systemPossSuperiors: 2.5.6.5
schemaIdGuid:: ilWLe6WT90qtysAX5n8QVw==
defaultSecurityDescriptor: D:(OD;;CR;00299570-246d-11d0-a768-
00aa006e0529;;WD)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPCRLCLORCSDDT;;;CO)(OA;;WP;4c164200-20c0-11d0-a768-00aa006e0529;;CO)
(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;CO)(OA;;SW;f3a64788-5306-11d1-
a9c5-0000f80367c1;;CO)(OA;;WP;3e0abfd0-126a-11d0-a060-00aa006c33ed;bf967a86-
0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;5f202010-79a5-11d0-9020-
00c04fc2d4cf;bf967a86-0de6-11d0-a285-00aa003049e2;CO)(OA;;WP;bf967950-0de6-
11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-00aa003049e2;CO)
(OA;;WP;bf967953-0de6-11d0-a285-00aa003049e2;bf967a86-0de6-11d0-a285-
00aa003049e2;CO)(OA;;SW;f3a64788-5306-11d1-a9c5-0000f80367c1;;PS)
(OA;;RPWP;77B5B886-944A-11d1-AEBD-0000F80367C1;;PS)(OA;;SW;72e39547-7b18-
11d1-adef-00c04fd8d5cd;;PS)(A;;RPLCLORC;;;AU)(OA;;RPWP;bf967a7f-0de6-11d0-
a285-00aa003049e2;;CA)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-
32-560)(OA;;RP;e362ed86-b728-0842-b27d-2dea7a9df218;;WD)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Group-Managed-Service-
Account,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
dn:
changetype: modify
schemaUpdateNow: 1
objectVersion: 51
Sch52.ldf
dn: CN=ms-DS-RID-Pool-Allocation-Enabled,CN=Schema,CN=Configuration,DC=X
ldapDisplayName: msDS-RIDPoolAllocationEnabled
adminDisplayName: ms-DS-RID-Pool-Allocation-Enabled
adminDescription: This attribute indicates whether RID pool allocation is

enabled or not.
attributeId: 1.2.840.113556.1.4.2213
omSyntax: 1
instanceType: 4
systemOnly: TRUE
searchFlags: 0
schemaFlagsEx: 1
schemaIdGuid:: jHyXJLfBQDO09is3XrcR1w==
systemFlags: 16
dn: CN=RID-Set-References,CN=Schema,CN=Configuration,DC=X
searchFlags: 8
dn: CN=Netboot-DUID,CN=Schema,CN=Configuration,DC=X
cn: Netboot-DUID
ldapDisplayName: netbootDUID
adminDisplayName: Netboot-DUID
adminDescription: This attribute is used to store DHCPv6 DUID device ID.
attributeId: 1.2.840.113556.1.4.2234
omSyntax: 4
instanceType: 4
searchFlags: 1
systemFlags: 16
systemOnly: FALSE
rangeLower: 2
rangeUpper: 128
schemaIdGuid:: vXAlU3c9T0KCLw1jbcbarQ==
dn:
changetype: modify
schemaUpdateNow: 1
dn: CN=RID-Manager,CN=Schema,CN=Configuration,DC=X
dn: CN=domainDNS-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
add: adminContextMenu
adminContextMenu: 3,{2fb1b669-59ea-4f64-b728-05309f2c11c8}
dn: CN=computer-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
add: adminPropertyPages
adminPropertyPages: 13,{2fb1b669-59ea-4f64-b728-05309f2c11c8}
dn: CN=Certificate-AutoEnrollment,CN=Extended-Rights,CN=Configuration,DC=X
appliesTo: e5209ca2-3bba-11d2-90cc-00c04fd91ab1
displayname: AutoEnrollment
rightsGuid: a05b8cc2-17bc-4802-a710-e7c15ab866a2
validAccesses: 256
# Update element: computer
add: mayContain
mayContain: 1.2.840.113556.1.4.2234
dn: CN=ms-DS-cloudExtensionAttribute1,CN=Schema,CN=Configuration,dc=X
cn: ms-DS-cloudExtensionAttribute1
lDAPDisplayName: msDS-cloudExtensionAttribute1
adminDisplayName: ms-DS-cloudExtensionAttribute1
adminDescription: An attribute used to house an arbitrary cloud-relevant

string
attributeID: 1.2.840.113556.1.4.2214
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: r+oJl9pJsk2QigRG5eq4RA==
attributeSecurityGUID:: hri1d0qU0RGuvQAA+ANnwQ==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2215
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: rOBO88HAqUuCyRqQdS8WpQ==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2216
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: Gsj2gtr6DUqw93BtRoOOtQ==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2217
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: NzS/nG5OW0iykSKwJVQnPw==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2218
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: W+gVKUfjUkiquyLlplHIZA==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2219
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: eSZFYOEo7Eus43EoMzYUVg==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2220
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: GRN8Sk7jwkCdAGD/eJDyBw==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2221
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: FMXRPEmEykSBwAIXgYANKg==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2222
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: LOFjCkAwQUSuJs2Vrw0kfg==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2223
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: s/wKZ70T/EeQswpSftgatw==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2224
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: yLuenqV9pkKJJSROEqVuJA==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2225
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: PcQBPAvhyk+Sskz2FdWwmg==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2226
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: S0a+KJCreUumsN9DdDHQNg==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2227
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: ura8zoBuJ0mFYJj+yghqnw==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2228
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: N9XkqvCKqk2cxmLq24T/Aw==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2229
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: WyGBlZZRU0ChHm/8r8YsTQ==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2230
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: 2m08PehrKUKWfi/1u5O0zg==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2231
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: NDvniKYKaUSYQm6wGzKltQ==
systemFlags: 16

string
attributeID: 1.2.840.113556.1.4.2232
oMSyntax: 64
systemOnly: FALSE
searchFlags: 1
schemaIDGUID:: mf51CQeWikaOGMgA0zhzlQ==
systemFlags: 16

string
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==
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
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
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
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
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
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-
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
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
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
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
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
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

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

(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

Number
attributeDisplayNames: sn,Last Name
attributeDisplayNames: st,State
dn: CN=domainPolicy-
changetype: modify
adminPropertyPages: 4,{AAD30A04-E1D0-11d0-B859-00A024CDD4DE}
dn: CN=serviceAdministrationPoint-
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-
changetype: modify
dn: CN=trustedDomain-
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

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
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
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
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
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
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
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
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
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
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
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
# 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
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
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-
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-
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
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
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
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

changetype: delete
dn: CN=Inter-Site Transports,CN=Site

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
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
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
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
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
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
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: 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

(Others)

Number (Others)
attributeDisplayNames: otherHomePhone,Home Phone (Others)

Number
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

Number
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: 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
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
transportDllName: ismip.dll
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: MaxNotificationPerConn=5
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
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-
# 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-
changetype: add
hideFromAB: TRUE
displayName: Manage Replication Topology
rightsGUID: 1131f6ac-9c07-11d1-f79f-00c04fc2dcd2
dn: CN=IntellimirrorGroup-
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{C641CF88-892F-11d1-BBEB-0060081692B3}
classDisplayName: IntelliMirror-Group
shellPropertyPages: 1,{C641CF88-892F-11d1-BBEB-0060081692B3}
dn: CN=IntellimirrorSCP-
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-
changetype: add
hideFromAB: TRUE
classDisplayName: Site Link Bridge
dn: CN=interSiteTransport-
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{6DFE6491-AC8D-11D0-B945-00C04FD8D5B0}
classDisplayName: Inter-Site Transport
dn: CN=licensingSiteSettings-
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{717ef500-ac8d-11d0-b945-00c04fd8d5b0}
classDisplayName: Licensing Site Settings
dn: CN=nTDSSiteSettings-
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-
changetype: add
hideFromAB: TRUE
adminPropertyPages: 1,{50d3055f-9911-11d1-b9af-00c04fd8d5b0}
classDisplayName: NTFRS Subscriber
dn: CN=nTFRSSubscriptions-
changetype: add
hideFromAB: TRUE
classDisplayName: NTFRS Subscriptions
dn: CN=rpcContainer-
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-
changetype: modify
dn: CN=nTDSDSA-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
changetype: modify
dn: CN=nTDSConnection-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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==
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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==
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
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
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
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
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-
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
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-
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-
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==
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-
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-
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-
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-
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-
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
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-
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-
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
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
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-
# 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
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-
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-
# 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
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
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: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
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
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
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
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-
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;;CC;;;AU)(A;;RPLCLORC;;;WD)S:(AU;SAFA;WDWOSDDTWPCRCCDCSW;;;WD)
(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
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
display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
dn: CN=localPolicy-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=nTDSDSA-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-
dn: CN=licensingSiteSettings-
dn: CN=nTFRSMember-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
dn: CN=container-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
dn: CN=rpcContainer-
dn: CN=volume-display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
dn: CN=sitesContainer-
dn: CN=interSiteTransportContainer-
dn: CN=subnetContainer-
dn: CN=serversContainer-
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-
add: creationWizard
creationWizard: {87b31390-d46d-11d1-8091-00a024c48131}
dn: CN=remoteStorageServicePoint-
replace: classDisplayName
classDisplayName: Remote Storage Service
adminContextMenu: 0,&Manage ...,RsAdmin.msc
adminContextMenu: 0,&Manage...,RsAdmin.msc
dn: CN=foreignSecurityPrincipal-
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

newrdn: Authenticated User
deleteoldrdn: 1
dn: CN=Authenticated User,CN=WellKnown Security

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
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
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
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-
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-
classDisplayName: MSMQ Configuration
dn: CN=mSMQEnterpriseSettings-
classDisplayName: MSMQ Enterprise

-
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
adminDescription: 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
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
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
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
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
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;;;SY)(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;;;SY)(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)
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
classDisplayName: Settings
dn: CN=nTDSDSA-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: Domain Controller Settings
classDisplayName: Connection
classDisplayName: FRS Settings
classDisplayName: FRS Replica Set

-
classDisplayName: Site Settings
dn: CN=nTFRSMember-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=X
classDisplayName: FRS Member
classDisplayName: FRS Subscriber
classDisplayName: FRS Subscriptions
dn: CN=nTDSService-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-
dn: CN=interSiteTransportContainer-
adminPropertyPages: 1,{6DFE6491-AC8D-11D0-B945-00C04FD8D5B0}
dn: CN=subnetContainer-
dn: CN=serversContainer-
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-
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,ia
s,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstora
ge,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclo
gon,scm,dcom,cifs,spooler,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-
dn: CN=mSMQEnterpriseSettings-
dn: CN=mSMQSettings-
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-
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
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
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-
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==
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=co
m
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=co
m
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=c
om
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=c
om
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=c
om
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=c
om
ldapDisplayName: 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,D
C=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,D
C=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=microsof
t,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=microsof
t,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=microsof
t,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=microsof
t,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=microso
ft,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=microso
ft,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=micros
oft,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=micr
osoft,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==
systemFlags: 16
dn: CN=MS-SQL-
InformationDirectory,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=mi
crosoft,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=microsof
t,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=microsof
t,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
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,D
C=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,D
C=com
dn: CN=MS-SQL-
OLAPCube,CN=Schema,CN=Configuration,DC=arobindg1,DC=nttest,DC=microsoft,DC=c
om
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=c
om
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;;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)
(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;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)
(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;;RS)(OA;;RPWP;bf967a7f-0de6-
11d0-a285-00aa003049e2;;CA)
(A;;RPLCLORC;;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)
defaultSecurityDescriptor: D:P(A;;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)
(A;CIOI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(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
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;BA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
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:
(AU;CIOISAFA;WDWOSDDTWPCRCCDCSW;;;WD)
(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
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
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

delete: systemFlags
dn: CN=Restricted Code,CN=WellKnown Security

add: systemFlags
dn: CN=Restricted Code,CN=WellKnown Security

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
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
(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;SW;f3a64788-5306-
11d1-a9c5-0000f80367c1;;PS)(OA;;RPWP;77B5B886-944A-11d1-AEBD-
0000F80367C1;;PS)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)
dn: CN=FT-Dfs,CN=Schema,CN=Configuration,DC=X
(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
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
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
dn: CN=Locality-Name,CN=schema,CN=configuration,DC=x
searchFlags: 17
dn: CN=Country-Name,CN=schema,CN=configuration,DC=x
searchFlags: 16
(A;;RPWPCRLCLOCCRCWDWOSW;;;DA)(A;CI;RPWPCRLCLOCCRCWDWOSDSW;;;BA)
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)S:
(AU;CISAFA;WDWOSDDTWPCRCCDCSW;;;WD)
(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;BA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
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-Configuration,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

Number (Others)
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

Number (Others)
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-
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
replace: rangeUpper
rangeUpper: 1024
(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;SW;f3a64788-5306-
11d1-a9c5-0000f80367c1;;PS)(OA;;RPWP;77B5B886-944A-11d1-AEBD-
0000F80367C1;;PS)(OA;;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd;;PS)
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,messeng
er,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman
,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,d
com,cifs,spooler,snmp,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)
defaultSecurityDescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
defaultSecurityDescriptor: D:(A;;CC;;;BA)
# 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
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
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==
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==
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==
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
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==
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==
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==
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
governsId: 1.2.840.113556.1.5.213
rdnAttId: 2.5.4.3
subClassOf: 2.5.6.0
schemaIdGuid:: eHCFq0IBBkSUWzTJtrEzcg==
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(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
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==
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==
systemOnly: FALSE
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==
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==
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==
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
schemaIdGuid:: FCRQB8r9UUiwShNkWxHSJg==
systemOnly: FALSE
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
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==
systemOnly: FALSE
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==
systemOnly: FALSE
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
SimplePolicyTemplate,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
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
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==
systemOnly: FALSE
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==
systemOnly: FALSE
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
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
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
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
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==
systemOnly: FALSE
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==
systemOnly: FALSE
defaultObjectCategory: CN=Application-
Version,CN=Schema,CN=Configuration,DC=X
systemFlags: 16
(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==
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==
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==
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
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
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==
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
ldapDisplayName: secretary
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
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;;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)
(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;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)
(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;;RS)(OA;;RPWP;bf967a7f-0de6-
11d0-a285-00aa003049e2;;CA)
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;;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;;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
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
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
dn: CN=carLicense,CN=Schema,CN=Configuration,DC=X
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
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
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-
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
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.
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
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;;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
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==
systemOnly: FALSE
defaultObjectCategory: CN=ms-ieee-80211-
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
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
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
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
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==
systemOnly: FALSE
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
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==
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==
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==
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==
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==
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==
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==
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==
systemOnly: FALSE
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-
displayName: Monitor Active Directory Replication
rightsGUID: f98340fb-7c5b-4cdb-a00b-2ebdfa115a96
validAccesses: 256
dn: CN=Update-Password-Not-Required-Bit,CN=Extended-
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-
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==
(A;;RPLCLORC;;;BA)(OA;;CR;4ecc03fe-ffc0-4947-b630-eb672a8a9dbc;;WD)
systemOnly: FALSE
defaultObjectCategory: CN=ms-DS-Quota-
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==
(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==
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
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==
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
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==
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
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
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
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
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
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==
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;DA)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;CO)
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==
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==
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==
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
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==
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==
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==
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
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
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==
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==
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==
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==
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==
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==
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==
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
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==
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==
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.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==
systemOnly: FALSE
defaultObjectCategory: CN=msSFU-30-NIS-Map-
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
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==
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==
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==
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
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 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
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
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
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
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==
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==
systemOnly: FALSE
defaultObjectCategory: CN=ms-net-ieee-80211-
GroupPolicy,CN=Schema,CN=Configuration,DC=X
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==
systemOnly: FALSE
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
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-
replace: localizationDisplayId
dn: cn=Read-Only-Replication-Secret-Synchronization,CN=Extended-
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
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
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
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
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 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
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-
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 Volume Encryption (FVE) was the pre-release
name for BitLocker Drive Encryption.
add: rangeUpper
rangeUpper: 256
searchFlags: 152
adminDescription: This attribute contains the GUID associated with a

BitLocker recovery password. Full Volume Encryption (FVE) was the pre-
release name for BitLocker Drive Encryption.
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
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
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==
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
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
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-
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-
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-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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-
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-
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
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==
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
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==
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==
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;CO)
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
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==
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==
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

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

Read-Only Domain Controller Updates
Article • 07/29/2021
There are no changes to adprep /rodcprep in Windows Server 2012 R2 or in Windows

Server 2012.
Domain-wide schema updates
Article • 05/17/2023
You can review the following set of changes to help understand and prepare for the schema updates performed by adprep /domainprep in
Windows Server.
Beginning in Windows Server 2012, Adprep commands run automatically as needed during AD DS installation. They can also be run
separately in advance of AD DS installation. For more information, see Running Adprep.exe.
For more information about how to interpret the access control entry (ACE) strings, see ACE strings. For more information about how to
interpret the security ID (SID) strings, see SID strings.
Windows Server (Semi-Annual Channel): Domain-wide updates

After the operations that are performed by domainprep in Windows Server 2016 (operation 89) complete, the revision attribute for the
CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=ForestRootDomain object is set to 16.
Operations number and Description Permissions

GUID
Operation 89: Delete the ACE granting Full Control to Enterprise Key Admins and Delete
{A0C238BA-9E30-4EE6- add an ACE granting Enterprise Key Admins Full Control over just the (A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;Enterprise
80A6-43F731E9A5CD} msdsKeyCredentialLink attribute. Key Admins)
Add (OA;CI;RPWP;5b47d60f-6090-40b2-9f37-
2a4de88f3063;;Enterprise Key Admins)
Windows Server 2016: Domain-wide updates

After the operations that are performed by domainprep in Windows Server 2016 (operations 82-88) complete, the revision attribute for the
CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=ForestRootDomain object is set to 15.
Operations Description Attributes Permissions

number and
GUID
Operation 82: Create CN=Keys container at root of domain - objectClass: container

(A;CI;RPWPCRLCLOCCDCRCWDWOSD
{83C53DA7- - description: Default container for key credential objects
427E-47A4- - ShowInAdvancedViewOnly: TRUE (A;CI;RPWPCRLCLOCCDCRCWDWOSD
A07A- (A;CI;RPWPCRLCLOCCDCRCWDWOSD
A324598B88F7} (A;CI;RPWPCRLCLOCCDCRCWDWOSD
Operation 83: Add Full Control allow aces to CN=Keys N/A (A;CI;RPWPCRLCLOCCDCRCWDWOSD
{C81FC9CC- container for "domain\Key Admins" and Admins)
0130-4FD1- "rootdomain\Enterprise Key Admins". (A;CI;RPWPCRLCLOCCDCRCWDWOSD

B272- Key Admins)
634D74818133}
Operation 84: Modify otherWellKnownObjects attribute to - otherWellKnownObjects: N/A

{E5F9E791- point to the CN=Keys container. B:32:683A24E2E8164BD3AF86AC3C2CF3F981:CN=Keys,%ws
D96D-4FC9-
93C9-
D53E1DC439BA}
Operation 85: Modify the domain NC to permit N/A (OA;CI;RPWP;5b47d60f-6090-40b2-9f

{e6d5fd00- "domain\Key Admins" and 2a4de88f3063;;Key Admins)
385d-4e65- "rootdomain\Enterprise Key Admins" to (OA;CI;RPWP;5b47d60f-6090-40b2-9f

b02d- modify the msds-KeyCredentialLink 2a4de88f3063;;Enterprise Key Admins
9da3493ed850} attribute. but in nonroot domains resulted in a
relative ACE with a nonresolvable -52
Operations Description Attributes Permissions
number and
GUID
Operation 86: Grant the DS-Validated-Write-Computer N/A (OA;CIIO;SW;9b026da6-0d3c-465c-8b

{3a6b3fbf-3168- CAR to creator owner and self 5199d7165cba;bf967a86-0de6-11d0-
4312-a10d- 00aa003049e2;PS)
dd5b3393952d} (OA;CIIO;SW;9b026da6-0d3c-465c-8b
5199d7165cba;bf967a86-0de6-11d0-
00aa003049e2;CO)
Operation 87: Delete the ACE granting Full Control to the N/A Delete
{7F950403- incorrect domain-relative Enterprise Key (A;CI;RPWPCRLCLOCCDCRCWDWOSD
0AB3-47F9- Admins group, and add an ACE granting Full Key Admins)
9730- Control to Enterprise Key Admins group.

5D7B0269F9BD} Add
Key Admins)
Operation 88: Add "msDS- N/A N/A

{434bb40d- ExpirePasswordsOnSmartCardOnlyAccounts"
dbc9-4fe7- on the domain NC object and set default
81d4- value to FALSE
d57229f7b080}
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 CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=ForestRootDomain object is set to 10.
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 CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=ForestRootDomain object is set to 9.
Operations number and Description Attributes Permissions

GUID
Operation 78: {c3c927a6- Create a new object CN=TPM Devices in the Object class: msTPM- N/A
cc1d-47c0-966b- Domain partition. InformationObjectsContainer
be8f9b63d991}
Operation 79: {54afcfb9- Created an access control entry for the TPM N/A (OA;CIIO;WP;ea1b7b93-5e48-46d5-bc6c-
637a-4251-9f47- service. 4df4fda78a35;bf967a86-0de6-11d0-a285-
4d50e7021211} 00aa003049e2;PS)
Operation 80: {f4728883- Grant "Clone DC" extended right to N/A (OA;;CR;3e0f7e18-2c7a-4c10-ba82-
84dd-483c-9897- Cloneable Domain Controllers group 4d926db99a3e;;domain SID-522)
274f2ebcf11e}
Operation 81: {ff4f9d27- Grant ms-DS-Allowed-To-Act-On-Behalf-Of- N/A (OA;CIOI;RPWP;3f78c3e5-f79a-46bd-a0b8-

7157-4cb0-80a9- Other-Identity to Principal Self on all 9d18116ddc79;;PS)
5d6f2b14c8ff} objects.
Forest-Wide Updates
Article • 05/22/2023
Applies to: Windows Server: (All supported versions)
You can review the following set of changes to help understand and prepare for the schema updates that are performed when running
adprep /forestprep on 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.
） Important
Forest-wide schema updates are performed cumulatively by adprep . For example, operations 131 - 135 are performed before
operations 136 - 142.
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 are performed by the /forestprep switch in Windows Server 2016 (operations 136-142) are complete, the revision
attribute for the CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain object is set to 16.
Operation number and GUID Description Attributes Permissions
Operation 136: {328092FB-16E7-4453-9AB8- Granting the CN=Send-As,CN=Extended-Rights to gMSA accounts. N/A N/A
7592DB56E9C4}
Operation 137: {3A1C887F-DF0A-489F-B3F2- Granting the CN=Receive-As,CN=Extended-Rights to gMSA accounts. N/A N/A
2D0409095F6E}
Operation 138: {232E831F-F988-4444-8E3E- Granting the CN=Personal-Information,CN=Extended-Rights to gMSA N/A N/A

8A352E2FD411} accounts.
Operation 139: {DDDDCF0C-BEC9-4A5A-AE86- Granting the CN=Public-Information,CN=Extended-Rights to gMSA N/A N/A

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

3CC5C46B52F2} accounts.
Operation 141: {3E7645F3-3EA5-4567-B35A- Granting the CN=Allowed-To-Authenticate,CN=Extended-Rights to N/A N/A

87630449C70C} gMSA accounts.
Operation 142: {E634067B-E2C4-4D79-B6E8- Granting the CN=MS-TS-GatewayAccess,CN=Extended-Rights to gMSA N/A N/A

73C619324D5E} accounts.
Windows Server 2012 R2: Forest-wide updates

After the operations are performed by the /forestprep switch in Windows Server 2012 R2 (operations 131-135) are complete, the
revision attribute for the CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain object is set to 15.
Operation Description Attributes Permissions

number and
GUID
Operation 131: Created a new authentication policy configuration - objectClass: container

(A;;RPLCLORC;;;AU)
{b83818c1-01a6- container object CN=AuthN Policy - displayName: Authentication (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
4f39-91b7- Configuration,CN=Services in the Configuration Policy Configuration

a3bb581c3ae3} partition. - description: Contains
configuration for
authentication policy.
- showInAdvancedViewOnly: True
number and
GUID
Operation 132: Created a new authentication policies object - objectClass: msDS- (A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;EA)
{bbbb9db0-4009- CN=AuthN Policies,CN=AuthN Policy AuthNPolicies

4368-8c40- Configuration,CN=Services in the Configuration - displayName: Authentication (A;;RPLCLORC;;;AU)

6674e980d3c3} partition. Policies
- description: Contains
authentication policy
objects.
Operation 133: Created a new authentication policy silos object - objectClass: msDS- (A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;EA)
{f754861c-3692- CN=AuthN Silos,CN=AuthN Policy AuthNPolicySilos

4a7b-b2c2- Configuration,CN=Services in the Configuration - displayName: Authentication (A;;RPLCLORC;;;AU)

d0fa28ed0b0b} partition. Policy Silos
- description: Contains
authentication policy silo
objects.
Operation 134: Created a new authentication silo claim type - objectClass: msDS-ClaimType
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;EA)
{d32f499f-3026- object CN=ad://ext/AuthenticationSilo,CN=Claim - displayname: (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
4af0-a5bd- Types,CN=Claims Configuration,CN=Services in the AuthenticationSilo

(A;;RPLCLORC;;;AU)
13fe5a331bd2} Configuration partition. - name:
ad://ext/AuthenticationSilo
- Enabled: True
- msDS-
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-ClaimIsValueSpaceRestricted - msDS- N/A

{38618886-98ee- attribute on new authentication silo claim type to ClaimIsValueSpaceRestricted:
4e42-8cf1- false False
d9a2cd9edf8b}
Windows Server 2012: Forest-wide updates

After the operations are performed by the /forestprep switch in Windows Server 2012 (operations 84-130) are complete, the revision
attribute for the CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain object is set to 11.

number and
GUID
number and
GUID
Operation 84: Created a new container CN=Claims - objectClass: container (A;;RPLCLORC;;;AU)
{4664e973- Configuration,CN=Services in the (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
cb20-4def- Configuration partition. (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

b3d5-
559d6fe123e0}
Operation 85: Created a new object CN=Claim - objectClass: msDS-ClaimTypes

(A;;RPLCLORC;;;AU)
{2972d92d- Types,CN=Claims Configuration,CN=Services in - showInAdvancedViewOnly: True (A;;RPWPCRLCLOCCDCRCWDWOSW;;;EA)
a07a-44ac- the Configuration partition. (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

9cb0-
bf243356f345}
Operation 86: Created a new object CN=Resource - objectClass: msDS-ResourceProperties

(A;;RPLCLORC;;;AU)
{09a49cb3- Properties,CN=Claims - showInAdvancedViewOnly: True (A;;RPWPCRLCLOCCDCRCWDWOSW;;;EA)
6c54-4b83- Configuration,CN=Services in the (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

ab20- Configuration partition.
8370838ba149}
Operation 87: Created a new container CN=Resource Property - objectClass: container

(A;;RPLCLORC;;;AU)
{77283e65- Lists,CN=Claims Configuration,CN=Services in - showInAdvancedViewOnly: True (A;;RPWPCRLCLOCCDCRCWDWOSW;;;EA)
ce02-4dc3- the Configuration partition. (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

8c1e-
bf99b22527c2}
Operation 88: Created a new object CN=Sam-Domain in the N/A Created the following access control
{0afb7f53- Schema partition. entry (ACE) to grant Write Property to
96bd-404b- Principal Self on the object:
a659- (OA;CIIO;WP;ea1b7b93-5e48-46d5-bc6c-
89e65c269420} 4df4fda78a35;bf967a86-0de6-11d0-
a285-00aa003049e2;PS)
Operation 89: Created a new object CN=Domain-DNS in the N/A Created the following access control
{c7f717ef-fdbe- Schema partition. entry (ACE) to grant Write Property to
4b4b-8dfc- Principal Self on the object:
fa8b839fbcfa} (OA;CIIO;WP;ea1b7b93-5e48-46d5-bc6c-
4df4fda78a35;bf967a86-0de6-11d0-
a285-00aa003049e2;PS)
Operation 90: Call back function to upgrade display N/A N/A

{00232167- specifiers.
f3a4-43c6-
b503-
9acb7a81b01c}
Operation 91: Created a new container CN=Microsoft - objectClass: container

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

(A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
2ed7-4fd3- SPP,CN=Services in the Configuration partition. - showInAdvancedViewOnly: True (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

8659-
7655a7e79397}
Operation 93: Created a new Central Access Policies - objectClass: msAuthz-CentralAccessPolicies

(A;;RPLCLORC;;;AU)
{ed0c8cca- container CN=Central Access - showInAdvancedViewOnly: True (A;;RPWPCRLCLOCCDCRCWDWOSW;;;EA)
80ab-4b6b- Policies,CN=Claims Configuration,CN=Services (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

ac5a- in the Configuration partition.
59b1d317e11f}
Operation 94: Created a new Central Access Policy Entries - objectClass: msAuthz-CentralAccessRules
(A;;RPLCLORC;;;AU)
{b6a6c19a- container CN=Central Access Rules,CN=Claims - showInAdvancedViewOnly: True (A;;RPWPCRLCLOCCDCRCWDWOSW;;;EA)
afc9-476b- Configuration,CN=Services in the (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

8994- Configuration partition.
61f5b14b3f05}
number and
GUID
Operation 95: Created a new Group Key Distribution service - objectClass: container
(A;;RPLCLORC;;;AU)
{defc28cd- container CN=Group Key Distribution - description: The container contains (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
6cb6-4479- Service,CN=Services in the Configuration configuration and data for Group Key (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
8bcb- partition. Distribution Service.
aabfb41e9713} - showInAdvancedViewOnly: True
Operation 96: Created a new Master Root Keys container - objectClass: container
(A;;RPLCLORC;;;AU )
{d6bd96d4- CN=Master Root Keys,CN=Group Key - description: The container contains master (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
e66b-4a38- Distribution Service,CN=Services in the root keys for Group Key Distribution Service.
9c6b- Configuration partition. - showInAdvancedViewOnly: True
e976ff58c56d}
Operation 97: Created a new Server Configuration container - objectClass: container

(A;;RPLCLORC;;;AU)
{bb8efc40- CN=Server Configuration,CN=Group Key - description: The container contains Group Key (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
3090-4fa2- Distribution Service,CN=Services in the Distribution Service configurations.

8a3f- Configuration partition. - showInAdvancedViewOnly: True
7cd1d380e695}
Operation 98: Created a new Empty server configuration - objectClass: msKds-ProvServerConfiguration

(A;;RPLCLORC;;;AU)
{2d6abe1b- objects container CN=Group Key Distribution - description: The configuration of (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
4326-489e- Service Server Configuration,CN=Server cryptography algorithms used by Group Key (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
920c- Configuration,CN=Group Key Distribution Distribution Service.
76d5337d2dc5} Service,CN=Services in the Configuration - msKds-Version: 1
partition. - showInAdvancedViewOnly: True
Operation 99: Created a new Claims Transformation Policies - objectClass: msDS- (A;;RPLCLORC;;;AU)
{6b13dfb5- configuration container CN=Claims ClaimsTransformationPolicies

(A;;RPWPCRLCLOCCDCRCWDWOSW;;;EA)
cecc-4fb8- Transformation Policies,CN=Claims - showInAdvancedViewOnly: True (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

b28d- Configuration,CN=Services in the
0505cea24175} Configuration partition.
Operation 100: Created a new Value Types configuration - objectClass: container

(A;;RPLCLORC;;;AU)
{92e73422- container CN=Value Types,CN=Claims - showInAdvancedViewOnly: True (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
c68b-46c9- Configuration,CN=Services in the (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

b0d5- Configuration partition.
b55f9c741410}
Operation 101: Created a new SinglevaluedChoice value type - objectClass: msDS-ValueType

(D;;SDDT;;;WD)
{c0ad80b4- configuration object CN=MS-DS- - description: You can use this type to author (A;;RPLCLORC;;;AU)
8e84-4cc4- SinglevaluedChoice,CN=Value Types,CN=Claims a resource property. When assigning value to a (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
9163- Configuration,CN=Services in the resource property of this value type, a user (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
2f84649bcc42} Configuration partition. can choose only one entry from a list of
suggested values.
- displayname: Single-valued Choice
- msDS-ClaimIsValueSpaceRestricted: True
- msDS-ClaimIsSingleValued: True
- msDS-IsPossibleValuesPresent: True
Operation 102: Created a new YesNo value type configuration - objectClass: msDS-ValueType
(D;;SDDT;;;WD)
{992fe1d0- object CN=MS-DS-YesNo,CN=Value - description: The valid values for this type (A;;RPLCLORC;;;AU)
6591-4f24- Types,CN=Claims Configuration,CN=Services in are Yes or No.

a163- the Configuration partition. - displayname: Yes/No

c820fcb7f308} - msDS-ClaimValueType: 6
- msDS-ClaimIsValueSpaceRestricted: False
- msDS-IsPossibleValuesPresent: False
number and
GUID
Operation 103: Created a new Number value type - objectClass: msDS-ValueType

(D;;SDDT;;;WD)
{ede85f96- configuration object CN=MS-DS-Number,CN=Value - description: You can use this type to author (A;;RPLCLORC;;;AU)
7061-47bf- Types,CN=Claims Configuration,CN=Services in resource properties that contain a single (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
b11b- the Configuration partition. number.

0c0d999595b5} - displayname: Number
Operation 104: Created a new DateTime value type - objectClass: msDS-ValueType

(D;;SDDT;;;WD)
{ee0f3271- configuration object CN=MS-DS- - description: You can use this type to author (A;;RPLCLORC;;;AU)
eb51-414a- DateTime,CN=Value Types,CN=Claims resource properties that are of the date and (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
bdac- Configuration,CN=Services in the time format.

8f9ba6397a39} Configuration partition. - displayname: Date Time
Operation 105: Created a new OrderedList value type - objectClass: msDS-ValueType

(D;;SDDT;;;WD)
{587d52e0- configuration object CN=MS-DS- - description: You can use this type to author (A;;RPLCLORC;;;AU)
507e-440e- OrderedList,CN=Value Types,CN=Claims resource properties that contain a single (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
9d67- Configuration,CN=Services in the choice entry that can be compared to other (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
e6129f33bb68} Configuration 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
Operation 106: Created a new Text value type configuration - objectClass: msDS-ValueType
(D;;SDDT;;;WD)
{ce24f0f6- object CN=MS-DS-Text,CN=Value - description: You can use this type to author (A;;RPLCLORC;;;AU)
237e-43d6- Types,CN=Claims Configuration,CN=Services in resource properties that contain a single text (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
ac04- the Configuration partition. entry.

1e918ab04aac} - displayname: Text
Operation 107: Created a new MultivaluedText value type - objectClass: msDS-ValueType

(D;;SDDT;;;WD)
{7f77d431- configuration object CN=MS-DS- - description: You can use this type to author (A;;RPLCLORC;;;AU)
dd6a-434f- MultivaluedText,CN=Value Types,CN=Claims resource properties that can have multiple text (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
ae4d- Configuration,CN=Services in the entries.

ce82928e498f} Configuration partition. - displayname: Multi-valued Text<br />- msDS-
ClaimValueType: 3<br />- msDS-
ClaimIsValueSpaceRestricted: False<br />- msDS-
ClaimIsSingleValued: False<br />- msDS-
IsPossibleValuesPresent: False<br />-
showInAdvancedViewOnly: True
number and
GUID
Operation 108: Created a new MultivaluedChoice value type - objectClass: msDS-ValueType

(D;;SDDT;;;WD)
{ba14e1f6- configuration object CN=MS-DS- - description: You can use this type to author (A;;RPLCLORC;;;AU)
7cd1-4739- MultivaluedChoice,CN=Value Types,CN=Claims resource properties that can have multiple (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
804f- Configuration,CN=Services in the entries that can't be compared. A user (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

57d0ea74edf4} Configuration partition. typically chooses each entry from a list of
suggested values that are provided by ms-DS-
Claim-Possible-Values on the resource
properties.
- displayname: Multi-valued Choice
- msDS-ClaimIsSingleValued: False
Operation 109: Created a new Personally Identifiable - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{156ffa2a- Information resource property object - description: The Personally Identifiable (A;;RPLCLORC;;;AU)
e07c-46fb- CN=PII_MS,CN=Resource Properties,CN=Claims Information (PII) property specifies whether (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
a5c4- Configuration,CN=Services in the the resource contains PII and if it does, what (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
fbd84a4e5cce} Configuration partition. the sensitivity level of that information is.
- displayname: Personally Identifiable

Information
- Enabled: False
- msDS-IsUsedAsResourceSecurityAttribute: True
- msDS-ValueTypeReference: CN=MS-DS-
OrderedList,CN=Value Types,CN=Claims
Configuration,CN=Services,CN=Configuration,CN=\
<forest root domain>
Operation 110: Created a new Protected Health Information - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{7771d7dd- resource property object - description: The Protected Health Information (A;;RPLCLORC;;;AU)
2231-4470- CN=ProtectedHealthInformation_MS,CN=Resource (PHI) property specifies whether the resource (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
aa74- Properties,CN=Claims contains any data related to an individual's (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

84a6f56fc3b6} Configuration,CN=Services in the medical record or medical payment history.
Configuration partition. - displayname: Protected Health Information
- Enabled: False
YesNo,CN=Value Types,CN=Claims
Operation 111: Created a new Required Clearance resource - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{49b2ae86- property object - description: The Required Clearance property (A;;RPLCLORC;;;AU)
839a-4ea0- CN=RequiredClearance_MS,CN=Resource specifies the level of clearance a user should (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
81fe- Properties,CN=Claims possess before attempting to access the (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

9171c1b98e83} Configuration,CN=Services in the resource.
Configuration partition. - displayname: Required Clearance
- Enabled: False
number and
GUID
Operation 112: Created a new Confidentiality resource - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{1b1de989- property object - description: The Confidentiality property (A;;RPLCLORC;;;AU)
57ec-4e96- CN=Confidentiality_MS,CN=Resource specifies the level of confidentiality of the (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
b933- Properties,CN=Claims resource, and the potential impact of (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

8279a8119da4} Configuration,CN=Services in the inadvertent access or disclosure.
Configuration partition. - displayname: Confidentiality
- Enabled: False
Operation 113: Created a new Compliancy resource property - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{281c63f0- object CN=Compliancy_MS,CN=Resource - description: The Compliancy property (A;;RPLCLORC;;;AU)
2c9a-4cce- Properties,CN=Claims specifies the compliance frameworks that apply (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
9256- Configuration,CN=Services in the to the resource.

a238c23c0db9} Configuration partition. - displayname: Compliancy
- Enabled: False
MultivaluedChoice,CN=Value Types,CN=Claims
Operation 114: Created a new Discoverability resource - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{4c47881a- property object - description: The Discoverability property (A;;RPLCLORC;;;AU)
f15a-4f6c-9f49- CN=Discoverability_MS,CN=Resource specifies whether the resource contains (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
2742f7a11f4b} Properties,CN=Claims potential evidence that might require (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

Configuration,CN=Services in the disclosure to opposing legal counsel during the
Configuration partition. course of current or future litigation.
- displayname: Discoverability
- Enabled: False
SinglevaluedChoice,CN=Value Types,CN=Claims
Operation 115: Created a new Immutable resource property - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{2aea2dc6- object CN=Immutable_MS,CN=Resource - description: The Immutable property specifies (A;;RPLCLORC;;;AU)
d1d3-4f0c- Properties,CN=Claims whether a user should be allowed to delete a (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
9994- Configuration,CN=Services in the resource or change its contents.

66c1da21de0f} Configuration partition. - displayname: Immutable
- Enabled: False
Operation 116: Created a new Intellectual Property resource - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{ae78240c- property object - description: The Intellectual Property (IP) (A;;RPLCLORC;;;AU)
43b9-499e- CN=IntellectualProperty_MS,CN=Resource property specifies whether the resource (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
ae65- Properties,CN=Claims contains IP, and if so, what kind.

2b6e0f0e202a} Configuration,CN=Services in the - displayname: Intellectual Property
Configuration partition. - Enabled: False
number and
GUID
Operation 117: Created a new Department resource property - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{261b5bba- object CN=Department_MS,CN=Resource - description: The Department property (A;;RPLCLORC;;;AU)
3438-4d5c- Properties,CN=Claims specifies the name of the department to which (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
a3e9- Configuration,CN=Services in the the resource belongs.

7b871e5f57f0} Configuration partition. - displayname: Department
- Enabled: False
Operation 118: Created a new Impact resource property object - objectClass: msDS-ResourceProperty
(D;;SDDT;;;WD)
{3fb79c05- CN=Impact_MS,CN=Resource - description: The Impact property specifies (A;;RPLCLORC;;;AU)
8ea1-438c- Properties,CN=Claims the degree of organizational impact from (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
8c7a- Configuration,CN=Services in the inappropriate access or loss of the resource.

81f213aa61c2} Configuration partition. - displayname: Impact
- Enabled: False
<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 resource property - objectClass: msDS-ResourceProperty
(D;;SDDT;;;WD)
{0b2be39a- object CN=PersonalUse_MS,CN=Resource - description: The Personal Use property (A;;RPLCLORC;;;AU)
d463-4c23- Properties,CN=Claims specifies whether the file is for personal use (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
8290- Configuration,CN=Services in the (not business related).

32186759d3b1} Configuration partition. - displayname: Personal Use
- Enabled: False
Operation 120: Created a new Project resource property - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{f0842b44- object CN=Project_MS,CN=Resource - description: The Project property specifies (A;;RPLCLORC;;;AU)
bc03-46a1- Properties,CN=Claims the names of one or more projects that are (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
a860- Configuration,CN=Services in the relevant to the resource.

006e8527fccd} Configuration partition. - displayname: Project
- Enabled: False
Operation 121: Created a new Retention Period resource - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{93efec15- property object - description: The Retention Period property (A;;RPLCLORC;;;AU)
4dd9-4850- CN=RetentionPeriod_MS,CN=Resource specifies the maximum period for which the file (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
bc86- Properties,CN=Claims should be retained.

a1f2c8e2ebb9} Configuration,CN=Services in the - displayname: Retention Period
Configuration partition. - Enabled: False
number and
GUID
Operation 122: Created a new Retention Start Date resource - objectClass: msDS-ResourceProperty
(D;;SDDT;;;WD)
{9e108d96- property object - description: The Retention Start Date (A;;RPLCLORC;;;AU)
672f-40f0- CN=RetentionStartDate_MS,CN=Resource property defines the starting date for a (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
b6bd- Properties,CN=Claims Retention Period. The retention period would (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

69ee1f0b7ac4} Configuration,CN=Services in the begin on the Retention Start Date.
Configuration partition. - displayname: Retention Start Date
- Enabled: False
- msDS-IsUsedAsResourceSecurityAttribute:
False
DateTime,CN=Value Types,CN=Claims
Operation 123: Created a new Company resource property - objectClass: msDS-ResourceProperty

(D;;SDDT;;;WD)
{1e269508- object CN=Company_MS,CN=Resource - description: The Company property specifies (A;;RPLCLORC;;;AU)
f862-4c4a- Properties,CN=Claims which company the resource belongs to.

b01f- Configuration,CN=Services in the - displayname: Company

420d26c4ff8c} Configuration partition. - Enabled: False
Operation 125: Created a new Folder Usage resource property - objectClass: msDS-ResourceProperty
(D;;SDDT;;;WD)
{e1ab17ed- object CN=FolderUsage_MS,CN=Resource - description: The Folder Usage property (A;;RPLCLORC;;;AU)
5efb-4691- Properties,CN=Claims specifies the purpose of the folder and the (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
ad2d- Configuration,CN=Services in the kind of files stored in it.

0424592c5755} Configuration partition. - displayname: Folder Usage
Note: - Enabled: False
Operation 124 - msDS-IsUsedAsResourceSecurityAttribute:

was deleted. False
- msDS-AppliestoResourceTypes: MS-DS-Container
Operation 126: Created a new Global Resource Property List - objectClass: msDS-ResourcePropertyList
(D;;SDDT;;;WD)
{0e848bd4- configuration object CN=Global Resource - description: This is a global out of box (A;;RPLCLORC;;;AU)
7c70-48f2- Property List,CN=Resource Property resource property list that contains all (A;;RPWPCRLCLOCCRCWDWOSW;;;EA)
b8fc- Lists,CN=Claims Configuration,CN=Services in resource properties that can be consumed by (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)

00fbaa82e360} the Configuration partition. applications.
- msDS-MembersOfResourcePropertyList:
CN=PII_MS,CN=Resource Properties,CN=Claims
CN=ProtectedHealthInformation_MS,CN=Resource
CN=RequiredClearance_MS,CN=Resource
CN=Confidentiality_MS,CN=Resource
CN=Compliancy_MS,CN=Resource
number and
GUID
CN=Discoverability_MS,CN=Resource
CN=Immutable_MS,CN=Resource
CN=IntellectualProperty_MS,CN=Resource
CN=Department_MS,CN=Resource
CN=Impact_MS,CN=Resource Properties,CN=Claims
CN=PersonalUse_MS,CN=Resource
CN=Project_MS,CN=Resource Properties,CN=Claims
CN=RetentionPeriod_MS,CN=Resource
CN=RetentionStartDate_MS,CN=Resource
CN=Company_MS,CN=Resource Properties,CN=Claims
CN=FolderUsage_MS,CN=Resource
Operation 127: Call back function to upgrade display N/A N/A

{016f23f7- specifiers.
077d-41fa-
a356-
de7cfdb01797}
number and
GUID
Operation 128: Updated strings for Folder Usage resource - description: The Folder Usage property N/A
{49c140db- property object specifies the purpose of the folder and the
2de3-44c2- CN=FolderUsage_MS,CN=Resource kind of files stored in it.
a99a- Properties,CN=Claims
bab2e6d2ba81} Configuration,CN=Services in the
Configuration partition.
Operation 129: Added ACE to grant Principal Self Write N/A (OA;CIOI;RPWP;3f78c3e5-f79a-46bd-
{e0b11c80- Property and Read Property on CN=Sam-Domain a0b8-9d18116ddc79;;PS)
62c5-47f7- object.
ad0d-
3734a71b8312}
Operation 130: Added ACE to grant Principal Self Write N/A (OA;CIOI;RPWP;3f78c3e5-f79a-46bd-
{2ada1a2d- Property and Read Property on CN=Domain-DNS a0b8-9d18116ddc79;;PS)
b02f-4731- object.
b4fe-
59f955e24f71}
Troubleshooting Domain Controller
Deployment
Article • 05/17/2023
Try our Virtual Agent - It can help you quickly identify and fix common Active
Directory replication issues.
This article 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.
Phase Log
Phase Log
Server Manager or ADDSDeployment - %systemroot%\debug\dcpromoui.log

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

controller - %systemroot%\debug\dcpromo*.log
- Event viewer\Windows logs\System
- Event viewer\Windows logs\Application
- Event viewer\Applications and services logs\Directory

Service
- Event viewer\Applications and services logs\File

Replication Service
- Event viewer\Applications and services logs\DFS

Replication
Forest or domain upgrade - %systemroot%\debug\adprep\<datetime>\adprep.log

- %systemroot%\debug\adprep\<datetime>\csv.log
- %systemroot%\debug\adprep\<datetime>\dspecup.log
- %systemroot%\debug\adprep\<datetime>\ldif.log*
Server Manager ADDSDeployment - Event viewer\Applications and services

Windows PowerShell deployment logs\Microsoft\Windows\DirectoryServices-
engine Deployment\Operational
Windows Servicing - %systemroot%\Logs\CBS\*

- %systemroot%\servicing\sessions\sessions.xml
- %systemroot%\winsxs\poqexec.log
- %systemroot%\winsxs\pending.xml
Tools and Commands for Troubleshooting Domain

Controller Configuration
point:
Dcdiag.exe
Repadmin.exe
AutoRuns.exe, Task Manager, and MSInfo32.exe

Network Monitor 3.4 (or a third party network capture and analysis tool)

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's
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're 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.
i. Always compare to a working sample log
ii. Examine the ADPrep logs for errors only if the results indicate a problem
extending the schema or preparing the forest or domain.
iii. 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, 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.
i. Remove third party software (don't simply disable the software; that doesn't
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.
i. Compare this to your working lab environment to understand what a healthy

promotion looks like and where it's failing.
ii. At this point, the errors are likely with the forest objects, nondefault 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, don't 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 10 seconds prior
to automatic reboot.
2. When using ADDSDeployment Windows PowerShell, examine the promotion results

in the 10 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 don't continue on to a reboot, so

they're 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
Error Explanation Note

Code
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 noncritical Typically seen when returning the DNS Delegation
failure warning. If not configuring DNS delegation, use:
-creatednsdelegation:$false
Error Explanation Note
Code
4 Exit, success, with a noncritical Typically seen when returning the DNS Delegation
failure, need to reboot warning. If not configuring DNS delegation, use:
-creatednsdelegation:$false
Promotion and demotion failure codes

Promotion and demotion return the following failure message codes. There's also likely to
be an extended error message; always read the entire error carefully, not just the numeric
portion.
Error Explanation Suggested resolution

Code
11 Domain controller Don't run more than one instance of domain controller
promotion is already promotion at the same time for the same target computer
running
12 User must be administrator Logon as a member of the built-in Administrators group and
ensure you're elevating with UAC
13 Certification Authority is You can't demote this domain controller, as it's also a
installed Certification Authority. Don't remove the CA before you
carefully inventory its usage - if it's 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 You must restart the server (due to prior configuration
or needs reboot 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, Reboot the server

needs reboot
20 Computer name is invalid Rename the computer with a valid name

syntax
Code
21 This domain controller Add -demoteoperationmasterrole when using -

holds FSMO roles, is a GC, forceremoval.
and/or is a DNS server
22 TCP/IP needs to be installed Verify computer has TCP/IP configured, bound, and working
or isn't functioning correctly
23 DNS client needs to be Set a primary DNS server when adding a new domain
configured first controller to a domain
24 Supplied credentials are Verify your user name and password is correct
invalid or missing required
elements
25 Domain controller for the Validate DNS client settings, firewall rules
specified domain could not
be located
26 List of domains could not Validate DNS client settings, LDAP functionality, firewall rules
be read from the forest
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 Verify the parent domain specified when creating a new child
exist 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 Validate your path to the Install From Media folder
invalid
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 Change path of Database and Logs to a fixed NTFS volume,
its logs is invalid not a mapped drive or UNC path
38 Volume does not have Free up space using cleanmgr.exe, add more disk space,
enough space for NTDS manually clear space by moving unnecessary data elsewhere
database or logs
Code
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 Provide a password for the DSRM account, it cannot be blank
for safe-mode no matter how the password policy is configured
42 Safe-mode password does Provide a password for the DSRM account that meets the
not meet criteria password policy's configured rules
(promotion only)
43 Admin password does not Provide a password for the local administrator account that
meet criteria (demotion meets the password policy's configured rules
only)
44 The specified name for the Specify a valid forest root DNS domain name
forest is invalid
45 A forest with the specified Choose a different forest root DNS domain name
name already exists
46 The specified name for the Specify a valid tree DNS domain name
tree is invalid
47 A tree with the specified Choose a different tree DNS domain name
name already exists
48 The tree name does not fit Choose a different tree DNS domain name
into the forest structure
49 The specified domain does Verify your typed domain name

not exist
50 During demote, last domain Do not specify Last Domain Controller in the Domain (-
controller was detected lastdomaincontrollerindomain) unless it is true. Use -
even though it is not, or last ignorelastdcindomainmismatch to override if this is truly the
domain controller was last domain controller and there's phantom domain
specified, but it is not controller metadata
51 App partitions exist on this Specify to Remove Application Partitions (-

domain controller removeapplicationpartitions)
52 Required command-line Only seen with dcpromo /unattend, which is deprecated. See
argument is missing (that is, older documentation
an answer file must be
specified on the command-
line)
Code
53 The promotion/demotion Examine the extended error and logs

failed, machine must be
rebooted to clean up

failed

was canceled by the user

was canceled by the user,
machine must be rebooted
to clean up
58 A site name must be You must specify a site for an RODC, it will not automatically
specified during RODC detect one like an RWDC
promotion
59 During demote, this Specify that this is the Last DNS Server in the Domain or use
domain controller is the last -ignorelastdnsserverfordomain
DNS server for one of its
zones
60 A domain controller Promote at least one Windows Server 2008 or later model
running Windows Server writable domain controller
2008 or later must be
present in the domain in
order to promote RODC
61 You cannot install Active Not possible to get this error

Directory Domain Services
with DNS in an existing
domain that does not
already host DNS
62 Answer file does not have a Only seen with dcpromo /unattend, which is deprecated. See
[DCInstall] section older documentation.
63 Forest functional level is Raise the forest functional level to at least Windows Server
below windows server 2003 2003 Native. Windows 2000 and Windows NT 4.0 are no
longer supported operating systems
64 Promo failed because Install the AD DS role

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

component binary
installation failed
66 Promo failed because Examine the extended error and logs; the server is failing to
operating system detection return its operating system version. It's likely that the
failed computer will need to be reinstalled, as its overall health is
highly suspect
68 Replication partner is Use repadmin.exe or the Get-ADReplication\* Windows

invalid PowerShell to validate partner domain controller health
69 Required Port is already in Use netstat.exe -anob to locate processes that are incorrectly
use by some other assigned to reserved AD DS ports
application
70 The forest root domain Only seen with dcpromo /unattend, which is deprecated. See
controller must be a GC older documentation
71 DNS server is already Don't specify to install DNS (-installDNS) if the DNS service is
installed already installed
72 Computer is running You can't promote this domain controller, as it's also a RDS
Remote Desktop Services in server configured for more than two admin users. Don't
nonadmin mode remove RDS before you carefully inventory its usage - if it's
being used by applications or end-users, removal will cause
an outage
73 The specified forest Specify a valid forest functional level

functional level is invalid.
74 The specified domain Specify a valid domain functional level

functional level is invalid.
75 Unable to determine the Validate that the RODC password replication policy exists and
default password is accessible
replication policy.
76 Specified replicated/non- Validate that you have typed in valid domain and user
replicated security groups accounts when specifying a password replication policy
are invalid
77 The specified argument is Examine the extended error and logs

invalid
78 Failed to examine Active Examine the extended error and logs

Directory Forest
Code
79 RODC cannot be promoted Use Windows Server 2012 to prepare the forest or use
because rodcprep has not adprep.exe /rodcprep
been performed
80 Domainprep has not been Use Windows Server 2012 to prepare the domain or use
performed adprep.exe /domainprep
81 Forestprep has not been Use Windows Server 2012 to prepare the forest or use
performed 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 Validate that existing domain controllers have correct user
controller account account control attribute set.
85 Unable to select a domain Returned if you specify "Use Existing Account" but either no
controller account for stage account found or there's an error during account lookup.
2 Ensure you provided the correct RODC staged account
86 Need to run stage 2 Returned if you promote an additional domain controller but
promotion an existing account exists and "Allow Reinstall" wasn't
specified
87 A domain controller Rename the computer before promoting, if not trying to

account of conflicting type attach to an unoccupied domain controller. You must attach
exists 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 You specified an invalid account for RODC admin delegation.
is not valid Verify that the account specified is a valid user or group
89 RID master for the specified Use netdom.exe query fsmo to detect the RID master. Bring
domain is offline. it online and make it accessible to the domain controller
you're promoting
90 Domain naming master is Use netdom.exe query fsmo to detect the domain naming
offline. master. Bring it online and make it accessible to the domain
controller you're promoting
91 Failed to detect if the Not possible to get this error anymore, the operating system is
process is wow64 64-bit
92 Wow64 process isn't Not possible to get this error anymore, the operating system is
supported 64-bit
Code
93 Domain controller service Start the AD DS service

isn't running for
nonforceful demotion
94 Local admin password Provide a nonblank password and ensure that the local
doesn't meet requirement: password policy requires a password
either blank or not required
95 Can't demote last Windows You must first demote all RODCs before you can demote all
Server 2008 or later domain Windows Server 2008 or later writable domain controllers
controller in the domain
where live RODCs exist
96 Unable to uninstall DS Only seen with dcpromo /unattend, which is deprecated. See
binaries older documentation
97 Forest functional level Provide a child domain functional the same or higher than
version higher than that of the forest functional level
the child domain operating
system
98 Component binary Only seen with dcpromo /unattend, which is deprecated. See
install/uninstall is in older documentation
progress.
99 Forest functional level is Raise the forest functional level to at least Windows Server
too low (error is Windows 2003 native. Windows 2000 and Windows NT 4.0 are no
Server 2012 only) longer supported operating systems
100 Domain functional level is Raise the domain functional level to at least Windows Server
too low (error is Windows 2003 native. Windows 2000 and Windows NT 4.0 are no
Server 2012 only) longer supported operating 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.
Issue Demoting a domain controller leaves DNS running with no zones
Symptoms Server still responds to DNS requests but has no zone information
Issue Demoting a domain controller leaves DNS running with no zones
Resolution When removing the AD DS role, also remove the DNS Server role or set the DNS Server
and Notes 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
Issue Promoting a Windows Server 2012 into an existing single-label domain doesn't
configure updatetopleveldomain=1 or allowsinglelabeldnsdomain=1
Symptoms DNS dynamic record registration doesn't occur
Resolution Set these values using the Netlogon and DNS group policies. Microsoft began blocking
and Notes 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.
Issue Demotion of last domain controller in a domain fails if there are pre-created,
unoccupied RODC accounts
Symptoms Demotion fails with message:

Dcpromo.General.54
Active Directory Domain Services couldn't find another Active Directory Domain
Controller to transfer the remaining data in directory partition
CN=Schema,CN=Configuration,DC=corp,DC=contoso,DC=com.
"The format of the specified domain name is invalid."
Resolution Remove any remaining pre-created RODC accounts before demoting a domain, using
and Notes Dsa.msc or Ntdsutil.exe metadata cleanup.
Issue Automated forest and domain preparation doesn't run GPPREP
Symptoms Cross-domain planning functionality for Group Policy, Resultant Set of Policy (RSOP)
Planning Mode, requires updated file system and Active Directory permissions for
existing GP. Without Gpprep, you can't use RSOP Planning across domains.
Resolution Run adprep.exe /gpprep manually for all domains that weren't previously prepared for
and Notes 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 isn't 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.
Issue Install from media fails to verify when pointing to a UNC path
Symptoms Error returned:

Code - Couldn't validate media path. Exception calling "GetDatabaseInfo" with "2"
arguments. The folder isn't valid.
Resolution You must store IFM files on a local disk, not a remote UNC path. This intentional block
and Notes prevents partial server promotion due to a network interruption.
Issue DNS delegation warning shown twice during domain controller promotion
Symptoms Warning returned twice when promoting using ADDSDeployment Windows

PowerShell:
Code - "A delegation for this DNS server can't be created because the authoritative
parent zone can't be found or it doesn't run Windows DNS server. If you're 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 Ignore. ADDSDeployment Windows PowerShell shows the warning first during
and Notes prerequisite checking, then again during configuration of the domain controller. If you
don't wish to configure DNS delegation, use argument:
Code - -creatednsdelegation:$false
Don't* skip the prerequisite checks in order to suppress this message
Issue Specifying UPN or nondomain credentials during configuration returns

misleading errors
Symptoms Server Manager returns error:

Code - Exception calling "DNSOption" with "6" Arguments
ADDSDeployment Windows PowerShell returns error:
Code - Verification of user permissions failed. You must supply the name of the
domain to which this user account belongs.
Resolution Ensure you're providing valid domain credentials in the form of domain\user.
and Notes
Issue Removing the DirectoryServices-DomainController role using Dism.exe leads to

unbootable server
Symptoms If using Dism.exe to remove the AD DS role before demoting a domain controller
gracefully, the server no longer boots normally and shows error:
Code - Status: 0x000000000
Info: An unexpected error has occurred.

Issue Removing the DirectoryServices-DomainController role using Dism.exe leads to
unbootable server
Resolution Boot into Directory Services Repair Mode using Shift+F8. Add the AD DS role back, and
and Notes then forcibly demote the domain controller. Alternatively, restore the System State
from backup. Don't use Dism.exe for AD DS role removal; the utility has no knowledge
of domain controllers.
Issue Installing a new forest fails when setting forestmode to Win2012
Symptoms Promotion using ADDSDeployment Windows PowerShell returns error:

Code - Test.VerifyDcPromoCore.DCPromo.General.74
Verification of prerequisites for Domain Controller promotion failed. The specified

domain functional level is invalid
Resolution Don't specify a forest functional mode of Win2012 without also specifying a domain
and Notes functional mode of Win2012. Here's an example that will work without errors:
Code - -forestmode Win2012 -domainmode Win2012]
Issue Clicking Verify in the Install from Media selection area appears to do nothing
Symptoms When you specify a path to an IFM folder, clicking the Verify button never returns a
message or appears to do anything.
Resolution The Verify button only returns errors if there are issues. Otherwise, it makes the Next
and Notes button selectable if you have provided an IFM path. You must select Verify to proceed
if you have selected IFM.
Issue Demoting with Server Manager doesn't provide feedback until completed.
Symptoms When using Server Manager to remove the AD DS role and demote a domain
controller, there's no ongoing feedback given until the demotion completes or fails.
Resolution This is a limitation of Server Manager. For feedback, use ADDSDeployment Windows
and Notes PowerShell cmdlet:
Code - Uninstall-addsdomaincontroller
Issue Install from Media Verify doesn't detect that RODC media provided for writable
domain controller, or vice versa.
Symptoms When promoting a new domain controller using IFM and providing incorrect media to
IFM - such as RODC media for a writable domain controller, or RWDC media for an
RODC - the Verify button doesn't 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 can't start because the specified
source database isn't allowed. Only databases from other RODCs can be used for IFM
promotion of a RODC.
Issue Install from Media Verify doesn't detect that RODC media provided for writable
domain controller, or vice versa.
Resolution Verify only validates the overall integrity of IFM. Don't provide the wrong IFM type to a
and Notes server. Restart the server before you attempt promotion again with the correct media.
Issue Promoting an RODC into a precreated computer account fails
Symptoms When using ADDSDeployment Windows PowerShell to promote a new RODC with a staged
computer account, receive error:
Code - Parameter set can't be resolved using the specified named parameters.
InvalidArgument: ParameterBindingException
+ FullyQualifiedErrorId :
AmbiguousParameterSet,Microsoft.DirectoryServices.Deployment.PowerShell.Commands.Install
Resolution Don't provide parameters already defined already on a precreated RODC account. These
and Notes include:
Code - -readonlyreplica
-installdns
-donotconfigureglobalcatalog
-sitename
-installdns
Issue Deselecting/selecting "Restart each destination server automatically if required"

does nothing
Symptoms If selecting (or not selecting) the Server Manager option Restart each destination
server automatically if required when demoting a domain controller through role
removal, the server always restarts, regardless of choice.
Resolution This is intentional. The demotion process restarts the server regardless of this setting.
and Notes
Issue Dcpromo.log shows "[error] setting security on server files failed with 2"
Symptoms Demotion of a domain controller completes without issues, but examination of

the dcpromo log shows error:
Code - [error] setting security on server files failed with 2
Resolution and Ignore, error is expected and cosmetic.

Notes
Issue Prerequisite adprep check fails with error "Unable to perform Exchange schema
conflict check"
Issue Prerequisite adprep check fails with error "Unable to perform Exchange schema
conflict check"
Symptoms When attempting to promote a Windows Server 2012 domain controller into an
existing Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2
forest, prerequisite check fails with error:
Code - Verification of prerequisites for AD prep failed. Unable to perform Exchange
schema conflict check for domain <domain name> (Exception: the RPC server is
unavailable)
The adprep.log shows error:
Code - Adprep couldn't retrieve data from the server <domain controller>
through Windows Management Instrumentation (WMI).
Resolution The new domain controller can't access WMI through DCOM/RPC protocols against
and Notes the existing domain controllers. To date, there have been three causes for this:
- A firewall rule blocks access to the existing domain controllers
- The NETWORK SERVICE account is missing from the "Logon as a service"

(SeServiceLogonRight) privilege on the existing domain controllers
- NTLM is disabled on domain controllers, using security policies described in

Introducing the Restriction of NTLM Authentication
Issue Creating a new AD DS forest always shows DNS warning
Symptoms When creating a new AD DS forest and creating the DNS zone on the new domain
controller for itself, you always receive warning message:
Code - An error was detected in the DNS configuration.
None of the DNS servers used by this computer responded within the timeout interval.
(error code 0x000005B4 "ERROR_TIMEOUT")
Resolution Ignore. This warning is intentional on the first domain controller in the root domain of
and Notes a new forest, in case you intended to point to an existing DNS server and zone.
Issue Windows PowerShell -whatif argument returns incorrect DNS server

information
Symptoms If you use the -whatif argument when configuring a domain controller with implicit
or explicit -installdns:$true, the resulting output shows:
Code - "DNS Server: No"
Resolution Ignore. DNS is installed and configured correctly.

and Notes
Issue After promotion, logon fails with " Not enough storage is available to process
this command"
Issue After promotion, logon fails with " Not enough storage is available to process
this command"
Symptoms After you promote a new domain controller and then log off and attempt to log on
interactively, you receive error:
Code - Not enough storage is available to process this command
Resolution The domain controller wasn't rebooted after promotion, either due to an error or
and Notes because you specified the ADDSDeployment Windows PowerShell argument -
norebootoncompletion. Restart the domain controller.
Issue The Next button isn't available on the Domain Controller Options page
Symptoms Even though you have set a password, the Next button on the Domain Controller
Options page in Server Manager isn't available. There's no site listed in the Site name
menu.
Resolution You have multiple AD DS sites and at least one is missing subnets; this future domain
and Notes controller belongs to one of those subnets. You must manually select the subnet from
the Site name dropdown menu. You should also review all AD sites using DSSITE.MSC
or use the following Windows PowerShell command to find all sites missing subnets:
Code - get-adreplicationsite -filter * -property subnets | where-object {!$_.subnets -eq
"*"} | format-table name
Issue Promotion or demotion fails with message "the service can't be started"
Symptoms If you attempt promotion, demotion, or cloning of a domain controller you receive
error:
Code - The service can't be started, either because it's 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 The DS Role Server service (DsRoleSvc) is disabled. By default, this service is installed
and Notes during AD DS role installation and set to a Manual start type. Don't disable this service.
Set it back to Manual and allow the DS role operations to start and stop it on demand.
This behavior is by design.
Issue Server Manager still warns that you need to promote DC
Symptoms If you promote a domain controller using the deprecated dcpromo.exe /unattend or
upgrade an existing Windows Server 2008 R2 domain controller in place to Windows
Server 2012, Server Manager still shows the post-deployment configuration task
Promote this server to a domain controller.
Resolution select the post-deployment warning link and the message will disappear for good. This
and Notes behavior is cosmetic and expected.
Issue Server Manager deployment script missing role installation
Symptoms If you promote a domain controller using Server Manager and save the Windows
PowerShell deployment script, it doesn't include the role installation cmdlet and
arguments (install-windowsfeature -name ad-domain-services -
includemanagementtools). Without the role, the DC can't be configured.
Resolution Manually add that cmdlet and arguments to any scripts. This behavior is expected and
and Notes by design.
Issue Server Manager deployment script isn't named PS1
Symptoms If you promote a domain controller using Server Manager and save the Windows
PowerShell deployment script, the file is named with a random temporary name and
not as a PS1 file.
Resolution Manually rename the file. This behavior is expected and by design.
and Notes
Issue Dcpromo /unattend allows unsupported functional levels

Issue Dcpromo /unattend allows unsupported functional levels
Symptoms If you promote a domain controller using dcpromo /unattend with the following
sample answer file:
Code -
[DCInstall]
NewDomain=Forest
ReplicaOrNewDomain=Domain
NewDomainDNSName=corp.contoso.com
SafeModeAdminPassword=Safepassword@6
DomainNetbiosName=corp
DNSOnNetwork=Yes
AutoConfigDNS=Yes
RebootOnSuccess=NoAndNoPromptEither
RebootOnCompletion=No
DomainLevel=0
ForestLevel=0
Promotion fails with the following errors in the dcpromoui.log:
Code - dcpromoui EA4.5B8 0089 13:31:50.783 Enter

CArgumentsSpec::ValidateArgument DomainLevel
dcpromoui EA4.5B8 008A 13:31:50.783 Value for DomainLevel is 0
dcpromoui EA4.5B8 008B 13:31:50.783 Exit code is 77
dcpromoui EA4.5B8 008C 13:31:50.783 The specified argument is invalid.
dcpromoui EA4.5B8 008D 13:31:50.783 closing log
dcpromoui EA4.5B8 0032 13:31:50.830 Exit code is 77
Level 0 is Windows 2000, which isn't supported in Windows Server 2012.
Resolution Don't use the deprecated dcpromo /unattend and understand that it allows you to
and Notes specify invalid settings that later fail. This behavior is expected and by design.
Issue Promotion "hangs" at creating NTDS settings object, never completes
Symptoms If you promote a replica DC or RODC, the promotion reaches "creating NTDS settings
object" and never proceeds or completes. The logs stop updating as well.
Issue Promotion "hangs" at creating NTDS settings object, never completes
Resolution This is a known issue caused by providing credentials of the built-in local Administrator
and Notes account with a matching password to the built-in domain Administrator account. This
causes a failure down in the core setup engine that doesn't 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. Readd 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
Article • 07/29/2021
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.
Best Practices for Securing Active Directory

Active Directory Replication and Topology Management Using Windows
PowerShell
Managing RID Issuance
Active Directory Domain Services Component Updates
Active Directory Forest Recovery Guide
Article • 07/10/2023
Windows Server 2012 R2 and 2012
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 2022, 2019, 2016, 2012 R2 and 2012 operating
systems.
Steps outlined in this guide

AD Forest Recovery - Prerequisites
AD Forest Recovery - Devise a custom forest recovery plan
AD Forest Recovery - Steps to restore the Forest
AD Forest Recovery - Identify the problem
AD Forest Recovery - Determine how to recover
AD Forest Recovery - Perform initial recovery
AD Forest Recovery - Procedures
AD Forest Recovery - Frequently Asked Questions (FAQ)
AD Forest Recovery - Recover a single domain within a multidomain forest
AD Forest Recovery - Redeploy remaining DCs
AD Forest Recovery - Virtualization
Legacy guidance
Older operating system guidance is found in the Windows Server archive.
Active Directory Forest Recovery -
Prerequisites
Article • 07/10/2023
Windows Server 2012 R2 and 2012.
The following document discusses prerequisites that you should be familiar with before
devising a forest recovery plan or attempting a recovery.
Assumptions
1. You have worked with a Microsoft Support professional and:
Determined the cause of the forest-wide failure. This guide doesn't suggest
the causes for failure nor does it recommend procedures to prevent failure.
Evaluated possible remedies.
Concluded, in consultation with Microsoft Support, that restoring the whole
forest to its state before the failure is the best way to recover from the failure.
In many cases, forest recovery should be the last option.
2. 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 isn't the case, you can still use the basic principles of this guide to perform
forest recovery. However, you'll 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. You may have a special configuration for the handling of Domain Controller disk
volumes in your physical or virtual hosting, such as solutions to protect access to
disk volumes, like BitLocker. As part of the procedure you may require access to
emergency situation information like BitLocker Recovery keys. Ensure this
information is available when needed during recovery.
4. Although this guide is intended as a generic guide for forest recovery, not all
possible scenarios are covered. For instance, there's a Server Core version, which is
a version of Windows Server without a desktop experience. Although it's 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'll 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.
Prerequisites
You are familiar with Active Directory concepts

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 (formerly known as flexible singles
master operations or FSMO) including:
Forest-wide Operation Master Roles:
Schema master
Domain naming master
Domain-wide Operation Master Roles:
Relative ID (RID) master
Primary domain controller (PDC) emulator master
Infrastructure master
You have a documented recovery plan with procedures

You should have a documented recovery plan with procedures for AD DS domain/forest
recoveries, object/subtree recoveries, and SYSVOL recoveries that have been tested in a
lab environment using production backups. The recovery procedures should be vetted
on a routine basis (for example, annually) and the documentation updated as required
by OS upgrades, architectural changes to the AD DS environment, or any other changes
that ensure the procedures are kept up to date. For more information and guidance on
these procedures, refer to the AD Forest Recovery – Procedures section of this guide.
 Tip
Microsoft offers the Active Directory Recovery Execution Service (ADRES) service
to assist customers with the development of this documentation/procedure.
Contact your Customer Success Account Management (CSAM) for details.
You have backed up and restored AD DS and SYSVOL in a

lab environment
You should have backed up and restored AD DS and SYSVOL in a lab environment on a
regular basis. For more information, see AD Forest Recovery - Backing up a full server.
and Performing Nonauthoritative Restore of Active Directory Domain Services.
Next steps
Devise an AD forest recovery plan
Article • 07/10/2023
Windows Server 2012 and 2012 R2, Windows Server 2008 and 2008 R2
Depending on your environment and business requirements, you may not need to
perform all the steps described in this guide to perform a successful forest recovery.
Given that this guide serves only as a template for forest recovery, it's vital that you
devise a custom forest recovery plan that suits your environment and meets your
business needs.
Plan
For example, in your forest recovery plan, you should have a detailed topology map of
your forests. The map should list all the information about the DCs, such as their names,
their roles and back up status, and the trust relationships between them.
Practice
You should practice your forest recovery plan at least once a year. Also, it's a good idea
to perform a forest recovery drill when there are membership changes to the Enterprise
Admins or Domain Admins group. This helps ensure that your information technology
(IT) staff fully understands the forest recovery plan.
Next steps
Active Directory Forest Recovery - Steps
to restore the forest
Article • 07/10/2023
This section provides an overview of the recommended path for recovering a forest. The
forest recovery steps are described in detail later.
We recommend you run through a forest recovery on a regular basis to:
Practice the recovery.

Ensure the custom steps you defined for your environment are still working.
If steps don't work, you notice and update the existing plan to adopt for a new
kind of potential failure.
Verify the defaults you have for selecting the DCs to restore in each of the domains
is still a good choice.
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. Determine how to recover the forest After you determine that forest recovery is
necessary, complete preliminary steps to prepare for it.
3. Perform initial recovery In isolation, recover one DC for each domain, clean it, 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. Adapt this step 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 may have to modify these steps to
account for such factors as:
Scalability
Remote manageability
Speed of recovery
Next steps
Identify the problem
Article • 07/10/2023
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.
[!MPORTANT] This guide doesn't cover security recommendations for how to

recover a forest that has been hacked or compromised. In general, it's
recommended to follow Best Practices for Securing Active Directory and Pass-the-
Hash mitigation techniques to harden the environment. For more information, see
Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques .
Examples of forest-wide failures

All DCs are logically corrupted or physically damaged to a point that business
continuity is impossible; for example, all business applications that depend on AD
DS aren't functional.
A rogue administrator 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.
The content, or a backup of a Domain Controller, has been exposed to an external
party, but leaked credentials haven't been used to modify AD data. In this case,
you may not need to restore the AD database from backup and reinstall all DCs.
You may need to reset all password of users, computers, trusts and (g)MSA
accounts.
An attacker installed malicious software on DCs, and you were advised by
Microsoft Support to recover the forest from backup.
None of the DCs can replicate with their replication partners.
Changes can't be made to AD DS at any domain controller.
New DCs can't be installed in any domain.
Next steps
Determine how to recover the forest
Article • 07/10/2023
Recovering an entire Active Directory forest involves restoring at least one Domain
Controller (DC) in every domain from an available backup. Recovering the forest restores
each domain in the forest to its state at the time of the last trusted backup.
What will be lost

The restore operation will result in the loss of at least the following Active Directory
data:
All objects (such as users and computers) that were added after the last trusted
back up
All updates that were made to existing objects since the last trusted back up
All changes that were made to either the configuration partition or the schema
partition in AD DS (such as schema changes) since the last trusted back up
Password knowledge
1. You must know the password of a Domain Admin account for each domain in the
forest. Preferably, this is the password of the built-in Administrator account.
2. You must also know the DSRM password to perform a system state restore of a DC.
It's a good practice to archive the Administrator account and DSRM password history in
a safe place for as long as the backups are valid. That is, within the tombstone lifetime
period or within the deleted object lifetime period if Active Directory Recycle Bin is
enabled.
You can also synchronize the DSRM password with a domain user account in order to
make it easier to remember. For more information, see this article. Synchronizing the
DSRM account must be done in advance of the forest recovery, as part of preparation.
７ Note
The Administrator account is a member of the built-in Administrators group by
default, as are the Domain Admins and Enterprise Admins groups. This group has
full control of all DCs in the domain.
Determine which backups to use

Back up at least two writeable DCs for each domain regularly so you have multiple
backups to choose from. Select one or more DCs as required and the PDC Emulator
operation master for SYSVOL data recovery.
７ Note
You cannot use the backup of a read-only domain controller (RODC) to restore a
writeable DC. We recommend that you restore the DCs by using backups that were
taken a few days before the occurrence of the failure. In general, you must
determine a tradeoff between the recentness and the safeness of the restored data.
Choosing a more recent backup recovers more useful data, but it might increase
the risk of reintroducing dangerous data into the restored forest.
Restoring system state backups depends on the original operating system and server of
the backup. For example, you shouldn't restore a system state backup to a different
server. In this case, you may see the following warning:
２ Warning
The specified backup is of a different server than the current one. We don't
recommend performing a system state recovery with the backup to an alternate
server because the server might become unusable. Are you sure you want to use
this backup for recovering the current server?
If you need to restore Active Directory to different hardware, create full server backups
and plan to perform a full server recovery.
） Important
Restoring system state backup to a new installation of Windows Server on new

hardware or the same hardware is not supported. If Windows Server is reinstalled
on the same hardware (recommended), you can restore the domain controller in
this order:
1. Perform a full server restore in order to restore the operating system and all
files and applications.
2. Perform a system state restore using wbadmin.exe in order to mark SYSVOL as
authoritative.
For more information, see How to restore a Windows 7 installation.
If the time of failure is unknown, investigate further to identify backups that hold the last
safe state of the forest.
This approach is less desirable. Therefore, we strongly recommend that you keep
detailed logs about the health state of AD DS on a daily basis so that, if there's a forest-
wide failure, the approximate time of failure can be identified. You should also keep a
local copy of backups to enable faster recovery.
If Active Directory Recycle Bin is enabled, the backup lifetime is equal to the
deletedObjectLifetime value or the tombstoneLifetime value, whichever is less. For
more information, see Active Directory Recycle Bin Step-by-Step Guide .
Alternatively, you can use the Active Directory database mounting tool Dsamain.exe and
a Lightweight Directory Access Protocol (LDAP) tool, such as Ldp.exe or Active Directory
Users and Computers, to identify which backup has the last safe state of the forest. The
Active Directory database mounting tool, which is included in Windows Server operating
systems, exposes Active Directory data that is stored in backups or snapshots as an
LDAP server. You can use an LDAP tool to browse the data. This approach has the
advantage of not requiring you to restart any DC in Directory Services Restore Mode
(DSRM) to examine the contents of the backup of AD DS.
For more information about using the Active Directory database mounting tool, see the
Active Directory Database Mounting Tool Step-by-Step Guide.
You can also use the ntdsutil snapshot command to create snapshots of the Active
Directory database. By scheduling a task to periodically create snapshots, you can obtain
additional copies of the Active Directory database over time. You can use these copies
to better identify when the forest-wide failure occurred and then choose the best
backup to restore. To create snapshots, use ntdsutil or the Remote Server
Administration Tools (RSAT).
The target DC can run any version of Windows Server. For more information about using
the ntdsutil snapshot command, see Snapshot.
Determine which domain controllers to restore
The ease of the restore process is an important factor when deciding which domain
controller to restore. Haveing a dedicated DC for each domain that is the preferred DC
for a restore is recommended. A dedicated restore DC makes it easier to reliably plan
and execute the forest recovery because you use the same source configuration that
was used to perform restore tests. You can script the recovery and avoid contending
with different configurations, such as whether the DC holds operations master roles, or
whether it's a GC or DNS server.
７ Note
Restoring an operations master role holder in the interest of simplicity isn't

recommended, as you always seize all roles. There is the case of a SYSVOL recovery
using a backup taken from the PDC Emulator operation master, as typically the PDC
has the best copy of SYSVOL data.
A good backup is a backup that can be restored successfully, was taken a few days
before the failure, and contains as much useful data as possible. Choose a DC that best
meets the following criteria:
A DC that is writeable. This is mandatory.
A DC running Windows Server 2012 or newer as a virtual machine on a hypervisor

that supports VM-GenerationID. This DC can be used as a source for cloning. In
general, use a DC with a good back up that has the most current OS.
A DC that is accessible, either physically or on a virtual network, and preferably

located in a datacenter. This way, you can easily isolate it from the network during
forest recovery.
A DC that has a good full server backup.
A DC running Domain Name System (DNS) role and hosting the forest and
domain(s) zone.
A DC configured as a Global Catalog (GC).
A DC that isn't confitured to use BitLocker Network Unlock, if you use Windows
Deployment Services. Using BitLocker Network Unlock for the first DC that you
restore from backup during a forest recovery isn't supported. On DCs where you
have deployed Windows Deployement Services (WDS),,BitLocker Network Unlock
as the only key protector can't be used because the first DC would require Active
Directory and WDS to be working in order to unlock. Before you restore the first
DC, Active Directory isn't yet available for WDS, so it can't unlock.
To determine if a DC is configured to use BitLocker Network Unlock, check that a

Network Unlock certificate is identified in the following registry key:
HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemCertificatesFVE_NKP
） Important
Maintain security procedures when handling or restoring backup files that include
Active Directory. The urgency that accompanies forest recovery can unintentionally
lead to overlooking security best practices.
Identify the current forest structure and DC

functions
Determine the current forest structure by identifying all the domains in the forest. Make
a list of all of the DCs in each domain, particularly the DCs that have backups, and
virtualized DCs which can be a source for cloning.
A list of DCs for the forest root domain is the most important because you'll recover this
domain first. After you restore the forest root domain, you can obtain a list of the other
domains, DCs, and the sites in the forest by using Active Directory snap-ins.
For each domain in the forest, identify a single writeable DC that has a trusted backup of
the Active Directory database for that domain. Use caution when you choose a backup
to restore a DC. If the day and cause of the failure are known, the general
recommendation is to identify and use a safe backup that was made a few days before
that date.
Prepare a table that shows the functions of each DC in the domain, as shown in the
following example. This will help you revert back to the pre-failure configuration of the
forest after recovery.
DC Operating FSMO GC RODC Backup DNS Server VM

name system Core
DC_1 Windows Schema master, Yes No Yes No No Yes

Server 2019 Domain naming
master
DC Operating FSMO GC RODC Backup DNS Server VM
name system Core
DC_2 Windows None Yes No Yes Yes No Yes

Server 2019
DC_3 Windows Infrastructure Master No No No Yes Yes Yes

Server 2022
DC_4 Windows PDC emulator, RID Yes No No No No Yes

Server 2022 Master
DC_5 Windows None No No Yes Yes No Yes

Server 2022
RODC_1 Windows None Yes Yes Yes Yes Yes Yes

Server 2016
RODC_2 Windows None Yes Yes No Yes Yes Yes

Server 2022
In this above example, there are four backup candidates: DC_1, DC_2, DC_4, and DC_5.
Of these backup candidates, you restore only one. The recommended DC is DC_5 for the
following reasons:
It is a good source for virtualized DC cloning, because it runs Windows Server 2022
as a virtual DC and runs software that is allowed to be cloned (or that can be
removed if it isn't able to be cloned). After the restore, the PDC emulator role will
be seized to that server and it can be added to the Cloneable Domain Controllers
group for the domain.
It runs a full installation of Windows Server 2022. A DC that runs a Server Core
installation can be less convenient as a target for recovery. This may not be a factor
if you're good with managing Windows Servers using the command line interface.
It's a DNS server.
７ Note
Because DC_5 is not a global catalog server, it has a slight advantage in that the
global catalog doesn't need to be removed after the restore. However you would
need to start recovery with the default Administrator account with Rid 500 or use
registry value ignoregcfailures:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Value: IgnoreGCFailures
Type: REG_DWORD
Data: 0 – Require GlobalCatalog for logon (default)
1 – Allow logon without groups from GC
Other factors are typically more important than the extra step of removing the GC role.
DC_3 or DC_4 are also good choices as the Operation Master Roles they have aren't a
problem. Consider the options and choose depending on your actual recovery situation.
You may normally plan and test by restoring the PDC Operations Master backup, but if
this backup doesn't work, for example because it is from the wrong time, pick a backup
from a GC of the same domain.
Recover the forest in isolation

The preferred scenario is to shut down all writeable DCs before the first restored DC is
brought back into production. This ensures that any dangerous data doesn't replicate
back into the recovered forest. It's particularly important to shut down all operations
master role holders.
７ Note
There may be cases where you move the first DC that you plan to recover for each
domain to an isolated network while allowing other DCs to remain online in order
to minimize system downtime. For example, if you are recovering from a failed
schema upgrade, you may choose to keep domain controllers running on the
production network while you perform recovery steps in isolation.
Virtualized DCs
If you're running virtualized DCs, you can move them to a virtual network that is isolated
from the production network where you'll perform recovery. Moving virtualized DCs to a
separate network provides two benefits:
Recovered DCs are prevented from reproducing the problem that caused the
forest recovery.
Virtualized DC cloning can be performed on the isolated network so that a critical
number of DCs can be running and tested before they're brought back to the
production network.
Physical DCs
If you're running DCs on physical hardware, disconnect the network cable of the first DC
that you plan to restore in the forest root domain. If possible, also disconnect the
network cables of all other DCs. This prevents DCs from replicating, if they're
accidentally started during the forest recovery process.
Large forests
In a large forest spread across multiple locations, it can be difficult to guarantee that all
writeable DCs are shut down. For this reason, the recovery steps—such as resetting the
computer account and krbtgt account, in addition to metadata cleanup—are designed
to ensure that the recovered writeable DCs don't replicate with dangerous writeable DCs
(in case some are still online in the forest).
However, only by taking writeable DCs offline can you guarantee that replication doesn't
occur. Therefore, whenever possible, you should deploy remote management
technology that can help you to shut down and physically isolate the writeable DCs
during forest recovery.
RODCs
RODCs can continue to operate while writeable DCs are offline. No other DC will directly
replicate any changes from any RODC—especially, no schema or configuration container
changes—so they don't pose the same risk as writeable DCs during recovery. After all
the writeable DCs are recovered and online, you should rebuild all the RODCs.
RODCs will continue to allow access to local resources that are cached in their respective
sites while the recovery operations are going on in parallel. Local resources that aren't
cached on the RODC will have authentication requests forwarded to a writeable DC.
These requests will fail because writeable DCs are offline. Some operations such as
password changes will also not work until you recover writeable DCs.
If you're using a hub-and-spoke network architecture, you can concentrate first on

recovering the writeable DCs in the hub sites. Later, you can rebuild the RODCs in
remote sites.
Compromised AD database
If the AD database of a writable DC is compromised, a new KDS Root Key should be
created after the recovery and all Group Managed Service Accounts (gMSA) should be
recreated depending on the compromission scenario. The details are described here:
How to recover from a Golden gMSA attack.
Next steps
Perform the initial recovery
Article • 07/10/2023
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 one writeable DC from backup. This is the
most important part of the recovery because the DC must have a database that hasn't
been influenced by whatever caused the forest to fail. It's important to have a trusted
backup that is thoroughly tested before it's 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 isn't attached and therefore isn't 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 (recommended). If Hyper-
Vistor Generation ID is supported on the host, then you can also do the
nonauthoritative restore using a VM snapshot.
An authoritative restore of SYSVOL is required on the first recovered DC,

because replication of the SYSVOL folder must be restarted with the new
instances 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.
２ Warning
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 didn't 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:
cli
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl
Perform Initial Synchronizations
Create the entry with the data type REG_DWORD and a value of 0. After the
forest is recovered completely, you can reset the value of this entry to 1,
which requires a domain controller that restarts and holds operations master
roles to have successful AD DS inbound and outbound replication with its
known replica partners before it advertises itself as domain controller and
starts providing services to clients. For more information about initial
synchronization requirements, see Active Directory FSMO Roles.
4. Continue to the Next steps only after you restore and verify the data and before
you join this computer to the production network.
5. 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 krbtgt account
complete password reset procedure is also needed.. The reset of administrative
account passwords should be completed before additional domain controllers are
installed during the next phase of the forest recovery.
In this case also, work on replacing all GMSA passwords as if an administrative

account was taken over, the attacker may have retrieved information that allows
them to authenticate as GMSA. For details see the article about the golden GMSA
attack.
6. If you suspect user accounts have been compromised, you also need to plan for a
user password reset for all users in the domain.
7. 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 as required.
In each child domain, seize domain-wide operations master roles as required.

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?. Also see Flexible Single-Master Operation (FSMO) placement
and optimization on AD DCs.
8. Clean up metadata of all other writeable DCs in the forest root domain that you
aren't 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 2012 or later or
RSAT for Windows 10 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 DCsand Clean up AD DS server metadata.
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, won't assume the RID master role and therefore won't
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.
9. 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 wasn't
a DNS server before the forest failure, you must install and configure the DNS
server role on the DC or a DNS server needs to be available on the restoration
environment.
In the forest root domain, configure the restored DC with its own IP address 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 Recommendations for Domain Name System (DNS) client settings.
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 Recommendations for Domain Name System (DNS) client settings.
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
10. 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, taking into account the average RID consumption on your
environment, the lowest increase that is still safe to use. RIDs are a finite resource
that shouldn't 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 isn't 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 wasn't originally intended.
For example, there may have been a new employee. The user object 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.
11. Invalidate the current RID pool. The current RID pool is invalidated after a system
state restore. But if a system state restore wasn't performed, the current RID pool
needs to be invalidated to prevent the restored DC from reissuing 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.
12. Reset the computer account password of this DC twice. For more information, see
Resetting the computer account password of the domain controller.
13. 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.
14. 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 isn't 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 aren't 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 can't be delivered.
Another problem is that a user account that no longer exists may still appear in the
global address list.
Addtionally, 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.
15. If you're using gMSA accounts, you may need to re-create them as the password
generation details may be exposed to an attacker, see:
How to recover from a Golden gMSA attack
See AD Forest Recovery - Recovering a Single Domain within a Multidomain Forest

for steps on how to replace the gMSAs and make sure they use secure key
material.
16. 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.
Verify forest replication health
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 DCs aren't 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's preferred that the forest root DC is a global catalog, it's generally
recommended to decide that all DCs to are 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:
cli
**HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Global Catalog
Promotion Complete**
For more information, see Adding the global catalog.
At this stage you should have a stable forest, with one DC for each domain and one
global catalog in the forest. You should make a new backup of each of the DCs that you
have just restored. You can now begin to redeploy other DCs in the forest by installing
AD DS and configuring additional Global Catalog servers.
Next steps
Procedures
Article • 07/10/2023
This section contains procedures related to the forest recovery process.
The following is a list of procedures that are used in backing up and restoring domain
controllers and Active Directory.
Back up a full server

Back up the System State data
Perform a full server recovery
Perform an authoritative synch of DFSR-replicated SYSVOL
Perform a nonauthoritative restore of Active Directory Domain Services
These steps explain how to perform an authoritative restore of SYSVOL at the same
time.
Configure the DNS Server service

Removethe global catalog
Raise the value of available RID pools
Invalidate the current RID pool
Seize an operations master role
Clean up after a restore
Clean the metadata of removed writable domain controllers
Reset the computer account password of the domain controller
Reset the krbtgt password
Reset a trust password on one side of the trust
Add the global catalog
Resources to verify replication is working
Next steps
AD Forest Recovery - FAQ
FAQ
Windows Server 2012 and 2012 R2 This document contains frequently asked
questions (FAQs) regarding forest recovery:
What can I do to speed up recovery?

Although speed of recovery isn't 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.
Performing a Windows Server Backup FULL backup which provides for both bare-
metal recovery (BMR) or a System State recovery.
Using virtualized domain controller (DC) cloning. Virtualized DC cloning
expedites the process to get additional Domain Controllers deployed to restore
the original bandwidth of domain services. DCs running after one DC is restored
from backup in each domain, as it's a nonauthoritative restoration, the PDC
Emulator must also be available during the cloning operation. The additional
virtualized DCs can be cloned rather than waiting for potentially lengthy AD DS
installations to be completed and for the completion of noncritical 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
colocated on the same hypervisor host should benefit.
Using Install From Media IFM to reduce the time needed for complete
replication, by reducing replication traffic, as only the delta will be replicated. It
also enable fast installation of multiple DCs.
If using complex remote site scenarios (rare): -** Install AD DS on one or multiple
servers in a hub or staging site**, and then ship them to the remote site.
Implement backup/restore procedures for DCs with poor/intermittent
connectivity, in addition to the DCs designated as primary backup and disaster
recovery (BDR) systems in primary datacenter locations. You'll need to add steps
to bring the restored DCs in other locations in sync with the main datacenter
DCs. To do this, designate one DC as the computer account reference and only
there let KDCSVC run. On the other DCs you restored, follow the steps in Reset
domain controller's password with Netdom.exe
Deploying read-only domain controllers (RODCs) RODCs can provide business
continuity during the recovery process because they don't have to be
disconnected from the network as writable DCs do. RODCs don't perform
outbound replication. Therefore, they don't 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 the Domain Controllers are Virtual machines, you may take advantage of
snapshot restore to roll back a DC to a known good state. This isn't the
recommended approach as snapshots used for backups come with a number of
caveats, such as the availability of disk space for the snapshots on the VM server to
have a usable backup history. We strongly recommend using regular backups as
the main means for recovery. VM snapshots may help for recovery from problems
after sensitive changes, such as forest-wide updates like domain rename or large
schema updates. Note: You need to mark SYSVOL as authoritative for DFSR
manually when needed. For more information about Virtualized Domain Controller,
see Virtualized Domain Controller Architecture.
When you restore DCs from backups, it takes time to locate and retrieve the
physical backup media, such as tapes, reinstall the operating system, depending on
the recovery scenario, and restore data from backup media.
７ Note
You can reduce the time required to reinstall the operating system and restore
data from backup by performing a BMR recovery instead of system state
restore. Because bare-metal 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 don't want to restore, bare-metal
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. General best
practice would recommend performing a FULL backup which will provide for
both a BMR or System State restore type.
When you rebuild DCs by replication, it takes time to replicate data for network-
based promotions. You can decrease the time required for restoring DCs by
placing the new domain controller in the same subnet as the partner to
promote. This minimizes delays that are caused by network roundtrip and
throughput.
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.
Labeling the backup media clearly and storing the media in an organized
fashion at a convenient, yet secure, location that allows fast retrieval. Make sure
you have valid credentials according to your backups.
Forcing 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 don't have to reinstall the operating system on the
DCs. For more information about forcing the removal of AD DS from a DC, see
Forcing the Removal of a Windows Server 2008 Domain Controller
(https://go.microsoft.com/fwlink/?LinkId=132627 ).
Use faster tape devices or disk backups to reduce the time that is required for
restore operations. Businesses that have a more aggressive service-level
agreement (SLA) might consider altering the forest recovery procedures to speed
recovery.
Can I automate the forest recovery

process?
Because of the complex and critical nature of the forest recovery process, there's
currently no end-to-end automation. 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 - Steps to restore the forest
AD Forest Recovery - Cleanup
Recover a single domain in a
multidomain forest
Article • 07/11/2023
In certain scenarios, it may be 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.
Similar to the forest recovery process, you restore one or more DCs from backup in the
domain and perform metadata cleanup of remaining DCs. New domain controllers are
then added by joining new members, installing AD DS roles and promoting them. You
can also use DC Cloning or Install from Media for the task.
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 the recovered domains partition from all GCs in the forest, except those in
the recovered domain, at the same time and once complete, rehost all GCs in the
forest. Also make sure you don't overload the remaining GCs. In large
environments, coordinating this activity can be very complex.
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.
Recreate Group Managed Service Accounts

(gMSA)
２ Warning
If the KDS Root Key objects in the forest were compromised, you should re-create
the gMSA accounts in multiple domains, even if the domain itself was not
compromised.
The problem and resolution is discussed in How to recover from a Golden gMSA attack.
You must prevent an attacker from using data harvested from a stolen Domain
Controller backup to authenticate using gMSA calculated credentials. Replace all gMSAs
in the domains of the forest that use the exposed KDS Root Key objects, with gMSA
accounts using a new KDS Root Key object. The procedure is described in Getting
Started with Group Managed Service Accounts with a few important changes:
Disable all existing gMSA accounts, set the userAccountControl attribute to 4098
(workstation type + disabled).
Create a new KDS Root Key object as described in Create the Key Distribution
Services KDS Root Key.
） Important
Restart the Microsoft Key Distribution Service (KDSSVC) on the same domain
controller. This is needed so the new object is picked up by KDSSVC. Create
new gMSA accounts to replace the existing accounts on the same domain
controller. At this point, edit the existing gMSA account as unique service
principal names must be assigned to the active gMSA.
After you have the member servers re-joined to the domain, update the
components that used gMSA with the new accounts.
To ensure the new gMSA uses the new KDS Root Key object, check the attribute msDS-
ManagedPasswordId binary data has the GUID of the matching KDS Root key object. The
object would have the CN of CN=e3779ca1-bfa2-9f7b-b9a5-20cf44f2f8d6 .
msDS-ManagedPasswordId of the gMSA should have the GUID starting offset 24 with the
first three parts of the GUID in byte-swapped order (red, green, blue), and the rest in
normal byte order (orange):
If the first gMSA was created using the new KDS Root Key, all subsequent gMSA
creations will be OK.
Cleanup
Delete the old gMSA accounts that used the old KDS Root Key Objects.
Delete the old KDS Root Key Objects.
Rehost all GCs
２ Warning
The login name and password of the default Domain Administrator user account
(“RID-500”) for all domains must available, and the account(s) enabled for use in
case a problem that prevents access to a GC for logon.
７ Note
To allow logon without the GC verification, it's possible also to configure

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\IgnoreGCFailures
value to 1.
If unknown, obtain the Domain ID by using whoami /all for another account in each
domain or run the following command to identify the RID 500. \$DomainSID = (Get-
ADDomain).DomainSID.Value \$ObjSID = New-Object
System.Security.Principal.SecurityIdentifier("\$DomainSID-500") \$RID500 =
\$ObjSID.Translate([System.Security.Principal.NTAccount]) \$RID500.Value
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 isn't recovered. It needs to be ensured, that all GCs don't
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. Since GCs don't 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. However, 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.
Check for and remove lingering objects

On the GCs of all other domains in the forest, you check and remove the potentially
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 doesn't have any lingering objects for any domain
partitions, you can remove the global catalog.
Removing lingering objects is advantageous for larger organizations that can't risk the
down time associated with rehosting the domain naming context.
For more information, see Use repadmin to remove lingering objects.
Next steps
Redeploy remaining DCs
Article • 07/10/2023
Windows Server 2012 and 2012 R2, Windows Server 2008 and 2008 R2
The steps up to this point apply to all forests: find a valid backup for each domain,
recover the domains in isolation, reconnect them, reset the global catalog, and clean up.
In this next step, you'll redeploy the forest. The way to do this will greatly depend on
your forest design, your service level agreements, site structure, available bandwidth,
and numerous other factors. You'll need to design your own redeployment plan based
on the principles and suggestions in this section, in a way that is best suited to your
business requirements.
The next step is to install AD DS on all DCs that were present before the forest recovery
took place. If the DCs still exist, the AD DS service will need to be removed forcibly, or
the DCs can be reinstalled. Any existing backups for these DCs can't be reused, because
the corresponding metadata has been removed during forest recovery. In an
uncomplicated environment this redeployment process can be as simple as
reconnecting the recovered DCs to the production network, and promoting new DCs as
needed.
In a large enterprise faced with a worldwide infrastructure, a more sophisticated plan is

needed. The first phase is usually to restore AD as a service; install strategically placed
DCs such that all critical business divisions and applications can start working again. (It
may be acceptable for branch offices to temporarily have reduced performance as a
result of this.) As a second phase, all remaining and less critical DCs are redeployed.
There are two methods to install additional DCs, both of which can be automated:
Clone
You can automate the recovery of all virtualized DCs in a domain after you restore a
single virtualized DC from backup. For more information about cloning and
prerequisites, see Introduction to Active Directory Domain Services (AD DS)
Virtualization (Level 100).
Reinstall AD DS using Windows Powershell
To expedite reinstalling AD DS, you can use Install from Media (IFM) option to reduce
replication traffic during the installation. For more information about using the ntdsutil
ifm command to create installation media, see Installing AD DS from Media.
Consider the following additional points for each replica DC that is recovered in the
forest by virtualized DC cloning or by installing AD DS (as opposed to restoring from
backup):
All software on a DC that is used as the source for cloning must be able to be
cloned. Applications and services that can't be cloned should be removed before
cloning is initiated. If that isn't possible, an alternative virtualized DC should be
chosen as the source.
If you clone additional virtualized DCs from the first virtualized DC to be restored,
the source DC will need to be shut down while its VHDX file is copied. Then, it will
need to be running and available online when the clone virtual DCs are first
started. If the downtime required by the shutdown isn't acceptable for the first
recovered DC, deploy an additional virtualized DC by installing AD DS to act as the
source for cloning.
There is no restriction on the host name of the cloned virtualized DC or the server
on which you want to install AD DS. You can use a new host name or the host
name that was in use previously. For more information about DNS host name
syntax, see Creating DNS Computer Names (https://go.microsoft.com/fwlink/?
LinkId=74564).
Configure each server with the first DNS server in the forest (the first DC that was
restored in the root domain) as the preferred DNS server in the TCP/IP properties
of its network adapter. For more information, see Configure TCP/IP to use DNS.
Redeploy all RODCs in the domain, either by virtualized DC cloning if several
RODCs are deployed in a central location, or by the traditional method of
rebuilding them by removing and reinstalling AD DS if they're deployed
individually in isolated located locations such as branch offices.
Rebuilding RODCs ensures that they don't contain any lingering objects and can
help prevent replication conflicts from occurring later. When you remove AD DS
from an RODC, choose the option to retain DC metadata. Using this option
retains the krbtgt account for the RODC and retains the permissions for the
delegated RODC administrator account and the Password Replication Policy
(PRP), and prevents you from having to use Domain Admin credentials to
remove and reinstall AD DS on an RODC. It also retains the DNS server and
global catalog roles if they're installed on the RODC originally.
When you rebuild DCs (RODCs or writeable DCs), there may be increased
replication traffic during their reinstallation. To help reduce that impact, you can
stagger the schedule of the RODC installations, and you can use the Install From
Media (IFM) option. If you use the IFM option, run the ntdsutil ifm command
on a writeable DC that you trust to be free of damaged data. This helps prevent
possible corruption from appearing on the RODC after the AD DS reinstallation
is complete. For more information about IFM, see Installing AD DS from Media.
For more information about rebuilding RODCs, see RODC Removal and
Reinstallation.
If a DC was running the DNS Server service before the forest malfunction, install
and configure the DNS Server service during the installation of AD DS. Otherwise,
configure its former DNS clients with other DNS servers.
If you require additional global catalogs to share authentication or query load for
users or applications, you can either add the global catalog to the source
virtualized DC before cloning or you can make a DC a global catalog server during
the installation of AD DS.
Next steps
Virtualization
Article • 07/10/2023
Use 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 to create cloned virtualized DCs and
build out the domain.
Requirements for virtualized DC cloning

The requirements for virtualized DC cloning are:
The hypervisor must support VM-GenerationID . For example, Hyper-V supports that
mechanism from Windows Server 2012, Windows 8, and newer operating systems.
Check with your hypervisor vendor to find out if VM-GenerationID is supported.
The virtualized DC that is used as a source for cloning must be a member of the
Cloneable Domain Controllers group.
The PDC Emulator must be available during cloning operations.For step-by-step

instructions for virtualized DC cloning, see Safely virtualizing Active Directory Domain
Services (AD DS). For details about how virtualized DC cloning works, see Virtualized
Domain Controller Technical Reference.
Next steps
Cleanup
Article • 07/10/2023
Windows Server 2012 and 2012 R2
Perform the following post recovery steps as needed:
Revert to the original DNS configuration

After the entire forest is recovered, you can revert to the original DNS configuration,
including configuration of the preferred and alternate DNS servers on each of the DCs.
After the DNS servers are configured as they were before the malfunction, their previous
name resolution capabilities will be restored. Delete any DNS records for DCs that
haven't been recovered.
Delete Windows Internet Name Service (WINS)

records
Delete Windows Internet Name Service (WINS) records for all DCs that haven't been
recovered.
Transfer operations master roles to other DCs

You can transfer the operations master roles to other DCs in the domain or forest and
add more global catalog servers based on the configuration before the failure.
Recreate missing objects

Because the entire forest is restored to a previous state, any objects (such as users and
computers) that were added and all updates (such as password changes) that were
made to existing objects after this point are lost. Therefore, you should recreate these
missing objects and reapply the missing updates as appropriate.
Restore outgoing domains and trusts

You might also need to restore outgoing trusts with external domains and forests,
because these external trust relationships aren't restored automatically from backups.
Next steps
AD Forest Recovery - Steps to restore the forest
AD Forest Recovery - Cleanup
Best Practices for Securing Active
Directory
Article • 07/29/2021
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
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

Executive Summary
Article • 07/29/2021
） Important
The following documentation was written in 2013 and is provided for historical
purposes only. Currently we are reviewing this documentation and it is subject to
change. It may not reflect current best practices.
No organization with an information technology (IT) infrastructure is immune from

attack, but if appropriate policies, processes, and controls are implemented to protect
key segments of an organization's computing infrastructure, it might be possible to
prevent a breach event from growing to a wholesale compromise of the computing
environment.
This executive summary is intended to be useful as a standalone document summarizing

the content of the document, which contains recommendations that will assist
organizations in enhancing the security of their Active Directory installations. By
implementing these recommendations, organizations will be able to identify and
prioritize security activities, protect key segments of their organization's computing
infrastructure, and create controls that significantly decrease the likelihood of successful
attacks against critical components of the IT environment.
Although this document discusses the most common attacks against Active Directory
and countermeasures to reduce the attack surface, it also contains recommendations for
recovery in the event of complete compromise. The only sure way to recover in the
event of a complete compromise of Active Directory is to be prepared for the
compromise before it happens.
The major sections of this document are:

This section provides information about some of the most commonly leveraged
vulnerabilities used by attackers to compromise customers' infrastructures. It contains
general categories of vulnerabilities and how they're used to initially penetrate
customers' infrastructures, propagate compromise across additional systems, and
eventually target Active Directory and domain controllers to obtain complete control of
the organizations' forests. It does not provide detailed recommendations about
addressing each type of vulnerability, particularly in the areas in which the vulnerabilities
are not used to directly target Active Directory. However, for each type of vulnerability,
we have provided links to additional information to use to develop countermeasures
and reduce the organization's attack surface.
Included are the following subjects:
Initial breach targets - Most information security breaches start with the
compromise of small pieces of an organization's infrastructure-often one or two
systems at a time. These initial events, or entry points into the network, often
exploit vulnerabilities that could have been fixed, but weren't. Commonly seen
vulnerabilities are:
Gaps in antivirus and antimalware deployments
Incomplete patching
Outdated applications and operating systems
Misconfiguration
Lack of secure application development practices
Attractive Accounts for Credential Theft - Credential theft attacks are those in
which an attacker initially gains privileged access to a computer on a network and
then uses freely available tooling to extract credentials from the sessions of other
logged-on accounts. Included in this section are the following:
Activities that Increase the Likelihood of Compromise - Because the target of

credential theft is usually highly privileged domain accounts and "very
important person" (VIP) accounts, it is important for administrators to be
conscious of activities that increase the likelihood of a success of a credential-
theft attack. These activities are:
Logging on to unsecured computers with privileged accounts
Browsing the Internet with a highly privileged account
Configuring local privileged accounts with the same credentials across

systems
Overpopulation and overuse of privileged domain groups
Insufficient management of the security of domain controllers.
Privilege Elevation and Propagation - Specific accounts, servers, and

infrastructure components are usually the primary targets of attacks against
Active Directory. These accounts are:
Permanently privileged accounts
VIP accounts
"Privilege-Attached" Active Directory accounts
Domain controllers
Other infrastructure services that affect identity, access, and configuration

management, such as public key infrastructure (PKI) servers and systems
management servers

This section focuses on technical controls to reduce the attack surface of an Active
Directory installation. Included in this section are the following subjects:
The Privileged Accounts and Groups in Active Directory section discusses the
highest privileged accounts and groups in Active Directory and the mechanisms by
which privileged accounts are protected. Within Active Directory, three built-in
groups are the highest privilege groups in the directory (Enterprise Admins,
Domain Admins, and Administrators), although a number of additional groups and
accounts should also be protected.
The Implementing Least-Privilege Administrative Models section focuses on

identifying the risk that the use of highly privileged accounts for day-to-day
administration presents, in addition to providing recommendations to reduce that
risk.
Excessive privilege isn't only found in Active Directory in compromised environments.

When an organization has developed the habit of granting more privilege than is
required, it is typically found throughout the infrastructure:
In Active Directory
On member servers
On workstations
In applications
In data repositories
The Implementing Secure Administrative Hosts section describes secure

administrative hosts, which are computers that are configured to support
administration of Active Directory and connected systems. These hosts are
dedicated to administrative functionality and do not run software such as email
applications, web browsers, or productivity software (such as Microsoft Office).
Included in this section are the following:
Principles for Creating Secure Administrative Hosts - The general principles to

keep in mind are:
Never administer a trusted system from a less-trusted host.
Do not rely on a single authentication factor when performing privileged
activities.
Do not forget physical security when designing and implementing secure
administrative hosts.
Securing Domain Controllers Against Attack - If a malicious user obtains

privileged access to a domain controller, that user can modify, corrupt, and destroy
the Active Directory database, and by extension, all of the systems and accounts
that are managed by Active Directory.
Included in this section are the following subjects:
Physical Security for Domain Controllers - Contains recommendations for

providing physical security for domain controllers in datacenters, branch offices,
and remote locations.
Domain Controller Operating Systems - Contains recommendations for securing

the domain controller operating systems.
Secure Configuration of Domain Controllers - Native and freely available

configuration tools and settings can be used to create security configuration
baselines for domain controllers that can subsequently be enforced by Group
Policy Objects (GPOs).
Monitoring Active Directory for Signs of

Compromise
This section provides information about legacy audit categories and audit policy
subcategories (which were introduced in Windows Vista and Windows Server 2008), and
Advanced Audit Policy (which was introduced in Windows Server 2008 R2). Also
provided is information about events and objects to monitor that can indicate attempts
to compromise the environment and some additional references that can be used to
construct a comprehensive audit policy for Active Directory.
Windows Audit Policy - Windows security event logs have categories and
subcategories that determine which security events are tracked and recorded.
Audit Policy Recommendations - This section describes the Windows default audit
policy settings, audit policy settings that are recommended by Microsoft, and more
aggressive recommendations for organizations to use to audit critical servers and
workstations.

This section contains recommendations that will help organizations prepare for a
compromise before it happens, implement controls that can detect a compromise event
before a full breach has occurred, and provide response and recovery guidelines for
cases in which a complete compromise of the directory is achieved by attackers.
Rethinking the Approach - Contains principles and guidelines to create secure

environments into which an organization can place their most critical assets. These
guidelines are as follows:
Identifying principles for segregating and securing critical assets
Defining a limited, risk-based migration plan
Leveraging "nonmigratory" migrations where necessary
Implementing "creative destruction"
Isolating legacy systems and applications
Simplifying security for end users
Maintaining a More Secure Environment - Contains high-level recommendations

meant to be used as guidelines to use in developing not only effective security, but
effective lifecycle management. Included in this section are the following subjects:
Creating Business-Centric Security Practices for Active Directory - To
effectively manage the lifecycle of the users, data, applications and systems
managed by Active Directory, follow these principles.
Assign a Business Ownership to Active Directory Data - Assign ownership of

infrastructure components to IT; for data that is added to Active Directory
Domain Services (AD DS) to support the business, for example, new
employees, new applications, and new information repositories, a designated
business unit or user should be associated with the data.
Implement Business-Driven Lifecycle Management - Lifecycle management

should be implemented for data in Active Directory.
Classify all Active Directory Data - Business owners should provide

classification for data in Active Directory. Within the data classification model,
classification for the following Active Directory data should be included:
Systems - Classify server populations, their operating system, their role,

the applications running on them, and the IT and business owners of
record.
Applications - Classify applications by functionality, user base, and their

operating system.
Users - The accounts in the Active Directory installations that are most
likely to be targeted by attackers should be tagged and monitored.
Summary of Best Practices for Securing Active

The following table provides a summary of the recommendations provided in this
document for securing an AD DS installation. Some best practices are strategic in nature
and require comprehensive planning and implementation projects; others are tactical
and focused on specific components of Active Directory and related infrastructure.
Practices are listed in approximate order of priority, that is., lower numbers indicate
higher priority. Where applicable, best practices are identified as preventative or
detective in nature. All of these recommendations should be thoroughly tested and
modified as needed for your organization's characteristics and requirements.
Best Practice Tactical Preventative

or or Detective
Strategic
or or Detective
Strategic
Patch applications. Tactical Preventative
Patch operating systems. Tactical Preventative
Deploy and promptly update antivirus and antimalware software Tactical Both
across all systems and monitor for attempts to remove or disable it.
Monitor sensitive Active Directory objects for modification attempts Tactical Detective
and Windows for events that may indicate attempted compromise.
Protect and monitor accounts for users who have access to sensitive Tactical Both
data
Prevent powerful accounts from being used on unauthorized systems. Tactical Preventative
Eliminate permanent membership in highly privileged groups. Tactical Preventative
Implement controls to grant temporary membership in privileged Tactical Preventative

groups when needed.
Implement secure administrative hosts. Tactical Preventative
Use application allowslists on domain controllers, administrative hosts, Tactical Preventative

and other sensitive systems.
Identify critical assets, and prioritize their security and monitoring. Tactical Both
Implement least-privilege, role-based access controls for Strategic Preventative

administration of the directory, its supporting infrastructure, and
domain-joined systems.
Isolate legacy systems and applications. Tactical Preventative
Decommission legacy systems and applications. Strategic Preventative
Implement secure development lifecycle programs for custom Strategic Preventative

applications.
Implement configuration management, review compliance regularly, Strategic Preventative

and evaluate settings with each new hardware or software version.
Migrate critical assets to pristine forests with stringent security and Strategic Both
monitoring requirements.
Simplify security for end users. Strategic Preventative
Use host-based firewalls to control and secure communications. Tactical Preventative

or or Detective
Strategic
Patch devices. Tactical Preventative
Implement business-centric lifecycle management for IT assets. Strategic N/A
Create or update incident recovery plans. Strategic N/A

Introduction
Article • 05/17/2023
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 isn't possible to prevent attacks, it's
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.
Account/Group Location Name of How It is

Account/Group Referenced in
this
Document
Active Directory - each domain Administrator Built-in

Administrator
account
Active Directory - each domain Administrators Built-in

Administrators
(BA) group
Active Directory - each domain Domain Domain

Admins Admins (DA)
group
Active Directory - forest root domain Enterprise Enterprise

Admins Admins (EA)
group
Local computer security accounts manager (SAM) database on Administrator Local

computers running Windows Server and workstations that Administrator
aren't domain controllers account
Local computer security accounts manager (SAM) database on Administrators Local

computers running Windows Server and workstations that Administrators
aren't domain controllers group
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 haven't
experienced significant compromise. Although individual customer data wasn't 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're 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're 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 doesn't provide detailed recommendations about addressing each type of
vulnerability, particularly in the areas in which the vulnerabilities aren't 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 doesn't 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're intellectual property, people,
or systems. In some cases, segregating and securing assets may be performed in your
existing AD DS environment, while in other cases, you should consider implementing
small, separate "cells" that allow you to establish a secure boundary around critical
assets and monitor those assets more stringently than less-critical components. A
concept called "creative destruction," which is a mechanism by which legacy applications
and systems can be eliminated by creating new solutions is discussed, and the section
ends with recommendations that can help to maintain a more secure environment by
combining business and IT information to construct a detailed picture of what is a
normal operational state. By knowing what is normal for an organization, abnormalities
that may indicate attacks and compromises can be more easily identified.
Summary of Best Practice Recommendations

This section provides a table that summarizes the recommendations made in this
document and orders them by relative priority, in addition to providing links to where
more information about each recommendation can be found in the document and its
appendices.
Appendices
Appendices are included in this document to augment the information contained in the
body of the document. The list of appendices and a brief description of each is included
the following table.
Appendix Description
Appendix B: Privileged Provides background information that helps you to identify the
Accounts and Groups in users and groups you should focus on securing because they can
Active Directory be leveraged by attackers to compromise and even destroy your
Active Directory installation.
Appendix C: Protected Contains information about protected groups in Active Directory. It

Accounts and Groups in also contains information for limited customization (removal) of
Active Directory groups that are considered protected groups and are affected by
AdminSDHolder and SDProp.
Appendix D: Securing Built- Contains guidelines to help secure the Administrator account in
In Administrator Accounts each domain in the forest.
in Active Directory
Appendix E: Securing Contains guidelines to help secure the Enterprise Admins group in
Enterprise Admins Groups the forest.
in Active Directory
Appendix F: Securing Contains guidelines to help secure the Domain Admins group in
Domain Admins Groups in each domain in the forest.
Active Directory
Appendix G: Securing Contains guidelines to help secure the Built-in Administrators

Administrators Groups in group in each domain in the forest.
Active Directory
Appendix H: Securing Local Contains guidelines to help secure local Administrator accounts
Administrator Accounts and and Administrators groups on domain-joined servers and
Groups workstations.
Appendix I: Creating Provides information to create accounts that have limited privileges
Management Accounts for and can be stringently controlled, but can be used to populate
Protected Accounts and privileged groups in Active Directory when temporary elevation is
Groups in Active Directory required.
Appendix L: Events to Lists events for which you should monitor in your environment.
Monitor
Appendix M: Document Contains a list of recommended reading. Also contains a list of

Links and Recommended links to external documents and their URLs so that readers of hard
Reading copies of this document can access this information.
Article • 05/16/2023
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 aren't 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's 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 aren't receiving
attention, and organizations begin to forget that they haven't 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
weren't. 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 isn't 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's 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's 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's 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 haven't 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 can't 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's 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's 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's
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 isn't. 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
shouldn't 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.
Protecting Domain Controllers
Domain controllers should be treated as critical infrastructure components, secured

more stringently and configured more rigidly than file, print, and application servers.
Domain controllers shouldn't run any software that isn't required for the domain
controller to function or doesn't protect the domain controller against attacks. Domain
controllers shouldn't 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.
Disabling Security Features
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's 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're running a server core installation (where UAC is disabled by design), you
shouldn't 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.
Granting Excessive Privilege
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's 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.
Standardizing Local Administrator Credentials

There has long been debate among security specialists as to whether there's value in
renaming local Administrator accounts on Windows computers. What is actually
important about local Administrator accounts is whether they're 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 doesn't 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.
Permitting Installation of Unauthorized Applications
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 aren't part of a server's defined role shouldn't be
permitted. By allowing software to be installed that isn't 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 doesn't 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's 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
select 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 can't 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's decommissioned. This integration of
effective security controls isn't only critical from a security perspective, it's critical to
ensure that application security is cost and schedule effective. Assessing an application
for security issues when it's 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.
Attractive Accounts for Credential Theft
Article • 06/08/2022
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.
Reducing the Active Directory Attack
Surface
Article • 04/28/2023
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
Enterprise Admins
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.
Domain Admins
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.
Administrators
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.
Schema Admins
A fourth privileged group, Schema Admins (SA), exists only in the forest root domain
and has only that domain's built-in Administrator account as a default member, similar
to the Enterprise Admins group. The Schema Admins group is intended to be populated
only temporarily and occasionally (when modification of the AD DS schema is required).
Although the SA group is the only group that can modify the Active Directory schema
(that is., the directory's underlying data structures such as objects and attributes), the
scope of the SA group's rights and permissions is more limited than the previously
described groups. It is also common to find that organizations have developed
appropriate practices for the management of the membership of the SA group because
membership in the group is typically infrequently needed, and only for short periods of
time. This is technically true of the EA, DA, and BA groups in Active Directory, as well,
but it is far less common to find that organizations have implemented similar practices
for these groups as for the SA group.
Protected Accounts and Groups in Active Directory
Within Active Directory, a default set of privileged accounts and groups called
"protected" accounts and groups are secured differently than other objects in the
directory. Any account that has direct or transitive membership in any protected group
(regardless of whether the membership is derived from security or distribution groups)
inherits this restricted security.
For example, if a user is a member of a distribution group that is, in turn, a member of a
protected group in Active Directory, that user object is flagged as a protected account.
When an account is flagged as a protected account, the value of the adminCount
attribute on the object is set to 1.
７ Note
Although transitive membership in a protected group includes nested distribution

and nested security groups, accounts that are members of nested distribution
groups will not receive the protected group's SID in their access tokens. However,
distribution groups can be converted to security groups in Active Directory, which
is why distribution groups are included in protected group member enumeration.
Should a protected nested distribution group ever be converted to a security
group, the accounts that are members of the former distribution group will
subsequently receive the parent protected group's SID in their access tokens at the
next logon.
The following table lists the default protected accounts and groups in Active Directory
by operating system version and service pack level.
Default Protected Accounts and Groups in Active Directory by Operating System and
Service Pack (SP) Version
Windows Windows 2000 SP4 - Windows Server Windows Server 2008 -

2000 <SP4 Windows Server 2003 2003 SP1+ Windows Server 2012
Administrators Account Operators Account Account Operators

Operators
Administrator Administrator Administrator
Administrators Administrators Administrators
Domain Backup Operators Backup Backup Operators

Admins Operators
Windows Windows 2000 SP4 - Windows Server Windows Server 2008 -
2000 <SP4 Windows Server 2003 2003 SP1+ Windows Server 2012
Cert Publishers
Domain Admins Domain Admins Domain Admins
Enterprise Domain Controllers Domain Domain Controllers

Admins Controllers
Enterprise Admins Enterprise Enterprise Admins

Admins
Krbtgt Krbtgt Krbtgt
Print Operators Print Operators Print Operators
Read-only Domain
Controllers
Replicator Replicator Replicator
Schema Schema Admins Schema Admins

Admins
AdminSDHolder and SDProp
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 .
AdminSDHolder Ownership
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 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
Article • 04/28/2023
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.
Configuring GPOs to Restrict Administrator Accounts on Domain-

Joined Systems
In one or more GPOs that you create and link to workstation and member server OUs in
each domain, add the Administrator account to the following user rights in Computer
Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights
Assignments:
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.
Enable the "Account is sensitive and cannot be delegated" flag on

the account
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.
Enable the "Smart card is required for interactive logon" flag on

the account
When you enable the Smart card is required for interactive logon attribute on an
account, Windows resets the account's password to a 120-character random value. By
setting this flag on built-in Administrator accounts, you ensure that the password for the
account is not only long and complex, but is not known to any user. It is not technically
necessary to create smart cards for the accounts before enabling this attribute, but if
possible, smart cards should be created for each Administrator account prior to
configuring the account restrictions and the smart cards should be stored in secure
locations.
Although setting the Smart card is required for interactive logon flag resets the
account's password, it does not prevent a user with rights to reset the account's
password from setting the account to a known value and using the account's name and
new password to access resources on the network. Because of this, you should
implement the following additional controls on the account.
Configuring GPOs to Restrict Domains' Administrator Accounts on

Domain-Joined Systems
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 Settings\Security Settings\Local
Policies\User Rights Assignments:

７ 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.
Configuring GPOs to Restrict Administrator Accounts on Domain

Controllers
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.
Configure Auditing of Built-in 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 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
properties or 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 Services user right does not include the Administrators group, because
including it in this setting would also block these logons for accounts that are
members of the local computer's Administrators group. If services on computers
are configured to run in the context of any of the privileged groups described in
this section, implementing these settings can cause services and applications to fail.
Therefore, as with all of the recommendations in this section, you should
thoroughly test settings for applicability in your environment.
Role-Based Access Controls (RBAC) for Active Directory

Generally speaking, role-based access controls (RBAC) are a mechanism for grouping
users and providing access to resources based on business rules. In the case of Active
Directory, implementing RBAC for AD DS is the process of creating roles to which rights
and permissions are delegated to allow members of the role to perform day-to-day
administrative tasks without granting them excessive privilege. RBAC for Active Directory
can be designed and implemented via native tooling and interfaces, by leveraging
software you may already own, by purchasing third-party products, or any combination
of these approaches. This section does not provide step-by-step instructions to
implement RBAC for Active Directory, but instead discusses factors you should consider
in choosing an approach to implementing RBAC in your AD DS installations.
Native Approaches to RBAC for Active Directory

In the simplest RBAC implementation, you can implement roles as AD DS groups and
delegate rights and permissions to the groups that allow them to perform daily
administration within the designated scope of the role.
In some cases, existing security groups in Active Directory can be used to grant rights
and permissions appropriate to a job function. For example, if specific employees in
your IT organization are responsible for the management and maintenance of DNS
zones and records, delegating those responsibilities can be as simple as creating an
account for each DNS administrator and adding it to the DNS Admins group in Active
Directory. The DNS Admins group, unlike more highly privileged groups, has few
powerful rights across Active Directory, although members of this group have been
delegated permissions that allow them to administer DNS and is still subject to
compromise and abuse could result in elevation of privilege.
In other cases, you may need to create security groups and delegate rights and
permissions to Active Directory objects, file system objects, and registry objects to allow
members of the groups to perform designated administrative tasks. For example, if your
Help Desk operators are responsible for resetting forgotten passwords, assisting users
with connectivity problems, and troubleshooting application settings, you may need to
combine delegation settings on user objects in Active Directory with privileges that
allow Help Desk users to connect remotely to users' computers to view or modify the
users' configuration settings. For each role you define, you should identify:
1. Which tasks members of the role perform on a day-to-day basis and which tasks
are less frequently performed.
2. On which systems and in which applications members of a role should be granted
rights and permissions.
3. Which users should be granted membership in a role.
4. How management of role memberships will be performed.
In many environments, manually creating role-based access controls for administration

of an Active Directory environment can be challenging to implement and maintain. If
you have clearly defined roles and responsibilities for administration of your IT
infrastructure, you may want to leverage additional tooling to assist you in creating a
manageable native RBAC deployment. For example, if Forefront Identity Manager (FIM)
is in use in your environment, you can use FIM to automate the creation and population
of administrative roles, which can ease ongoing administration. If you use 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 smart card for
interactive logon attribute, and audit for changes to (at a minimum), any of the
attributes on the Account tab for the account (for example, cn, name,
sAMAccountName, userPrincipalName, and userAccountControl) administrative user
objects.
Although setting the Require smart card for interactive logon on accounts resets the
account's password to a 120-character random value and requires smart cards for
interactive logons, the attribute can still be overwritten by users with permissions that
allow them to change passwords on the accounts, and the accounts can then be used to
establish non-interactive logons with only user name and password.
In other cases, depending on the configuration of accounts in Active Directory and

certificate settings in Active Directory Certificate Services (AD CS) or a third-party PKI,
User Principal Name (UPN) attributes for administrative or VIP accounts can be targeted
for a specific kind of attack, as described here.
UPN Hijacking for Certificate Spoofing
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.
Implementing Secure Administrative
Hosts
Article • 07/29/2021
Secure administrative hosts are workstations or servers that have been configured
specifically for the purposes of creating secure platforms from which privileged accounts
can perform administrative tasks in Active Directory or on domain controllers, domain-
joined systems, and applications running on domain-joined systems. In this case,
"privileged accounts" refers not only to accounts that are members of the most
privileged groups in Active Directory, but to any accounts that have been delegated
rights and permissions that allow administrative tasks to be performed.
These accounts may be Help Desk accounts that have the ability to reset passwords for
most of the users in a domain, accounts that are used to administer DNS records and
zones, or accounts that are used for configuration management. Secure administrative
hosts are dedicated to administrative functionality, and they do not run software such as
email applications, web browsers, or productivity software such as Microsoft Office.
Although the "most privileged" accounts and groups should accordingly be the most
stringently protected, this does not eliminate the need to protect any accounts and
groups to which privileges above those of standard user accounts have been granted.
A secure administrative host can be a dedicated workstation that is used only for
administrative tasks, a member server that runs the Remote Desktop Gateway server
role and to which IT users connect to perform administration of destination hosts, or a
server that runs the Hyper-V role and provides a unique virtual machine for each IT user
to use for their administrative tasks. In many environments, combinations of all three
approaches may be implemented.
Implementing secure administrative hosts requires planning and configuration that is

consistent with your organization's size, administrative practices, risk appetite, and
budget. Considerations and options for implementing secure administrative hosts are
provided here for you to use in developing an administrative strategy suitable for your
organization.
Principles for Creating Secure Administrative
Hosts
To effectively secure systems against attacks, a few general principles should be kept in
mind:
1. You should never administer a trusted system (that is, a secure server such as a
domain controller) from a less-trusted host (that is, a workstation that is not
secured to the same degree as the systems it manages).
2. You should not rely on a single authentication factor when performing privileged
activities; that is, user name and password combinations should not be considered
acceptable authentication because only a single factor (something you know) is
represented. You should consider where credentials are generated and cached or
stored in administrative scenarios.
3. Although most attacks in the current threat landscape leverage malware and
malicious hacking, do not omit physical security when designing and
implementing secure administrative hosts.
Account Configuration
Even if your organization does not currently use smart cards, you should consider
implementing them for privileged accounts and secure administrative hosts.
Administrative hosts should be configured to require smart card logon for all accounts
by modifying the following setting in a GPO that is linked to the OUs containing
administrative hosts:
Computer Configuration\Policies\Windows Settings\Local Policies\Security

Options\Interactive logon: Require smart card
This setting will require all interactive logons to use a smart card, regardless of the
configuration on an individual account in Active Directory.
You should also configure secure administrative hosts to permit logons only by
authorized accounts, which can be configured in:
Computer Configuration\Policies\Windows Settings\Local Policies\Security

Settings\Local Policies\User Rights Assignment
This grants interactive (and, where appropriate, Remote Desktop Services) logon rights
only to authorized users of the secure administrative host.
Physical Security
For administrative hosts to be considered trustworthy, they must be configured and
protected to the same degree as the systems they manage. Most of the
recommendations provided in Securing Domain Controllers Against Attack are also
applicable to the hosts that are used to administer domain controllers and the AD DS
database. One of the challenges of implementing secure administrative systems in most
environments is that physical security can be more difficult to implement because these
computers often reside in areas that are not as secure as servers hosted in datacenters,
such as administrative users' desktops.
Physical security includes controlling physical access to administrative hosts. In a small

organization, this may mean that you maintain a dedicated administrative workstation
that is kept locked in an office or a desk drawer when not in use. Or it may mean that
when you need to perform administration of Active Directory or your domain
controllers, you log on to the domain controller directly.
In medium-sized organizations, you may consider implementing secure administrative

"jump servers" that are located in a secured location in an office and are used when
management of Active Directory or domain controllers is required. You may also
implement administrative workstations that are locked in secure locations when not in
use, with or without jump servers.
In large organizations, you can deploy datacenter-housed jump servers that provide
strictly controlled access to Active Directory; domain controllers; and file, print, or
application servers. Implementation of a jump server architecture is most likely to
include a combination of secure workstations and servers in large environments.
Regardless of the size of your organization and the design of your administrative hosts,
you should secure physical computers against unauthorized access or theft, and should
use BitLocker Drive Encryption to encrypt and protect the drives on administrative hosts.
By implementing BitLocker on administrative hosts, even if a host is stolen or its disks
are removed, you can ensure that the data on the drive is inaccessible to unauthorized
users.
Operating System Versions and Configuration

All administrative hosts, whether servers or workstations, should run the newest
operating system in use in your organization for the reasons described earlier in this
document. By running current operating systems, your administrative staff benefits from
new security features, full vendor support, and additional functionality introduced in the
operating system. Moreover, when you are evaluating a new operating system, by
deploying it first to administrative hosts, you will need to familiarize yourself with the
new features, settings and management mechanisms it offers, which can subsequently
be leveraged in planning broader deployment of the operating system. By then, the
most sophisticated users in your organization will also be the users who are familiar with
the new operating system and best positioned to support it.
Microsoft Security Configuration Wizard

If you implement jump servers as part of your administrative host strategy, you should
use the built-in Security Configuration Wizard to configure service, registry, audit, and
firewall settings to reduce the server's attack surface. When the Security Configuration
Wizard configuration settings have been collected and configured, the settings can be
converted to a GPO that is used to enforce a consistent baseline configuration on all
jump servers. You can further edit the GPO to implement security settings specific to
jump servers, and can combine all of the settings with additional baseline settings
extracted from the Microsoft Security Compliance Manager.
Microsoft Security Compliance Manager

The Microsoft Security Compliance Manager is a freely available tool that integrates
security configurations that are recommended by Microsoft, based on operating system
version and role configuration, and collects them in a single tool and UI that can be
used to create and configure baseline security settings for domain controllers. Microsoft
Security Compliance Manager templates can be combined with Security Configuration
Wizard settings to produce comprehensive configuration baselines for jump servers that
are deployed and enforced by GPOs deployed at the OUs in which jump servers are
located in Active Directory.
７ Note
As of this writing, the Microsoft Security Compliance Manager does not include
settings specific to jump servers or other secure administrative hosts, but Security
Compliance Manager (SCM) can still be used to create initial baselines for your
administrative hosts. To properly secure the hosts, however, you should apply
additional security settings appropriate to highly secured workstations and servers.
AppLocker
Administrative hosts and virtual 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
Article • 03/10/2023
Applies to: 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 Active Directory Domain
Services (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, they 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 can recover using a known good backup
and to close the gaps that allowed the compromise.
Depending on an attacker's preparation, tooling, and skill, irreparable damage 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 direct path to destruction of member servers,
workstations, and Active Directory. Because of this threat, domain controllers should be
secured separately and more stringently than the general infrastructure.
Physical Security for Domain Controllers

This section provides information about physically securing domain controllers. Domain
controllers may be physical or virtual machines, in datacenters, branch offices, or remote
locations.
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 adds a small 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 can’t 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
also 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 in Windows Server, 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 where multiple servers reside but aren't 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 can’t be stored in a locked room in branch locations, you should consider
deploying Read-Only Domain Controllers (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
where virtual domain controllers can’t 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 where only a single physical server can be
installed, a server capable of running virtualization workloads should be installed, and
BitLocker Drive Encryption should be configured to protect all volumes in the server.
One virtual machine on the server should run as a RODC, with other servers running as
separate virtual machines on the host. Information about planning for deployment of
RODCs 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 the security of 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. Organizations should prioritize decommissioning
legacy operating systems in the domain controller population. Keeping domain
controllers current and eliminating legacy domain controllers, allows you to take
advantage of new functionality and security. This functionality 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

Tools can be used to create an initial security configuration baseline for domain
controllers that can later 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 like jump
servers. Control can be achieved through a combination of user rights settings and
WFAS configuration implemented with GPOs so that the policy is consistently applied. If
policy 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 use 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. No web browser
should be used on domain controllers. An analysis of thousands of domain controllers
has revealed numerous cases where 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 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 and current versions of Internet Explorer offer many
protections against malicious downloads, in most cases where 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 restricted by policy and

technical controls. Further to this, general Internet access to and from domain
controllers should also be strictly controlled.
Microsoft encourages all organizations to move to a cloud-based approach to identity

and access management and migrate from Active Directory to Azure Active Directory
(Azure AD). Azure AD is a complete cloud identity and access management solution for
managing directories, enabling access to on-premises and cloud apps, and protecting
identities from security threats. Azure AD also offers a robust and granular set of
security controls to help protect identities, such as multi-factor authentication,
Conditional Access policies, Identity Protection, identity governance, and Privileged
Identity Management.
Most organizations will operate in a hybrid identity model during their transition to the
cloud, where some element of their on-premises Active Directory will be synchronized
using Azure AD Connect. Whilst this hybrid model exists in any organization, Microsoft
recommends cloud powered protection of those on-premises identities using Microsoft
Defender for Identity. The configuration of the Defender for Identity sensor on domain
controllers and AD FS servers allows for a highly secured, one-way connection to the
cloud service through a proxy and to specific endpoints. A complete explanation on how
to configure this proxy connection can be found in the technical documentation for
Defender for Identity. This tightly controlled configuration ensures that the risk of
connecting these servers to the cloud service is mitigated, and organizations benefit
from the increase in protection capabilities Defender for Identity offers. Microsoft also
recommends that these servers are protected with cloud powered endpoint detection
like Microsoft Defender for Servers.
For those organizations that have regulatory or other policy driven requirements to
maintain an on-premises only implementation of Active Directory, Microsoft
recommends entirely restricting internet access to and from domain controllers.
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 .
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
Article • 02/15/2023
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 targets 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 to 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 added to Windows 7 and Windows Server
2008 R2 that lets you set what types of data you want to audit easily without
having to 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'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.
The following links provide information about improvements to Windows auditing in

Windows 8 and Windows Server 2012, and information about AD DS auditing in
What's New in Security Auditing - Provides an overview of new security auditing

features in Windows 8 and Windows Server 2012.
AD DS Auditing Step-by-Step Guide - Describes the new Active Directory Domain
Services (AD DS) auditing feature in Windows Server 2008. 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.
Audit Account Logon Events

Audit Account Logon Events report each instance of a security principal (for example,
user, computer, or service account) that's logging on to or logging off from one
computer when 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's 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. Despite this inconvenience, every security plan should include the success and
failure of this audit category.
Audit Account Management
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. Users and groups
should also be tracked when a user or computer account is renamed, disabled, or
enabled, and when a user or computer password is changed. An event can be generated
for users or groups added to or removed from other groups.
Audit Directory Service Access
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. This setting generates a lot
of "noise" if enabled.
Audit Logon Events
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 this policy nevertheless should be enabled by default in any security
auditing plan.
Audit Object Access
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 10 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.
Auditing Policy Change
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."
Audit Privilege Use
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.
Audit Process Tracking
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's useful for tracking malicious users and the programs they use.
Enabling Audit Process Tracking generates a large number of events, so typically it's 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 don't 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.
System Events Audit
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's 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 that aren't useful.
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 command on any computer
running Windows Server 2012, Windows Server 2008 R2, 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
command:
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 descriptions of their functions.
Auditing Subcategories Descriptions

Audit policy subcategories enable the following event log message types:
Account Logon
Credential Validation
This subcategory reports the results of validation tests on credentials submitted for a
user account logon request. These events occur on the computer that's authoritative for
the credentials. For domain accounts, the domain controller is authoritative; 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.
Kerberos Service Ticket Operations
This subcategory reports events generated by Kerberos ticket request processes on the
domain controller that's authoritative for the domain account.
Kerberos Authentication Service
This subcategory reports events generated by the Kerberos authentication service. These
events occur on the computer that's authoritative for the credentials.
Other Account Logon Events
This subcategory reports the events that occur in response to credentials submitted for
a user account logon request that don't relate to credential validation or Kerberos
tickets. These events occur on the computer that's 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
User Account Management
This subcategory reports each event of user account management, such as:
User account created, changed, or deleted
User account renamed, disabled, or enabled
Password set or changed
If this audit policy setting is enabled, administrators can track events to detect malicious,
accidental, and authorized creation of user accounts.
Computer Account Management
This subcategory reports each event of computer account management, such as when a
computer account is created, changed, deleted, renamed, disabled, or enabled.
Security Group Management
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.
Distribution Group Management
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.
Application Group Management
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.
Other Account Management Events
This subcategory reports other account management events.
Detailed Process Tracking

Detailed Process Tracking monitoring includes both creation and termination of
processes.
Process Creation
This subcategory reports the creation of a process and the name of the user or program
that created it.
Process Termination
This subcategory reports when a process terminates.
DPAPI 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.
RPC Events
This subcategory reports remote procedure call (RPC) connection events.
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.
Directory Service Changes
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 don't cause audit events
to be generated due to settings on the object class in the schema. This subcategory
applies only to domain controllers.
Directory Service Replication
This subcategory reports when replication between two domain controllers begins and
ends.
Detailed Directory Service Replication
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 the user 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's difficult or impossible to determine which
user has accessed or attempted to access organization computers.
Network Policy Server
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.
IPsec Main Mode
This subcategory reports the results of Internet Key Exchange (IKE) protocol and
Authenticated Internet Protocol (AuthIP) during Main Mode negotiations.
IPsec Extended Mode
This subcategory reports the results of AuthIP during Extended Mode negotiations.
Other Logon/Logoff Events
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.
Logoff
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 the user 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's difficult or impossible to determine which user has
accessed or attempted to access organization computers.
Account Lockout
This subcategory reports when a user's account is locked out as a result of too many
failed logon attempts.
IPsec Quick Mode
This subcategory reports the results of IKE protocol and AuthIP during Quick Mode
negotiations.
Special Logon
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
Audit Policy Change
This subcategory reports changes in audit policy including SACL changes.
Authentication Policy Change
This subcategory reports changes in authentication policy.

Authorization Policy Change
This subcategory reports changes in authorization policy including permissions (DACL)

changes.
MPSSVC Rule-Level Policy Change
This subcategory reports changes in policy rules used by the Microsoft Protection
Service (MPSSVC.exe). This service is used by Windows Firewall.
Filtering Platform Policy Change
This subcategory reports the addition and removal of objects from WFP, including
startup filters. These events can be very high in volume.
Other Policy Change Events
This subcategory reports other types of security policy changes such as configuration of
the Trusted Platform Module (TPM) or cryptographic providers.
Privilege Use
Privilege Use covers both sensitive and nonsensitive privileges.
Sensitive Privilege Use
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
Take ownership of files or other objects.
Auditing this subcategory will create a high volume of events.

Nonsensitive Privilege Use
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

Add workstations to domain
Adjust memory quotas for a process
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 locally
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
Synchronize directory service data.
Auditing this subcategory will create a very high volume of events.
Other Privilege Use Events
This security policy setting is not currently used.

Object Access
The Object Access category includes File System and Registry subcategories.
File System
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 won't 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.
Registry
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 won't cause auditing of any
events.
Kernel Object
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.
SAM
This subcategory reports when local Security Accounts Manager (SAM) authentication
database objects are accessed.
Certification Services
This subcategory reports when Certification Services operations are performed.

Application Generated
This subcategory reports when applications attempt to generate audit events by using
the Windows auditing application programming interfaces (APIs).
Handle Manipulation
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).
File Share
This subcategory reports when a file share is accessed. By itself, this policy setting won't
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.
Filtering Platform Packet Drop
This subcategory reports when packets are dropped by Windows Filtering Platform
(WFP). These events can be very high in volume.
Filtering Platform Connection
This subcategory reports when connections are allowed or blocked by WFP. These
events can be high in volume.
Other Object Access Events
This subcategory reports other object access-related events such as Task Scheduler jobs
and COM+ objects.
System
Security State Change
This subcategory reports changes in security state of the system, such as when the
security subsystem starts and stops.
Security System Extension
This subcategory reports the loading of extension code such as authentication packages
by the security subsystem.
System Integrity
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.
Other System Events
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 won't 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 can't be logged for any reason. Typically, an
event fails to be logged when the security audit log is full and the retention method
specified for the security log is Do Not Overwrite Events or Overwrite Events by Days.
Usually this policy is only enabled in 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'll 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, change
won't 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 can't 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 the
following privileges are assigned to a user security token:
AssignPrimaryTokenPrivilege
AuditPrivilege
BackupPrivilege
CreateTokenPrivilege
DebugPrivilege
EnableDelegationPrivilege
ImpersonatePrivilege
LoadDriverPrivilege
RestorePrivilege
SecurityPrivilege
SystemEnvironmentPrivilege
TakeOwnershipPrivilege
TcbPrivilege.
If this option is not enabled (default=Disabled), the BackupPrivilege and RestorePrivilege

privileges aren't recorded. Enabling this option can make the security log extremely
noisy (sometimes hundreds of events per 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 is 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
can't be both.
To prevent the legacy traditional category policy from overwriting audit policy
subcategories, you must enable the Force audit policy subcategory settings(Windows
Vista or later) to override audit policy category settings policy setting located under
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options.
We recommend that the subcategories be enabled and configured instead of the nine
main categories. This requires that a Group Policy setting be enabled (to allow
subcategories to override the auditing categories) along with configuring the different
subcategories that support auditing policies.
Auditing subcategories can be configured by using several methods, including Group

Policy and the command-line program, auditpol.exe.
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

Audit Policy Recommendations
Article • 08/03/2023
Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows 8.1,
Windows 7
This section addresses the Windows default audit policy settings, baseline
recommended audit policy settings, and the more aggressive recommendations from
Microsoft, for workstation and server products.
The SCM baseline recommendations shown here, along with the settings we
recommend to help detect compromise, are intended only to be a starting baseline
guide to administrators. Each organization must make its own decisions regarding the
threats they face, their acceptable risk tolerances, and what audit policy categories or
subcategories they should enable. For further information about threats, refer to the
Threats and Countermeasures Guide. Administrators without a thoughtful audit policy in
place are encouraged to start with the settings recommended here, and then to modify
and test, prior to implementing in their production environment.
The recommendations are for enterprise-class computers, which Microsoft defines as

computers that have average security requirements and require a high level of
operational functionality. Entities needing higher security requirements should consider
more aggressive audit policies.
７ Note
Microsoft Windows defaults and baseline recommendations were taken from the
Microsoft Security Compliance Manager tool.
The following baseline audit policy settings are recommended for normal security
computers that are not known to be under active, successful attack by determined
adversaries or malware.
Recommended Audit Policies by Operating

System
This section contains tables that list the audit setting recommendations that apply to the
following operating systems:
Windows Server 2016
Windows Server 2012
Windows Server 2008
Windows 10
Windows 8.1
Windows 7
These tables contain the Windows default setting, the baseline recommendations, and
the stronger recommendations for these operating systems.
Audit Policy Tables Legend
Notation Recommendation
Yes Enable in general scenarios
No Do not enable in general scenarios
If Enable if needed for a specific scenario, or if a role or feature for which auditing is
desired is installed on the machine
DC Enable on domain controllers
[Blank] No recommendation
Windows 10, Windows 8, and Windows 7 Audit Settings Recommendations
Audit Policy
Audit Policy Category or Windows Baseline Stronger

Subcategory Default Recommendation Recommendation
Success | Success | Failure Success | Failure
Failure
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
Failure
Account Management
Audit Application Group

Management
Audit Computer Account Yes | No Yes | Yes

Management
Audit Distribution Group

Management
Audit Other Account Yes | No Yes | Yes

Management Events
Audit Security Group Yes | No Yes | Yes

Management
Audit User Account Yes | No Yes | No Yes | Yes

Management

Failure
Detailed Tracking
Audit DPAPI Activity Yes | Yes
Audit Process Creation Yes | No Yes | Yes
Audit Process Termination
Audit RPC Events

Failure
DS Access
Audit Detailed Directory

Service Replication
Failure
Audit Directory Service

Access

Changes

Replication

Failure
Logon and Logoff
Audit Account Lockout Yes | No Yes | No
Audit User/Device Claims
Audit IPsec Extended Mode
Audit IPsec Main Mode IF | IF
Audit IPsec Quick Mode
Audit Logoff Yes | No Yes | No Yes | No
Audit Logon 1 Yes | Yes Yes | Yes Yes | Yes
Audit Network Policy Server Yes | Yes
Audit Other Logon/Logoff

Events
Audit Special Logon Yes | No Yes | No Yes | Yes

Failure
Object Access
Failure
Audit Application
Generated
Audit Certification Services
Audit Detailed File Share
Audit File Share
Audit File System
Audit Filtering Platform

Connection

Packet Drop
Audit Handle Manipulation
Audit Kernel Object
Audit Other Object Access

Events
Audit Registry
Audit Removable Storage
Audit SAM
Audit Central Access Policy

Staging

Failure
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

Failure
Change

Policy Change
Audit MPSSVC Rule-Level Yes

Policy Change
Audit Other Policy Change

Events

Failure
Privilege Use
Audit Non Sensitive

Privilege Use
Audit Other Privilege Use

Events
Audit Sensitive Privilege

Use

Failure
System
Audit IPsec Driver Yes | Yes Yes | Yes
Audit Other System Events Yes | Yes
Audit Security State Yes | No Yes | Yes Yes | Yes

Change
Audit Security System Yes | Yes Yes | Yes

Extension
Audit System Integrity Yes | Yes Yes | Yes Yes | Yes

Failure
Global Object Access

Auditing
Audit IPsec Driver
Audit Other System Events
Audit Security State

Change
Audit Security System

Extension
Audit System Integrity
1
Beginning with Windows 10 version 1809, Audit Logon is enabled by default for both
Success and Failure. In previous versions of Windows, only Success is enabled by default.
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows
Server 2008 R2, and Windows Server 2008 Audit Settings Recommendations

Failure
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
Failure
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

Failure
Detailed Tracking
Audit DPAPI Activity Yes | Yes
Audit Process Creation Yes | No Yes | Yes
Audit Process Termination
Audit RPC Events

Failure
DS Access
Audit Detailed Directory

Service Replication
Failure
Audit Directory Service DC | DC DC | DC

Access
Audit Directory Service DC | DC DC | DC

Changes

Replication

Failure
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

Failure
Object Access
Failure
Audit Application
Generated
Audit Certification Services
Audit Detailed File Share
Audit File Share
Audit File System

Connection

Packet Drop
Audit Handle Manipulation
Audit Kernel Object
Audit Other Object Access

Events
Audit Registry
Audit Removable Storage
Audit SAM
Audit Central Access Policy

Staging

Failure
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

Failure
Change

Policy Change
Audit MPSSVC Rule-Level Yes

Policy Change
Audit Other Policy Change

Events

Failure
Privilege Use
Audit Non Sensitive

Privilege Use
Audit Other Privilege Use

Events
Audit Sensitive Privilege

Use

Failure
System
Audit IPsec Driver Yes | Yes Yes | Yes
Audit Other System Events Yes | Yes
Audit Security State Yes | No Yes | Yes Yes | Yes

Change
Audit Security System Yes | Yes Yes | Yes

Extension
Audit System Integrity Yes | Yes Yes | Yes Yes | Yes

Failure
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

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.
Article • 05/16/2023
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's 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'll be attacked again and again. It isn't 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 AD Forest

Recovery - Steps for Restoring the forest. You may be able to prevent your new
environment from being completely compromised, but even if you can't, you'll 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's 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 doesn't 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're 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'll
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 doesn't 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's much harder to secure an infrastructure after the fact than
it's to start fresh and to construct an environment that is resistant to attack and
compromise. But as previously noted, it's 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's 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's 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's 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. Don't configure a pristine environment to trust a legacy forest, although you can
configure a legacy environment to trust a pristine forest.
3. Don't migrate user accounts or groups from a legacy forest to a pristine

environment if there's 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. Don't 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. Don't permit the installation of legacy operating systems or applications in the

pristine forest. If an application can't 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 don't 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
don't 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 can't 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 doesn't 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 re-homing and modernizing your critical business
assets, you can focus on deploying effective management and monitoring while not
needing to accommodate legacy settings and protocols.
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's 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. Alternate approaches include smart cards (that 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's secured by
trusted platform module (TPM) chips in users' computers. Multi-factor authentication
doesn't prevent credential theft attacks if a computer is already compromised. However,
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
Article • 05/17/2023
Law Number Ten: Technology isn't 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's maintained securely. Although you've
been given specific technical controls to increase the security of your AD DS
installations, technology alone won't protect an environment in which IT doesn't 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 aren't 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's a core business function. If your
organization couldn't 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 isn't 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's 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 can't 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 shouldn't 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're 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's
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're 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 shouldn't 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's simply not
feasible to monitor all of the activities of all users. However, if you're 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 isn't 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're 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
Article • 07/29/2021
Appendices are included in this document to augment the information contained in the
body of the document. The list of appendices and a brief description of each in included
the following table.
Appendix B: Privileged Provides background information that helps you to identify the
Accounts and Groups in users and groups you should focus on securing because they can
Active Directory be leveraged by attackers to compromise and even destroy your
Active Directory installation.
Appendix C: Protected Contains information about protected groups in Active Directory. It

Accounts and Groups in also contains information for limited customization (removal) of
Active Directory groups that are considered protected groups and are affected by
AdminSDHolder and SDProp.
Appendix D: Securing Built- Contains guidelines to help secure the Administrator account in
In Administrator Accounts each domain in the forest.
in Active Directory
Appendix E: Securing Contains guidelines to help secure the Enterprise Admins group in
Enterprise Admins Groups the forest.
in Active Directory
Appendix F: Securing Contains guidelines to help secure the Domain Admins group in
Domain Admins Groups in each domain in the forest.
Active Directory
Appendix G: Securing Contains guidelines to help secure the Built-in Administrators

Administrators Groups in group in each domain in the forest.
Active Directory
Appendix H: Securing Local Contains guidelines to help secure local Administrator accounts
Administrator Accounts and and Administrators groups on domain-joined servers and
Groups workstations.
Appendix I: Creating Provides information to create accounts that have limited privileges
Management Accounts for and can be stringently controlled, but can be used to populate
Protected Accounts and privileged groups in Active Directory when temporary elevation is
Groups in Active Directory required.
Appendix L: Events to Lists events for which you should monitor in your environment.
Monitor
Appendix M: Document Contains a list of recommended reading. Also contains a list of

Links and Recommended links to external documents and their URLs so that readers of hard
Reading copies of this document can access this information.
Appendix B: Privileged Accounts and
Groups in Active Directory
Article • 07/29/2021
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.
Table B-1: User Rights and Privileges

User Right in Group Policy Name of Constant
Access Credential Manager as a trusted caller SeTrustedCredManAccessPrivilege
Access this computer from the network SeNetworkLogonRight
Act as part of the operating system SeTcbPrivilege
Add workstations to domain SeMachineAccountPrivilege
Adjust memory quotas for a process SeIncreaseQuotaPrivilege
Allow log on locally SeInteractiveLogonRight
Allow log on through Terminal Services SeRemoteInteractiveLogonRight
Back up files and directories SeBackupPrivilege
Bypass traverse checking SeChangeNotifyPrivilege
Change the system time SeSystemtimePrivilege
Change the time zone SeTimeZonePrivilege
Create a pagefile SeCreatePagefilePrivilege
Create a token object SeCreateTokenPrivilege
Create global objects SeCreateGlobalPrivilege
Create permanent shared objects SeCreatePermanentPrivilege
Create symbolic links SeCreateSymbolicLinkPrivilege
Debug programs SeDebugPrivilege
Deny access to this computer from the network SeDenyNetworkLogonRight
Deny log on as a batch job SeDenyBatchLogonRight
Deny log on as a service SeDenyServiceLogonRight
Deny log on locally SeDenyInteractiveLogonRight
Deny log on through Terminal Services SeDenyRemoteInteractiveLogonRight
Enable computer and user accounts to be trusted for SeEnableDelegationPrivilege

delegation
Force shutdown from a remote system SeRemoteShutdownPrivilege
Generate security audits SeAuditPrivilege
Impersonate a client after authentication SeImpersonatePrivilege

User Right in Group Policy Name of Constant
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.
Table B-1: Built-in and Default Accounts and Groups in Active

Directory
Account or Group Default Description and Default User Rights

Container,
Group Scope
and Type
Access Control Assistance Built-in Members of this group can remotely query
Operators (Active container authorization attributes and permissions for
Directory in Windows Domain-local resources on this computer.
Server 2012) security Direct user rights: None
group
Inherited user rights:
Account Operators Built-in Members can administer domain user and group
container accounts.
Domain-local Direct user rights: None
security
group Inherited user rights:
Administrator account Users Built-in account for administering the domain.

container Direct user rights: None
Not a group

Container,
Group Scope
and Type
Change the time zone
Create a pagefile
Debug programs
Enable computer and user accounts to be trusted for

delegation
Impersonate a client after authentication
Restore files and directories

Container,
Group Scope
and Type
Take ownership of files or other objects
Administrators group Built-in Administrators have complete and unrestricted

container access to the domain.
Domain-local Direct user rights:
security
group Access this computer from the network
Create a pagefile
Debug programs

delegation

Container,
Group Scope
and Type
Allowed RODC Password Users Members in this group can have their passwords
Replication Group container replicated to all read-only domain controllers in the
Domain-local domain.
security Direct user rights: None
group

Container,
Group Scope
and Type
Backup Operators Built-in Backup Operators can override security restrictions

container for the sole purpose of backing up or restoring files.
security
group Allow log on locally
Cert Publishers Users Members of this group are permitted to publish

container certificates to the directory.
security

Container,
Group Scope
and Type
Certificate Service DCOM Built-in If Certificate Services is installed on a domain

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

container operations.
security

Container,
Group Scope
and Type
Debugger Users This is The presence of a Debugger Users group indicates

neither a that debugging tools have been installed on the
default nor a system at some point, whether via Visual Studio, SQL,
built-in Office, or other applications that require and support
group, but a debugging environment. This group allows remote
when debugging access to computers. When this group
present in exists at the domain level, it indicates that a
AD DS, is debugger or an application that contains a debugger
cause for has been installed on a domain controller.
further
investigation.
Denied RODC Password Users Members in this group cannot have their passwords
Replication Group container replicated to any read-only domain controllers in the
Domain-local domain.
group
DHCP Administrators Users Members of this group have administrative access to

container the DHCP Server service.
security

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

container the DNS Server service.
security

Container,
Group Scope
and Type
DnsUpdateProxy Users Members of this group are DNS clients who are
container permitted to perform dynamic updates on behalf of
Global clients that cannot themselves perform dynamic
security updates. Members of this group are typically DHCP
group servers.
Direct user rights: None
Domain Admins Users Designated administrators of the domain; Domain

container Admins is a member of every domain-joined
Global computer's local Administrators group and receives
security rights and permissions granted to the local
group Administrators group, in addition to the domain's
Administrators group.
Create a pagefile

Container,
Group Scope
and Type
Debug programs

delegation
Domain Computers Users All workstations and servers that are joined to the
container domain are by default members of this group.
Global Default direct user rights: None
security

Container,
Group Scope
and Type
Domain Controllers Users All domain controllers in the domain. Note: Domain
container controllers are not a member of the Domain
Global Computers group.
group
Domain Guests Users All guests in the domain

Global
security Inherited user rights:
group
Domain Users Users All users in the domain

Global
group
Enterprise Admins (exists Users Enterprise Admins have permissions to change

only in forest root container forest-wide configuration settings; Enterprise Admins
domain) Universal is a member of every domain's Administrators group
security and receives rights and permissions granted to that
group group.

Container,
Group Scope
and Type
Create a pagefile
Debug programs

delegation

Container,
Group Scope
and Type
Enterprise Read-only Users This group contains the accounts for all read-only
Domain Controllers container domain controllers in the forest.
Universal Direct user rights: None
security
Event Log Readers Built-in Members of this group in can read the event logs on
container domain controllers.
security
Group Policy Creator Users Members of this group can create and modify Group
Owners container Policy Objects in the domain.
Global Direct user rights: None
security

Container,
Group Scope
and Type
Guest Users This is the only account in an AD DS domain that

container does not have the Authenticated Users SID added to
Not a group its access token. Therefore, any resources that are
configured to grant access to the Authenticated
Users group will not be accessible to this account.
This behavior is not true of members of the Domain
Guests and Guests groups, however- members of
those groups do have the Authenticated Users SID
added to their access tokens.
Guests Built-in Guests have the same access as members of the

container Users group by default, except for the Guest account,
Domain-local which is further restricted as described earlier.
group
Hyper-V Administrators Built-in Members of this group have complete and

(Windows Server 2012) container unrestricted access to all features of Hyper-V.
security

Container,
Group Scope
and Type
IIS_IUSRS Built-in Built-in group used by Internet Information Services.

Domain-local
group
Incoming Forest Trust Built-in Members of this group can create incoming, one-
Builders (exists only in container way trusts to this forest. (Creation of outbound forest
forest root domain) Domain-local trusts is reserved for Enterprise Admins.)
group
Krbtgt Users The Krbtgt account is the service account for the
container Kerberos Key Distribution Center in the domain. This
Not a group 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
Container,
Group Scope
and Type
Network Configuration Built-in Members of this group are granted privileges that
Operators container allow them to manage configuration of networking
Domain-local features.
group
Performance Log Users Built-in Members of this group can schedule logging of
container performance counters, enable trace providers, and
Domain-local collect event traces locally and via remote access to
security the computer.
group Direct user rights:
Performance Monitor Built-in Members of this group can access performance

Users container counter data locally and remotely.
security

Container,
Group Scope
and Type
Pre-Windows 2000 Built-in This group exists for backward compatibility with
Compatible Access container operating systems prior to Windows 2000 Server,
Domain-local and it provides the ability for members to read user
security and group information in the domain.
group Direct user rights:
Print Operators Built-in Members of this group can administer domain

container printers.
security

Container,
Group Scope
and Type
RAS and IAS Servers Users Servers in this group can read remote access
container properties on user accounts in the domain.
security
RDS Endpoint Servers Built-in Servers in this group run virtual machines and host
(Windows Server 2012) container sessions where users RemoteApp programs and
Domain-local personal virtual desktops run. This group needs to be
security populated on servers running RD Connection Broker.
group RD Session Host servers and RD Virtualization Host
servers used in the deployment need to be in this
group.

Container,
Group Scope
and Type
RDS Management Servers Built-in Servers in this group can perform routine
(Windows Server 2012) container administrative actions on servers running Remote
Domain-local Desktop Services. This group needs to be populated
security on all servers in a Remote Desktop Services
group deployment. The servers running the RDS Central
Management service must be included in this group.
RDS Remote Access Built-in Servers in this group enable users of RemoteApp
Servers (Windows Server container programs and personal virtual desktops access to
2012) Domain-local these resources. In Internet-facing deployments,
security these servers are typically deployed in an edge
group 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.

Container,
Group Scope
and Type
Read-only Domain Users This group contains all read-only domain controllers
Controllers container in the domain.
Global Direct user rights: None
security
Remote Desktop Users Built-in Members of this group are granted the right to log
container on remotely using RDP.
security
Remote Management Built-in Members of this group can access WMI resources
Users (Windows Server container over management protocols (such as WS-
2012) Domain-local Management via the Windows Remote Management
security service). This applies only to WMI namespaces that
group grant access to the user.

Container,
Group Scope
and Type
Replicator Built-in Supports legacy file replication in a domain.

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

Container,
Group Scope
and Type
Server Operators Built-in Members of this group can administer domain

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

Container,
Group Scope
and Type
Users Built-in Users have permissions that allow them to read

container many objects and attributes in Active Directory,
Domain-local although they cannot change most. Users are
security prevented from making accidental or intentional
group system-wide changes and can run most applications.
Direct user rights:
Windows Authorization Built-in Members of this group have access to the computed
Access Group container tokenGroupsGlobalAndUniversal attribute on User
Domain-local objects
group
WinRMRemoteWMIUsers_ Users Members of this group can access WMI resources

(Windows Server 2012) container over management protocols (such as WS-
Domain-local Management via the Windows Remote Management
security service). This applies only to WMI namespaces that
group grant access to the user.

Appendix C: Protected Accounts and
Article • 05/18/2023
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. Even if somebody manually changes a
protected object's permissions, this process ensures that permissions are returned to
their defaults quickly.
Protected Groups
The following table contains the protected groups in Active Directory listed by domain
controller operating system.
Protected Accounts and Groups in Active Directory by Operating

System
Windows Server Windows Server Windows Server Windows Server

2003 RTM 2003 SP1+ 2012,
2016
Windows Server
2008 R2,
Windows Server
2008
Account Operators Account Operators Account Operators Account Operators

Windows Server Windows Server Windows Server Windows Server
2003 RTM 2003 SP1+ 2012,
2016
Windows Server
2008 R2,
Windows Server
2008
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
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.
Changing SDProp Interval
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.
Running SDProp Manually
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.
Running SDProp Manually in Windows Server 2008 or Earlier
You can force SDProp to run by using Ldp.exe or by running an LDAP modification
script. To run SDProp using Ldp.exe, perform the following steps after you have made
changes to the AdminSDHolder object in a domain:
1. Launch Ldp.exe.
2. Click Connection on the Ldp dialog box, and click Connect.
3. In the Connect dialog box, type the name of the domain controller for the domain
that holds the PDC Emulator (PDCE) role and click OK.
4. Verify that you have connected successfully, as indicated by Dn: (RootDSE) in the
following screenshot, click Connection and click Bind.
5. In the Bind dialog box, type the credentials of a user account that has permission
to modify the rootDSE object. (If you are logged on as that user, you can select
Bind as currently logged on user.) Click OK.
6. After you have completed the bind operation, click Browse, and click Modify.
7. In the Modify dialog box, leave the DN field blank. In the Edit Entry Attribute field,
type FixUpInheritance, and in the Values field, type Yes. Click Enter to populate the
Entry List as shown in the following screen shot.
8. In the populated Modify dialog box, click Run, and verify that the changes you
made to the AdminSDHolder object have appeared on that object.
７ Note
For information about modifying AdminSDHolder to allow designated unprivileged

accounts to modify the membership of protected groups, see Appendix I: Creating
Management Accounts for Protected Accounts and Groups in Active Directory.
If you prefer to run SDProp manually via LDIFDE or a script, you can create a modify
entry as shown here:
Running SDProp Manually in Windows Server 2012 or Windows Server
2008 R2
You can also force SDProp to run by using Ldp.exe or by running an LDAP modification
script. To run SDProp using Ldp.exe, perform the following steps after you have made
changes to the AdminSDHolder object in a domain:
1. Launch Ldp.exe.
2. In the Ldp dialog box, click Connection, and click Connect.
3. In the Connect dialog box, type the name of the domain controller for the domain
that holds the PDC Emulator (PDCE) role and click OK.
4. Verify that you have connected successfully, as indicated by Dn: (RootDSE) in the
following screenshot, click Connection and click Bind.
5. In the Bind dialog box, type the credentials of a user account that has permission
to modify the rootDSE object. (If you are logged on as that user, you can select
Bind as currently logged on user.) Click OK.
6. After you have completed the bind operation, click Browse, and click Modify.
7. In the Modify dialog box, leave the DN field blank. In the Edit Entry Attribute field,
type RunProtectAdminGroupsTask, and in the Values field, type 1. Click Enter to
populate the entry list as shown here.
8. In the populated Modify dialog box, click Run, and verify that the changes you
made to the AdminSDHolder object have appeared on that object.
If you prefer to run SDProp manually via LDIFDE or a script, you can create a modify
entry as shown here:
Appendix D: Securing Built-in
Administrator Accounts in Active
Directory
Article • 07/14/2022
Appendix D: Securing Built-in Administrator

Accounts in Active Directory
In each domain in Active Directory, an Administrator account is created as part of the
creation of the domain. This account is by default a member of the Domain Admins and
Administrators groups in the domain, and if the domain is the forest root domain, the
account is also a member of the Enterprise Admins group.
Use of a domain's Administrator account should be reserved only for initial build
activities, and possibly, disaster-recovery scenarios. To ensure that an Administrator
account can be used to effect repairs in the event that no other accounts can be used,
you should not change the default membership of the Administrator account in any
domain in the forest. Instead, you should secure the Administrator account in each
domain in the forest as described in the following section and detailed in the step-by-
step instructions that follow.
７ Note
This guide used to recommend disabling the account. This was removed as the
forest recovery white paper makes use of the default administrator account. The
reason is, this is the only account that allows logon without a Global Catalog Server.
Controls for Built-in Administrator Accounts
For the Built-in Administrator account in each domain in your forest, you should
configure the following settings:
Enable the Account is sensitive and cannot be delegated flag on the account.
Enable the Smart card is required for interactive logon flag on the account.
Configure GPOs to restrict the Administrator account's use on domain-joined
systems:
In one or more GPOs that you create and link to workstation and member
server OUs in each domain, add each domain's Administrator account to the
following user rights in Computer Configuration\Policies\Windows
Settings\Security Settings\Local Policies\User Rights Assignments:
７ Note
When you add accounts to this setting, you must specify whether you are
configuring local Administrator accounts or domain Administrator accounts. For
example, to add the NWTRADERS domain's Administrator account to these deny
rights, you must type the account as NWTRADERS\Administrator, or browse to the
Administrator account for the NWTRADERS domain. If you type "Administrator" in
these user rights settings in the Group Policy Object Editor, you will restrict the
local Administrator account on each computer to which the GPO is applied.
We recommend restricting local Administrator accounts on member servers and

workstations in the same manner as domain-based Administrator accounts.
Therefore, you should generally add the Administrator account for each domain in
the forest and the Administrator account for the local computers to these user
rights settings. The following screenshot shows an example of configuring these
user rights to block local Administrator accounts and a domain's Administrator
account from performing logons that should not be needed for these accounts.
Configure GPOs to restrict Administrator accounts on domain controllers

In each domain in the forest, the Default Domain Controllers GPO or a policy
linked to the domain controllers OU should be modified to add each domain's
Administrator account to the following user rights in Computer
Configuration\Policies\Windows Settings\Security Settings\Local
７ 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 can log on locally
to domain controllers. Because this account should only be 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, you should
configure auditing to monitor for usage of, or changes to the account. If the
account is signed in to, its password is reset, or any other modifications are made
to the account, alerts should be sent to the users or teams responsible for
administration of Active Directory, in addition to incident response teams in your
organization.
Step-by-Step Instructions to Secure Built-in Administrator Accounts

in Active Directory
1. In Server Manager, click Tools, and click Active Directory Users and Computers.
2. To prevent attacks that leverage delegation to use the account's credentials on

other systems, perform the following steps:
a. Right-click the Administrator account and click Properties.
b. Click the Account tab.

c. Under Account options, select Account is sensitive and cannot be delegated
flag as indicated in the following screenshot, and click OK.
3. To enable the Smart card is required for interactive logon flag on the account,
perform the following steps:
a. Right-click the Administrator account and select Properties.
b. Click the Account tab.
c. Under Account options, select the Smart card is required for interactive logon
flag as indicated in the following screenshot, and click OK.
Configuring GPOs to Restrict Administrator Accounts at the
Domain-Level
２ Warning
This GPO should never be linked at the domain-level because it can make the built-
in Administrator account unusable, even in disaster recovery scenarios.
1. In Server Manager, click Tools, and click Group Policy Management.
2. In the console tree, expand <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 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 <GPO Name>, and click OK (where <GPO
Name> is the name of this GPO) as indicated in the following screenshot.
5. In the details pane, right-click <GPO Name>, 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 <DomainName>\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.
screenshot.
9. Configure the user rights to prevent the Administrator account from logging on as
a service by doing the following:
a. Double-click Deny log on as a service and select Define these policy settings.
screenshot.
10. Configure the user rights to prevent the Administrator account from accessing
member servers and workstations via Remote Desktop Services by doing the
following:
a. Double-click Deny log on through Remote Desktop Services and select Define
screenshot.
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 <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).
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.
Verify "Smart card is required for interactive logon" Account

Option
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.
Verify "Deny access to this computer from the network" GPO
Settings
From any member server or workstation that is not affected by the GPO changes (such
as a jump server), attempt to access a member server or workstation over the network
that is affected by the GPO changes. To verify the GPO settings, attempt to map the
system drive by using the NET USE command by performing the following steps:
1. Log on to the domain using the domain's Built-in Administrator account.
2. With the mouse, move the pointer into the upper-right or lower-right corner of the
screen. When the Charms bar appears, click Search.
3. In the Search box, type command prompt, right-click Command Prompt, and then
click Run as administrator to open an elevated command prompt.
4. When prompted to approve the elevation, click Yes.
5. In the Command Prompt window, type net use \\<Server Name>\c$, where
<Server Name> is the name of the member server or workstation you are
attempting to access over the network.
6. The following screenshot shows the error message that should appear.
Verify "Deny log on as a batch job" GPO Settings
From any member server or workstation affected by the GPO changes, log on locally.
Create a Batch File
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 <Filename>.bat (where <Filename> is the name of the
new batch file).
Schedule a Task
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 <Task Name> (where <Task Name> is the
name of the new task).
5. Click the Actions tab, and click New.
6. Under Action:, select Start a program.
7. Under Program/script:, click Browse, locate and select the batch file created in the
"Create a Batch File" section, and click Open.
8. Click OK.
9. Click the General tab.
10. Under Security options, click Change User or Group.
11. Type the name of the Administrator 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.
Verify "Deny log on as a service" GPO Settings
1. From any member server or workstation affected by the GPO changes, log on
locally.
3. In the Search box, type services, and click Services.

4. Locate and double-click Print Spooler.
5. Click the Log On tab.
6. Under Log on as:, select This account.
7. Click Browse, type the name of the Administrator account at the domain-level,
click Check Names, and click OK.
8. Under Password: and Confirm password:, type the Administrator account's

password, and click OK.
9. Click OK three more times.
10. Right-click the Print Spooler service and select Restart.
11. When the service is restarted, a dialog box similar to the following should appear.
Revert Changes to the Printer Spooler Service
locally.
6. Under Log on as:, select the Local System account, and click OK.
Verify "Deny log on through Remote Desktop Services" GPO

Settings
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 Administrator account at
the domain-level.

Appendix E: Securing Enterprise Admins
Article • 10/08/2021
Appendix E: Securing Enterprise Admins

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:

domain, the Enterprise Admins group should be added to the following user rights
in Computer Configuration\Policies\Windows Settings\Security Settings\Local
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 <Domain>, and then click Change Domain (where <Domain> 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
2. In the console tree, expandv <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).
７ 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.
Name> 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:
c. Type Enterprise Admins, click Check Names, and click OK.
from logging on as a batch job by doing the following:
settings.
７ 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. Double-click Deny log as a service and select Define these policy settings.
b. Click Add User or Group and then click Browse.
７ Note
10. Configure user rights to prevent members of the Enterprise Admins group from
logging on locally to member servers and workstations by doing the following:
a. Double-click Deny log on locally and select Define these policy settings.
７ Note
from accessing member servers and workstations via Remote Desktop Services by
doing the following:
７ Note


Group Policy).
GPO.
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
Settings
as a "jump server"), attempt to access a member server or workstation over the network
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.
<Server Name> is the name of the member server or workstation you're

Create a Batch File
4. Click File, and click Save As.
5. In the File name box, type <Filename>.bat (where <Filename> is the name of the
new batch file).
Schedule a Task
７ Note

3. Click Action, and click Create Task.
6. In the Action field, select Start a program.
7. Under Program/script, click Browse, locate and select the batch file created in the
Create a Batch File section, and click Open.
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.
locally.
6. Under Log on as, select This account.
7. Click Browse, type the name of an account that is a member of the EAs group, click
Check Names, and click OK.
8. Under Password: and Confirm password, type the selected account's password,
and click OK.

10. Right-click the Print Spooler service and select Restart.

locally.
6. Under Log on as, select the Local System account, and click OK.
Verify "Deny log on locally" GPO Settings

log on locally using an account that is a member of the EA group. A dialog box
similar to the following should appear.
Settings
2. In the Search box, type remote desktop connection, and then click Remote
Desktop Connection.
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
Article • 07/29/2021
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.

domain, the DA group should be added to the following user rights in Computer
Configuration\Policies\Windows Settings\Security Settings\Local Policies\User
Rights Assignments:

Deny log on locally
Deny log on through Remote Desktop Services user rights
properties or 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

the domain where you want to set the Group Policy).

7. Configure the user rights to prevent members of the Domain Admins group from
accessing members servers and workstations over the network by doing the
following:
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:
settings.
9. Configure the user rights to prevent members of the DA group from logging on as
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.

accessing member servers and workstations via Remote Desktop Services by doing
the following:

Group Policy).
GPO.
） Important
If jump servers are used to administer domain controllers and Active

Directory, ensure that jump servers are located in an OU to which this
GPOs is not linked.
Verification Steps

Settings
system drive by using the NET USE command.
1. Log on locally using an account that is a member of the Domain Admins group.

Create a Batch File
5. In the File name field, type <Filename>.bat (where <Filename> is the name of the
new batch file).
Schedule a Task
７ Note

3. In the Task Scheduler menu bar, click Action, and click Create Task.
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.
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
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.

locally.
6. Under Log on as, select the This account option.
7. Click Browse, type the name of an account that is a member of the Domain
Admins group, click Check Names, and click OK.
8. Under Password and Confirm password, type the selected account's password,
and click OK.
10. Right-click Print Spooler and click Restart.

locally.
6. Under Log on as, select the Local System account, and click OK.
Verify "Deny log on locally" GPO Settings
log on locally using an account that is a member of the Domain Admins group. A
dialog box similar to the following should appear.

Settings
Connection.
name.)
4. When prompted, provide credentials for an account that is a member of the

Domain Admins group.
Appendix G: Securing Administrators
Article • 10/08/2021
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.

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:
properties or 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

4. In the New GPO dialog box, type <GPO Name>, and click OK (where GPO Name is
the name of this GPO).

7. Configure the user rights to prevent members of the Administrators group from
accessing member servers and workstations over the network by doing the
following:
c. Type Administrators, click Check Names, and click OK.
logging on as a batch job by doing the following:
settings.
logging on as a service 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).
GPO.
） 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 Services user right does not include the
Administrators group, because including it in this setting would also block
these logons for accounts that are members of the local computer's
Administrators group. If services on computers are configured to run in the
context of any of the privileged groups described in this section,
implementing these settings can cause services and applications to fail.
Therefore, as with all of the recommendations in this section, you should
thoroughly test settings for applicability in your environment.
Step-by-Step Instructions to Grant User Rights to the
Administrators Group


7. Configure the user rights to allow members of the Administrators group to access
domain controllers over the network by doing the following:
a. Double-click Access to this computer from the network and select Define
c. Click Add User or Group and click Browse.
8. Configure the user rights to allow members of the Administrators group to log on
locally by doing the following:
a. Double-click Allow log on locally and select Define these policy settings.
9. Configure the user rights to allow members of the Administrators group to log on
through Remote Desktop Services by doing the following:
a. Double-click Allow log on through Remote Desktop Services and select Define

11. In Group Policy Management, link the GPO to the domain controllers OU by doing
the following:

Group Policy).
b. Right-click the domain controllers OU and click Link an existing GPO.
Verification Steps

Settings
1. Log on locally using an account that is a member of the Administrators group.
Create a Batch File

5. In the File name field, type <Filename>.bat (where <Filename> is the name of the
new batch file).
Schedule a Task
７ 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
13. Click OK.
15. After entering the password, click OK.

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

locally.
6. In the Log on as field, click Local System account, and click OK.
Appendix H: Securing Local
Administrator Accounts and Groups
Article • 07/29/2021
Appendix H: Securing Local Administrator

Accounts and Groups
On all versions of Windows currently in mainstream support, the local Administrator
account is disabled by default, which makes the account unusable for pass-the-hash and
other credential theft attacks. However, in environments that contain legacy operating
systems or in which local Administrator accounts have been enabled, these accounts can
be used as previously described to propagate compromise across member servers and
workstations. Each local Administrator account and group should be secured as
described in the step-by-step instructions that follow.
For detailed information about considerations in securing Built-in Administrator (BA)

groups, see Implementing Least-Privilege Administrative Models.
Controls for Local Administrator Accounts

For the local Administrator account in each domain in your forest, you should configure
the following settings:
Configure GPOs to restrict the domain's Administrator account's use on domain-

joined systems
In one or more GPOs that you create and link to workstation and member
server OUs in each domain, add the Administrator account to the following user
rights in Computer Configuration\Policies\Windows Settings\Security
Settings\Local Policies\User Rights Assignments:

Step-by-Step Instructions to Secure Local Administrators Groups
Configuring GPOs to Restrict Administrator Account on Domain-

Joined Systems


7. Configure the user rights to prevent the local Administrator account from
accessing members servers and workstations over the network by doing the
following:
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:
settings.
is installed.
c. Click OK.
） Important
whether you are configuring local Administrator account or domain
9. Configure the user rights to prevent the local Administrator account from logging
on as a service by doing the following:
is installed.
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:
is installed.
c. Click OK.
） Important
Group Policy).
GPO.
c. Select the GPO that you created and click OK.
Verification Steps

Settings
as a jump server), attempt to access a member server or workstation over the network
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
Create a Batch File

5. In the File name box, type <Filename>.bat (where <Filename> is the name of the
new batch file).
Schedule a Task
７ Note

6. In the Action field, click Start a program.
7. In the Program/script field, click Browse, locate and select the batch file created in
the Create a Batch File 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.
locally.
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
locally.
6. In the Log on as: field, select Local System Account, and click OK.
Verify "Deny log on through Remote Desktop Services" GPO Settings
Connection.
name.)
4. When prompted, provide credentials for the system's local Administrator account.

Appendix I: Creating Management
Accounts for Protected Accounts and
Article • 07/29/2021
One of the challenges in implementing an Active Directory model that does not rely on
permanent membership in highly privileged groups is that there must be a mechanism
to populate these groups when temporary membership in the groups is required. Some
privileged identity management solutions require that the software's service accounts
are granted permanent membership in groups such as DA or Administrators in each
domain in the forest. However, it is technically not necessary for Privileged Identity
Management (PIM) solutions to run their services in such highly privileged contexts.
This appendix provides information that you can use for natively implemented or third-
party PIM solutions to create accounts that have limited privileges and can be
stringently controlled, but can be used to populate privileged groups in Active Directory
when temporary elevation is required. If you are implementing PIM as a native solution,
these accounts may be used by administrative staff to perform the temporary group
population, and if you're implementing PIM via third-party software, you might be able
to adapt these accounts to function as service accounts.
７ Note
The procedures described in this appendix provide one approach to the

management of highly privileged groups in Active Directory. You can adapt these
procedures to suit your needs, add additional restrictions, or omit some of the
restrictions that are described here.
Creating Management Accounts for Protected

Accounts and Groups in Active Directory
Creating accounts that can be used to manage the membership of privileged groups
without requiring the management accounts to be granted excessive rights and
permissions consists of four general activities that are described in the step-by-step
instructions that follow:
1. First, you should create a group that will manage the accounts, because these
accounts should be managed by a limited set of trusted users. If you do not
already have an OU structure that accommodates segregating privileged and
protected accounts and systems from the general population in the domain, you
should create one. Although specific instructions are not provided in this appendix,
screenshots show an example of such an OU hierarchy.
2. Create the management accounts. These accounts should be created as "regular"

user accounts and granted no user rights beyond those that are already granted to
users by default.
3. Implement restrictions on the management accounts that make them usable only
for the specialized purpose for which they were created, in addition to controlling
who can enable and use the accounts (the group you created in the first step).
4. Configure permissions on the AdminSDHolder object in each domain to allow the

management accounts to change the membership of the privileged groups in the
domain.
You should thoroughly test all of these procedures and modify them as needed for your
environment before implementing them in a production environment. You should also
verify that all settings work as expected (some testing procedures are provided in this
appendix), and you should test a disaster recovery scenario in which the management
accounts are not available to be used to populate protected groups for recovery
purposes. For more information about backing up and restoring Active Directory, see
the AD DS Backup and Recovery Step-by-Step Guide.
７ Note
By implementing the steps described in this appendix, you will create accounts that
will be able to manage the membership of all protected groups in each domain,
not only the highest-privilege Active Directory groups like EAs, DAs and BAs. For
more information about protected groups in Active Directory, see Appendix C:
Protected Accounts and Groups in Active Directory.
Step-by-Step Instructions for Creating Management

Accounts for Protected Groups
Creating a Group to Enable and Disable Management Accounts
Management accounts should have their passwords reset at each use and should be
disabled when activities requiring them are complete. Although you might also consider
implementing smart card logon requirements for these accounts, it is an optional
configuration and these instructions assume that the management accounts will be
configured with a user name and long, complex password as minimum controls. In this
step, you will create a group that has permissions to reset password on the
management accounts and to enable and disable the accounts.
To create a group to enable and disable management accounts, perform the following
steps:
1. In the OU structure where you will be housing the management accounts, right-
click the OU where you want to create the group, click New and click Group.
2. In the New Object - Group dialog box, enter a name for the group. If you plan to
use this group to "activate" all management accounts in your forest, make it a
universal security group. If you have a single-domain forest or if you plan to create
a group in each domain, you can create a global security group. Click OK to create
the group.
3. Right-click the group you just created, click Properties, and click the Object tab. In
the group's Object property dialog box, select Protect object from accidental
deletion, which will not only prevent otherwise-authorized users from deleting the
group, but also from moving it to another OU unless the attribute is first
deselected.
７ Note
If you have already configured permissions on the group's parent OUs to

restrict administration to a limited set of users, you may not need to perform
the following steps. They are provided here so that even if you have not yet
implemented limited administrative control over the OU structure in which
you've created this group, you can secure the group against modification by
unauthorized users.
4. Click the Members tab, and add the accounts for members of your team who will
be responsible for enabling management accounts or populating protected groups
when necessary.
5. If you have not already done so, in the Active Directory Users and Computers
console, click View and select Advanced Features. Right-click the group you just
created, click Properties, and click the Security tab. On the Security tab, click
Advanced.
6. In the Advanced Security Settings for [Group] dialog box, click Disable
Inheritance. When prompted, click Convert inherited permissions into explicit
permissions on this object, and click OK to return to the group's Security dialog
box.
7. On the Security tab, remove groups that should not be permitted to access this
group. For example, if you do not want Authenticated Users to be able to read the
group's name and general properties, you can remove that ACE. You can also
remove ACEs, such as those for account operators and pre-Windows 2000 Server
compatible access. You should, however, leave a minimum set of object
permissions in place. Leave the following ACEs intact:
SELF
SYSTEM
Domain Admins
Enterprise Admins
Administrators
Windows Authorization Access Group (if applicable)
ENTERPRISE DOMAIN CONTROLLERS
Although it may seem counterintuitive to allow the highest privileged groups in

Active Directory to manage this group, your goal in implementing these settings is
not to prevent members of those groups from making authorized changes. Rather,
the goal is to ensure that when you have occasion to require very high levels of
privilege, authorized changes will succeed. It is for this reason that changing
default privileged group nesting, rights, and permissions are discouraged
throughout this document. By leaving default structures intact and emptying the
membership of the highest privilege groups in the directory, you can create a more
secure environment that still functions as expected.
７ Note
If you have not already configured audit policies for the objects in the OU
structure where you created this group, you should configure auditing to log
changes this group.
8. You have completed configuration of the group that will be used to "check out"
management accounts when they are needed and "check in" the accounts when
their activities have been completed.
Creating the Management Accounts
You should create at least one account that will be used to manage the membership of
privileged groups in your Active Directory installation, and preferably a second account
to serve as a backup. Whether you choose to create the management accounts in a
single domain in the forest and grant them management capabilities for all domains'
protected groups, or whether you choose to implement management accounts in each
domain in the forest, the procedures are effectively the same.
７ Note
The steps in this document assume that you have not yet implemented role-based
access controls and privileged identity management for Active Directory. Therefore,
some procedures must be performed by a user whose account is a member of the
Domain Admins group for the domain in question.
When you are using an account with DA privileges, you can log on to a domain
controller to perform the configuration activities. Steps that do not require DA
privileges can be performed by less-privileged accounts that are logged on to
administrative workstations. Screen shots that show dialog boxes bordered in the
lighter blue color represent activities that can be performed on a domain controller.
Screen shots that show dialog boxes in the darker blue color represent activities
that can be performed on administrative workstations with accounts that have
limited privileges.
To create the management accounts, perform the following steps:
1. Log on to a domain controller with an account that is a member of the domain's

DA group.
2. Launch Active Directory Users and Computers and navigate to the OU where you
will be creating the management account.
3. Right-click the OU and click New and click User.
4. In the New Object - User dialog box, enter your desired naming information for
the account and click Next.
5. Provide an initial password for the user account, clear User must change password
at next logon, select User cannot change password and Account is disabled, and
click Next.
6. Verify that the account details are correct and click Finish.
7. Right-click the user object you just created and click Properties.
8. Click the Account tab.
9. In the Account Options field, select the Account is sensitive and cannot be
delegated flag, select the This account supports Kerberos AES 128 bit encryption
and/or the This account supports Kerberos AES 256 encryption flag, and click OK.
７ Note
Because this account, like other accounts, will have a limited, but powerful
function, the account should only be used on secure administrative hosts. For
all secure administrative hosts in your environment, you should consider
implementing the Group Policy setting Network Security: Configure
Encryption types allowed for Kerberos to allow only the most secure
encryption types you can implement for secure hosts.
Although implementing more secure encryption types for the hosts does not
mitigate credential theft attacks, the appropriate use and configuration of the
secure hosts does. Setting stronger encryption types for hosts that are only
used by privileged accounts simply reduces the overall attack surface of the
computers.
For more information about configuring encryption types on systems and

accounts, see Windows Configurations for Kerberos Supported Encryption
Type.
These settings are supported only on computers running Windows Server

2012, Windows Server 2008 R2, Windows 8, or Windows 7.
10. On the Object tab, select Protect object from accidental deletion. This will not
only prevent the object from being deleted (even by authorized users), but will
prevent it from being moved to a different OU in your AD DS hierarchy, unless the
check box is first cleared by a user with permission to change the attribute.
11. Click the Remote control tab.
12. Clear the Enable remote control flag. It should never be necessary for support staff
to connect to this account's sessions to implement fixes.
７ Note
Every object in Active Directory should have a designated IT owner and a

designated business owner, as described in Planning for Compromise. If you
are tracking ownership of AD DS objects in Active Directory (as opposed to an
external database), you should enter appropriate ownership information in
this object's properties.
In this case, the business owner is most likely an IT division, andthere is no

prohibition on business owners also being IT owners. The point of
establishing ownership of objects is to allow you to identify contacts when
changes need to be made to the objects, perhaps years from their initial
creation.
13. Click on the Organization tab.
14. Enter any information that is required in your AD DS object standards.
15. Click on the Dial-in tab.
16. In the Network Access Permission field, select Deny access.This account should
never need to connect over a remote connection.
７ Note
It is unlikely that this account will be used to log on to read-only domain

controllers (RODCs) in your environment. However, should circumstance ever
require the account to log on to an RODC, you should add this account to the
Denied RODC Password Replication Group so that its password is not cached
on the RODC.
Although the account's password should be reset after each use and the
account should be disabled, implementing this setting does not have a
deleterious effect on the account, and it might help in situations in which an
administrator forgets to reset the account's password and disable it.
17. Click the Member Of tab.
18. Click Add.
19. Type Denied RODC Password Replication Group in the Select Users, Contacts,
Computers dialog box and click Check Names. When the name of the group is
underlined in the object picker, click OK and verify that the account is now a
member of the two groups displayed in the following screenshot. Do not add the
account to any protected groups.
20. Click OK.

21. Click the Security tab and click Advanced.
22. In the Advanced Security Settings dialog box, click Disable inheritance and copy
the inherited permissions as explicit permissions, and click Add.
23. In the Permission Entry for [Account] dialog box, click Select a principal and add
the group you created in the previous procedure. Scroll to the bottom of the
dialog box and click Clear all to remove all default permissions.
24. Scroll to the top of the Permission Entry dialog box. Ensure that the Type drop-
down list is set to Allow, and in the Applies to drop-down list, select This object
only.
25. In the Permissions field, select Read all properties, Read permissions, and Reset
password.
26. In the Properties field, select Read userAccountControl and Write

userAccountControl.
27. Click OK, OK again in the Advanced Security Settings dialog box.
７ Note
The userAccountControl attribute controls multiple account configuration

options. You cannot grant permission to change only some of the
configuration options when you grant write permission to the attribute.
28. In the Group or user names field of the Security tab, remove any groups that
should not be permitted to access or manage the account. Do not remove any
groups that have been configured with Deny ACEs, such as the Everyone group
and the SELF computed account (that ACE was set when the user cannot change
password flag was enabled during creation of the account. Also do not remove the
group you just added, the SYSTEM account, or groups such as EA, DA, BA, or the
Windows Authorization Access Group.
29. Click Advanced and verify that the Advanced Security Settings dialog box looks
similar to the following screenshot.
30. Click OK, and OK again to close the account's property dialog box.
31. Setup of the first management account is now complete. You will test the account
in a later procedure.
Creating Additional Management Accounts
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.
Auditing Management Accounts
You should configure auditing on the account to log, at minimum, all writes to the
account. This will allow you to not only identify successful enabling of the account and
resetting of its password during authorized uses, but to also identify attempts by
unauthorized users to manipulate the account. Failed writes on the account should be
captured in your Security Information and Event Monitoring (SIEM) system (if
applicable), and should trigger alerts that provide notification to the staff responsible for
investigating potential compromises.
SIEM solutions take event information from involved security sources (for example,
event logs, application data, network streams, antimalware products, and intrusion
detection sources), collate the data, and try to make intelligent views and proactive
actions. There are many commercial SIEM solutions, and many enterprises create private
implementations. A well designed and appropriately implemented SIEM can significantly
enhance security monitoring and incident response capabilities. However, capabilities
and accuracy vary tremendously between solutions. SIEMs are beyond the scope of this
paper, but the specific event recommendations contained should be considered by any
SIEM implementer.
For more information about recommended audit configuration settings for domain
controllers, see Monitoring Active Directory for Signs of Compromise. Domain
controller-specific configuration settings are provided in Monitoring Active Directory for
Signs of Compromise.
Enabling Management Accounts to Modify the Membership of

Protected Groups
In this procedure, you will configure permissions on the domain's AdminSDHolder
object to allow the newly created management accounts to modify the membership of
protected groups in the domain. This procedure cannot be performed via a graphical
user interface (GUI).
As discussed in Appendix C: Protected Accounts and Groups in Active Directory, the ACL
on a domain's AdminSDHolder object is effectively "copied" to protected objects when
the SDProp task runs. Protected groups and accounts do not inherit their permissions
from the AdminSDHolder object; their permissions are explicitly set to match those on
the AdminSDHolder object. Therefore, when you modify permissions on the
AdminSDHolder object, you must modify them for attributes that are appropriate to the
type of the protected object you are targeting.
In this case, you will be granting the newly created management accounts to allow them
to read and write the members attribute on group objects. However, the
AdminSDHolder object is not a group object and group attributes are not exposed in
the graphical ACL editor. It is for this reason that you will implement the permissions
changes via the Dsacls command-line utility. To grant the (disabled) management
accounts permissions to modify the membership of protected groups, perform the
following steps:
1. Log on to a domain controller, preferably the domain controller holding the PDC
Emulator (PDCE) role, with the credentials of a user account that has been made a
member of the DA group in the domain.
2. Open an elevated command prompt by right-clicking Command Prompt and click

Run as administrator.
７ Note
For more information about elevation and user account control (UAC) in
Windows, see UAC Processes and Interactions on the TechNet website.
4. At the Command Prompt, type (substituting your domain-specific information)

Dsacls [distinguished name of the AdminSDHolder object in your domain] /G
[management account UPN]:RPWP;member.
The previous command (which is not case-sensitive) works as follows:
Dsacls sets or displays ACEs on directory objects
CN=AdminSDHolder,CN=System,DC=TailSpinToys,DC=msft identifies the

object to be modified
/G indicates that a grant ACE is being configured
PIM001@tailspintoys.msft is the User Principal Name (UPN) of the security

principal to which the ACEs will be granted
RPWP grants read property and write property permissions

Member is the name of the property (attribute) on which the permissions will
be set
For more information about use of Dsacls, type Dsacls without any parameters at a
command prompt.
If you have created multiple management accounts for the domain, you should run
the Dsacls command for each account. When you have completed the ACL
configuration on the AdminSDHolder object, you should force SDProp to run, or
wait until its scheduled run completes. For information about forcing SDProp to
run, see "Running SDProp Manually" in Appendix C: Protected Accounts and
Groups in Active Directory.
When SDProp has run, you can verify that the changes you made to the
AdminSDHolder object have been applied to protected groups in the domain. You
cannot verify this by viewing the ACL on the AdminSDHolder object for the
reasons previously described, but you can verify that the permissions have been
applied by viewing the ACLs on protected groups.
5. In Active Directory Users and Computers, verify that you have enabled Advanced
Features. To do so, click View, locate the Domain Admins group, right-click the
group and click Properties.
6. Click the Security tab and click Advanced to open the Advanced Security Settings
for Domain Admins dialog box.
7. Select Allow ACE for the management account and click Edit. Verify that the
account has been granted only Read Members and Write Members permissions
on the DA group, and click OK.
8. Click OK in the Advanced Security Settings dialog box, and click OK again to close
the property dialog box for the DA group.
9. You can repeat the previous steps for other protected groups in the domain; the
permissions should be the same for all protected groups. You have now completed
creation and configuration of the management accounts for the protected groups
in this domain.
７ Note
Any account that has permission to write membership of a group in Active

Directory can also add itself to the group. This behavior is by design and
cannot be disabled. For this reason, you should always keep management
accounts disabled when not in use, and should closely monitor the accounts
when they're disabled and when they're in use.
Verifying Group and Account Configuration Settings

Now that you have created and configured management accounts that can modify the
membership of protected groups in the domain (which includes the most highly
privileged EA, DA, and BA groups), you should verify that the accounts and their
management group have been created properly. Verification consists of these general
tasks:
1. Test the group that can enable and disable management accounts to verify that
members of the group can enable and disable the accounts and reset their
passwords, but cannot perform other administrative activities on the management
accounts.
2. Test the management accounts to verify that they can add and remove members
to protected groups in the domain, but cannot change any other properties of
protected accounts and groups.
Test the Group that Will Enable and Disable Management

Accounts
1. To test enabling a management account and resetting its password, log on to a
secure administrative workstation with an account that is a member of the group
you created in Appendix I: Creating Management Accounts for Protected Accounts
and Groups in Active Directory.
2. Open Active Directory Users and Computers, right-click the management

account, and click Enable Account.
3. A dialog box should display, confirming that the account has been enabled.
4. Next, reset the password on the management account. To do so, right-click the
account again and click Reset Password.
5. Type a new password for the account in the New password and Confirm password
fields, and click OK.
6. A dialog box should appear, confirming that the password for the account has
been reset.
7. Now attempt to modify additional properties of the management account. Right-

click the account and click Properties, and click the Remote control tab.
8. Select Enable remote control and click Apply. The operation should fail and an
Access Denied error message should display.
9. Click the Account tab for the account and attempt to change the account's name,
logon hours, or logon workstations. All should fail, and account options that are
not controlled by the userAccountControl attribute should be grayed out and
unavailable for modification.
10. Attempt to add the management group to a protected group such as the DA
group. When you click OK, a message should appear, informing you that you do
not have permissions to modify the group.
11. Perform additional tests as required to verify that you cannot configure anything
on the management account except userAccountControl settings and password
resets.
７ Note
The userAccountControl attribute controls multiple account configuration

options. You cannot grant permission to change only some of the
configuration options when you grant write permission to the attribute.
Test the Management Accounts
Now that you have enabled one or more accounts that can change the membership of
protected groups, you can test the accounts to ensure that they can modify protected
group membership, but cannot perform other modifications on protected accounts and
groups.
1. Log on to a secure administrative host as the first management account.
2. Launch Active Directory Users and Computers and locate the Domain Admins
group.
3. Right-click the Domain Admins group and click Properties.

4. In the Domain Admins Properties, click the Members tab and click Add. Enter the
name of an account that will be given temporary Domain Admins privileges and
click Check Names. When the name of the account is underlined, click OK to
return to the Members tab.
5. On the Members tab for the Domain Admins Properties dialog box, click Apply.
After clicking Apply, the account should stay a member of the DA group and you
should receive no error messages.
6. Click the Managed By tab in the Domain Admins Properties dialog box and verify
that you cannot enter text in any fields and all buttons are grayed out.
7. Click the General tab in the Domain Admins Properties dialog box and verify that
you cannot modify any of the information about that tab.
8. Repeat these steps for additional protected groups as needed. When you have
finished, log on to a secure administrative host with an account that is a member
of the group you created to enable and disable the management accounts. Then
reset the password on the management account you just tested and disable the
account. You have completed setup of the management accounts and the group
that will be responsible for enabling and disabling the accounts.
Appendix L: Events to Monitor
Article • 06/08/2022
The following table lists events that you should monitor in your environment, according
to the recommendations provided in Monitoring Active Directory for Signs of
Compromise. In the following table, the "Current Windows Event ID" column lists the
event ID as it is implemented in versions of Windows and Windows Server that are
currently in mainstream support.
The "Legacy Windows Event ID" column lists the corresponding event ID in legacy
versions of Windows such as client computers running Windows XP or earlier and
servers running Windows Server 2003 or earlier. The "Potential Criticality" column
identifies whether the event should be considered of low, medium, or high criticality in
detecting attacks, and the "Event Summary" column provides a brief description of the
event.
A potential criticality of High means that one occurrence of the event should be
investigated. Potential criticality of Medium or Low means that these events should only
be investigated if they occur unexpectedly or in numbers that significantly exceed the
expected baseline in a measured period of time. All organizations should test these
recommendations in their environments before creating alerts that require mandatory
investigative responses. Every environment is different, and some of the events ranked
with a potential criticality of High may occur due to other harmless events.
Current Legacy Potential Event Summary

Windows Windows Criticality
Event ID Event ID
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.
Event ID Event ID
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 Possible denial-of-service (DoS) attack

to High
1102 517 Medium The audit log was cleared

to High
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

Event ID Event ID
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.
4866 N/A Medium A trusted forest information entry was removed.
4867 N/A Medium A trusted forest information 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.
Event ID Event ID
4961 N/A Medium IPsec dropped an inbound packet that failed a replay check.
If this problem persists, it could indicate a replay attack
against this computer.
4962 N/A Medium IPsec dropped an inbound packet that failed a replay check.
The inbound packet had too low a sequence number to
ensure it was not a replay.
4963 N/A Medium IPsec dropped an inbound clear text packet that should have
been secured. This is usually due to the remote computer
changing its IPsec policy without informing this computer.
This could also be a spoofing attack attempt.
4965 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 persists, it could indicate a
network issue or an attempt to modify or replay this
negotiation.
4977 N/A Medium During Quick Mode negotiation, IPsec received an invalid
negotiation.
4978 N/A Medium During Extended Mode negotiation, IPsec received an invalid
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.
Event ID Event ID
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.
5028 N/A Medium The Windows Firewall Service was unable to parse the new
security policy. The service will continue with currently
enforced policy.
5029 N/A Medium The Windows Firewall Service failed to initialize the driver.
The service will continue to enforce the current policy.
5030 N/A Medium The Windows Firewall 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.
Event ID Event ID
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.
5827 N/A Medium The Netlogon service denied a vulnerable Netlogon secure
channel connection from a machine account.
5828 N/A Medium The Netlogon service denied a vulnerable Netlogon secure
channel connection using a trust account.
6145 N/A Medium One or more errors occurred while processing security policy
in the Group Policy objects.
6273 N/A Medium Network Policy Server denied access to a user.
6274 N/A Medium Network Policy Server discarded the request for a user.
6275 N/A Medium Network Policy Server discarded the accounting request for a
user.
6276 N/A Medium Network Policy Server quarantined a user.
6277 N/A Medium Network Policy Server granted access to a user but put it on
probation because the host did not meet the defined health
policy.
6278 N/A Medium Network Policy Server granted full access to a user because
the host met the defined health policy.
6279 N/A Medium Network Policy Server locked the user account due to
repeated failed authentication attempts.
6280 N/A Medium Network Policy Server 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

Event ID Event ID
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- Low An account failed to log on.

537,539
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.

Event ID Event ID
4650 N/A Low An IPsec Main Mode security association was established.
Extended Mode was not enabled. Certificate authentication
was not used.
4651 N/A Low An IPsec Main Mode security association was established.
Extended Mode was not enabled. A certificate was used for
authentication.
4652 N/A Low An IPsec Main Mode negotiation failed.
4653 N/A Low An IPsec Main Mode negotiation failed.
4654 N/A Low An IPsec Quick Mode negotiation failed.
4655 N/A Low An IPsec Main Mode 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.
4665 N/A Low An attempt was made to 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.

Event ID Event ID
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.
4690 594 Low An attempt was made to 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.
4699 602 Low A scheduled task was deleted.
4700 602 Low A scheduled task was enabled.
4701 602 Low A scheduled task was disabled.
4702 602 Low A scheduled task was 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.

Event ID Event ID
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 computer. PAStore
Engine applied local registry storage IPsec policy on the
computer. PAStore Engine failed to apply locally cached copy
of Active Directory storage IPsec policy on the computer.
PAStore Engine failed to apply Active Directory storage IPsec
policy on the computer. PAStore Engine failed to apply local
registry storage IPsec policy on the computer. PAStore Engine
failed to apply some rules of the active IPsec policy on the
computer. PAStore Engine failed to load directory storage
IPsec policy on the computer. PAStore Engine loaded
directory storage IPsec policy on the computer. PAStore
Engine failed to load local storage IPsec policy on the
computer. PAStore Engine loaded local storage IPsec policy
on the 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.
4723 627 Low An attempt was made to change an account's password.
4725 629 Low A user account was disabled.
4726 630 Low A user account was deleted.
4728 632 Low A member was added to a security-enabled global group.
4729 633 Low A member was removed from a security-enabled global

group.
4730 634 Low A security-enabled global group was deleted.
4731 635 Low A security-enabled local group was created.
4732 636 Low A member was added to a security-enabled local group.
4733 637 Low A member was removed from a security-enabled local group.
Event ID Event ID
4734 638 Low A security-enabled local group was deleted.
4738 642 Low A user account was changed.
4740 644 Low A user account was locked out.
4741 645 Low A computer account was changed.
4742 646 Low A computer account was changed.
4743 647 Low A computer account was deleted.
4744 648 Low A security-disabled local group was created.
4745 649 Low A security-disabled local group was changed.
4746 650 Low A member was added to a security-disabled local group.
4747 651 Low A member was removed from a security-disabled local

group.
4748 652 Low A security-disabled local group was deleted.
4749 653 Low A security-disabled global group was created.
4750 654 Low A security-disabled global group was changed.
4751 655 Low A member was added to a security-disabled global group.
4752 656 Low A member was removed from a security-disabled global

group.
4753 657 Low A security-disabled global group was deleted.
4756 660 Low A member was added to a security-enabled universal group.
4757 661 Low A member was removed from a security-enabled universal

group.
4758 662 Low A security-enabled universal group was deleted.
4759 663 Low A security-disabled universal group was created.
4760 664 Low A security-disabled universal group was changed.
4761 665 Low A member was added to a security-disabled universal group.
4762 666 Low A member was removed from a security-disabled universal

group.
Event ID Event ID
4767 671 Low A user account was unlocked.
4768 672,676 Low A Kerberos authentication ticket (TGT) was requested.
4769 673 Low A Kerberos service ticket was requested.
4770 674 Low A Kerberos service ticket was renewed.
4771 675 Low Kerberos pre-authentication failed.
4772 672 Low A Kerberos authentication ticket request failed.
4774 678 Low An account was mapped for logon.
4775 679 Low An account could not be mapped for logon.
4776 680,681 Low The domain controller attempted to validate the credentials
for an account.
4777 N/A Low The domain controller failed to validate the credentials for an
account.
4778 682 Low A session was reconnected to a Window Station.
4779 683 Low A session was disconnected from a Window Station.
4781 685 Low The name of an account was changed:
4782 N/A Low The password hash an account was accessed.
4783 667 Low A basic application group was created.
4784 N/A Low A basic application group was changed.
4785 689 Low A member was added to a basic application group.
4786 690 Low A member was removed 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.

Event ID Event ID
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.
4871 775 Low Certificate Services received 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.
4875 779 Low Certificate Services received 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.
4883 787 Low Certificate Services retrieved an archived key.
4884 788 Low Certificate Services imported a certificate into its database.
4886 790 Low Certificate Services received a certificate request.
4887 791 Low Certificate Services approved a certificate request and issued
a certificate.
4888 792 Low Certificate Services denied a certificate request.
4889 793 Low Certificate Services set the status of a certificate request to
pending.
4891 795 Low A configuration entry changed in Certificate Services.

Event ID Event ID
4893 797 Low Certificate Services archived a key.
4894 798 Low Certificate Services imported and archived a key.
4895 799 Low Certificate Services published the CA certificate to Active

Directory Domain Services.
4898 802 Low Certificate Services loaded a template.
4902 N/A Low The Per-user audit policy table was created.
4904 N/A Low An attempt was made to register a security event source.
4905 N/A Low An attempt was made to 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.
4931 N/A Low An Active Directory replica 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.
Event ID Event ID
4946 N/A Low A change has been made to Windows Firewall exception list.
A rule was added.
A rule was modified.
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.
were established.
were established.
were established.
4985 N/A Low The state of a transaction has changed.

Event ID Event ID
5024 N/A Low The Windows Firewall Service has started successfully.
5025 N/A Low The Windows Firewall Service has been stopped.
5031 N/A Low The Windows Firewall 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.
5040 N/A Low A change has been made to IPsec settings. An Authentication
Set was added.
Set was modified.
Set was deleted.
5043 N/A Low A change has been made to IPsec settings. A Connection
Security Rule was added.
Security Rule was modified.
Security Rule was deleted.
5046 N/A Low A change has been made to IPsec settings. A Crypto Set was
added.
modified.
deleted.
5050 N/A Low An attempt to programmatically disable the Windows

Firewall using a call to InetFwProfile.FirewallEnabled(False)
5051 N/A Low A file was virtualized.

Event ID Event ID
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 operation was attempted.
5065 N/A Low A cryptographic context modification was attempted.
5066 N/A Low A cryptographic function operation was attempted.
5067 N/A Low A cryptographic function modification was attempted.
5068 N/A Low A cryptographic function provider operation was attempted.
5069 N/A Low A cryptographic function property operation was attempted.
5070 N/A Low A cryptographic function 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.
5139 N/A Low A directory service object was moved.
5140 N/A Low A network share object was accessed.

Event ID Event ID
5141 N/A Low A directory service object 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.
5154 N/A Low The Windows Filtering Platform has permitted an application
or service to listen on a port for incoming connections.
5155 N/A Low The Windows Filtering Platform has blocked an application or
service from listening on a port for incoming connections.
5156 N/A Low The Windows Filtering Platform has allowed a connection.
5157 N/A Low The Windows Filtering Platform has blocked a connection.
5158 N/A Low The Windows Filtering Platform has permitted a bind to a
local port.
5159 N/A Low The Windows Filtering 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 present when the Windows Filtering
Platform Base Filtering Engine started.
5442 N/A Low The following provider was present when the Windows
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 present when the Windows
5446 N/A Low A Windows Filtering Platform callout has been changed.
5447 N/A Low A Windows Filtering Platform filter has been changed.
5448 N/A Low A Windows Filtering Platform provider has been changed.
Event ID Event ID
5449 N/A Low A Windows Filtering Platform provider context has been
changed.
5450 N/A Low A Windows Filtering Platform sublayer has been changed.
5451 N/A Low An IPsec Quick Mode security association was established.
5452 N/A Low An IPsec Quick Mode 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 storage IPsec
policy on the computer.
5458 N/A Low PAStore Engine applied locally cached copy of Active
Directory storage IPsec policy on the computer.
5459 N/A Low PAStore Engine failed to apply locally cached copy of Active
Directory storage IPsec policy on the computer.
5460 N/A Low PAStore Engine applied local registry storage IPsec policy on
the computer.
5461 N/A Low PAStore Engine failed to apply local registry storage IPsec
policy on the computer.
5462 N/A Low PAStore Engine failed to apply some rules of the active IPsec
policy on the computer. Use the IP Security Monitor snap-in
to diagnose the problem.
5463 N/A Low PAStore Engine polled for changes to the active IPsec policy
and detected no changes.
5464 N/A Low PAStore Engine polled for 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.
5466 N/A Low PAStore Engine polled for changes to the Active Directory
IPsec policy, determined that Active Directory cannot be
reached, and will use the cached copy of the Active Directory
IPsec policy instead. Any changes made to the Active
Directory IPsec policy since the last poll could not be applied.
Event ID Event ID
IPsec policy, determined that Active Directory can be
reached, and found no changes to the policy. The cached
copy of the Active Directory IPsec policy is no longer being
used.
IPsec policy, determined that Active Directory can be
reached, found changes to the policy, and applied those
changes. The cached copy of the Active Directory IPsec policy
is no longer being used.
5471 N/A Low PAStore Engine loaded local storage IPsec policy on the
computer.
5472 N/A Low PAStore Engine failed to load local storage IPsec policy on
the computer.
5473 N/A Low PAStore Engine loaded directory storage IPsec policy on the
computer.
5474 N/A Low PAStore Engine failed to load directory storage IPsec policy
on the computer.
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.
Event ID Event ID
6272 N/A Low Network Policy Server granted access to a user.
N/A 561 Low A handle to an object was requested.
N/A 563 Low Object open for delete
N/A 625 Low User Account Type Changed
N/A 613 Low IPsec policy agent started
N/A 614 Low IPsec policy agent disabled
N/A 615 Low IPsec policy agent
N/A 616 Low IPsec policy agent encountered a potential serious failure
24577 N/A Low Encryption of volume started
24578 N/A Low Encryption of volume stopped
24579 N/A Low Encryption of volume completed
24580 N/A Low Decryption of volume started
24581 N/A Low Decryption of volume stopped
24582 N/A Low Decryption of volume 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 Basic security audit policy settings. You can also download
Windows security audit events , which provide detailed event information for the
referenced operating systems in spreadsheet format.
Article • 06/08/2022
Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Document Links
The following table contains a list of links to external documents and their URLs so that readers of hard copies of this document can access
this information. The links are listed in the order they appear in the document.
Links URLs
10 Immutable https://technet.microsoft.com/library/cc722488.aspx
Laws of Security
Administration
Microsoft https://technet.microsoft.com/library/cc677002.aspx
Security
Compliance
Manager
Gartner http://www.gartner.com/technology/symposium/orlando/
Symposium
ITXPO
2012 Data Breach http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf

Investigations
Report (DBIR)
Ten Immutable https://technet.microsoft.com/security/hh278941.aspx

Laws of Security
(Version 2.0)
Using Heuristic https://technet.microsoft.com/library/bb418939.aspx

Scanning
Drive-by /windows/win32/secgloss/security-glossary
download
Microsoft https://support.microsoft.com/kb/2526083
Support article
2526083
Microsoft https://support.microsoft.com/kb/814777
Support article
814777
Open Web https://www.owasp.org/index.php/Main_Page

Application
Security Project
(OWASP)
Microsoft /windows/security/threat-protection/msft-security-dev-lifecycle
Security
Development
Lifecycle
Mitigating Pass- https://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating Pass-the-Hash (PtH) Attacks and Other

the-Hash (PtH) Techniques_English.pdf
Attacks and
Other Credential
Theft
Techniques
Determined https://www.microsoft.com/download/details.aspx?id=34793
Adversaries and
Targeted
Attacks
Links URLs
Solution for https://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789

management of
built-in
Administrator
account's
password via
GPO
Microsoft https://support.microsoft.com/?id=817433
Support article
817433
Microsoft /microsoft-365/admin/get-help-support
Support article
973840
Administrator https://technet.microsoft.com/library/cc753450.aspx
account is
disabled by
default
The https://technet.microsoft.com/library/cc162797.aspx
Administrator
Accounts
Security Planning
Guide
Microsoft https://www.microsoft.com/learning/en/us/book.aspx?ID=6815&locale=en-us
Windows
Security Resource
Kit
Authentication https://technet.microsoft.com/library/dd378897(WS.10).aspx
Mechanism
Assurance for AD
DS in Windows
Server 2008 R2
Step-by-Step
Guide
Windows Server https://technet.microsoft.com/windowsserver/bb332157

Update Services
Personal Virtual https://technet.microsoft.com/library/dd759174.aspx

Desktops
Read-Only https://technet.microsoft.com/library/cc771744(WS.10).aspx
Domain
Controller
Planning and
Deployment
Guide
Running Domain https://technet.microsoft.com/library/dd363553(v=ws.10).aspx

Controllers in
Hyper-V
Hyper-V Security https://www.microsoft.com/download/details.aspx?id=16650

Guide
Ask the Directory https://blogs.technet.com/b/askds/archive/2011/09/12/managing-rid-pool-depletion.aspx

Services Team
How to configure https://support.microsoft.com/kb/179442

a firewall for
domains and
trusts
2009 Verizon http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf

Data Breach
Report
2012 Verizon http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf

Data Breach
report
Links URLs
Introducing https://blogs.technet.com/b/askds/archive/2007/10/19/introducing-auditing-changes-in-windows-2008.aspx
Auditing
Changes in
Windows 2008
Cool Auditing https://blogs.technet.com/b/askds/archive/2007/11/16/cool-auditing-tricks-in-vista-and-2008.aspx

Tricks in Vista
and 2008
Global Object https://blogs.technet.com/b/askds/archive/2011/03/10/global-object-access-auditing-is-magic.aspx

Access Auditing
is Magic
One-Stop Shop https://blogs.technet.com/b/askds/archive/2008/03/27/one-stop-shop-for-auditing-in-windows-server-2008-and-windows-vista.aspx

for Auditing in
Windows Server
2008 and
Windows Vista
AD DS Auditing https://technet.microsoft.com/library/a9c25483-89e2-4202-881c-ea8e02b4b2a5.aspx
Step-by-Step
Guide
Getting the http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf

Effective Audit
Policy in
Windows 7 and
2008 R2
Sample script http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf
Audit Option http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf

Type
Auditing and https://technet.microsoft.com/magazine/2008.03.auditing.aspx

Compliance in
Windows Server
2008
How to use /troubleshoot/windows-server/group-policy/configure-group-policies-set-security

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
Server domain
Advanced https://technet.microsoft.com/library/dd408940(WS.10).aspx
Security Audit
Policy Step-by-
Step Guide
Threats and https://technet.microsoft.com/library/hh125921(v=ws.10).aspx

Countermeasures
Guide
MaxTokenSize https://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-token-bloat.aspx
and Kerberos
Token Bloat
Authentication https://technet.microsoft.com/library/dd391847(v=WS.10).aspx
Mechanism
Assurance
Links URLs
Microsoft Data https://technet.microsoft.com/library/hh204743.aspx

Classification
Toolkit
Dynamic Access https://blogs.technet.com/b/windowsserver/archive/2012/05/22/introduction-to-windows-server-2012-dynamic-access-control.aspx

Control
Absolute https://www.absolute.com/company/press-releases/2009/computrace-by-absolute-software-now-supported-in-firmware-of-getac-computers/
Software
Absolute https://www.absolute.com/resources/solution-sheets/itam/
Manage
Absolute Manage https://www.absolute.com/company/press-releases/2012/absolute-manage-the-first-mdm-solution-with-integrated-secure-document-distributio

MDM campaignid=983063266&adgroupid=136612784634&feeditemid=&loc_physical_ms=9003653&matchtype=&network=g&device=c&gclid=CjwKC
QxzCEYK-OV4yQhIOyQp-n51UZZjS87_vrK5qPcE-xoCDL8QAvD_BwE&creative=583299092096&keyword=&adposition=&utm_term=&gclid=CjwKC
QxzCEYK-OV4yQhIOyQp-n51UZZjS87_vrK5qPcE-xoCDL8QAvD_BwE
SolarWinds http://www.solarwinds.com/eminentware-products.aspx
EminentWare http://solarwinds-marketing.s3.amazonaws.com/solarwinds/Datasheets/EminentWare-WSUS-Extension-Pack-005-Datasheet2.pdf
WSUS Extension
Pack
EminentWare http://solarwinds-marketing.s3.amazonaws.com/solarwinds/Datasheets/EminentWare-Extension-Pack-for-CM-Datasheet-006-Revised.pdf
Configuration
Manager
Extension Pack
GFI Software http://www.gfi.com/?adv=952&loc=58&gclid=CLq9y5603rMCFal7QgodMFkAyA
GFI LanGuard http://www.gfi.com/network-security-vulnerability-scanner/?adv=952&loc=60&gclid=CP2t-7i03rMCFQuCQgodNkAA7g
Secunia http://secunia.com/
Secunia http://secunia.com/products/corporate/csi/
Corporate
Software
Inspector (CSI)
Vulnerability http://secunia.com/vulnerability_intelligence/
Intelligence
Manager
eEye Digital http://www.wideeyesecurity.com/?gclid=CK6b0sm13rMCFad_QgodhScAiw

Security
Retina CS http://www.wideeyesecurity.com/products.asp
Management
Lumension http://www.lumension.com/?rpLeadSourceId=5009&gclid=CKuai_e13rMCFal7QgodMFkAyA
Lumension http://www.lumension.com/Solutions/Vulnerability-Management.aspx
Vulnerability
Management
Threats and https://technet.microsoft.com/library/hh125917(v=ws.10).aspx

Countermeasures
Guide: User
Rights
Threats and https://technet.microsoft.com/library/cc755181(v=ws.10).aspx

Vulnerabilities
Mitigation
User Rights https://technet.microsoft.com/library/dd349804(v=WS.10).aspx
Access Credential https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_2

Manager as a
trusted caller
Access this https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_1

computer from
the network
Links URLs
Act as part of the https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_3

operating system
Add workstations https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_4

to domain
Adjust memory https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_5

quotas for a
process
Allow log on https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_6

locally
Allow log on https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_7

through Terminal
Services
Back up files and https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_8

directories
Bypass traverse https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_9

checking
Change the https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_10

system time
Change the time https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_11

zone
Create a pagefile https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_12
Create a token https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_13

object
Create global https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_14

objects
Create https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_15
permanent
shared objects
Create symbolic https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_16

links
Debug programs https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_17
Deny access to https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_18

this computer
from the network
Deny log on as a https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_18a

batch job
Deny log on as a https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_19

service
Deny log on https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_20

locally
Deny log on https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_21

through Terminal
Services
Enable computer https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_22

and user
accounts to be
trusted for
delegation
Force shutdown https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_23

from a remote
system
Generate security https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_24

audits
Links URLs
Impersonate a https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_25
client after
authentication
Increase a https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_26
process working
set
Increase https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_27
scheduling
priority
Load and unload https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_28

device drivers
Lock pages in https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_29

memory
Log on as a https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_30
batch job
Log on as a https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_31
service
Manage auditing https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_32

and security log
Modify an object https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_33

label
Modify firmware https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_34

environment
values
Perform volume https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_35

maintenance
tasks
Profile single https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_36

process
Profile system https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_37

performance
Remove https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_38
computer from
docking station
Replace a https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_39
process level
token
Restore files and https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_40

directories
Shut down the https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_41

system
Synchronize https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_42
directory service
data
Take ownership https://technet.microsoft.com/library/db585464-a2be-41b1-b781-e9845182f4b6(v=ws.10)#BKMK_43

of files or other
objects
Access Control https://msdn.microsoft.com/library/aa374860(v=VS.85).aspx
Microsoft /microsoft-365/admin/get-help-support
Support
rootDSE Modify https://msdn.microsoft.com/library/cc223297.aspx

Operations
Links URLs
AD DS Backup https://technet.microsoft.com/library/cc771290(v=ws.10).aspx
and Recovery
Step-by-Step
Guide
Windows /archive/blogs/openspecification/windows-configurations-for-kerberos-supported-encryption-type
Configurations
for Kerberos
Supported
Encryption Type
UAC Processes https://technet.microsoft.com/library/dd835561(v=WS.10).aspx#1

and Interactions
EmpowerID http://www.empowerid.com/products/authorizationservices
Role-based http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.security%2Fdoc%2Fsecurity%2Fdomain_rbac.htm
access control
(RBAC)
The RBAC http://docs.oracle.com/cd/E19082-01/819-3321/6n5i4b7ap/index.html

model
Active Directory- http://www.centrify.com/solutions/it-security-access-control.asp

centric access
control
Cyber-Ark's http://www.cyber-ark.com/digital-vault-products/pim-suite/index.asp
Privileged
Identity
Management
(PIM) Suite
Quest One https://www.quest.com/products/gpoadmin/
Enterprise http://www.liebsoft.com/Random_Password_Manager/
Random
Password
Manager
(ERPM)
NetIQ Privileged https://www.netiq.com/products/privileged-user-manager/

User Manager
CA https://www.scmagazine.com/feature/sc-awards-2007-time-to-be-counted
IdentityMinder
Description of /windows/win32/wmisdk/event-security-constants
security events in
Windows Vista
and in Windows
Server 2008
Description of /windows/win32/win7appqual/security
security events in
Windows 7 and
in Windows
Server 2008 R2
Security Audit https://www.microsoft.com/download/details.aspx?id=21561

Events for
Windows 7
Windows Server https://www.microsoft.com/download/details.aspx?id=35753

2008 R2 and
Windows 8 and
Windows Server
2012 Security
Event Details
Georgia Tech's http://www.gtsecuritysummit.com/report.html

Emerging Cyber
Threats for 2013
report
Links URLs
Microsoft /azure/defender-for-cloud/threat-intelligence-reports
Security
Intelligence
Report
Australian http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm
Government
Defense Signals
Directory Top 35
Mitigation
Strategies
Cloud /azure/defender-for-cloud/enhanced-security-features-overview
Computing
Security Benefits
Applying the /windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models

Principle of Least
Privilege to User
Accounts on
Windows
The /sharepoint/security-for-sharepoint-server/plan-for-administrative-and-service-accounts
Administrator
Accounts
Security Planning
Guide
Best Practice /previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn487446(v=ws.11)

Guide for
Securing Active
Directory
Installations for
Windows Server
2003
Best Practices for /azure/active-directory/external-identities/b2b-fundamentals

Delegating Active
Directory
Administration
for Windows
Server 2003
Microsoft https://support.microsoft.com/common/international.aspx?RDPATH=%2flifecycle%2fdefault.aspx
Support
Lifecycle
Active Directory https://msdn.microsoft.com/library/cc223122(v=prot.20).aspx

Technical
Specification
Error message https://support.microsoft.com/kb/932455

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"
Authentication https://technet.microsoft.com/library/dd378897(WS.10).aspx
Mechanism
Assurance for AD
DS in Windows
Server 2008 R2
Step-by-Step
Guide
Links URLs
Strict KDC https://www.microsoft.com/download/details.aspx?id=6382

Validation
Recommended Reading
The following table contains a list of recommended reading that will assist you in enhancing the security of your Active Directory systems.
Recommended Reading
Georgia Tech's Emerging Cyber Threats for 2014 Report
Microsoft Security Intelligence Report
Mitigating Pass-the-Hash (PTH) Attacks and Other Credential Theft Techniques
Australian Government Defense Signals Directory Top 35 Mitigation Strategies
2012 Data Breach Investigations Report - (Verizon, US Secret Service)
2009 Data Breach Investigations Report
Cloud Computing Security Benefits
Applying the Principle of Least Privilege to User Accounts on Windows
The Administrator Accounts Security Planning Guide
Best Practice Guide for Securing Active Directory Installations for Windows Server 2003
Best Practices for Delegating Active Directory Administration for Windows Server 2003
Microsoft Support Lifecycle
Active Directory Technical Specification - dSHeuristics information
Error message when nonadministrator users who have been delegated control try to join computers to a Windows Server 2003-based or a Windows Server
2008-based domain controller: "Access is denied"
Best Practice Guide for Securing Active Directory Installations.doc
Hyper-V Security Guide
Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide.
Strict KDC Validation
Copyright Information
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of
publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part
of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This white paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this document.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this
document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this
document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give
you any license to these patents, trademarks, copyrights, or other intellectual property.
Microsoft, Active Directory, BitLocker, Hyper-V, Internet Explorer, Windows Vista, Windows, and Windows Server are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their
respective owners.
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are
fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is
intended or should be inferred.
2013 Microsoft Corporation. All rights reserved.

Active Directory Replication and
Topology Management Using Windows
PowerShell
Article • 07/29/2021
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)
Article • 07/29/2021
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 Instructions for installation steps.
Scenarios for testing Windows PowerShell for

Active Directory replication and topology
management cmdlets
The following scenarios are designed for administrators to familiarize themselves with
the new management cmdlets:
Get a list of all domain controllers and their corresponding sites
Manage replication topology
View replication status and information
Lab Requirements
Two Windows Server 2012 domain controllers: DC1 and DC2 that are part of the
contoso.com domain and reside in the CORPORATE site within that domain.
View domain controllers and their sites

In this step, you will use the Active Directory Module for Windows PowerShell to view
the existing domain controllers and the replication topology for the domain.
To complete the steps in the following procedures, you must be a member of the
Domain Admins group or have equivalent permissions.
To view all Active Directory sites
1. On DC1, click Windows PowerShell on the taskbar.
2. Type the following command:
Get-ADReplicationSite -Filter *
This returns detailed information about each site. The Filter parameter is used
throughout Active Directory PowerShell cmdlets to limit the list of objects
returned. In this case, the asterisk (*) indicates all site objects.
 Tip
You can use the Tab key to auto-complete commands in Windows PowerShell.
Example: Type Get-ADRep and press Tab multiple times to skip through the
matching commands until you reach Get-ADReplicationSite . Auto-complete
also works for parameter names such as Filter .
To format the output from the Get-ADReplicationSite command as a table and

limit the display to specific fields, you can pipe the output to the Format-Table
command (or " ft " for short):
Get-ADReplicationSite -Filter * | ft Name
This returns a shorter version of the site list, including only the Name field.
To produce a table of all domain controllers

Type the following command at the Active Directory module for Windows
PowerShell prompt:
Get-ADDomainController -Filter * | ft Hostname,Site
This command returns the domain controllers host name as well as their site
associations.
Manage replication topology

In the previous step, after running the command, Get-ADDomainController -Filter * |
ft Hostname,Site , DC2 was listed as part of the CORPORATE site. In the procedures
below, you will create a new branch office site, BRANCH1, create a new site link, set the
site link cost and replication frequency and then move DC2 to BRANCH1.
To create a new site
PowerShell prompt:
New-ADReplicationSite BRANCH1
This command creates the new branch office site, branch1.
To create a new site link
PowerShell prompt:
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

PowerShell prompt:
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

PowerShell prompt:
Get-ADDomainController DC2 | Move-ADDirectoryServer -Site BRANCH1
This command moves the domain controller, DC2 to the BRANCH1 site.
Verification
To verify site creation, new site link, and cost and replication
frequency
Click Server Manager, click Tools and then click Active Directory Sites and
Services and verify the following:
Verify that the BRANCH1 site contains all of the correct values from the Windows
PowerShell commands.
Verify the CORPORATE-BRANCH1 site link is created and connects the BRANCH1
and CORPORATE sites.
Verify DC2 is now in the BRANCH1 site. Alternatively, you can open the Active
Directory Module for Windows PowerShell and type the following command to
verify DC2 is now in the BRANCH1 site: Get-ADDomainController -Filter * | ft
Hostname,Site .
View replication status information

In the following procedures, you will use one of the Windows PowerShell for Active
Directory replication and management cmdlets, Get-
ADReplicationUpToDatenessVectorTable DC1 , to produce a simple replication report using
the up-to-dateness vector table maintained by each domain controller. This up-to-
dateness vector table keeps track of the highest originating write USN seen from each
domain controller in the forest.
To view the up-to-dateness vector table for a single domain

controller
1. Type the following command at the Active Directory module for Windows
PowerShell prompt:
Get-ADReplicationUpToDatenessVectorTable DC1
This shows a list of the highest USNs seen by DC1 for every domain controller in
the forest. The Server value refers to the server maintaining the table, in this case
DC1. The Partner value refers to the replication partner (direct or indirect) on which
changes were made. The UsnFilter value is the highest USN seen by DC1 from
Partner. If a new domain controller is added to the forest, it will not appear in DC1's
table until DC1 receives a change that originated from the new domain.
To view the up-to-dateness vector table for all domain controllers

in a domain
1. Type the following command at the Active Directory module for Windows
PowerShell prompt:
Get-ADReplicationUpToDatenessVectorTable * | sort Partner,Server | ft
Partner,Server,UsnFilter
This command replaces DC1 with * , thus collecting the up-to-dateness vector
table data from all domain controllers. The data is sorted by Partner and Server
and then displayed in a table.
The sorting allows you to easily compare the last USN seen by each domain
controller for a given replication partner. This is a quick way to check that
replication is occurring across your environment. If replication is working correctly,
the UsnFilter values reported for a given replication partner should be fairly similar
across all domain controllers.
See Also
Advanced Active Directory Replication and Topology Management Using Windows
Advanced Active Directory Replication
and Topology Management Using
Windows PowerShell (Level 200)
Article • 12/15/2021
This topic explains the 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
The following table lists replication and topology cmdlets added to the Active Directory
Windows PowerShell module:
Cmdlet Explanation
Get-ADReplicationAttributeMetadata Returns attribute replication metadata for an object
Get-ADReplicationConnection Returns domain controller connection object details

Cmdlet Explanation
Get-ADReplicationFailure Returns the most replication recent failure for a domain

controller
Get-ADReplicationPartnerMetadata Returns replication configuration of a domain

controller
Get-ADReplicationQueueOperation Returns the current replication queue backlog
Get-ADReplicationSite Returns site information
Get-ADReplicationSiteLink Returns site link information
Get-ADReplicationSiteLinkBridge Returns site link bridge information
Get-ADReplicationSubnet Returns AD subnet information
Get- Returns the UTD vector for a domain controller

Get-ADTrust Returns information about an inter-domain or inter-

forest trust
New-ADReplicationSite Creates a new site
New-ADReplicationSiteLink Creates a new site link
New-ADReplicationSiteLinkBridge Creates a new site link bridge
New-ADReplicationSubnet Creates a new AD subnet
Remove-ADReplicationSite Deletes a site
Remove-ADReplicationSiteLink Deletes a site link
Remove-ADReplicationSiteLinkBridge Deletes a site link bridge
Remove-ADReplicationSubnet Deletes an AD subnet
Set-ADReplicationConnection Modifies a connection
Set-ADReplicationSite Modifies a site
Set-ADReplicationSiteLink Modifies a site link
Set-ADReplicationSiteLinkBridge Modifies a site link bridge
Set-ADReplicationSubnet Modifies an AD subnet
Sync-ADObject Forces replication of a single object

Most of these cmdlets have their basis in Repadmin.exe. Other cmdlets (not listed)
handle features like Dynamic Access Control and Group Managed Service Accounts.
For a complete list of all Active Directory Windows PowerShell cmdlets, run:
Get-Command -module ActiveDirectory
For a complete list of all Active Directory Windows PowerShell cmdlet arguments,
reference the help. For example:
Get-Help New-ADReplicationSite
Use the Update-Help cmdlet to download and install help files
Replication and Metadata

Repadmin.exe validates the health and consistency of Active Directory replication.
Repadmin.exe offers simple data manipulation options - some arguments support CSV
outputs, for example - but automation generally required parsing through text file
outputs. The Active Directory module for Windows PowerShell is the first attempt at
offering an option that allows real control over the returned data; prior to this, you had
to create scripts or use third-party tools.
Additionally, the following cmdlets implement a new parameter set of Target, Scope,
and EnumerationServer:
Get-ADReplicationFailure
Get-ADReplicationPartnerMetadata
Get-ADReplicationUpToDatenessVectorTable
The Target argument accepts a comma-separated list of strings that identify the target
servers, sites, domains, or forests specified by the Scope argument. An asterisk (*) is also
permissible and means all servers within the specified scope. If no scope is specified, it
implies all servers in the current user's forest. The Scope argument specifies the latitude
of the search. Acceptable values are Server, Site, Domain, and Forest. The
EnumerationServer specifies the server that enumerates the list of domain controllers
specified in Target and Scope. It operates the same as the Server argument and requires
the specified server run the Active Directory Web Service.
To introduce the 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
it 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-

Both of these cmdlets return further aspects of domain controller and whether it's up to
date, 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
Article • 05/17/2023
This article 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 can't 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 isn't 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 can't 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 isn't 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. Select the Connection menu and select Connect for the Windows Server 2012 RID
Master on port 389, and then select Bind as a domain administrator.
4. Select the Browse menu and select Modify.
5. Ensure that DN is blank.
6. In Edit Entry Attribute, type:
SidCompatibilityVersion
7. In Values, type:
8. Ensure that Add is selected in Operation and select Enter. This updates the Entry
List.
9. Select the Synchronous and Extended options, then select 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
won't 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=<domain>
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. Select the Connection menu and select Connect for the Windows Server 2012 RID
Master on port 389, and then select Bind as a domain administrator.
4. Select the View menu and select Tree, then for the Base DN select the RID Master's
own domain naming context. Select Ok.
5. In the navigation pane, drill down into the CN=System container and select the
CN=RID Manager$ object. Right select it and select Modify.
6. In Edit Entry Attribute, type:
MsDS-RidPoolAllocationEnabled
7. In Values, type (in upper case):
TRUE
8. Select Replace in Operation and select Enter. This updates the Entry List.
9. Enable the Synchronous and Extended options, then select 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 doesn't 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're
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
clearer:
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

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 nonspecific? For
example, "Windows can't 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 article (16655, 16656, 16657).
c. Validate Active Directory replication health with Repadmin.exe and RID Master
availability with Dcdiag.exe /test:ridmanager /v. Enable double-sided network
captures between the domain controller and the RID Master if these tests are
inconclusive.

The following new messages log in the System event log on Windows Server 2012
domain controllers. Automated AD health tracking systems, such as System Center
Operations Manager, should monitor for these events; all are notable, and some are
indicators of critical domain issues.
Event ID 16653
Source Directory-Services-SAM
Severity Warning
Message A pool size for account-identifiers (RIDs) that was configured by an Administrator is
greater than the supported maximum. The maximum value of %1 will be used when
the domain controller is the RID master.
For more information, see RID Block Size Limit.
Notes The maximum value for the RID Block Size is now 15000 decimal (3A98 hexadecimal).
and A domain controller can't request more than 15,000 RIDs. This event logs at every
resolution boot until the value is set to a value at or below this maximum.
Event ID 16654
Message A pool of account-identifiers (RIDs) has been invalidated. This may occur in the
following expected cases:
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 If this event is unexpected, contact all domain administrators and determine which of
and them performed the action. The Directory Services event log also contains further
resolution information on when one of these steps was performed.
Event ID 16655
Message The global maximum for account-identifiers (RIDs) has been increased to %1.
Notes If this event is unexpected, contact all domain administrators and determine which of
and them performed the action. This event notes the increase of the overall RID pool size
resolution beyond the default of 230and won't happen automatically; only by administrative
action.
Event ID 16656
Severity Warning
Message The global maximum for account-identifiers (RIDs) has been increased to %1.
Notes Action required! An account-identifier (RID) pool was allocated to this domain
and controller. The pool value indicates this domain has consumed a considerable portion
resolution 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.
Event ID 16657
Severity Error
Event ID 16657
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's extremely important that certain diagnostics are performed prior to re-enabling
account creation to ensure this domain isn't 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.
Notes Contact all domain administrators and inform them that no further security principals
and can be created in this domain until this protection is overridden. For more
resolution information about how to override the protection and possibly increase the overall
RID pool, see Global RID Space Size Unlock.
Event ID 16658
Severity Warning
Message This event is a periodic update on the remaining total quantity of available account-
identifiers (RIDs). The number of remaining account-identifiers is approximately: %1.
Account-identifiers are used as accounts are created, when they're exhausted no new
accounts may be created in the domain.
Notes Contact all domain administrators and inform them that RID consumption has
and crossed a major milestone; determine if this is expected behavior or not by reviewing
resolution 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
Component Updates
Article • 04/28/2023
This module introduces the components that received minor updates in the Directory
Services and Identity spaces.
About the Author
Author:
Bio:
Contributors
Reviewers
７ Note
This content is written by a Microsoft customer support engineer, and is intended

for experienced administrators and systems architects who are looking for deeper
technical explanations of features and solutions in Windows Server 2012 R2 than
topics on TechNet usually provide. However, it has not undergone the same editing
passes, so some of the language may seem less polished than what is typically
found on TechNet.
What You Will Learn

After completing this module, you will be able to:
Explain the component updates made within the Directory Services and Identity
technology areas in Windows Server 2012 R2
SPN and UPN uniqueness
Winlogon Automatic Restart Sign-On (ARSO)
TPM Key Attestation

CA Backup and Restore Windows PowerShell cmdlets
Command line process auditing
Credentials Protection and Management
Directory Services component updates
Domain and Forest Functional Levels
Deprecation of NTFRS
LDAP Query Optimizer changes
1644 Event improvements
Active Directory Replication throughput improvement

Identity component updates
Article • 07/29/2021
Lesson 1: Identity component updates

This lesson explains the Identity component updates in Windows Server 2012 R2.
What You Will Learn

After completing this lesson, you will be able to:
Describe the following changes:
Winlogon Automatic Restart Sign-On (ARSO)
TPM Key Attestation
CA Backup and Restore Windows PowerShell cmdlets
Credentials Protection and Management
Author: Justin Turner, Senior Support Escalation Engineer with the Windows group
７ Note

found on TechNet.
Article • 05/18/2023
７ Note

found on TechNet.
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's no in-box method to
block the addition of a duplicate SPN or UPN. *
Duplicate UPN values break synchronization between on-premises AD and Office 365.
*Setspn.exe is commonly used to create new SPNs, and functionally was built into the
version released with Windows Server 2008 that adds a check for duplicates.
Table SEQ Table \* ARABIC 1: UPN and SPN uniqueness
Feature Comment
Feature Comment
UPN Duplicate UPNs break synchronization of on-premises AD accounts with Microsoft

uniqueness Azure AD-based services such as Office 365.
SPN Kerberos requires SPNs for mutual authentication. Duplicate SPNs result in
uniqueness authentication failures.
For more information about uniqueness requirements for UPNs and SPNs, see
Uniqueness Constraints.
Symptoms
Error codes 8467 or 8468 or their hex, symbolic or string equivalents are logged in
various on-screen dialogues and in event ID 2974 in the Directory Services event log.
The attempt to create a duplicate UPN or SPN is blocked only under the following
circumstances:
The write is processed by a Windows Server 2012 R2 DC
Table SEQ Table \* ARABIC 2: UPN and SPN uniqueness error codes
Decimal Hex Symbolic String
8647 21C7 ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST The operation failed

because SPN value
provided for
addition/modification
isn't unique forest-wide.
8648 21C8 ERROR_DS_UPN_VALUE_NOT_UNIQUE_IN_FOREST The operation failed

because UPN value
provided for
addition/modification
isn't unique forest-wide.
New user creation fails if UPN isn't 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 returns 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
isn't 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:
PowerShell running from Server 2012 targeting a Windows Server 2012 R2 DC:
DSAC.exe running on Windows Server 2012 targeting a Windows Server 2012 R2 DC:
Figure SEQ Figure \* ARABIC 5 DSAC user creation error on non-Windows Server 2012
R2 while targeting Windows Server 2012 R2 DC
Figure SEQ Figure \* ARABIC 6 DSAC user modification error on non-Windows Server
2012 R2 while targeting Windows Server 2012 R2 DC
Restore of an object that would result in a duplicate UPN

fails:
No event is logged when an object fails to restore because of a duplicate UPN / SPN.
The UPN of the object must be unique in order for it to be restored.
1. Identify the UPN that exists on the object in the Recycle Bin
2. Identify all objects that have the same value
3. Remove the duplicate UPN(s)
Identify the conflicting UPN on the deleted objectUsing

repadmin.exe
Repadmin /showattr DCName "DN of deleted objects container" /subtree
/filter:"(msDS-LastKnownRDN=<NAME>)" /deleted /atts:userprincipalname
repadmin /showattr DCName "CN=Deleted Objects,DC=blue,DC=contoso,DC=com"

/subtree /filter:"(msDS-LastKnownRDN=Dianne Hunt2)" /deleted
/atts:userprincipalname
C:\>repadmin /showattr winbluedc1 "cn=deleted

objects,dc=blue,dc=contoso,dc=com" /subtree /filter:"(msds-
lastknownrdn=Dianne Hunt2)" /deleted /atts:userprincipalname
DN: CN=Dianne Hunt2\0ADEL:dd3ab8a4-3005-4f2f-814f-d6fc54a1a1c0,CN=Deleted

Object
s,DC=blue,DC=contoso,DC=com
1> userPrincipalName: dhunt@blue.contoso.com
To identify all objects with the same UPN:Using

Repadmin.exe
repadmin /showattr WinBlueDC1 "DC=blue,DC=contoso,DC=com" /subtree /filter:"

(userPrincipalName=dhunt@blue.contoso.com)" /deleted /atts:DN
C:\>repadmin /showattr winbluedc1 "dc=blue,dc=contoso,dc=com" /subtree

/filter:"(userPrincipalName=dhunt@blue.contoso.com)" /deleted /atts:DN
DN: CN=Administrator,CN=Users,DC=blue,DC=contoso,DC=com
DN: CN=xouser1,CN=Users,DC=blue,DC=contoso,DC=com
DN: CN=Dianne Hunt,OU=Marketing,DC=blue,DC=contoso,DC=com
DN: CN=Dianne Hunt2\0ADEL:dd3ab8a4-3005-4f2f-814f-d6fc54a1a1c0,CN=Deleted

Objects,DC=blue,DC=contoso,DC=com
 Tip
The previously undocumented /deleted parameter in repadmin.exe is used to

include deleted objects in the result set
Using Global Search

Open Active Directory Administrative Center and navigate to Global Search
Select the Convert to LDAP radio button
Type (userPrincipalName=ConflictingUPN)
Replace ConflictingUPN with the actual UPN that is in conflict
Select Apply
Using Windows PowerShell
Get-ADObject -LdapFilter "(userPrincipalName=dhunt@blue.contoso.com)" -

IncludeDeletedObjects -SearchBase "DC=blue,DC=Contoso,DC=com" -SearchScope
Subtree -Server winbluedc1.blue.contoso.com
If the object needs to be restored, you'll need remove the duplicate UPNs from the
other objects. For only one object, it's simple enough to use ADSIEdit to remove the
duplicate. If there are multiple objects with duplicates, then Windows PowerShell might
be the better tool to use.
To null out the UserPrincipalName attribute using Windows PowerShell:
７ Note
The userPrincipalName attribute is single-valued attribute, so this procedure will

only remove the duplicate UPN.
Duplicate SPN
Figure SEQ Figure \* ARABIC 8 Error message displayed in ADSIEdit when addition of
duplicate SPN is blocked
Logged in the Directory Services event log is an ActiveDirectory_DomainService event

ID 2974.
Operation failed. Error code: 0x21c7
The operation failed
The attribute value provided is not unique in the forest or partition.

Attribute:
servicePrincipalName Value=<SPN>
<Object DN> Winerror: 8467
Figure SEQ Figure \* ARABIC 9 Error logged when creation of duplicate SPN is
blocked
Workflow
If DC == GC
No offbox call required, query can be satisfied locally
UPN case
Query local forest-wide UPN index for supplied UPN (userPrincipalName; a

global index)
If entries returned == 0 -> write proceeds
If entries returned !=0 -> write fails
Event logged
Also returns extended error:
8648:
ERROR_DS_UPN_VALUE_NOT_UNIQUE_IN_FOREST
SPN case
Query local forest-wide SPN index for supplied SPN (servicePrincipalName; a

global index)
Event logged
8647:
ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST
If DC != GC
Offbox call desirable but not critical, that is, this is a best-effort uniqueness
check
Check proceeds against local DIT only if GC can't 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 reanimated, SPN or UPN values present are checked for
uniqueness. If a duplicate is found, the request fails.
For certain attribute changes like DNS Host Name, SAM Account Name etc., when
the modification is made, SPNs are updated accordingly. In the process, the
obsolete SPNs are deleted and new SPNs are constructed and added to the
database. The requisite attribute modifications against which this path is triggered
are:
ATT_DNS_HOST_NAME
ATT_MS_DS_ADDITIONAL_DNS_HOST_NAME
ATT_SAM_ACCOUNT_NAME
ATT_MS_DS_ADDITIONAL_SAM_ACCOUNT_NAME
ATT_SERVER_REFERENCE_BL
ATT_USER_ACCOUNT_CONTROL
If any of the new SPN value is a duplicate, we fail the modification. Of the above list, the
important attributes are ATT_DNS_HOST_NAME (Machine name) and
ATT_SAM_ACCOUNT_NAME (SAM Account Name).
Try This: Exploring SPN and UPN uniqueness

This is the first of several "Try This" activities in the module. There isn't a separate lab
guide for this module. The Try This activities are free-form activities that allow you
explore the lesson material in the lab environment. You have the option of following the
prompt or going off script and come up with your own activity.
７ Note
This is the first of several "Try This" activities.

There is not a separate lab guide for this module.
The Try This activities are essentially free-form activities that allow you
explore the lesson material in the lab environment.
You have the option of following the prompt or going off script and come up
with your own activity.
While not all sections have a Try This prompt, you are still encouraged to
explore the lesson content in the lab where appropriate.
Experiment with SPN and UPN uniqueness. Follow these prompts, or complete your
own.
1. Create new users with UPN
2. Create accounts with SPNs
3. Either create a new user with a UPN already previously defined or change an
existing account's UPN. Do the same for an SPN on another account
a. Populate an existing user account with a UPN already in use

i. Using PowerShell, ADSIEDIT, or Active Directory Administrative Center
(DSAC.exe)
b. Populate an existing account with an SPN already in use

i. Using Windows PowerShell, ADSIEDIT, or SetSPN
4. Observe the errors
Optionally
1. Verify with the classroom instructor that it's 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 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)
Article • 05/01/2023
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 sign in 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 initiates the RPC call.
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 is initiated via
Winlogon whereas the credential management is done by the Local Security Authority
(LSA). Upon a successful ARSO configuration and sign in, 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.
Windows shutdown -g -t User-initiated APIs with SHUTDOWN_ARSO /

Update 0 reboots EWX_ARSO flags
Managed devices Managed devices Managed devices Managed devices - Yes

- Yes - Yes - No Unmanaged devices - Yes
Unmanaged Unmanaged Unmanaged
devices - Yes devices - Yes devices - 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 opted out for Client SKUs.
Group policy location: Computer Configuration > Administrative Templates > Windows
Components > Windows sign in Options
Intune policy:
Platform: Windows 10 and later

Profile type: Administrative Templates
Path: \Windows Components\Windows Logon Options
Supported 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.
It 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, it applies to both Windows Update
restarts and user-initiated restarts and shutdowns.
If you don't configure this policy setting, it's enabled by default. When the policy is
enabled, the user is automatically signed in. Additionally, after the device boots, the
session is locked with all lock screen apps configured for that user.
After enabling this policy, you can configure its settings through the
ConfigAutomaticRestartSignOn policy. It sets the mode to automatic sign in and locks
the last interactive user after a restart or cold boot.
If you disable this policy setting, the device doesn't configure automatic sign in. The
user's lock screen apps aren't restarted after the system restarts.
Registry editor:
Value Name Type Data
DisableAutomaticRestartSignOn DWORD 0 (Enable ARSO)
1 (Disable ARSO)
Policy registry 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
Supported 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
won't occur and this policy doesn't 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 isn't 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 isn't enabled,
personal data is accessible on the hard drive. Automatic restart and sign on should
only be run under this condition if you're 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.
Registry editor
Value Name Type Data
AutomaticRestartSignOnConfig DWORD 0 (Enable ARSO if secure)
1 (Enable ARSO always)
Policy registry location:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Type: DWORD
Troubleshooting
When Winlogon automatically locks, Winlogon's state trace is stored in the Winlogon
event log.
The status of an Autologon configuration attempt is logged
If it's successful
records it as such
If it's a failure:
records what the failure was
When BitLocker's state changes:
the removal of credentials will be logged
These are stored in the LSA Operational log.
Reasons why autologon might fail

There are several cases in which a user automatic login can't 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 wouldn't be permitted to
log in. The policy also 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 doesn't 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 doesn't 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
Password hash Credential key Ticket-granting ticket Primary refresh token

Password hash Credential key Ticket-granting ticket Primary refresh token
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 Azure AD joined Azure AD joined account Azure AD joined account
account - Yes account - Yes - Yes (if hybrid) - Yes
Domain joined Domain joined Domain joined account - Domain joined account -
account - Yes account - 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's 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
Article • 05/17/2023
７ Note

found on TechNet.
Overview
While support for TPM-protected keys has existed since Windows 8, there were no
mechanisms for CAs to cryptographically attest that the certificate requester private key
is actually protected by a Trusted Platform Module (TPM). This update enables a CA to
perform that attestation and to reflect that attestation in the issued certificate.
７ Note
This article assumes that the reader is familiar with certificate template concept (for
reference, see Certificate Templates). It also assumes that the reader is familiar with
how to configure enterprise CAs to issue certificates based on certificate templates
(for reference, see Checklist: Configure CAs to Issue and Manage Certificates).
Terminology
Term Definition
EK Endorsement Key. This is an asymmetric key contained inside the TPM (injected at
manufacturing time). The EK is unique for every TPM and can identify it. The EK can't be
changed or removed.
Term Definition
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 wasn't 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 article.
Why is TPM key attestation important?

A user certificate with a TPM-attested key provides higher security assurance, backed up
by nonexportability, 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's 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's assumed that a Windows Server 2012 R2 enterprise CA is set up.
Also, clients (Windows 8.1) are configured to enroll against that enterprise CA using
certificate templates.
There are three steps to deploying TPM key attestation:
1. Plan the TPM trust model: The first step is to decide which TPM trust model to
use. There are 3 supported ways for doing this:
Trust based on user credential: The enterprise CA trusts the user-provided

EKPub as part of the certificate request and no validation is performed other
than the user's domain credentials.
Trust based on EKCert: The enterprise CA validates the EKCert chain that is
provided as part of the certificate request against an administrator-managed
list of acceptable EK cert chains. The acceptable chains are defined per-
manufacturer and are expressed via two custom certificate stores on the
issuing CA (one store for the intermediate and one for root CA certificates).
This trust mode means that all TPMs from a given manufacturer are trusted.
Note that in this mode, TPMs in use in the environment must contain EKCerts.
Trust based on EKPub: The enterprise CA validates that the EKPub provided
as part of the certificate request appears in an administrator-managed list of
allowed EKPubs. This list is expressed as a directory of files where the name of
each file in this directory is the SHA-2 hash of the allowed EKPub. This option
offers the highest assurance level but requires more administrative effort,
because each device is individually identified. In this trust model, only the
devices that have had their TPM's EKPub added to the allowed list of EKPubs
are permitted to enroll for a TPM-attested certificate.
Depending on which method is used, the CA will apply a different issuance policy
OID to the issued certificate. For more details about issuance policy OIDs, see the
Issuance Policy OIDs table in the Configure a certificate template section in this
article.
Note that it's possible to choose a combination of TPM trust models. In this case,
the CA will accept any of the attestation methods, and the issuance policy OIDs will
reflect all attestation methods that succeed.
2. Configure the certificate template: Configuring the certificate template is

described in the Deployment details section in this article. This article doesn't cover
how this certificate template is assigned to the enterprise CA or how enroll access
is given to a group of users. For more information, see Checklist: Configure CAs to
Issue and Manage Certificates.
3. Configure the CA for the TPM trust model
a. Trust based on user credential: No specific configuration is required.
b. Trust based on EKCert: The administrator must obtain the EKCert chain
certificates from TPM manufacturers, and import them to two new certificate
stores, created by the administrator, on the CA that perform TPM key
attestation. For more information, see the CA configuration section in this
article.
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
article.
７ Note
This feature requires Windows 8.1/Windows Server 2012 R2.
TPM key attestation for third-party smart card KSPs is not supported.
Microsoft Platform Crypto Provider KSP must be used.
TPM key attestation only works for RSA keys.
TPM key attestation is not supported for a standalone CA.
TPM key attestation does not support non-persistent certificate
processing.
Deployment details
Configure a certificate template

To configure the certificate template for TPM key attestation, do the following
configuration steps:
1. Compatibility tab
In the Compatibility Settings section:
Ensure Windows Server 2012 R2 is selected for the Certification Authority.
Ensure Windows 8.1 / Windows Server 2012 R2 is selected for the Certificate
recipient.
2. Cryptography tab
Ensure Key Storage Provider is selected for the Provider Category and RSA is
selected for the Algorithm name. Ensure Requests must use one of the following
providers is selected and the Microsoft Platform Crypto Provider option is
selected under Providers.
3. Key Attestation tab
This is a new tab for Windows Server 2012 R2:

Choose an attestation mode from the three possible options.
None: Implies that key attestation must not be used
Required, if client is capable: Allows users on a device that doesn't 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 doesn't support key attestation, or the device not having a TPM at
all.
Required: Client must perform TPM key attestation, otherwise the certificate
request will fail.
Then choose the TPM trust model. There are again three options:
User credentials: Allow an authenticating user to vouch for a valid TPM by

specifying their domain credentials.
Endorsement certificate: The EKCert of the device must validate through

administrator-managed TPM intermediate CA certificates to an administrator-
managed root CA certificate. If you choose this option, you must set up EKCA
and EKRoot certificate stores on the issuing CA as described in the CA
configuration section in this article.
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 article.
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's possible to choose a combination of enforcement
methods. In this case, the CA will accept any of the attestation methods, and the
issuance policy OID will reflect all attestation methods that succeeded.
Issuance Policy OIDs
OID Key Description Assurance

attestation level
type
1.3.6.1.4.1.311.21.30 EK "EK Verified": For administrator- High

managed list of EK
1.3.6.1.4.1.311.21.31 Endorsement "EK Certificate Verified": When EK Medium

certificate certificate chain is validated
OID Key Description Assurance
attestation level
type
1.3.6.1.4.1.311.21.32 User "EK Trusted on Use": For user-attested Low

credentials EK
The OIDs will be inserted into the issued certificate if Include Issuance Policies is
selected (the default configuration).
 Tip
One potential use of having the OID present in the certificate is to limit access
to VPN or wireless networking to certain devices. For example, your access
policy might allow connection (or access to a different VLAN) if OID
1.3.6.1.4.1.311.21.30 is present in the certificate. This allows you to limit access
to devices whose TPM EK is present in the EKPUB list.
CA configuration
1. Setup EKCA and EKROOT certificate stores on an issuing CA
If you chose Endorsement Certificate for the template settings, do the following
configuration steps:
a. Use Windows PowerShell to create two new certificate stores on the certification
authority (CA) server that will perform TPM key attestation.
b. Obtain the intermediate and root CA certificate(s) from manufacturer(s) that you
want to allow in your enterprise environment. Those certificates must be
imported into the previously-created certificate stores (EKCA and EKROOT) as
appropriate.
The following Windows PowerShell script performs both of these steps. In the
following example, the TPM manufacturer Fabrikam has provided a root certificate
FabrikamRoot.cer and an issuing CA certificate Fabrikamca.cer.
PowerShell
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
"allowlist" of devices that are permitted to obtain TPM key-attested certificates.
Because you must manually add the EKPUB for each and every device that requires
an attested certificate, it provides the enterprise with a guarantee of the devices
that are authorized to obtain TPM key attested certificates. Configuring a CA for
this mode requires two steps:
a. Create the EndorsementKeyListDirectories registry entry: Use the Certutil

command-line tool to configure the folder locations where trusted EKpubs are
defined as described in the following table.
Operation Command syntax
Add folder locations certutil.exe -setreg CA\EndorsementKeyListDirectories +"

<folder>"
Remove folder certutil.exe -setreg CA\EndorsementKeyListDirectories -"

locations <folder>"
The EndorsementKeyListDirectories in certutil command is a registry setting as

Value name Type Data
EndorsementKeyListDirectories REG_MULTI_SZ <LOCAL or UNC path to EKPUB allow

list(s)>
Example:
\\blueCA.contoso.com\ekpub
\\bluecluster1.contoso.com\ekpub
D:\ekpub
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA
Sanitized Name>
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 allowlist 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 won't 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.
PowerShell
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 aren't available if the template settings don't meet the
requirements for attestation. Common reasons are:
1. The compatibility settings aren't configured correctly. Make sure that they're
configured as follows:
a. Certification Authority: Windows Server 2012 R2

b. Certificate Recipient: Windows 8.1/Windows Server 2012 R2
2. The cryptography settings aren't configured correctly. Make sure that they're
a. Provider Category: Key Storage Provider
b. Algorithm Name: RSA
c. Providers: Microsoft Platform Crypto Provider
3. The request handling settings aren't configured correctly. Make sure that they're
a. The Allow private key to be exported option must not be selected.
b. The Archive subject's encryption private key option must not be selected.
Verification of TPM device for attestation

Use the Windows PowerShell cmdlet, Confirm-CAEndorsementKeyInfo, to verify that a
specific TPM device is trusted for attestation by CAs. There are two options: one for
verifying the EKCert, and the other for verifying an EKPub. The cmdlet is either run
locally on a CA, or on remote CAs by using Windows PowerShell remoting.
1. For verifying trust on an EKPub, do the following two steps:
a. Extract the EKPub from the client computer: The EKPub can be extracted from
a client computer via Get-TpmEndorsementKeyInfo. From an elevated
command prompt, run the following:
PS C:>\$a=Get-TpmEndorsementKeyInfo -hashalgorithm sha256
b. Verify trust on an EKCert on a CA computer: Copy the extracted string (the

SHA-2 hash of the EKPub) to the server (for example, via email) and pass it to
the Confirm-CAEndorsementKeyInfo cmdlet. Note that this parameter must be
64 characters.
Confirm-CAEndorsementKeyInfo [-PublicKeyHash] <string>
2. For verifying trust on an EKCert, do the following two steps:

a. Extract the EKCert from the client computer: The EKCert can be extracted from
a client computer via Get-TpmEndorsementKeyInfo. From an elevated
command prompt, run the following:
PS C:>\$a=Get-TpmEndorsementKeyInfo
PS C:>\$a.manufacturerCertificates|Export-Certificate -filepath
c:\myEkcert.cer
b. Verify trust on an EKCert on a CA computer: Copy the extracted EKCert

(EkCert.cer) to the CA (for example, via email or xcopy). As an example, if you
copy the certificate file the "c:\diagnose" folder on the CA server, run the
following to finish verification:
PS C:>new-object
System.Security.Cryptography.X509Certificates.X509Certificate2
"c:\diagnose\myEKcert.cer" | Confirm-CAEndorsementKeyInfo
See Also
Trusted Platform Module Technology Overview
External Resource: Trusted Platform
Module
CA Backup and Restore Windows
PowerShell cmdlets
Article • 05/17/2023
７ Note

found on TechNet.
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
ADCSAdministration Cmdlet: Backup-CARoleService
Arguments - Bold Description

arguments are
required
arguments are
required
-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 pre-exists 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 isn't specified,
log files are truncated by default except in the Incremental scenario
Backup-CARoleService c:\adcsbackup7 -KeepLog
-Password <Secure String>

If the -Password parameter is used, the supplied password must be a secure string. Use
the Read-Host cmdlet to launch an interactive prompt for secure password entry, or use
the ConvertTo-SecureString cmdlet to specify the password in-line.
Review the following examples
Specifying a secure string for the Password parameter using Read-Host
PowerShell
Backup-CARoleService c:\adcsbackup4 -Password (Read-Host -prompt "Password:"

-AsSecureString)
Specifying a secure string for the Password parameter using ConvertTo-SecureString
PowerShell
Backup-CARoleService c:\adcsbackup5 -Password (ConvertTo-SecureString

"Pa55w0rd!" -AsPlainText -Force)
Restore-CARoleService
ADCSAdministration Cmdlet: Restore-CARoleService

arguments are required
-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

arguments are required
-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 nonpassword protected backup is taken if the ConvertTo-SecureString function fails
while using the Backup-CARoleService with the -Password parameter.
Common errors
Action Error Comment
Restore-CARoleService Restore-CARoleService : The Stop the Active Directory

C:\ADCSBackup process can't access the file Certificate Services service prior
because it's being used by to running the Restore-
another process. (Exception CARoleService cmdlet
from HRESULT:
0x80070020)
Restore-CARoleService Restore-CARoleService : The Use the -Force parameter to

C:\ADCSBackup directory isn't empty. overwrite preexisting keys
(Exception from HRESULT:
0x80070091)
Backup-CARoleService Backup-CARoleService : The -Password parameter is only

C:\ADCSBackup -Password Parameter set can't be used to password protect private
(Read-Host -Prompt resolved using the specified keys and is therefore invalid
"Password:" - named parameters. when you aren't backing them up
AsSecureString) -
DatabaseOnly
Action Error Comment
Restore-CARoleService Restore-CARoleService : The -Password parameter is only

C:\ADCSBack15 -Password Parameter set can't be used to password protect private
(Read-Host -Prompt resolved using the specified keys and is therefore invalid
"Password:" - named parameters. when you aren't restoring them
AsSecureString) -
DatabaseOnly
Restore-CARoleService Restore-CARoleService : The The path specified doesn't

C:\ADCSBack14 -Password system can't find the file contain a valid database backup.
(Read-Host -Prompt specified. (Exception from Perhaps the path is invalid or the
"Password:" - HRESULT: 0x80070002) backup was taken with the -
AsSecureString) 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.

Article • 05/01/2023
７ Note

found on TechNet.
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's 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'll need to enable two policy settings.
You must have Audit Process Creation auditing enabled

to see event ID 4688.
To enable the Audit Process Creation policy, edit the following group policy:
Policy location: Computer Configuration > Policies > Windows Settings > Security
Settings > Advanced Audit Configuration > Detailed Tracking
Policy Name: Audit Process Creation
Supported on: Windows 7 and above
Description/Help:
This security policy setting determines whether the operating system generates audit
events when a process is created (starts) and the name of the program or user that
created it.
These audit events can help you understand how a computer is being used and to track
user activity.
Event volume: Low to medium, depending on system usage
Default: Not configured
In order to see the additions to event ID 4688, you must

enable the new policy setting: Include command line in
process creation events
Table SEQ Table \* ARABIC 19 Command line process policy setting
Policy Details
Configuration
Path Administrative Templates\System\Audit Process Creation
Setting Include command line in process creation events
Default Not Configured (not enabled)

setting
Supported on: ?
Policy Details
Configuration
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 don't configure this policy setting, the process's command line
information won't 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 aren't 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 aren't overwritten
1. Open the Group Policy Management console
2. Right-click Default Domain Policy, and then select 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 select Security
Options.
5. Double-click Audit: Force audit policy subcategory settings (Windows Vista or

later) to override audit policy category settings, and then select Define this policy
setting.
6. Select Enabled, and then select 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 isn't overwritten
2. Create a script that generates 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\ntuserright
s.vbs
del c:\systemfiles\temp\*.* /Q
3. Enable the command line process auditing
4. Execute the same script as before and observe the events

Directory Services component updates
Article • 05/16/2023
７ Note

found on TechNet.
This lesson explains the Directory Services component updates in Windows Server 2012
R2.
What You'll Learn

Explain the following new Directory Services component updates:
Explain the following new Directory Services component updates:
Active Directory Replication throughput improvement
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 preauthentication
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 doesn't provide any new features, but it
ensures that any new domain created in the forest will automatically operate at the
Windows Server 2012 R2 domain functional level.
Minimum DFL enforced on new domain creation

Windows Server 2008 DFL is the minimum functional level supported on new domain
creation.
７ Note
The deprecation of FRS is accomplished by removing the ability to install a new

domain with a domain functional level lower than Windows Server 2008 with Server
Manager or via Windows PowerShell.
Lowering the forest and domain functional levels

The forest and domain functional levels are set to Windows Server 2012 R2 by default
on new domain and new forest creation but can be lowered using Windows PowerShell.
To raise or lower the forest functional level using Windows PowerShell, use the Set-
ADForestMode cmdlet.
To set the contoso.com FFL to Windows Server 2008 mode:
SQL
Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com
To raise or lower the domain functional level using Windows PowerShell, use the Set-
ADDomainMode cmdlet.
To set the contoso.com DFL to Windows Server 2008 mode:
PowerShell
Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com
Promotion of a DC running Windows Server 2012 R2 as an additional replica into an

existing domain running 2003 DFL works.
New domain creation in an existing forest

ADPREP
There are no new forest or domain operations in this release.
These .ldf files contain schema changes for the Device Registration Service.
1. Sch59
2. Sch61
3. Sch62
4. Sch63
5. Sch64
6. Sch65
7. Sch67
Work Folders:
1. Sch66
MSODS:
1. Sch60
Authentication Policies and Silos
1. Sch68
2. Sch69
Overview
FRS is deprecated in Windows Server 2012 R2. The deprecation of FRS is accomplished
by enforcing a minimum domain functional level (DFL) of Windows Server 2008. This
enforcement is present only if the new domain is created using Server Manager or
Windows PowerShell.
You use the -DomainMode parameter with the Install-ADDSForest or Install-

ADDSDomain cmdlets to specify the domain functional level. Supported values for this
parameter can be either a valid integer or a corresponding enumerated string value. For
example, to set the domain mode level to Windows Server 2008 R2, you can specify
either a value of 4 or "Win2008R2". When executing these cmdlets from Server 2012 R2
valid values include those for Windows Server 2008 (3, Win2008) Windows Server 2008
R2 (4, Win2008R2) Windows Server 2012 (5, Win2012) and Windows Server 2012 R2 (6,
Win2012R2). The domain functional level can't be lower than the forest functional level,
but it can be higher. Since FRS is deprecated in this release, Windows Server 2003 (2,
Win2003) isn't a recognized parameter with these cmdlets when executed from
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 isn't available. As a core and
heavily used service, it's 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, select Controls.
3. On the Controls dialog box, expand the Load Predefined pull-down menu, select
Search Stats and then select OK.
4. On the Browse menu, select 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'll 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 doesn't 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's 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 isn't able to optimize because
one or more attributes aren't indexed.
Active Directory Replication throughput

improvement
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
Active Directory accounts
Article • 05/18/2023
Windows Server operating systems are installed with default local accounts. In addition,
you can create user accounts to meet the requirements of your organization.
This reference article describes the Windows Server default local accounts that are
stored locally on the domain controller and used in Active Directory. It doesn't describe
default local user accounts for a member, standalone server, or Windows client. For
more information, see Local accounts.
Default local accounts in Active Directory

Default local accounts are built-in accounts that are created automatically when a
Windows Server domain controller is installed and the domain is created. These default
local accounts have counterparts in Active Directory. They also have domain-wide access
and are completely separate from the default local user accounts for a member or
standalone server.
You can assign rights and permissions to default local accounts on a particular domain
controller, and only on that domain controller. These accounts are local to the domain.
After the default local accounts are installed, they're stored in the Users container in
Active Directory Users and Computers. It's a best practice to keep the default local
accounts in the User container and not attempt to move these accounts to, for example,
a different organizational unit (OU).
The default local accounts in the Users container include: Administrator, Guest, and
KRBTGT. The HelpAssistant account is installed when a Remote Assistance session is
established. The following sections describe the default local accounts and their use in
Active Directory.
Default local accounts perform the following actions:
Let the domain represent, identify, and authenticate the identity of the user who's
assigned to the account by using unique credentials (user name and password). It's
a best practice to assign each user to a single account to ensure maximum
security. Multiple users aren't allowed to share one account. A user account lets a
user sign in to computers, networks, and domains with a unique identifier that can
be authenticated by the computer, network, or domain.
Authorize (grant or deny) access to resources. After a user’s credentials have been
authenticated, the user is authorized to access the network, and domain resources
based on the user’s explicitly assigned rights on the resource.
Audit the actions that are carried out on user accounts.
In Active Directory, administrators use default local accounts to manage domain and
member servers directly and from dedicated administrative workstations. Active
Directory accounts provide access to network resources. Active Directory User accounts
and Computer accounts can represent a physical entity, such as a computer or person,
or act as dedicated service accounts for some applications.
Each default local account is automatically assigned to a security group that's

preconfigured with the appropriate rights and permissions to perform specific tasks.
Active Directory security groups collect user accounts, computer accounts, and other
groups into manageable units. For more information, see Active Directory security
groups.
On an Active Directory domain controller, each default local account is referred to as a

security principal. A security principal is a directory object that's used to secure and
manage Active Directory services that provide access to domain controller resources. A
security principal includes objects such as user accounts, computer accounts, security
groups, or the threads or processes that run in the security context of a user or
computer account. For more information, see Security principals.
A security principal is represented by a unique security identifier (SID). The SIDs that are
related to each of the default local accounts in Active Directory are described in the next
sections.
Some of the default local accounts are protected by a background process that
periodically checks and applies a specific security descriptor. A security descriptor is a
data structure that contains security information that's associated with a protected
object. This process ensures that any successful unauthorized attempt to modify the
security descriptor on one of the default local accounts or groups is overwritten with the
protected settings.
This security descriptor is present on the AdminSDHolder object. If you want to modify
the permissions on one of the service administrator groups or on any of its member
accounts, you must modify the security descriptor on the AdminSDHolder object to
ensure that it's applied consistently. Be careful when you're making these modifications,
because you're also changing the default settings that are applied to all your protected
accounts.
Administrator account
An Administrator account is a default account that's used in all versions of the Windows
operating system on every computer and device. The Administrator account is used by
the system administrator for tasks that require administrative credentials. This account
can't be deleted or locked out, but the account can be renamed or disabled.
The Administrator account gives the user complete access (Full Control permissions) of
the files, directories, services, and other resources that are on that local server. The
Administrator account can be used to create local users, and to assign user rights and
access control permissions. The account can also be used to take control of local
resources at any time simply by changing the user rights and permissions. Although files
and directories can be protected from the Administrator account temporarily, the
account can take control of these resources at any time by changing the access
permissions.
Account group membership

The Administrator account has membership in the default security groups, as described
in the Administrator account attributes table later in this article.
The security groups ensure that you can control administrator rights without having to
change each Administrator account. In most instances, you don't have to change the
basic settings for this account. However, you might have to change its advanced
settings, such as membership in particular groups.
After installation of the server operating system, your first task is to set up the
Administrator account properties securely. This includes setting up an especially long,
strong password, and securing the Remote control and Remote Desktop Services profile
settings.
The Administrator account can also be disabled when it's not required. Renaming or
disabling the Administrator account makes it more difficult for malicious users to try to
gain access to the account. However, even when the Administrator account is disabled,
it can still be used to gain access to a domain controller by using safe mode.
On a domain controller, the Administrator account becomes the Domain Admin

account. The Domain Admin account is used to sign in to the domain controller, and
this account requires a strong password. The Domain Admin account gives you access
to domain resources.
７ Note
When the domain controller is initially installed, you can sign in and use Server
Manager to set up a local Administrator account, with the rights and permissions
you want to assign. For example, you can use a local Administrator account to
manage the operating system when you first install it. By using this approach, you
can set up the operating system without getting locked out. Generally, you don't
need to use the account after installation. You can create local user accounts on the
domain controller only before Active Directory Domain Services is installed, and not
afterward.
When Active Directory is installed on the first domain controller in the domain, the
Administrator account is created for Active Directory. The Administrator account is the
most powerful account in the domain. It's given domain-wide access and administrative
rights to administer the computer and the domain, and it has the most extensive rights
and permissions over the domain. The person who installs Active Directory Domain
Services on the computer creates the password for this account during the installation.
Administrator account attributes
Attribute Value
Well-known SID/RID S-1-5- <domain> -500
Type User
Default container CN=Users, DC= <domain> , DC=
Default members N/A
Default member of Administrators, Domain Admins, Enterprise Administrators,

Domain Users (the Primary Group ID of all user accounts is
Domain Users)
Group Policy Creator Owners, and Schema Admins in Active

Directory Domain Users group
Protected by ADMINSDHOLDER? Yes
Safe to move out of default Yes

container?
Safe to delegate management of No

this group to non-service
administrators?
Guest account
The Guest account is a default local account that has limited access to the computer and
is disabled by default. By default, the Guest account password is left blank. A blank
password allows the Guest account to be accessed without requiring the user to enter a
password.
The Guest account enables occasional or one-time users, who don't have an individual
account on the computer, to sign in to the local server or domain with restricted rights
and permissions. The Guest account can be enabled, and the password can be set up if
needed, but only by a member of the Administrator group on the domain.
Guest account group membership
The Guest account has membership in the default security groups that are described in
the following Guest account attributes table. By default, the Guest account is the only
member of the default Guests group, which lets a user sign in to a server, and the
Domain Guests global group, which lets a user sign in to a domain.
A member of the Administrators group or Domain Admins group can set up a user with
a Guest account on one or more computers.
Guest account security considerations
Because the Guest account can provide anonymous access, it's a security risk. It also has
a well-known SID. For this reason, it's a best practice to leave the Guest account
disabled, unless its use is required and then only with restricted rights and permissions
for a very limited period of time.
When the Guest account is required, an Administrator on the domain controller is

required to enable the Guest account. The Guest account can be enabled without
requiring a password, or it can be enabled with a strong password. The Administrator
also grants restricted rights and permissions for the Guest account. To help prevent
unauthorized access:
Do not grant the Guest account the Shut down the system user right. When a
computer is shutting down or starting up, it's possible that a Guest user or anyone
with local access, such as a malicious user, could gain unauthorized access to the
computer.
Do not provide the Guest account with the ability to view the event logs. After the
Guest account is enabled, it's a best practice to monitor this account frequently to
ensure that other users can't use services and other resources, such as resources
that were unintentionally left available by a previous user.
Do not use the Guest account when the server has external network access or
access to other computers.
If you decide to enable the Guest account, be sure to restrict its use and to change the
password regularly. As with the Administrator account, you might want to rename the
account as an added security precaution.
In addition, an administrator is responsible for managing the Guest account. The

administrator monitors the Guest account, disables the Guest account when it's no
longer in use, and changes or removes the password as needed.
For details about the Guest account attributes, see the following table:
Guest account attributes
Attribute Value
Type User
Default members None
Default member of Guests, Domain Guests
Protected by ADMINSDHOLDER? No
Safe to move out of default container? Can be moved out, but we don't
recommend it.
Safe to delegate management of this group to non- No

Service admins?
HelpAssistant account (installed with a Remote

Assistance session)
The HelpAssistant account is a default local account that's enabled when a Remote
Assistance session is run. This account is automatically disabled when no Remote
Assistance requests are pending.
HelpAssistant is the primary account that's used to establish a Remote Assistance
session. The Remote Assistance session is used to connect to another computer running
the Windows operating system, and it's initiated by invitation. For solicited remote
assistance, a user sends an invitation from their computer, through email or as a file, to a
person who can provide assistance. After the user’s invitation for a Remote Assistance
session is accepted, the default HelpAssistant account is automatically created to give
the person who provides assistance limited access to the computer. The HelpAssistant
account is managed by the Remote Desktop Help Session Manager service.
HelpAssistant security considerations

The SIDs that pertain to the default HelpAssistant account include:
SID: S-1-5- <domain> -13, display name Terminal Server User. This group includes all
users who sign in to a server with Remote Desktop Services enabled. In Windows
Server 2008, Remote Desktop Services is called Terminal Services.
SID: S-1-5- <domain> -14, display name Remote Interactive Logon. This group
includes all users who connect to the computer by using a remote desktop
connection. This group is a subset of the Interactive group. Access tokens that
contain the Remote Interactive Logon SID also contain the Interactive SID.
For the Windows Server operating system, Remote Assistance is an optional component
that isn't installed by default. You must install Remote Assistance before you can use it.
For details about the HelpAssistant account attributes, see the following table:
HelpAssistant account attributes
Attribute Value
Well-known SID/RID S-1-5- <domain> -13 (Terminal Server User), S-1-5-

<domain> -14 (Remote Interactive Logon)
Type User
Default member of Domain Guests
Guests
Protected by ADMINSDHOLDER? No
Attribute Value
Safe to move out of default container? Can be moved out, but we don't recommend it.
Safe to delegate management of this No

group to non-Service admins?
KRBTGT account
The KRBTGT account is a local default account that acts as a service account for the Key
Distribution Center (KDC) service. This account can't be deleted, and the account name
can't be changed. The KRBTGT account can't be enabled in Active Directory.
KRBTGT is also the security principal name used by the KDC for a Windows Server
domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT
security principal, and it's created automatically when a new domain is created.
Windows Server Kerberos authentication is achieved by the use of a special Kerberos

ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from
the password of the server or service to which access is requested. The TGT password of
the KRBTGT account is known only by the Kerberos service. To request a session ticket,
the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the
KDC.
KRBTGT account maintenance considerations

A strong password is assigned to the KRBTGT and trust accounts automatically. Like any
privileged service accounts, organizations should change these passwords on a regular
schedule. The password for the KDC account is used to derive a secret key for
encrypting and decrypting the TGT requests that are issued. The password for a domain
trust account is used to derive an inter-realm key for encrypting referral tickets.
Resetting the password requires you either to be a member of the Domain Admins
group or be delegated the appropriate authority. In addition, you must be a member of
the local Administrators group or be delegated the appropriate authority.
After you reset the KRBTGT password, ensure that event ID 9 in the (Kerberos) Key-
Distribution-Center event source is written to the System event log.
KRBTGT account security considerations

It's also a best practice to reset the KRBTGT account password to ensure that a newly
restored domain controller doesn't replicate with a compromised domain controller. In
this case, in a large forest recovery that's spread across multiple locations, you can't
guarantee that all domain controllers are shut down and, if they are shut down, that
they can't be rebooted again before all the appropriate recovery steps have been
performed. After you reset the KRBTGT account, another domain controller can't
replicate this account password by using an old password.
An organization suspecting domain compromise of the KRBTGT account should consider

the use of professional incident response services. The impact to restore the ownership
of the account is domain-wide, labor intensive, and should be undertaken as part of a
larger recovery effort.
The KRBTGT password is the key from which all trust in Kerberos chains up to. Resetting
the KRBTGT password is similar to renewing the root CA certificate with a new key and
immediately not trusting the old key, resulting in almost all subsequent Kerberos
operations will be affected.
For all account types (users, computers, and services)
All the TGTs that are already issued and distributed will be invalid because the DCs
will reject them. These tickets are encrypted with the KRBTGT so any DC can
validate them. When the password changes, the tickets become invalid.
All currently authenticated sessions that signed-in users have established (based
on their service tickets) to a resource (such as a file share, SharePoint site, or
Exchange server) are good until the service ticket is required to reauthenticate.
NTLM authenticated connections aren't affected.
Because it's impossible to predict the specific errors that will occur for any given user in
a production operating environment, you must assume that all computers and users will
be affected.
） Important
Rebooting a computer is the only reliable way to recover functionality, because

doing so will cause both the computer account and user accounts to sign back in
again. Signing in again will request new TGTs that are valid with the new KRBTGT,
which will correct any KRBTGT-related operational issues on that computer.
Read-only domain controllers and the KRBTGT account

Windows Server 2008 introduced the read-only domain controller (RODC). The RODC is
advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a
different KRBTGT account and password than the KDC on a writable domain controller
when it signs or encrypts ticket-granting ticket (TGT) requests. After an account is
successfully authenticated, the RODC determines whether a user's credentials or a
computer's credentials can be replicated from the writable domain controller to the
RODC by using the Password Replication Policy.
After the credentials are cached on the RODC, the RODC can accept that user's sign-in
requests until the credentials change. When a TGT is signed with the KRBTGT account of
the RODC, the RODC recognizes that it has a cached copy of the credentials. If another
domain controller signs the TGT, the RODC forwards requests to a writable domain
controller.
KRBTGT account attributes
For details about the KRBTGT account attributes, see the following table:
Attribute Value
Type User
Default member of Domain Users group (the Primary Group ID of all

user accounts is Domain Users)
Protected by ADMINSDHOLDER? Yes
Safe to move out of default container? Can be moved out, but we don't recommend it.

group to non-Service admins?
Settings for default local accounts in Active

Directory
Each default local account in Active Directory has several account settings that you can
use to configure password settings and security-specific information, as described in the
following table:
Account settings Description
User must Forces a password change the next time that the user signs in to the network.
change password Use this option when you want to ensure that the user is the only person who
at next logon knows their password.
User can't change Prevents the user from changing the password. Use this option when you
password want to maintain control over a user account, such as for a Guest or
temporary account.
Password never Prevents a user password from expiring. It's a best practice to enable this
expires option with service accounts and to use strong passwords.
Store passwords Provides support for applications that use protocols requiring knowledge of
using reversible the plaintext form of the user’s password for authentication purposes.
encryption This option is required when you're using Challenge Handshake
Authentication Protocol (CHAP) in Internet Authentication Services (IAS), and
when you're using digest authentication in Internet Information Services (IIS).
Account is Prevents the user from signing in with the selected account. As an
disabled administrator, you can use disabled accounts as templates for common user
accounts.
Smart card is Requires that a user has a smart card to sign on to the network interactively.
required for The user must also have a smart card reader attached to their computer and
interactive logon a valid personal identification number (PIN) for the smart card.
When this attribute is applied on the account, the effect is as follows:

The attribute restricts only initial authentication for interactive sign-in and
Remote Desktop sign-in. When interactive or Remote Desktop sign-in
requires a subsequent network sign-in, such as with a domain credential, an
NT Hash provided by the domain controller is used to complete the
smartcard authentication process.
Each time the attribute is enabled on an account, the account’s current
password hash value is replaced with a 128-bit random number. This
invalidates the use of any previously configured passwords for the account.
The value doesn't change after that unless a new password is set or the
attribute is disabled and re-enabled.
Accounts with this attribute can't be used to start services or run
scheduled tasks.
Account settings Description
Account is Lets a service running under this account to perform operations on behalf of
trusted for other user accounts on the network. A service running under a user account
delegation (also known as a service account) that's trusted for delegation can
impersonate a client to gain access to resources, either on the computer
where the service is running or on other computers. For example, in a forest
that's set to the Windows Server 2003 functional level, this setting is found on
the Delegation tab. It's available only for accounts that have been assigned
service principal names (SPNs), which are set by using the setspn command
from Windows Support Tools. This setting is security-sensitive and should be
assigned cautiously.
Account is Gives control over a user account, such as for a Guest account or a temporary
sensitive and account. This option can be used if this account can't be assigned for
can't be delegation by another account.
delegated
Use DES Provides support for the Data Encryption Standard (DES). DES supports
encryption types multiple levels of encryption, including Microsoft Point-to-Point Encryption
for this account (MPPE) Standard (40-bit and 56-bit), MPPE standard (56-bit), MPPE Strong
(128-bit), Internet Protocol Security (IPSec) DES (40-bit), IPSec 56-bit DES, and
IPSec Triple DES (3DES).
Do not require Provides support for alternate implementations of the Kerberos protocol.
Kerberos Because preauthentication provides additional security, use caution when
preauthentication you're enabling this option. Domain controllers running Windows 2000 or
Windows Server 2003 can use other mechanisms to synchronize time.
７ Note
DES isn't enabled by default in Windows Server operating systems (starting with
Windows Server 2008 R2) or in Windows client operating systems (starting with
Windows 7). For these operating systems, computers won't use DES-CBC-MD5 or
DES-CBC-CRC cipher suites by default. If your environment requires DES, this
setting might affect compatibility with client computers or services and applications
in your environment.
For more information, see Hunting down DES to securely deploy Kerberos.
Manage default local accounts in Active

Directory
After the default local accounts are installed, these accounts reside in the Users
container in Active Directory Users and Computers. You can create, disable, reset, and
delete default local accounts by using the Active Directory Users and Computers
Microsoft Management Console (MMC) and by using command-line tools.
You can use Active Directory Users and Computers to assign rights and permissions on a
specified local domain controller, and that domain controller only, to limit the ability of
local users and groups to perform certain actions. A right authorizes a user to perform
certain actions on a computer, such as backing up files and folders or shutting down a
computer. In contrast, an access permission is a rule that's associated with an object,
usually a file, folder, or printer that regulates which users can have access to the object
and in what manner.
For more information about creating and managing local user accounts in Active
Directory, see Manage local users.
You can also use Active Directory Users and Computers on a domain controller to target
remote computers that aren't domain controllers on the network.
You can obtain recommendations from Microsoft for domain controller configurations
that you can distribute by using the Security Compliance Manager (SCM) tool. For more
information, see Microsoft Security Compliance Manager.
Some of the default local user accounts are protected by a background process that
periodically checks and applies a specific security descriptor, which is a data structure
that contains security information that's associated with a protected object. This security
descriptor is present on the AdminSDHolder object.
This means that, when you want to modify the permissions on a service administrator
group or on any of its member accounts, you're also required to modify the security
descriptor on the AdminSDHolder object. This approach ensures that the permissions
are applied consistently. Be careful when you make these modifications, because this
action can also affect the default settings that are applied to all your protected
administrative accounts.
Restrict and protect sensitive domain accounts

Restricting and protecting domain accounts in your domain environment requires you
to adopt and implement the following best practices approach:
Strictly limit membership to the Administrators, Domain Admins, and Enterprise

Admins groups.
Stringently control where and how domain accounts are used.
Member accounts in the Administrators, Domain Admins, and Enterprise Admins groups
in a domain or forest are high-value targets for malicious users. To limit any exposure,
it's a best practice to strictly limit membership to these administrator groups to the
smallest number of accounts. Restricting membership in these groups reduces the
possibility that an administrator might unintentionally misuse these credentials and
create a vulnerability that malicious users can exploit.
Moreover, it's a best practice to stringently control where and how sensitive domain
accounts are used. Restrict the use of Domain Admins accounts and other Administrator
accounts to prevent them from being used to sign in to management systems and
workstations that are secured at the same level as the managed systems. When
Administrator accounts aren't restricted in this manner, each workstation from which a
domain administrator signs in provides another location that malicious users can exploit.
Implementing these best practices is separated into the following tasks:
Separate Administrator accounts from user accounts

Restrict administrator sign-in access to servers and workstations
Disable the account delegation right for sensitive Administrator accounts
To provide for instances where integration challenges with the domain environment are
expected, each task is described according to the requirements for a minimum, better,
and ideal implementation. As with all significant changes to a production environment,
ensure that you test these changes thoroughly before you implement and deploy them.
Then stage the deployment in a manner that allows for a rollback of the change if
technical issues occur.
Separate Administrator accounts from user accounts

Restrict Domain Admins accounts and other sensitive accounts to prevent them from
being used to sign in to lower trust servers and workstations. Restrict and protect
Administrator accounts by segregating Administrator accounts from standard user
accounts, by separating administrative duties from other tasks, and by limiting the use
of these accounts. Create dedicated accounts for administrative personnel who require
administrator credentials to perform specific administrative tasks, and then create
separate accounts for other standard user tasks, according to the following guidelines:
Privileged account: Allocate Administrator accounts to perform the following

administrative duties only:
Minimum: Create separate accounts for domain administrators, enterprise
administrators, or the equivalent with appropriate administrator rights in the
domain or forest. Use accounts that have been granted sensitive administrator
rights only to administer domain data and domain controllers.
Better: Create separate accounts for administrators that have reduced

administrative rights, such as accounts for workstation administrators, and
accounts with user rights over designated Active Directory organizational units
(OUs).
Ideal: Create multiple, separate accounts for an administrator who has several
job responsibilities that require different trust levels. Set up each Administrator
account with different user rights, such as for workstation administration, server
administration, and domain administration, to let the administrator sign in to
specified workstations, servers, and domain controllers based strictly on their
job responsibilities.
Standard user account: Grant standard user rights for standard user tasks, such as
email, web browsing, and using line-of-business (LOB) applications. These accounts
should not be granted administrator rights.
） Important
Ensure that sensitive Administrator accounts can't access email or browse the
internet as described in the following section.
To learn more about privileged access, see Privileged access devices.
Restrict administrator sign-in access to servers and

workstations
It's a best practice to restrict administrators from using sensitive Administrator accounts
to sign in to lower-trust servers and workstations. This restriction prevents
administrators from inadvertently increasing the risk of credential theft by signing in to
a lower-trust computer.
） Important
Ensure that you either have local access to the domain controller or you've built at
least one dedicated administrative workstation.
Restrict sign-in access to lower-trust servers and workstations by using the following
guidelines:
Minimum: Restrict domain administrators from having sign-in access to servers

and workstations. Before you start this procedure, identify all OUs in the domain
that contain workstations and servers. Any computers in OUs that aren't identified
won't restrict administrators with sensitive accounts from signing in to them.
Better: Restrict domain administrators from non-domain controller servers and

workstations.
Ideal: Restrict server administrators from signing in to workstations, in addition to

domain administrators.
７ Note
For this procedure, do not link accounts to the OU that contain workstations for
administrators that perform administration duties only, and do not provide internet
or email access.
To restrict domain administrators from workstations (minimum)
1. As a domain administrator, open the Group Policy Management Console (GPMC).
2. Open Group Policy Management, expand <forest>\Domains\ <domain> .
3. Right-click Group Policy Objects, and then select New.

4. In the New GPO window, name the GPO that restricts administrators from signing
in to workstations, and then select OK.
5. Right-click New GPO, and then select Edit.
6. Configure user rights to deny sign-in locally for domain administrators.
7. Select Computer Configuration > Policies > Windows Settings > Local Policies,
select User Rights Assignment, and then do the following:
a. Double-click Deny logon locally, and then select Define these policy settings.
b.
Select Add User or Group, select Browse, type Enterprise Admins, and then select
OK.
c. Select Add User or Group, select Browse, type Domain Admins, and then
select OK.
 Tip
You can optionally add any groups that contain server administrators whom
you want to restrict from signing in to workstations.
７ Note
Completing this step might cause issues with administrator tasks that run as
scheduled tasks or services with accounts in the Domain Admins group. The
practice of using domain Administrator accounts to run services and tasks on
workstations creates a significant risk of credential theft attacks and,
therefore, should be replaced with alternative means to run scheduled tasks
or services.
d. Select OK to complete the configuration.
8. Link the GPO to the first Workstations OU. Go to the <forest>\Domains\

<domain> \OU path, and then do the following:
a. Right-click the workstation OU, and then select Link an Existing GPO.
b. Select the GPO that you just created, and then select OK.
9. Test the functionality of enterprise applications on workstations in the first OU, and
resolve any issues caused by the new policy.
10. Link all other OUs that contain workstations.
However, do not create a link to the Administrative Workstation OU if it's created

for administrative workstations that are dedicated to administration duties only
and are without internet or email access.
） Important
If you later extend this solution, do not deny sign-in rights for the Domain
Users group. The Domain Users group includes all user accounts in the
domain, including Users, Domain Administrators, and Enterprise
Administrators.
Disable the account delegation right for sensitive

Administrator accounts
Although user accounts aren't marked for delegation by default, accounts in an Active
Directory domain can be trusted for delegation. This means that a service or a computer
that's trusted for delegation can impersonate an account that authenticates to them to
access other resources across the network.
For sensitive accounts, such as those belonging to members of the Administrators,

Domain Admins, or Enterprise Admins groups in Active Directory, delegation can
present a substantial risk of rights escalation. For example, if an account in the Domain
Admins group is used to sign in to a compromised member server that's trusted for
delegation, that server can request access to resources in the context of the Domain
Admins account, and escalate the compromise of that member server to a domain
compromise.
It's a best practice to configure the user objects for all sensitive accounts in Active
Directory by selecting the Account is sensitive and cannot be delegated checkbox
under Account options to prevent the accounts from being delegated. For more
information, see Settings for default local accounts in Active Directory.
As with any configuration change, test this enabled setting fully to ensure that it
performs correctly before you implement it.
Secure and manage domain controllers
It's a best practice to strictly enforce restrictions on the domain controllers in your
environment. This ensures that the domain controllers:
Run only required software.

Require that software is regularly updated.
Are configured with the appropriate security settings.
One aspect of securing and managing domain controllers is to ensure that the default
local user accounts are fully protected. It's of primary importance to restrict and secure
all sensitive domain accounts, as described in the preceding sections.
Because domain controllers store credential password hashes of all accounts in the
domain, they're high-value targets for malicious users. When domain controllers aren't
well managed and secured by using restrictions that are strictly enforced, they can be
compromised by malicious users. For example, a malicious user could steal sensitive
domain administrator credentials from one domain controller, and then use these
credentials to attack the domain and forest.
In addition, installed applications and management agents on domain controllers might
provide a path for escalating rights that malicious users can use to compromise the
management service or administrators of that service. The management tools and
services, which your organization uses to manage domain controllers and their
administrators, are equally important to the security of the domain controllers and the
domain Administrator accounts. Ensure that these services and administrators are fully
secured with equal effort.
See also
Security principals
Access control overview
Special identity groups
Article • 09/20/2022
Learn about Windows Server special identity groups (sometimes called security groups)
that are used for Windows access control.
What is a special identity group?

Special identity groups are similar to the Active Directory security groups that are listed
in the Active Directory Users and BuiltIn containers. Special identity groups can provide
an efficient way to assign access to resources in your network. By using special identity
groups, you can:
Assign user rights to security groups in Active Directory.
Assign permissions to security groups to access resources.
How special identity groups work in Windows

Server
If a server is running one of the versions of the Windows Server operating system shown
in Applies to at the beginning of this article, the server has several special identity
groups. These special identity groups don't have specific memberships that you can
modify, but they can represent different users at different times depending on the
circumstances.
Although you can assign rights and permissions for specific resources to a special
identity group, you can't view or modify the membership of a special identity group.
Group scopes don't apply to special identity groups. Users are automatically assigned to
special identity groups when they sign in or access a specific resource.
For information about Active Directory security groups and group scopes, see Active
Directory security groups.
Default special identity groups

Default special identity groups in Windows Server are described in the following list:
Anonymous Logon
Attested key property
Authenticated Users
Authentication authority asserted identity
Batch
Console logon
Creator Group
Creator Owner
Dialup
Digest Authentication
Enterprise Domain Controllers
Enterprise Read-only Domain Controllers
Everyone
Fresh Public Key identity
Interactive
IUSR
Key trust
Local Service
LocalSystem
MFA key property
Network
Network Service
NTLM Authentication
Other Organization
Owner Rights
Principal Self
Proxy
Read-only Domain Controller
Remote Interactive Logon
Restricted
SChannel Authentication
Service
Service asserted identity
Terminal Server User
This Organization
Window Manager\Window Manager Group
Anonymous Logon
Any user who accesses the system through an anonymous logon has the Anonymous
Logon identity. This identity allows anonymous access to resources, like to a webpage
that's published on a corporate server. The Anonymous Logon group isn't a member of
the Everyone group by default.
Attribute Value
Well-known SID/RID S-1-5-7
Object class Foreign Security Principal
Default location in Active CN=WellKnown Security Principals, CN=Configuration, DC=

Directory <forestRootDomain>
Default user rights None
Attested key property

A security identifier (SID) that means the key trust object had the attestation property.
Attribute Value

Authenticated Users
Any user who accesses the system through a sign-in process has the Authenticated
Users identity. This identity allows access to shared resources within the domain, such as
files in a shared folder that should be accessible to all the workers in the organization.
Membership is controlled by the operating system.
Attribute Value

Attribute Value
Default user rights Access this computer from the network: SeNetworkLogonRight
Add workstations to domain: SeMachineAccountPrivilege
Bypass traverse checking: SeChangeNotifyPrivilege
Authentication authority asserted identity

An SID that means the client's identity is asserted by an authentication authority based
on proof of possession of client credentials.
Attribute Value

Batch
Any user or process that accesses the system as a batch job or through the batch queue
has the Batch identity. This identity allows batch jobs to run scheduled tasks, such as a
nightly cleanup job that deletes temporary files. Membership is controlled by the
operating system.
Attribute Value

Default user rights none
Console logon
A group that includes users who are logged on to the physical console. This SID can be
used to implement security policies that grant different rights based on whether a user
has been granted physical access to the console.
Attribute Value

Creator Group
The person who created a file or directory is a member of this special identity group.
The Windows Server operating system uses this identity to automatically grant access
permissions to the creator of a file or directory.
A placeholder SID is created in an inheritable access control entry (ACE). When the ACE
is inherited, the system replaces this SID with the SID for the primary group of the
object’s current owner. The primary group is used only by the POSIX subsystem.
Attribute Value

Creator Owner
The person who created a file or directory is a member of this special identity group.
The Windows Server operating system uses this identity to automatically grant access
permissions to the creator of a file or directory. A placeholder SID is created in an
inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for
the object’s current owner.
Attribute Value

Attribute Value

Dialup
Any user who accesses the system through a dial-up connection has the Dialup identity.
This identity distinguishes dial-up users from other types of authenticated users.
Attribute Value

Digest Authentication
Attribute Value
Well-known SID/RID S-1-5-64-21

Enterprise Domain Controllers

This group includes all domain controllers in an Active Directory forest. Domain
controllers with enterprise-wide roles and responsibilities have the Enterprise Domain
Controllers identity. This identity allows domain controllers to perform certain tasks in
the enterprise by using transitive trusts. Membership is controlled by the operating
system.
Attribute Value

Allow log on locally: SeInteractiveLogonRight

This group includes all domain controllers in an Active Directory forest. Domain
controllers with enterprise-wide roles and responsibilities have the Enterprise Domain
Controllers identity. Except for account passwords, a read-only domain controller
(RODC) holds all the Active Directory objects and attributes that a writable domain
controller holds. Membership is controlled by the operating system.
Attribute Value
Well-known SID/RID S-1-5-21-<RootDomain>

Everyone
All interactive, network, dial-up, and authenticated users are members of the Everyone
group. This special identity group gives wide access to system resources. When a user
logs on to the network, the user is automatically added to the Everyone group.
Membership is controlled by the operating system.
On computers running Windows 2000 and earlier, the Everyone group included the
Anonymous Logon group as a default member. Beginning in Windows Server 2003, the
Everyone group contains only Authenticated Users and Guest. The group no longer
includes Anonymous Logon by default. To change the Everyone group setting to include
the Anonymous Logon group, in Registry Editor, go to the
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa key and
set the value of the everyoneincludesanonymous DWORD to 1.
Attribute Value

Act as part of the operating system: SeTcbPrivilege
Fresh Public Key identity

An SID that means the client's identity is asserted by an authentication authority based
on proof of current possession of client public key credentials.
Attribute Value

Interactive
Any user who is logged on to the local system has the Interactive identity. This identity
allows only local users to access a resource. When a user accesses a specific resource on
the computer to which they're currently logged on, the user is automatically added to
the Interactive group. Membership is controlled by the operating system.
Attribute Value

Attribute Value

IUSR
Internet Information Services (IIS) uses this account by default when anonymous
authentication is enabled.
Attribute Value

Key trust
An SID that means the client's identity is based on proof of possession of public key
credentials by using the key trust object.
Attribute Value

Local Service
The Local Service account is similar to the Authenticated User account. Members of the
Local Service account have the same level of access to resources and objects as
members of the Users group. This limited access helps safeguard your system if
individual services or processes are compromised. Services that run as the Local Service
account access network resources as a null session with anonymous credentials. The
name of the account is NT AUTHORITY\LocalService. This account doesn't have a
password.
Attribute Value

Default user rights Adjust memory quotas for a process: SeIncreaseQuotaPrivilege
Change the system time: SeSystemtimePrivilege
Change the time zone: SeTimeZonePrivilege
Create global objects: SeCreateGlobalPrivilege
Generate security audits: SeAuditPrivilege
Impersonate a client after authentication: SeImpersonatePrivilege
Replace a process level token: SeAssignPrimaryTokenPrivilege
LocalSystem
The LocalSystem account is a service account that's used by the operating system. The
LocalSystem account is a powerful account that has full access to the system and acts as
the computer on the network. If a service logs on to the LocalSystem account on a
domain controller, that service has access to the entire domain. Some services are
configured by default to log on to the LocalSystem account. Don't change the default
service setting. The name of the account is LocalSystem. This account doesn't have a
password.
Attribute Value

Attribute Value
MFA key property

An SID that means the key trust object had the multifactor authentication (MFA)
property.
Attribute Value

Network
This group implicitly includes all users who are logged on through a network
connection. Any user who accesses the system through a network has the Network
identity. This identity allows only remote users to access a resource. When a user
accesses a specific resource over the network, the user is automatically added to the
Network group. Membership is controlled by the operating system.
Attribute Value

Network Service
The Network Service account is similar to the Authenticated User account. Members of
the Network Service account have the same level of access to resources and objects as
members of the Users group. This limited access helps safeguard your system if
individual services or processes are compromised. Services that run as the Network
Service account access network resources by using the credentials of the computer
account. The name of the account is NT AUTHORITY\NetworkService. This account
doesn't have a password.
Attribute Value

Default user rights Adjust memory quotas for a process: SeIncreaseQuotaPrivilege
Generate security audits: SeAuditPrivilege
Replace a process level token: SeAssignPrimaryTokenPrivilege
NTLM Authentication
Attribute Value

Other Organization
This group implicitly includes all users who are logged on to the system through a dial-
up connection. Membership is controlled by the operating system.
Attribute Value

Attribute Value

Owner Rights
The Owner Rights group represents the current owner of the object. When an ACE that
carries this SID is applied to an object, the system ignores the implicit READ_CONTROL
and WRITE_DAC permissions for the object owner.
Attribute Value

Principal Self
This identity is a placeholder in an ACE on a user, group, or computer object in
Active Directory. When you grant permissions to Principal Self, you grant permissions to
the security principal that's represented by the object. During an access check, the
operating system replaces the SID for Principal Self with the SID for the security principal
that's represented by the object.
Attribute Value


Proxy
Identifies a SECURITY_NT_AUTHORITY proxy.
Attribute Value

Read-only Domain Controller

This group includes all RODCs in the forest with read-only rights to the Active Directory
database. It allows domain controller deployment when physical security is scarce or not
guaranteed. Membership is controlled by the operating system.
Attribute Value
Well-known SID/RID S-1-5-21-<domain>

７ Note
The Denied RODC Password Replication group is created automatically when an

RODC account is created in the forest. Passwords can't be replicated in the Denied
RODC Password Replication group.
Remote Interactive Logon

This identity represents all users who are currently logged on to a computer by using a
Remote Desktop Protocol connection. This group is a subset of the Interactive group.
Access tokens that contain the Remote Interactive Logon SID also contain the Interactive
SID.
Attribute Value

Restricted
Users and computers with restricted capabilities have the Restricted identity. This
identity group is used by a process that's running in a restricted security context, such as
running an application with the RunAs service. When code runs at the Restricted security
level, the Restricted SID is added to the user’s access token.
Attribute Value

SChannel Authentication
Attribute Value

Service
Any service that accesses the system has the Service identity. This identity group
includes all security principals that are signed in as a service. This identity grants access
to processes that Windows Server services are running. Membership is controlled by the
operating system.
Attribute Value

Default user rights Create global objects: SeCreateGlobalPrivilege
Service asserted identity

An SID that means the client's identity is asserted by a service.
Attribute Value

Terminal Server User

Any user that's accessing the system through Terminal Services has the Terminal Server
User identity. This identity allows users to access Terminal Server applications and to do
other necessary tasks with Terminal Server services. Membership is controlled by the
operating system.
Attribute Value

Attribute Value
This Organization
Attribute Value

Window Manager\Window Manager Group
Attribute Value

Default user rights Bypass traverse checking: SeChangeNotifyPrivilege
Increase a process working set: SeIncreaseWorkingSetPrivilege
See also
Active Directory security groups
Security principals

Active Directory security groups
Article • 04/11/2023
Learn about default Active Directory security groups, group scope, and group functions.
What is a security group in Active Directory?

Active Directory has two forms of common security principals: user accounts and
computer accounts. These accounts represent a physical entity that is either a person or
a computer. A user account also can be used as a dedicated service account for some
applications.
Security groups are a way to collect user accounts, computer accounts, and other
groups into manageable units.
In the Windows Server operating system, several built-in accounts and security groups
are preconfigured with the appropriate rights and permissions to perform specific tasks.
In Active Directory, administrative responsibilities are separated into two types of
administrators:
Service administrators: Responsible for maintaining and delivering Active

Directory Domain Services (AD DS), including managing domain controllers and
configuring AD DS.
Data administrators: Responsible for maintaining the data that's stored in AD DS

and on domain member servers and workstations.
How Active Directory security groups work

Use groups to collect user accounts, computer accounts, and other groups into
manageable units. Working with groups instead of with individual users helps you
simplify network maintenance and administration.
Active Directory has two types of groups:
Security groups: Use to assign permissions to shared resources.
Distribution groups: Use to create email distribution lists.

Security groups
Security groups can provide an efficient way to assign access to resources on your
network. By using security groups, you can:
Assign user rights to security groups in Active Directory.
Assign user rights to a security group to determine what members of that group
can do within the scope of a domain or forest. User rights are automatically
assigned to some security groups when Active Directory is installed to help
administrators define a person’s administrative role in the domain.
For example, a user who you add to the Backup Operators group in Active
Directory can back up and restore files and directories that are located on each
domain controller in the domain. The user can complete these actions because, by
default, the user rights Backup files and directories and Restore files and directories
are automatically assigned to the Backup Operators group. Therefore, members of
this group inherit the user rights that are assigned to that group.
You can use Group Policy to assign user rights to security groups to delegate
specific tasks. For more information about using Group Policy, see User Rights
Assignment.
Assign permissions to security groups for resources.
Permissions are different from user rights. Permissions are assigned to a security
group for a shared resource. Permissions determine who can access the resource
and the level of access, such as Full control or Read. Some permissions that are set
on domain objects are automatically assigned to allow various levels of access to
default security groups like the Account Operators group or the Domain Admins
group.
Security groups are listed in Discretionary Access Control Lists (DACLs) that define
permissions on resources and objects. When administrators assign permissions for
resources like file shares or printers, they should assign those permissions to a
security group instead of to individual users. The permissions are assigned once to
the group instead of multiple times to each individual user. Each account that's
added to a group receives the rights that are assigned to that group in Active
Directory. The user receives permissions that are defined for that group.
You can use a security group as an email entity. Sending an email message to a security
group sends the message to all the members of the group.
Distribution groups
You can use distribution groups only to send email to collections of users by using an
email application like Exchange Server. Distribution groups aren't security enabled, so
you can't include them in DACLs.
Group scope
Each group has a scope that identifies the extent to which the group is applied in the
domain tree or forest. The scope of a group defines where in the network permissions
can be granted for the group. Active Directory defines the following three group scopes:
Universal
Global
Domain Local
７ Note
In addition to these three scopes, the default groups in the Builtin container have a
group scope of Builtin Local. This group scope and group type can't be changed.
The following table describes the three group scopes and how they work as security
groups:
Scope Possible members Scope conversion Can grant Possible member of

permissions
Universal Accounts from any Can be converted to On any Other Universal groups in
domain in the Domain Local scope domain in the same forest
same forest if the group isn't a the same Domain Local groups in
Global groups member of any forest or the same forest or
from any domain other Universal trusting trusting forests
in the same forest group forests
Can be converted to Local groups on
Other Universal Global scope if the computers in the same
groups from any group doesn't forest or trusting forests
domain in the contain any other
same forest Universal group
Scope Possible members Scope conversion Can grant Possible member of
permissions
Global Accounts from the Can be converted to On any Universal groups from
same domain Universal scope if domain in any domain in the same
Other Global the group isn't a the same forest
groups from the member of any forest, or Other Global groups from
same domain other Global group trusting the same domain
domains or
forests Domain Local groups
from any domain in the
same forest, or from any
trusting domain
Domain Accounts from any Can be converted to Within the Other Domain Local
Local domain or any Universal scope if same groups from the same
trusted domain the group doesn't domain domain
Global groups contain any other Local groups on
from any domain Domain Local group computers in the same
or any trusted domain, excluding built-
domain in groups that have well-
known security identifiers
Universal groups (SIDs)
from any domain
in the same forest
Other Domain
Local groups from
the same domain
Accounts, Global
groups, and
Universal groups
from other forests
and from external
domains

Special identities are referred to as groups. Special identity groups don't have specific
memberships that you can modify, but they can represent different users at different
times depending on the circumstances. Some of these groups include Creator Owner,
Batch, and Authenticated User.
For more information, see Special identity groups.
Default security groups

Default groups like the Domain Admins group are security groups that are created
automatically when you create an Active Directory domain. You can use these
predefined groups to help control access to shared resources and to delegate specific
domain-wide administrative roles.
Many default groups are automatically assigned a set of user rights that authorize
members of the group to perform specific actions in a domain, like logging on to a local
system or backing up files and folders. For example, a member of the Backup Operators
group can perform backup operations for all domain controllers in the domain.
When you add a user to a group, the user receives all the user rights that are assigned
to the group, including all the permissions that are assigned to the group for any shared
resources.
Default groups are located in the Builtin container and in the Users container in Active
Directory Users and Computers. The Builtin container includes groups that are defined
with the Domain Local scope. The Users container includes groups that are defined with
Global scope and groups that are defined with Domain Local scope. You can move
groups that are located in these containers to other groups or organizational units
within the domain, but you can't move them to other domains.
Some of the administrative groups that are listed in this article and all members of these
groups are protected by a background process that periodically checks for and applies a
specific security descriptor. This descriptor is a data structure that contains security
information that's associated with a protected object. This process ensures that any
successful unauthorized attempt to modify the security descriptor on one of the
administrative accounts or groups is overwritten with the protected settings.
The security descriptor is present on the AdminSDHolder object. If you want to modify
the permissions on one of the service administrator groups or on any of its member
accounts, you must modify the security descriptor on the AdminSDHolder object so that
it's applied consistently. Be careful when you make these modifications because you're
also changing the default settings that are applied to all your protected administrative
accounts.
Default Active Directory security groups

The following list provides descriptions of the default groups that are located in the
Builtin and Users containers in Active Directory:
Access Control Assistance Operators

Account Operators
Administrators
Allowed RODC Password Replication
Backup Operators
Certificate Service DCOM Access
Cert Publishers
Cloneable Domain Controllers
Cryptographic Operators
Denied RODC Password Replication
Device Owners
DHCP Administrators
DHCP Users
Distributed COM Users
DnsUpdateProxy
DnsAdmins
Domain Admins
Domain Computers
Domain Controllers
Domain Guests
Domain Users
Enterprise Admins
Enterprise Key Admins
Event Log Readers
Group Policy Creator Owners
Guests
Hyper-V Administrators
IIS_IUSRS
Incoming Forest Trust Builders
Key Admins
Network Configuration Operators
Performance Log Users
Performance Monitor Users
Pre–Windows 2000 Compatible Access
Print Operators
Protected Users
RAS and IAS Servers
RDS Endpoint Servers
RDS Management Servers
RDS Remote Access Servers
Read-only Domain Controllers
Remote Desktop Users
Remote Management Users
Replicator
Schema Admins
Server Operators
Storage Replica Administrators
System Managed Accounts
Terminal Server License Servers
Users
Windows Authorization Access
WinRMRemoteWMIUsers_
Access Control Assistance Operators

Members of this group can remotely query authorization attributes and permissions for
resources on the computer.
The Access Control Assistance Operators group applies to the Windows Server
operating system listed in the Default Active Directory security groups table.
Attribute Value
Type Builtin Local
Default container CN=Builtin, DC=<domain>,

DC=
Default member of None
Protected by AdminSDHolder? No
Safe to move out of default container? Can't be moved
Safe to delegate management of this group to non-service

admins?
Account Operators
The Account Operators group grants limited account creation privileges to a user.
Members of this group can create and modify most types of accounts, including
accounts for users, Local groups, and Global groups. Group members can log in locally
to domain controllers.
Members of the Account Operators group can't manage the Administrator user account,
the user accounts of administrators, or the Administrators, Server Operators, Account
Operators, Backup Operators, or Print Operators groups. Members of this group can't
modify user rights.
The Account Operators group applies to the Windows Server operating system in the
Default Active Directory security groups list.
７ Note
By default, this built-in group has no members. The group can create and manage
users and groups in the domain, including its own membership and that of the
Server Operators group. This group is considered a service administrator group
because it can modify Server Operators, which in turn can modify domain controller
settings. As a best practice, leave the membership of this group empty, and don't
use it for any delegated administration. This group can't be renamed, deleted, or
removed.
Attribute Value
Type Builtin Local
Default container CN=Builtin, DC=<domain>, DC=
Protected by AdminSDHolder? Yes

service admins?
Default user rights Allow log on locally:

SeInteractiveLogonRight
Administrators
Members of the Administrators group have complete and unrestricted access to the
computer. If the computer is promoted to a domain controller, members of the
Administrators group have unrestricted access to the domain.
The Administrators group applies to the Windows Server operating system in the
Default Active Directory security groups list.
７ Note
The Administrators group has built-in capabilities that give its members full control
over the system. This group can't be renamed, deleted, or removed. This built-in
group controls access to all the domain controllers in its domain, and it can change
the membership of all administrative groups. Members of the following groups can
modify the Administrators group membership: the default service Administrators,
Domain Admins in the domain, and Enterprise Admins. This group has the special
privilege to take ownership of any object in the directory or any resource on a
domain controller. This account is considered a service administrator group
because its members have full access to the domain controllers in the domain.
This security group includes the following changes since Windows Server 2008:
Default user rights changes: Allow log on through Terminal Services existed in
Windows Server 2008, and it was replaced by Allow log on through Remote
Desktop Services.
Remove computer from docking station was removed in Windows Server 2012 R2.
Attribute Value
Type Builtin Local
Default members Administrator, Domain Admins, Enterprise Admins

group to non-service admins?
Attribute Value
Default user rights Adjust memory quotas for a process:

SeIncreaseQuotaPrivilege
Access this computer from the network:

SeNetworkLogonRight
Allow log on locally: SeInteractiveLogonRight
Allow log on through Remote Desktop Services:

SeRemoteInteractiveLogonRight
Back up files and directories: SeBackupPrivilege
Change the system time: SeSystemTimePrivilege
Create a pagefile: SeCreatePagefilePrivilege
Create symbolic links: SeCreateSymbolicLinkPrivilege
Debug programs: SeDebugPrivilege

delegation: SeEnableDelegationPrivilege
Force shutdown from a remote system:

SeRemoteShutdownPrivilege
Impersonate a client after authentication:

SeImpersonatePrivilege
Increase scheduling priority:

SeIncreaseBasePriorityPrivilege
Load and unload device drivers: SeLoadDriverPrivilege
Log on as a batch job: SeBatchLogonRight
Manage auditing and security log: SeSecurityPrivilege
Modify firmware environment values:

SeSystemEnvironmentPrivilege
Perform volume maintenance tasks:

SeManageVolumePrivilege
Profile system performance: SeSystemProfilePrivilege

Attribute Value
Profile single process: SeProfileSingleProcessPrivilege
Remove computer from docking station:

SeUndockPrivilege
Restore files and directories: SeRestorePrivilege
Shut down the system: SeShutdownPrivilege
Take ownership of files or other objects:

SeTakeOwnershipPrivilege
Allowed RODC Password Replication

The purpose of this security group is to manage a read-only domain controller (RODC)
password replication policy. This group has no members by default, and it results in the
condition that new RODCs don't cache user credentials. The Denied RODC Password
Replication group contains various high-privilege accounts and security groups. The
Denied RODC Password Replication group supersedes the Allowed RODC Password
Replication group.
The Allowed RODC Password Replication group applies to the Windows Server
operating system in Default Active Directory security groups.
Attribute Value
Well-known SID/RID S-1-5-21-<domain>-571
Type Domain local
Default container CN=Users DC=<domain>,

DC=

admins?

Backup Operators
Members of the Backup Operators group can back up and restore all files on a
computer, regardless of the permissions that protect those files. Backup Operators also
can log on to and shut down the computer. This group can't be renamed, deleted, or
removed. By default, this built-in group has no members, and it can perform backup and
restore operations on domain controllers. Members of the following groups can modify
Backup Operators group membership: default service Administrators, Domain Admins in
the domain, and Enterprise Admins. Members of the Backup Operators group can't
modify the membership of any administrative groups. Although members of this group
can't change server settings or modify the configuration of the directory, they do have
the permissions needed to replace files (including operating system files) on domain
controllers. Because members of this group can replace files on domain controllers,
they're considered service administrators.
The Backup Operators group applies to the Windows Server operating system in Default
Active Directory security groups.
Attribute Value
Type Builtin Local

service admins?
Attribute Value

Back up files and directories:

SeBackupPrivilege
Log on as a batch job:

SeBatchLogonRight
Restore files and directories:

SeRestorePrivilege
Shut down the system:

SeShutdownPrivilege
Certificate Service DCOM Access

Members of this group can connect to certification authorities in the enterprise.
The Certificate Service DCOM Access group applies to the Windows Server operating
system in Default Active Directory security groups.
Attribute Value
Type Domain Local

DC=

admins?
Cert Publishers
Members of the Cert Publishers group are authorized to publish certificates for User
objects in Active Directory.
The Cert Publishers group applies to the Windows Server operating system in Default
Attribute Value
Type Domain Local
Default container CN=Users, DC=<domain>, DC=
Default member of Denied RODC Password

Replication
Safe to delegate management of this group to non-service No

admins?
Cloneable Domain Controllers

Members of the Cloneable Domain Controllers group that are domain controllers may
be cloned. In Windows Server 2012 R2 and Windows Server 2012, you can deploy
domain controllers by copying an existing virtual domain controller. In a virtual
environment, you no longer have to repeatedly deploy a server image that's prepared
by using Sysprep.exe, promoting the server to a domain controller, and then complete
more configuration requirements for deploying each domain controller (including
adding the virtual domain controller to this security group).
For more information, see Introduction to Active Directory Domain Services (AD DS)
Virtualization (Level 100).
Attribute Value
Type Global
Attribute Value
Default container CN=Users, DC=<domain>,

DC=

admins?
Cryptographic Operators
Members of this group are authorized to perform cryptographic operations. This
security group was added in Windows Vista Service Pack 1 (SP1) to configure Windows
Firewall for IPsec in Common Criteria mode.
The Cryptographic Operators group applies to the Windows Server operating system in
Default Active Directory security groups.
This security group was introduced in Windows Vista SP1, and it hasn't changed in
subsequent versions.
Attribute Value
Type Builtin Local

DC=

admins?
Attribute Value

Passwords of members of the Denied RODC Password Replication group can't be
replicated to any RODC.
The purpose of this security group is to manage a RODC password replication policy.
This group contains various high-privilege accounts and security groups. The Denied
RODC Password Replication group supersedes the Allowed RODC Password Replication
group.
Windows Server 2012 changed the default members to include Cert Publishers.
Attribute Value
Type Domain local

DC=
Default members Cert Publishers
Domain Admins
Domain Controllers
Enterprise Admins
Schema Admins
Safe to move out of default container?

admins?
Attribute Value
Device Owners
When the Device Owners group has no members, we recommend that you don't change
the default configuration for this security group. Changing the default configuration
might hinder future scenarios that rely on this group. The Device Owners group
currently isn't used in Windows.
The Device Owners group applies to the Windows Server operating system in Default
Attribute Value
Type Builtin Local
Safe to move out of default container? You can move the group, but we don't
recommend it
Safe to delegate management of this group to No

non-service admins?
Default user rights Allow log on locally: SeInteractiveLogonRight
Access this computer from the network:

SeNetworkLogonRight
Bypass traverse checking:

SeChangeNotifyPrivilege
DHCP Administrators
Members of the DHCP Administrators group can create, delete, and manage different
areas of the server's scope, including the rights to back up and restore the Dynamic
Host Configuration Protocol (DHCP) database. Even though this group has
administrative rights, it isn't part of the Administrators group because this role is limited
to DHCP services.
The DHCP Administrators group applies to the Windows Server operating system in
Attribute Value
Type Builtin Local
Default member of Users
recommend it

service admins?
DHCP Users
Members of the DHCP Users group can see which scopes are active or inactive, see
which IP addresses are assigned, and view connectivity issues if the DHCP server isn't
configured correctly. This group is limited to read-only access to the DHCP server.
The DHCP Users group applies to the Windows Server operating system in Default
Attribute Value
Type Builtin Local

Attribute Value
recommend it

service admins?
Distributed COM Users

Members of the Distributed COM Users group can launch, activate, and use Distributed
COM objects on the computer. Microsoft Component Object Model (COM) is a
platform-independent, distributed, object-oriented system for creating binary software
components that can interact. Distributed Component Object Model (DCOM) allows
applications to be distributed across locations that make the most sense to you and to
the application. This group appears as an SID until the domain controller is made the
primary domain controller and it holds the operations master (also called the flexible
single master operations or FSMO) role.
The Distributed COM Users group applies to the Windows Server operating system in
Attribute Value
Type Builtin Local

DC=

admins?
Attribute Value
DnsUpdateProxy
Members of the DnsUpdateProxy group are DNS clients. They're permitted to perform
dynamic updates on behalf of other clients, like for DHCP servers. A DNS server can
develop stale resource records when a DHCP server is configured to dynamically register
host (A) and pointer (PTR) resource records on behalf of DHCP clients by using dynamic
update. Adding clients to this security group mitigates this scenario.
However, to protect against unsecured records or to permit members of the

DnsUpdateProxy group to register records in zones that allow only secured dynamic
updates, you must create a dedicated user account and configure DHCP servers to
perform DNS dynamic updates by using the credentials (username, password, and
domain) of this account. Multiple DHCP servers can use the credentials of one dedicated
user account. This group exists only if the DNS server role is or was once installed on a
domain controller in the domain.
For more information, see DNS record ownership and the DnsUpdateProxy group.
Attribute Value
Well-known SID/RID S-1-5-21-<domain>-<variable

RI>
Type Global
Safe to move out of default container? Yes

admins?
DnsAdmins
Members of the DnsAdmins group have access to network DNS information. The default
permissions are Allow: Read, Write, Create All Child objects, Delete Child objects, Special
Permissions. This group exists only if the DNS server role is or was once installed on a
domain controller in the domain.
For more information about security and DNS, see DNSSEC in Windows Server 2012.
Attribute Value

RI>
Type Builtin Local

admins?
Domain Admins
Members of the Domain Admins security group are authorized to administer the
domain. By default, the Domain Admins group is a member of the Administrators group
on all computers that have joined a domain, including the domain controllers. The
Domain Admins group is the default owner of any object that's created in Active
Directory for the domain by any member of the group. If members of the group create
other objects, such as files, the default owner is the Administrators group.
The Domain Admins group controls access to all domain controllers in a domain, and it
can modify the membership of all administrative accounts in the domain. Members of
the service administrator groups in its domain (Administrators and Domain Admins) and
members of the Enterprise Admins group can modify Domain Admins membership. This
group is considered a service administrator account because its members have full
access to the domain controllers in a domain.
The Domain Admins group applies to the Windows Server operating system in Default
Attribute Value
Type Global
Default members Administrator
Default member of Administrators
Denied RODC Password

Replication

admins?
Default user rights See Administrators
See Denied RODC Password

Replication
Domain Computers
This group can include all computers and servers that have joined the domain, excluding
domain controllers. By default, any computer account that's created automatically
becomes a member of this group.
The Domain Computers group applies to the Windows Server operating system in
Attribute Value
Type Global
Default members All computers joined to the domain, excluding

domain controllers
Attribute Value
Safe to move out of default container? Yes (but not required)
Safe to delegate management of this group to Yes

non-service admins?
Domain Controllers
The Domain Controllers group can include all domain controllers in the domain. New
domain controllers are automatically added to this group.
The Domain Controllers group applies to the Windows Server operating system in
Attribute Value
Type Global
Default members Computer accounts for all domain

controllers of the domain
Default member of Denied RODC Password Replication
Safe to move out of default container? No
Safe to delegate management of this group to No

non-service admins?
Domain Guests
The Domain Guests group includes the domain’s built-in Guest account. When members
of this group sign in as local guests on a domain-joined computer, a domain profile is
created on the local computer.
The Domain Guests group applies to the Windows Server operating system in Default
Attribute Value
Type Global
Default members Guest
Default member of Guests
recommend it

service admins?
Default user rights See Guests
Domain Users
The Domain Users group includes all user accounts in a domain. When you create a user
account in a domain, it's automatically added to this group.
By default, any user account that's created in the domain automatically becomes a
member of this group. You can use this group to represent all users in the domain. For
example, if you want all domain users to have access to a printer, you can assign
permissions for the printer to this group or add the Domain Users group to a Local
group on the print server that has permissions for the printer.
The Domain Users group applies to the Windows Server operating system in Default
Attribute Value
Type Global

DC=
Attribute Value
krbtgt

admins?
Default user rights See Users
Enterprise Admins
The Enterprise Admins group exists only in the root domain of an Active Directory forest
of domains. The group is a Universal group if the domain is in native mode. The group is
a Global group if the domain is in mixed mode. Members of this group are authorized
to make forest-wide changes in Active Directory, like adding child domains.
By default, the only member of the group is the Administrator account for the forest
root domain. This group is automatically added to the Administrators group in every
domain in the forest, and it provides complete access to configuring all domain
controllers. Members in this group can modify the membership of all administrative
groups. Members of the default service administrator groups in the root domain can
modify Enterprise Admins membership. This group is considered a service administrator
account.
The Enterprise Admins group applies to the Windows Server operating system in Default
Attribute Value
Well-known SID/RID S-1-5-21-<root domain>-519
Type Universal if domain is in native mode;

otherwise, Global

Attribute Value
Default member of Administrators

service admins?
Default user rights See Administrators
See Denied RODC Password Replication
Enterprise Key Admins

Members of this group can perform administrative actions on key objects within the
forest.
Attribute Value
Type Global

DC=

admins?

Members of this group are RODCs in the enterprise. Except for account passwords, an
RODC holds all the Active Directory objects and attributes that a writable domain
controller holds. However, changes can't be made to the database that's stored on the
RODC. Changes must be made on a writable domain controller and then replicated to
the RODC.
RODCs address some of the issues that are commonly found in branch offices. These
locations might not have a domain controller, or they might have a writable domain
controller but not the physical security, network bandwidth, or local expertise to support
it.
For more information, see What is a read-only domain controller?
The Enterprise Read-only Domain Controllers group applies to the Windows Server
Attribute Value
Type Universal

DC=

admins?
Event Log Readers

Members of this group can read event logs from local computers. The group is created
when the server is promoted to a domain controller.
The Event Log Readers group applies to the Windows Server operating system in
Attribute Value
Type Domain Local

Attribute Value

DC=

admins?

This group is authorized to create, edit, and delete Group Policy Objects in the domain.
By default, the only member of the group is Administrator.
For information about other features you can use with this security group, see Group
Policy overview.
The Group Policy Creator Owners group applies to the Windows Server operating
Attribute Value
Type Global

Replication
Safe to move out of default container? No

admins?
Attribute Value
Default user rights See Denied RODC Password

Replication
Guests
Members of the Guests group have the same access as members of the Users group by
default, except that the Guest account has further restrictions. By default, the only
member is the Guest account. The Guests group allows occasional or one-time users to
sign in with limited privileges to a computer’s built-in Guest account.
When a member of the Guests group signs out, the entire profile is deleted. The profile
deletion includes everything that's stored in the %userprofile% directory, including the
user's registry hive information, custom desktop icons, and other user-specific settings.
This fact implies that a guest must use a temporary profile to sign in to the system. This
security group interacts with the Group Policy setting. When this security group is
enabled, don't log on users that have temporary profiles. To access this setting, go to
Computer Configuration > Administrative Templates > System > User Profiles.
７ Note
A Guest account is a default member of the Guests security group. People who
don't have an actual account in the domain can use the Guest account. A user
whose account is disabled (but not deleted) can also use the Guest account. The
Guest account does not require a password. You can set rights and permissions for
the Guest account as in any user account. By default, the Guest account is a
member of the built-in Guests group and of the Domain Guests Global group,
which allows a user to sign in to a domain. The Guest account is disabled by
default, and we recommend that it stay disabled.
The Guests group applies to the Windows Server operating system in Default Active
Attribute Value
Type Builtin Local

DC=
Attribute Value
Default members Domain Guests

admins?
Hyper-V Administrators
Members of the Hyper-V Administrators group have complete and unrestricted access
to all the features in Hyper-V. Adding members to this group helps reduce the number
of members required in the Administrators group and further separates access.
７ Note
Before Windows Server 2012, access to features in Hyper-V was controlled in part
by membership in the Administrators group.
Attribute Value
Type Builtin Local

DC=

admins?

IIS_IUSRS
IIS_IUSRS is a built-in group that's used by Internet Information Services (IIS) beginning
with IIS 7. A built-in account and group are guaranteed by the operating system to
always have a unique SID. IIS 7 replaces the IUSR_MachineName account and the
IIS_WPG group with the IIS_IUSRS group to ensure that the actual names that the new
account and group use are never localized. For example, regardless of the language of
the Windows operating system that you install, the IIS account name will always be
IUSR, and the group name will be IIS_IUSRS.
For more information, see Understand built-in user and group accounts in IIS 7.
Attribute Value
Type Builtin Local

DC=
Default members IUSR

admins?
Incoming Forest Trust Builders

Members of the Incoming Forest Trust Builders group can create incoming, one-way
trusts to this forest. Active Directory provides security across multiple domains or forests
through domain and forest trust relationships. Before authentication can occur across
trusts, Windows must determine whether the domain being requested by a user,
computer, or service has a trust relationship with the logon domain of the requesting
account.
To make this determination, the Windows security system computes a trust path
between the domain controller for the server that receives the request and a domain
controller in the domain of the requesting account. A secured channel extends to other
Active Directory domains through interdomain trust relationships. This secured channel
is used to obtain and verify security information, including SIDs for users and groups.
This group appears as an SID until the domain controller is made the primary domain
controller and it holds the operations master (FSMO) role. This group can't be renamed,
deleted, or removed.
For more information, see How domain and forest trusts work: Domain and forest trusts.
The Incoming Forest Trust Builders group applies to the Windows Server operating
Attribute Value
Type Builtin Local

DC=

admins?
Key Admins
Members of this group can perform administrative actions on key objects within the
domain.
The Key Admins group applies to the Windows Server operating system in Default
Attribute Value
Type Global
Attribute Value

DC=

admins?
Network Configuration Operators

Members of the Network Configuration Operators group can have the following
administrative privileges to manage configuration of networking features:
Modify the Transmission Control Protocol/Internet Protocol (TCP/IP) properties for

a local area network (LAN) connection, which includes the IP address, the subnet
mask, the default gateway, and the name servers.
Rename the LAN connections or remote access connections that are available to all
the users.
Enable or disable a LAN connection.
Modify the properties of all remote access connections of users.
Delete all the remote access connections of users.
Rename all the remote access connections of users.
Issue ipconfig , ipconfig /release , and ipconfig /renew commands.
Enter the PIN unblock key (PUK) for mobile broadband devices that support a SIM
card.
The Network Configuration Operators group applies to the Windows Server operating
Attribute Value
Type Builtin Local

DC=
Safe to delegate management of this group to non-service Yes

admins?
Performance Log Users

Members of the Performance Log Users group can manage performance counters, logs,
and alerts locally on the server and from remote clients without being a member of the
Administrators group. Specifically, members of this security group:
Can use all the features that are available to the Performance Monitor Users group.
Can create and modify Data Collector Sets after the group is assigned the Log on
as a batch job user right.
２ Warning
If you're a member of the Performance Log Users group, you must configure
Data Collector Sets that you create to run under your credentials.
７ Note
In Windows Server 2016 and later, a member of the Performance Log Users
group can't create Data Collector Sets. If a member of the Performance Log
Users group tries to create Data Collector Sets, they can't complete the action
because access is denied.
Can't use the Windows Kernel Trace event provider in Data Collector Sets.
For members of the Performance Log Users group to initiate data logging or modify
Data Collector Sets, the group must first be assigned the Log on as a batch job user
right. To assign this user right, use the Local Security Policy snap-in in Microsoft
Management Console (MMC).
controller and it holds the operations master (FSMO) role. This account can't be
renamed, deleted, or moved.
The Performance Log Users group applies to the Windows Server operating system in
Attribute Value
Type Builtin Local

admins?
Default user rights Log on as a batch job:

SeBatchLogonRight
Performance Monitor Users

Members of this group can monitor performance counters on domain controllers in the
domain, locally and from remote clients, without being a member of the Administrators
or Performance Log Users groups. The Windows Performance Monitor is an MMC snap-
in that provides tools for analyzing system performance. From a single console, you can
monitor application and hardware performance, customize what data you want to
collect in logs, define thresholds for alerts and automatic actions, generate reports, and
view past performance data in various ways.
Specifically, members of this security group:
Can use all the features that are available to the Users group.
Can view real-time performance data in Performance Monitor.
Can change the Performance Monitor display properties while viewing data.
Can't create or modify Data Collector Sets.
２ Warning
Members of the Performance Monitor Users group can't configure Data Collection
Sets.
The Performance Monitor Users group applies to the Windows Server operating system
in Default Active Directory security groups.
Attribute Value
Type Builtin Local

DC=

admins?

Pre–Windows 2000 Compatible Access
Members of the Pre–Windows 2000 Compatible Access group have Read access for all
users and groups in the domain. This group is provided for backward compatibility for
computers running Windows NT 4.0 and earlier. By default, the special identity group
Everyone is a member of this group. Add users to this group only if they're running
Windows NT 4.0 or earlier.
２ Warning
This group appears as an SID until the domain controller is made the primary
domain controller and it holds the operations master (FSMO) role.
The Pre–Windows 2000 Compatible Access group applies to the Windows Server
Attribute Value
Type Builtin Local
Default members If you choose the Pre–Windows 2000 Compatible Permissions mode,
Everyone and Anonymous are members. If you choose the Windows
2000-only permissions mode, Authenticated Users are members.
Protected by No
AdminSDHolder?
Safe to move out of Can't be moved

default container?
Safe to delegate No
management of this
group to non-service
admins?
Print Operators
Members of this group can manage, create, share, and delete printers that are
connected to domain controllers in the domain. They also can manage Active Directory
printer objects in the domain. Members of this group can locally sign in to and shut
down domain controllers in the domain.
This group has no default members. Because members of this group can load and
unload device drivers on all domain controllers in the domain, add users with caution.
This group can't be renamed, deleted, or removed.
The Print Operators group applies to the Windows Server operating system in Default
For more information, see Assign delegated print administrator and printer permission
settings in Windows Server 2012.
Attribute Value
Type Builtin Local

service admins?

Load and unload device drivers:

SeLoadDriverPrivilege
Shut down the system:

SeShutdownPrivilege
Protected Users
Members of the Protected Users group have extra protection against the compromise of
credentials during authentication processes.
This security group is designed as part of a strategy to effectively protect and manage
credentials within the enterprise. Members of this group automatically have non-
configurable protection applied to their accounts. Membership in the Protected Users
group is meant to be restrictive and proactively secure by default. The only way you can
modify the protection for an account is to remove the account from the security group.
This domain-related, Global group triggers non-configurable protection on devices and

host computers, starting with the Windows Server 2012 R2 and Windows 8.1 operating
systems. It also triggers non-configurable protection on domain controllers in domains
that have a primary domain controller running Windows Server 2016 or Windows Server
2012 R2. This protection greatly reduces the memory footprint of credentials when users
sign in to computers on the network from a non-compromised computer.
Depending on the account’s domain functional level, members of the Protected Users
group are further protected due to behavior changes in the authentication methods that
are supported in Windows:
Members of the Protected Users group can't authenticate by using the following
Security Support Providers (SSPs): NTLM, Digest Authentication, or CredSSP.
Passwords aren't cached on a device running Windows 10 or Windows 8.1, so the
device fails to authenticate to a domain when the account is a member of the
Protected User group.
The Kerberos protocol won't use the weaker DES or RC4 encryption types in the
preauthentication process. The domain must be configured to support at least the
AES cipher suite.
The user’s account can't be delegated with Kerberos constrained or unconstrained

delegation. If the user is a member of the Protected Users group, earlier
connections to other systems might fail.
You can change the default Kerberos ticket-granting tickets (TGTs) lifetime setting
of four hours by using Authentication Policies and Silos in the Active Directory
Administrative Center. In the default setting, when four hours have passed, the
user must authenticate again.
The Protected Users group applies to the Windows Server operating system in Default
This group was introduced in Windows Server 2012 R2. For more information about how
this group works, see Protected Users security group.
The following table specifies the properties of the Protected Users group:
Attribute Value
Type Global

DC=

admins?
RAS and IAS Servers

Computers that are members of the RAS and IAS Servers group, when properly
configured, can use remote access services. By default, this group has no members.
Computers that are running the Routing and Remote Access Service (RRAS) and remote
access services like Internet Authentication Service (IAS) and Network Policy Servers are
added to the group automatically. Members of this group have access to certain
properties of User objects, such as Read Account Restrictions, Read Logon Information,
and Read Remote Access Information.
The RAS and IAS Servers group applies to the Windows Server operating system in
Attribute Value
Type Builtin Local

DC=

Attribute Value

admins?
RDS Endpoint Servers

Servers that are members in the RDS Endpoint Servers group can run virtual machines
and host sessions where user RemoteApp programs and personal virtual desktops run.
You must populate this group on servers running RD Connection Broker. Session Host
servers and RD Virtualization Host servers used in the deployment must be in this
group.
For information about Remote Desktop Services (RDS), see Host desktops and apps in
Remote Desktop Services.
Attribute Value
Type Builtin Local

DC=

admins?
RDS Management Servers

You can use servers that are members of the RDS Management Servers group to
complete routine administrative actions on servers running RDS. You must populate this
group on all servers in an RDS deployment. The servers running the RDS Central
Management service must be included in this group.
Attribute Value
Type Builtin Local

DC=

admins?
RDS Remote Access Servers

Servers in the RDS Remote Access Servers group provide users with access to
RemoteApp programs and personal virtual desktops. In internet-facing deployments,
these servers typically are deployed in an edge network. You must populate this group
on servers running RD Connection Broker. RD Gateway servers and RD Web Access
servers that are used in the deployment must be in this group.
For more information, see Host desktops and apps in Remote Desktop Services.
Attribute Value
Type Builtin Local

DC=

Attribute Value

admins?

This group is composed of the RODCs in the domain. An RODC makes it possible for
organizations to easily deploy a domain controller in scenarios in which physical security
can't be guaranteed, such as in branch office locations or when local storage of all
domain passwords is considered a primary threat, like in an extranet or application-
facing role.
Because you can delegate administration of an RODC to a domain user or security

group, an RODC is well suited for a site that shouldn't have a user who is a member of
the Domain Admins group. An RODC has the following functionality:
Contains read-only AD DS database
Unidirectional replication
Credential caching
Administrator role separation
Contains read-only Domain Name System (DNS)
For more information, see Understand planning and deployment for read-only domain
controllers.
Attribute Value
Type Global

Attribute Value

Replication

admins?
Default user rights See Denied RODC Password

Replication
Remote Desktop Users

Use the Remote Desktop Users group on an RD Session Host server to grant users and
groups permissions to remotely connect to an RD Session Host server. This group can't
be renamed, deleted, or removed. The group appears as an SID until the domain
controller is made the primary domain controller and it holds the operations master
(FSMO) role.
The Remote Desktop Users group applies to the Windows Server operating system in
Attribute Value
Type Builtin Local

DC=

admins?

Remote Management Users
Members of the Remote Management Users group can access Windows Management
Instrumentation (WMI) resources over management protocols like WS-Management via
the Windows Remote Management service. Access to WMI resources applies only to
WMI namespaces that grant access to the user.
Use the Remote Management Users group to allow users to manage servers through
the Server Manager console. Use the WinRMRemoteWMIUsers\_ group to allow users to
remotely run Windows PowerShell commands.
For more information, see What's new in MI? and About WMI.
Attribute Value
Type Builtin Local

DC=

admins?
Replicator
Computers that are members of the Replicator group support file replication in a
domain. Windows Server operating systems use the File Replication Service (FRS) to
replicate system policies and logon scripts that are stored in the System Volume folder
(sysvol folder). Each domain controller keeps a copy of the sysvol folder for network
clients to access. FRS can also replicate data for the Distributed File System (DFS) and
sync the content of each member in a replica set as defined by DFS. FRS can copy and
maintain shared files and folders on multiple servers simultaneously. When changes
occur, content is synced immediately within sites and on a schedule between sites.
２ Warning
In Windows Server 2008 R2, you can't use FRS to replicate DFS folders or custom
(non-sysvol) data. A Windows Server 2008 R2 domain controller can still use FRS to
replicate the contents of sysvol folder shared resource in a domain that uses FRS to
replicate the sysvol folder shared resource between domain controllers. However,
Windows Server 2008 R2 servers can't use FRS to replicate the contents of any
replica set except the sysvol folder shared resource. The DFS Replication service is a
replacement for FRS. You can use DFS Replication to replicate the contents of a
sysvol folder shared resource, DFS folders, and other custom (non-sysvol) data. You
should migrate all non-sysvol FRS replica sets to DFS Replication.
For more information, see:
File Replication Service (FRS) is deprecated in Windows Server 2008 R2 (Windows)

DFS namespaces and DFS Replication overview
Attribute Value
Type Builtin Local

DC=

admins?
Schema Admins
Members of the Schema Admins group can modify the Active Directory schema. This
group exists only in the root domain of an Active Directory forest of domains. This
group is a Universal group if the domain is in native mode. This group is a Global group
if the domain is in mixed mode.
The group is authorized to make schema changes in Active Directory. By default, the
only member of the group is the Administrator account for the forest root domain. This
group has full administrative access to the schema.
Any of the service administrator groups in the root domain can modify the membership
of this group. This group is considered a service administrator account because its
members can modify the schema, which governs the structure and content of the entire
directory.
For more information, see What is the Active Directory schema?
The Schema Admins group applies to the Windows Server operating system in Default
Attribute Value
Type Universal (if Domain is in Native-Mode)

else Global
Default member of Denied RODC Password Replication

service admins?
Default user rights See Denied RODC Password Replication
Server Operators
Members of the Server Operators group can administer domain controllers. This group
exists only on domain controllers. By default, the group has no members. Members of
the Server Operators group can take the following actions: sign in to a server
interactively, create and delete network shared resources, start and stop services, back
up and restore files, format the hard disk drive of the computer, and shut down the
computer. This group can't be renamed, deleted, or removed.
By default, this built-in group has no members. The group has access to server
configuration options on domain controllers. Its membership is controlled by the service
administrator groups Administrators and Domain Admins in the domain, and by the
Enterprise Admins group in the forest root domain. Members in this group can't change
any administrative group memberships. This group is considered a service administrator
account because its members have physical access to domain controllers. Members of
this group can perform maintenance tasks like backup and restore, and they can change
binaries that are installed on the domain controllers. See the group's default user rights
in the following table.
The Server Operators group applies to the Windows Server operating system in Default
Attribute Value
Type Builtin Local
Safe to delegate management of this group No

to non-service admins?
Default user rights Allow log on locally: SeInteractiveLogonRight
Back up files and directories: SeBackupPrivilege
Change the system time: SeSystemTimePrivilege
Force shutdown from a remote system:

SeRemoteShutdownPrivilege
Restore files and directories: Restore files and

directories SeRestorePrivilege
Shut down the system: SeShutdownPrivilege
Storage Replica Administrators

Members of the Storage Replica Administrators group have complete and unrestricted
access to all features of Storage Replica. The Storage Replica Administrators group
applies to the Windows Server operating system in Default Active Directory security
groups.
Attribute Value
Type Builtin Local

DC=

admins?
System Managed Accounts

Membership of the System Managed Accounts group is managed by the system.
The System Managed Accounts group applies to the Windows Server operating system
Attribute Value
Type Builtin Local

DC=
Default members Users
Attribute Value

admins?
Terminal Server License Servers

Members of the Terminal Server License Servers group can update user accounts in
Active Directory with information about license issuance. The group is used to track and
report TS Per User CAL usage. A TS Per User CAL gives one user the right to access an
instance of Terminal Server from an unlimited number of client computers or devices.
For more information about this security group, see Terminal Services License Server
security group configuration.
The Terminal Server License Servers group applies to the Windows Server operating
Attribute Value
Type Builtin Local

DC=

admins?

Users
Members of the Users group are prevented from making accidental or intentional
system-wide changes. Members of this group can run most applications. After the initial
installation of the operating system, the only member is the Authenticated Users group.
When a computer joins a domain, the Domain Users group is added to the Users group
on the computer.
Users can do tasks like run an application, use local and network printers, shut down the
computer, and lock the computer. Users can install applications that only they can use if
the installation program of the application supports per-user installation. This group
can't be renamed, deleted, or removed.
The Users group applies to the Windows Server operating system in Default Active
In Windows Server 2008 R2, Interactive was added to the default members list.
In Windows Server 2012, the default Member Of list changed from Domain Users
to none.
Attribute Value
Type Builtin Local

DC=
Default members Authenticated Users
Domain Users
Interactive

admins?

Windows Authorization Access
Members of this group have access to the computed token GroupsGlobalAndUniversal
attribute on User objects. Some applications have features that read the token-groups-
global-and-universal (TGGAU) attribute on user account objects or on computer account
objects in AD DS. Some Win32 functions make it easier to read the TGGAU attribute.
Applications that read this attribute or that call an API (a function) that reads this
attribute don't succeed if the calling security context doesn't have access to the
attribute. This group appears as an SID until the domain controller is made the primary
domain controller and it holds the operations master (FSMO) role. This group can't be
renamed, deleted, or removed.
The Windows Authorization Access group applies to the Windows Server operating
Attribute Value
Type Builtin Local

DC=
Default members Enterprise Domain Controllers

admins?
WinRMRemoteWMIUsers_
In Windows Server 2012 and Windows 8, a Share tab was added to the Advanced
Security Settings user interface. This tab displays the security properties of a remote file
share. To view this information, you must have the following permissions and
memberships, as appropriate for the version of Windows Server that the file server is
running.
The WinRMRemoteWMIUsers_ group applies to the Windows Server operating system
If the file share is hosted on a server that's running a supported version of the
operating system:
You must be a member of the WinRMRemoteWMIUsers__ group or the

BUILTIN\Administrators group.
You must have Read permissions to the file share.
If the file share is hosted on a server that's running a version of Windows Server
that's earlier than Windows Server 2012:
You must be a member of the BUILTIN\Administrators group.
You must have Read permissions to the file share.
In Windows Server 2012, the Access Denied Assistance functionality adds the
Authenticated Users group to the local WinRMRemoteWMIUsers__ group. When the
Access Denied Assistance functionality is enabled, all authenticated users who have
Read permissions to the file share can view the file share permissions.
７ Note
The WinRMRemoteWMIUsers__ group allows running Windows PowerShell

commands remotely. In contrast, you typically use the Remote Management Users
group to allow users to manage servers by using the Server Manager console.
Attribute Value

RI>
Type Domain local

Attribute Value

admins?
See also
Security principals

Service accounts
Article • 09/20/2022
A service account is a user account that's created explicitly to provide a security context
for services that are running on Windows Server operating systems. The security context
determines the service's ability to access local and network resources. Windows
operating systems rely on services to run various features. These services can be
configured through the applications, the Services snap-in, or Task Manager, or by using
Windows PowerShell.
This article contains information about the following types of service accounts:
Standalone managed service accounts

Group-managed service accounts
Virtual accounts
Standalone managed service accounts

Managed service accounts are designed to isolate domain accounts in crucial
applications, such as Internet Information Services (IIS). They eliminate the need for an
administrator to manually administer the service principal name (SPN) and credentials
for the accounts.
To use managed service accounts, the server on which the application or service is
installed must be running Windows Server 2008 R2 or later. One managed service
account can be used for services on a single computer. Managed service accounts can't
be shared between multiple computers, and they can't be used in server clusters where
a service is replicated on multiple cluster nodes. For this scenario, you must use a
group-managed service account. For more information, see Group-managed service
accounts overview.
In addition to the enhanced security that's provided by having individual accounts for
critical services, there are four important administrative benefits associated with
managed service accounts:
You can create a class of domain accounts that can be used to manage and
maintain services on local computers.
Unlike domain accounts in which administrators must manually reset passwords,
the network passwords for these accounts are automatically reset.
You don't have to complete complex SPN management tasks to use managed
service accounts.
You can delegate administrative tasks for managed service accounts to non-
administrators.
７ Note
Managed service accounts apply only to the Windows operating systems that are
listed in "Applies to" at the beginning of this article.
Group-managed service accounts

Group-managed service accounts are an extension of standalone managed service
accounts, which were introduced in Windows Server 2008 R2. These accounts are
managed domain accounts that provide automatic password management and
simplified SPN management, including delegation of management to other
administrators.
A group-managed service account provides the same functionality as a standalone

managed service account within the domain, but it extends that functionality over
multiple servers. When you're connecting to a service that's hosted on a server farm,
such as Network Load Balancing, the authentication protocols that support mutual
authentication require all instances of the services to use the same principal. When
group-managed service accounts are used as service principals, the Windows Server
operating system manages the password for the account instead of relying on the
administrator to manage the password.
The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely
obtain the latest key or a specific key with a key identifier for an Active Directory
account. This service was introduced in Windows Server 2012, and it doesn't run on
earlier versions of the Windows Server operating system. The Key Distribution Service
shares a secret, which is used to create keys for the account. These keys are periodically
changed. For a group-managed service account, the domain controller computes the
password on the key that's provided by the Key Distribution Service, in addition to other
attributes of the group-managed service account.
Group-managed practical applications

Group-managed service accounts provide a single identity solution for services that are
running on a server farm, or on systems that use Network Load Balancing. By providing
a group-managed service account solution, services can be configured for the group-
managed service account principal, and the password management is handled by the
operating system.
By using a group-managed service account, service administrators don't need to

manage password synchronization between service instances. The group-managed
service account supports hosts that are kept offline for an extended time period and the
management of member hosts for all instances of a service. This provision means that
you can deploy a server farm that supports a single identity to which existing client
computers can authenticate without knowing the instance of the service to which
they're connecting.
Failover clusters don't support group-managed service accounts. However, services that
run on top of the Cluster service can use a group-managed service account or a
standalone managed service account if they're a Windows service, an App pool, or a
scheduled task, or if they natively support group-managed service accounts or
standalone managed service accounts.
Group-managed software requirements

Group-managed service accounts can be configured and administered only on
computers that are running Windows Server 2012 or later. But the accounts can be
deployed as a single service identity solution in domains that still have domain
controllers that are running operating systems earlier than Windows Server 2012. There
are no domain or forest functional level requirements.
A 64-bit architecture is required to run the Windows PowerShell commands that are
used to administer group-managed service accounts.
A managed service account is dependent on encryption types that are supported by

Kerberos. When a client computer authenticates to a server by using the Kerberos
protocol, the domain controller creates a Kerberos service ticket that's protected with
encryption that the domain controller and the server support. The domain controller
uses the account’s msDS-SupportedEncryptionTypes attribute to determine what
encryption the server supports. If there is no attribute, it assumes that the client
computer doesn't support stronger encryption types. The Advanced Encryption
Standard (AES) must always be configured for managed service accounts. If computers
that host the managed service account are configured to not support RC4,
authentication will always fail.
７ Note
Introduced in Windows Server 2008 R2, the Data Encryption Standard (DES) is

disabled by default. Group-managed service accounts aren't applicable in Windows
operating systems earlier than Windows Server 2012.
For more information about supported encryption types, see Changes in Kerberos
Authentication.
Virtual accounts
Virtual accounts were introduced in Windows Server 2008 R2 and Windows 7. They are
managed local accounts that simplify service administration by providing the following
benefits:
The virtual account is automatically managed.

The virtual account can access the network in a domain environment.
No password management is required. For example, if the default value is used for
the service accounts during SQL Server setup on Windows Server 2008 R2, a virtual
account that uses the instance name as the service name is established in the
format NT SERVICE\<SERVICENAME>.
Services that run as virtual accounts access network resources by using the credentials
of the computer account in the format <domain_name>\<computer_name>$.
To learn how to configure and use virtual service accounts, see Service accounts step-
by-step guide.
７ Note
Virtual accounts apply only to the Windows operating systems that are listed in
"Applies to" at the beginning of this article.
See also
For other resources that are related to standalone managed service accounts, group-
managed service accounts, and virtual accounts, see:
Content References
type
Content References
type
Product What's new for managed service accounts
evaluation Get started with group-managed service accounts
Deployment Windows Server 2012: Group-managed service accounts - Ask Premier Field

Engineering (PFE) Platforms - Site Home - TechNet Blogs
Related Security principals
technologies What's new in Active Directory Domain Services

Microsoft accounts
Article • 09/20/2022
Understand how a Microsoft account works to enhance security and privacy for users
and how you can manage consumer account types in your organization.
What is a Microsoft account?

Microsoft sites, services, properties, and computers running Windows 10 can use a
Microsoft account as a way to identify a user. A Microsoft account previously was called
a Windows Live ID. A Microsoft account has user-defined secrets and consists of a
unique email address and a password.
When a user signs in with a Microsoft account, the device is connected to cloud services.
The user can share many of their settings, preferences, and apps across devices.
How a Microsoft account works

A user can use a Microsoft account to sign in to websites that support this service by
using a single set of credentials. A user's credentials are validated by a Microsoft
account authentication server that's associated with a website. Microsoft Store is an
example of this association. When a new user signs in to a website that's enabled to use
Microsoft accounts, the user is redirected to the nearest authentication server, which
asks for a username and password. Windows uses the Schannel Security Support
Provider to open a Transport Level Security/Secure Sockets Layer (TLS/SSL) connection
for this function. Users have the option to use Credential Manager to store their
credentials.
When a user signs in to a website that's enabled to use a Microsoft account, a time-
limited cookie is installed on their computer. The cookie includes a triple-DES encrypted
ID tag. The encrypted ID tag has been agreed upon between the authentication server
and the website. The ID tag is sent to the website, and the website places another time-
limited encrypted HTTP cookie on the user’s computer. While the cookie is valid, the
user isn't required to enter a username and password. If a user actively signs out of their
Microsoft account, these cookies are removed.
７ Note
Local Windows account functionality is still an option you can use in a managed
environment.
How a Microsoft account is created

To prevent fraud, the Microsoft system verifies a user's IP address when the user creates
a Microsoft account. A user who tries to create multiple Microsoft accounts by using the
same IP address is stopped from creating more accounts. Microsoft accounts aren't
designed to be created in batches, such as for a group of domain users in your
enterprise.
To create a Microsoft account, a user has two options:
Use an existing email address. The user can use their valid email address to sign
up for a Microsoft account. The service turns the requesting user's email address
into a Microsoft account. The user can choose a separate password to use for the
Microsoft account.
Sign up for a Microsoft email address. A user can sign up for an email account
through Microsoft webmail services. The user can use the account to sign in to
websites that are enabled to use Microsoft accounts.
How Microsoft account information is safeguarded

Credential information is encrypted twice. The first encryption is based on the account
password. Credentials are encrypted again when they're sent across the internet. The
credential data that's stored isn't available to other Microsoft services or to non-
Microsoft services.
A strong password is required. Blank passwords aren't allowed.
For more information, see How to help keep your Microsoft account safe and
secure .
Secondary proof of identity is required. Before a user can access user profile
information and settings on a second supported Windows computer for the first
time, trust must be established for that device. To establish trust, the user must
provide secondary proof of identity. The user can prove their identity by entering a
code that's sent to a mobile phone number or by following the instructions that
are sent to an alternate email address that a user specifies in the account settings.
All user profile data is encrypted on the client before it's transmitted to the
cloud. User data doesn't roam over a wireless wide area network by default so that
profile data is protected. All data and settings that leave a device are transmitted
through the TLS/SSL protocol.
Microsoft account security information

A user can add security information to their Microsoft account through the Accounts
interface on computers running supported versions of Windows. In Accounts, the user
can update the security information that they provided when they created their account.
This security information includes an alternate email address or phone number so that if
their password is compromised or forgotten, a verification code can be sent to verify
their identity. A user can potentially use their Microsoft account to store corporate data
on a personal OneDrive or email app. A safe practice is for the account owner to keep
this security information up-to-date.
Microsoft accounts in the enterprise

Although the Microsoft account was designed to serve consumers, you might have
situations in which your domain users might benefit by using their personal Microsoft
account in your enterprise. The following list describes some advantages:
Download Microsoft Store apps. If your enterprise chooses to distribute apps or

software through Microsoft Store, an enterprise user can use a Microsoft account
to download and use the apps on up to five devices running any version of
Windows 10, Windows 8.1, Windows 8, or Windows RT.
Single sign-on. An enterprise user can use Microsoft account credentials to sign in
to devices running Windows 10, Windows 8.1, Windows 8, or Windows RT. In this
scenario, Windows works with your Microsoft Store app to provide an
authenticated experience in the app. A user can associate a Microsoft account with
their sign-in credentials for Microsoft Store apps or websites so that these
credentials roam across any devices that run these supported versions.
Personalized settings synchronization. A user can associate their most commonly

used operating system settings with a Microsoft account. These settings are
available whenever a user signs in with that account on any device that's running a
supported version of Windows and connected to the cloud. After a user signs in,
the device automatically attempts to get the user's settings from the cloud and
apply them to the device.
App synchronization. Microsoft Store apps can store user-specific settings so that
these settings are available to any device. As with operating system settings, these
user-specific app settings are available whenever the user signs in with the same
Microsoft account on any device that's running a supported version of Windows
and connected to the cloud. After the user signs in, that device automatically
downloads the settings from the cloud and applies them when the app is installed.
Integrated social media services. Contact information and status for a user's
friends and associates automatically stay up-to-date from sites such as Outlook,
Facebook, Twitter, and LinkedIn. A user also can access and share photos,
documents, and other files from sites like OneDrive, Facebook, and Flickr.
Manage Microsoft accounts in the domain

Depending on your IT and business models, introducing Microsoft accounts into your
enterprise might add complexity or it might provide solutions. You should address the
following considerations before you allow the use of these account types in your
enterprise:
Restrict the use of Microsoft accounts
Configure connected accounts
Provision Microsoft accounts in the enterprise
Audit account activity
Reset a password
Restrict app installation and usage
Restrict the use of Microsoft accounts

The following Group Policy settings help control the use of Microsoft accounts in the
enterprise:
Apps and services: Block Microsoft account user authentication
Accounts: Block Microsoft accounts
Apps and services: Block Microsoft account user authentication

This setting controls whether a user can provide a Microsoft account for authentication
for an app or service.
If this setting is enabled, all apps and services on a device are prevented from using a
Microsoft account for authentication. This setting applies both to existing device users
and to any new users.
Any app or service that has already authenticated a user who used a Microsoft account
isn't affected by enabling this setting until the authentication cache expires. We
recommend that you enable this setting before any user signs in to a device to prevent
cached tokens from authenticating a Microsoft account.
If this setting is disabled or not configured, apps and services can use a Microsoft
account for authentication. This setting is disabled by default.
This setting doesn't affect whether a user can sign in to a device by using a Microsoft
account or the ability of a user to provide a Microsoft account via the browser for
authentication with a web-based app.
The path to this setting is Computer Configuration\Administrative Templates\Windows

Components\Microsoft account.
Accounts: Block Microsoft accounts
This setting prevents using the Settings app to add a Microsoft account for single sign-
on authentication for Microsoft services and some background services or using a
Microsoft account for single sign-on to other apps or services.
If this setting is enabled, a user has two options:
The user can't add a Microsoft account. Existing connected accounts can still sign
in to the device (and they appear on the Sign in page). However, a user can't use
the Settings app to add a new connected account or to connect a local account to
a Microsoft account.
The user can’t add or sign in with a Microsoft account. A user can't add a new
connected account (or connect a local account to a Microsoft account) or use an
existing connected account through Settings.
This setting doesn't affect adding a Microsoft account for app authentication. For
example, if this setting is enabled, a user can still provide a Microsoft account for
authentication with an app like Mail, but the user can't use the Microsoft account for
single sign-on authentication for other apps or services. For other apps and services, the
user is prompted to authenticate.
This setting isn't configured by default.

The path to this setting is Computer Configuration\Windows Settings\Security
Settings\Local Policies\Security Options.
Configure connected accounts

A user can connect a Microsoft account to their domain account and sync the settings
and preferences between the accounts. By syncing settings and preferences between
accounts, the user sees the same desktop background, app settings, browser history and
favorites, and other Microsoft account settings on their other devices.
Disconnect a connected account

A user can disconnect a Microsoft account from their domain account at any time: In PC
settings, select Users > Disconnect > Finish.
７ Note
Connecting a Microsoft account to a domain account might limit access to some

high-privileged tasks in Windows. For example, Task Scheduler evaluates the
connected Microsoft account for access and fails. In this scenario, the account
owner should disconnect the account.
Provision Microsoft accounts in the enterprise

A Microsoft account is a private user account. Microsoft doesn't provide a way to
provision Microsoft accounts for an enterprise. Enterprises should use domain accounts.
Audit account activity

Because a Microsoft account is internet-based, Windows doesn't have a way to audit a
Microsoft account unless the account is associated with a domain account. You can't
audit the activity of accounts that aren't associated with your domain because a user can
disconnect the account or leave the domain at any time.
Reset a password
Only the owner of a Microsoft account can change the password that's associated with
the account. A user can change the password for their Microsoft account in the
Microsoft account sign-in portal .
Restrict app installation and usage
Within your organization, you can set application control policies to regulate app
installation and usage for Microsoft accounts. For more information, see AppLocker and
Packaged apps and packaged app installer rules in AppLocker.
See also
Manage privacy: Using a Microsoft account to sign in and resulting internet
communication

Security principals
Article • 09/20/2022
This reference article describes security principals for Windows accounts and security
groups, in addition to security technologies that are related to security principals.
What are security principals?

A security principal is any entity that can be authenticated by the operating system, such
as a user account, a computer account, or a thread or process that runs in the security
context of a user or computer account, or the security groups for these accounts.
Security principals have long been a foundation for controlling access to securable
resources on Windows computers. Each security principal is represented in the
operating system by a unique security identifier (SID).
７ Note
This content pertains only to the Windows versions in the "Applies to" list at the
beginning of the article.
How security principals work

Security principals that are created in an Active Directory domain are Active Directory
objects, which can be used to manage access to domain resources. Each security
principal is assigned a unique identifier, which it retains for its entire lifetime. Local user
accounts and security groups are created on a local computer, and they can be used to
manage access to resources on that computer. Local user accounts and security groups
are managed by the Security Accounts Manager (SAM) on the local computer.
Authorization and access control components

The following diagram illustrates the Windows authorization and access control process.
In the diagram, the subject (a process that's initiated by a user) attempts to access an
object, such as a shared folder. The information in the user’s access token is compared
to the access control entries (ACEs) in the object’s security descriptor, and the access
decision is made. The SIDs of security principals are used in the user’s access token and
in the ACEs in the object’s security descriptor.
Authorization and access control process
Security principals are closely related to the following components and technologies:
Security identifiers
Access tokens
Security descriptors and access control lists
Permissions
Security identifiers (SIDs) provide a fundamental building block of the Windows security
model. They work with specific components of the authorization and access control
technologies in the security infrastructure of the Windows Server operating systems.
This helps protect access to network resources and provides a more secure computing
environment.
A SID is a value of variable length that's used to uniquely identify a security principal
that represents any entity that can be authenticated by the system. These entities
include a user account, a computer account, or a thread or process that runs in the
security context of a user or computer account. Each security principal is automatically
assigned a SID when it's created. The SID is stored in a security database. When a SID is
used as the unique identifier for a user or group, it can never be used to identify another
user or group.
Each time a user signs in, the system creates an access token for that user. The access
token contains the user’s SID, user rights, and the SIDs for groups that the user belongs
to. This token provides the security context for whatever actions the user performs on
that computer.
In addition to the uniquely created, domain-specific SIDs that are assigned to specific
users and groups, there are well-known SIDs that identify generic groups and generic
users. For example, the Everyone and World SIDs identify groups that include all users.
Well-known SIDs have values that remain constant across all operating systems.
Access tokens
An access token is a protected object that contains information about the identity and
user rights that are associated with a user account.
When a user signs in interactively or tries to make a network connection to a computer

running Windows, the sign-in process authenticates the user’s credentials. If
authentication is successful, the process returns a SID for the user and a list of SIDs for
the user’s security groups. The Local Security Authority (LSA) on the computer uses this
information to create an access token (in this case, the primary access token). This
includes the SIDs that are returned by the sign-in process and a list of user rights that
are assigned by the local security policy to the user and to the user’s security groups.
After the LSA creates the primary access token, a copy of the access token is attached to
every thread and process that executes on the user’s behalf. Whenever a thread or
process interacts with a securable object or tries to perform a system task that requires
user rights, the operating system checks the access token that's associated with the
thread to determine the level of authorization.
There are two kinds of access tokens, primary and impersonation. Every process has a
primary token that describes the security context of the user account that's associated
with the process. A primary access token is typically assigned to a process to represent
the default security information for that process. Impersonation tokens, on the other
hand, are used for client and server scenarios. Impersonation tokens enable a thread to
run in a security context that differs from the security context of the process that owns
the thread.
Security descriptors and access control lists

A security descriptor is a data structure that's associated with each securable object. All
objects in Active Directory and all securable objects on a local computer or on the
network have security descriptors to help control access to the objects. Security
descriptors include information about who owns an object, who can access it and in
what way, and what types of access are audited. Security descriptors contain the access
control list (ACL) of an object, which includes all the security permissions that apply to
that object. An object’s security descriptor can contain two types of ACLs:
A discretionary access control list (DACL), which identifies the users and groups
who are allowed or denied access.
A system access control list (SACL), which controls how access is audited.
You can use this access control model to individually secure objects and attributes such
as files and folders, Active Directory objects, registry keys, printers, devices, ports,
services, processes, and threads. Because of this individual control, you can adjust the
security of objects to meet the needs of your organization, delegate authority over
objects or attributes, and create custom objects or attributes that require unique
security protections to be defined.
Permissions
Permissions enable the owner of each securable object, such as a file, Active Directory
object, or registry key, to control who can perform an operation or a set of operations
on the object or object property. Permissions are expressed in the security architecture
as ACEs. Because access to an object is at the discretion of the object’s owner, the type
of access control that's used in Windows is called discretionary access control.
Permissions are different from user rights in that permissions are attached to objects,
and user rights apply to user accounts. Administrators can assign user rights to groups
or users. These rights authorize users to perform specific actions, such as signing in to a
system interactively or backing up files and directories.
On computers, user rights enable administrators to control who has the authority to
perform operations that affect an entire computer, rather than a particular object.
Administrators assign user rights to individual users or groups as part of the security
settings for the computer. Although user rights can be managed centrally through
Group Policy, they are applied locally. Users can (and usually do) have different user
rights on different computers.
For information about which user rights are available and how they can be
implemented, see User Rights Assignment.
Security context in authentication

A user account enables a user to sign in to computers, networks, and domains with an
identity that can be authenticated by the computer, network, or domain.
In Windows, any user, service, group, or computer that can initiate action is a security
principal. Security principals have accounts, which can be local to a computer or
domain-based. For example, domain-joined Windows client computers can participate
in a network domain by communicating with a domain controller, even when no user is
signed in.
To initiate communications, the computer must have an active account in the domain.
Before accepting communications from the computer, the Local Security Authority on
the domain controller authenticates the computer’s identity and then defines the
computer’s security context just as it would for a user’s security principal.
This security context defines the identity and capabilities of a user or service on a
particular computer, or of a user, service, group or computer on a network. For example,
it defines the resources (such as a file share or printer) that can be accessed and the
actions (such as Read, Write, or Modify) that can be performed by a user, service, or
computer on that resource.
The security context of a user or computer can vary from one computer to another, such
as when a user authenticates to a server or a workstation other than the user’s primary
workstation. It can also vary from one session to another, such as when an administrator
modifies the user’s rights and permissions. In addition, the security context is different
when a user or computer is operating on a standalone basis, in a mixed network
domain, or as part of an Active Directory domain.
Accounts and security groups

Accounts and security groups that are created in an Active Directory domain are stored
in the Active Directory database and managed by using Active Directory tools. These
security principals are directory objects, and they can be used to manage access to
domain resources.
Local user accounts and security groups are created on a local computer, and they can
be used to manage access to resources on that computer. Local user accounts and
security groups are stored in and managed by the Security Accounts Manager (SAM) on
the local computer.
User accounts
A user account uniquely identifies a person who is using a computer system. The
account signals the system to enforce the appropriate authorization to allow or deny
that user access to resources. User accounts can be created in Active Directory and on
local computers, and administrators use them to:
Represent, identify, and authenticate the identity of a user. A user account enables
a user to sign in to computers, networks, and domains with a unique identifier that
can be authenticated by the computer, network, or domain.
Authorize (grant or deny) access to resources. After a user has been authenticated,
the user is authorized access to resources based on the permissions that are
assigned to that user for the resource.
Audit the actions that are carried out on a user account.
Windows and the Windows Server operating systems have built-in user accounts, or you
can create user accounts to meet the requirements of your organization.
Security groups
A security group is a collection of user accounts, computer accounts, and other groups
of accounts that can be managed as a single unit from a security perspective. In
Windows operating systems, there are several built-in security groups that are
preconfigured with the appropriate rights and permissions for performing specific tasks.
Additionally, you can (and usually will) create a security group for each unique
combination of security requirements that applies to multiple users in your organization.
Groups can be Active Directory-based or local to a particular computer:
Active Directory security groups are used to manage rights and permissions to

domain resources.
Local groups exist in the SAM database on local computers (on all Windows-based
computers) except domain controllers. You use local groups to manage rights and
permissions only to resources on the local computer.
By using security groups to manage access control, you can:
Simplify administration. You can assign a common set of rights, a common set of
permissions, or both to many accounts at one time, rather than assigning them to
each account individually. Also, when users transfer jobs or leave the organization,
permissions aren't tied to their user accounts, making permission reassignment or
removal easier.
Implement a role-based access control model. You can use this model to grant
permissions by using groups with different scopes for appropriate purposes.
Scopes that are available in Windows include local, global, domain local, and
universal.
Minimize the size of ACLs and speed security checking. A security group has its
own SID; therefore, the group SID can be used to specify permissions for a
resource. In an environment with more than a few thousand users, if the SIDs of
individual user accounts are used to specify access to a resource, the ACL of that
resource can become unmanageably large, and the time that's needed for the
system to check permissions to the resource can become unacceptable.
For descriptions and settings information about the domain security groups that are
defined in Active Directory, see Active Directory security groups.
For descriptions and settings information about special identities, see Special identity
groups.
See also
Article • 05/09/2023
This article describes how security identifiers (SIDs) work with accounts and groups in the Windows Server operating system.
What are security identifiers?

A security identifier is used to uniquely identify a security principal or security group. Security principals can represent any entity that can
be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security
context of a user or computer account.
Each account or group, or each process that runs in the security context of the account, has a unique SID that's issued by an authority,
such as a Windows domain controller. The SID is stored in a security database. The system generates the SID that identifies a particular
account or group at the time the account or group is created. When a SID has been used as the unique identifier for a user or group, it can
never be used again to identify another user or group.
Each time a user signs in, the system creates an access token for that user. The access token contains the user's SID, user rights, and the
SIDs for any groups the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
In addition to the uniquely created domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that
identify generic groups and generic users. For example, the Everyone and World SIDs identify a group that includes all users. Well-known
SIDs have values that remain constant across all operating systems.
SIDs are a fundamental building block of the Windows security model. They work with specific components of the authorization and
access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network
resources and provides a more secure computing environment.
７ Note
This content pertains only to the Windows versions in the "Applies to" list at the beginning of the article.
How security identifiers work

Users refer to accounts by the account name, but the operating system internally refers to accounts and processes that run in the security
context of the account by using their SIDs. For domain accounts, the SID of a security principal is created by concatenating the SID of the
domain with a relative identifier (RID) for the account. SIDs are unique within their scope (domain or local), and they're never reused.
The operating system generates a SID that identifies a particular account or group at the time the account or group is created. The SID for
a local account or group is generated by the Local Security Authority (LSA) on the computer, and it's stored with other account
information in a secure area of the registry. The SID for a domain account or group is generated by the domain security authority, and it's
stored as an attribute of the User or Group object in Active Directory Domain Services.
For every local account and group, the SID is unique for the computer where it was created. No two accounts or groups on the computer
ever share the same SID. Likewise, for every domain account and group, the SID is unique within an enterprise. This means that the SID for
an account or group that's created in one domain will never match the SID for an account or group created in any other domain in the
enterprise.
SIDs always remain unique. Security authorities never issue the same SID twice, and they never reuse SIDs for deleted accounts. For
example, if a user with a user account in a Windows domain leaves their job, an administrator deletes their Active Directory account,
including the SID that identifies the account. If they later return to a different job at the same company, an administrator creates a new
account, and the Windows Server operating system generates a new SID. The new SID doesn't match the old one, so none of the user's
access from their old account is transferred to the new account. Both their accounts represent two different security principals.
Security identifier architecture

A security identifier is a data structure in binary format that contains a variable number of values. The first values in the structure contain
information about the SID structure. The remaining values are arranged in a hierarchy (similar to a telephone number), and they identify
the SID-issuing authority (for example, “NT Authority”), the SID-issuing domain, and a particular security principal or group. The following
image illustrates the structure of a SID.
The individual values of a SID are described in the following table:
Comment Description
Revision Indicates the version of the SID structure that's used in a particular SID.
Identifier Identifies the highest level of authority that can issue SIDs for a particular type of security principal. For example, the identifier authority
authority value in the SID for the Everyone group is 1 (World Authority). The identifier authority value in the SID for a specific Windows Server
account or group is 5 (NT Authority).
Subauthorities Holds the most important information in a SID, which is contained in a series of one or more subauthority values. All values up to, but not
including, the last value in the series collectively identify a domain in an enterprise. This part of the series is called the domain identifier.
The last value in the series, which is called the relative identifier (RID), identifies a particular account or group relative to a domain.
The components of a SID are easier to visualize when SIDs are converted from a binary to a string format by using standard notation:
S-R-X-Y1-Y2-Yn-1-Yn
In this notation, the components of a SID are described in the following table:
Comment Description
S Indicates that the string is a SID
R Indicates the revision level
X Indicates the identifier authority value
Y Represents a series of subauthority values, where n is the number of values
The SID's most important information is contained in the series of subauthority values. The first part of the series (-Y1-Y2-Yn-1) is the
domain identifier. This element of the SID becomes significant in an enterprise with several domains, because the domain identifier
differentiates SIDs that are issued by one domain from SIDs that are issued by all other domains in the enterprise. No two domains in an
enterprise share the same domain identifier.
The last item in the series of subauthority values (-Yn) is the relative identifier. It distinguishes one account or group from all other
accounts and groups in the domain. No two accounts or groups in any domain share the same relative identifier.
For example, the SID for the built-in Administrators group is represented in standardized SID notation as the following string:
S-1-5-32-544
This SID has four components:
A revision level (1)

An identifier authority value (5, NT Authority)
A domain identifier (32, Builtin)
A relative identifier (544, Administrators)
SIDs for built-in accounts and groups always have the same domain identifier value, 32. This value identifies the domain, Builtin, which
exists on every computer that's running a version of the Windows Server operating system. It's never necessary to distinguish one
computer's built-in accounts and groups from another computer's built-in accounts and groups, because they're local in scope. They're
local to a single computer or, in the case of domain controllers for a network domain, they're local to several computers that are acting as
one.
Built-in accounts and groups need to be distinguished from one another within the scope of the Builtin domain. Therefore, the SID for
each account and group has a unique relative identifier. A relative identifier value of 544 is unique to the built-in Administrators group. No
other account or group in the Builtin domain has a SID with a final value of 544.
In another example, consider the SID for the global group, Domain Admins. Every domain in an enterprise has a Domain Admins group,
and the SID for each group is different. The following example represents the SID for the Domain Admins group in the Contoso, Ltd.
domain (Contoso\Domain Admins):
S-1-5-21-1004336348-1177238915-682003330-512
The SID for Contoso\Domain Admins has:
A revision level (1)

An identifier authority (5, NT Authority)
A domain identifier (21-1004336348-1177238915-682003330, Contoso)
A relative identifier (512, Domain Admins)
The SID for Contoso\Domain Admins is distinguished from the SIDs for other Domain Admins groups in the same enterprise by its domain
identifier: 21-1004336348-1177238915-682003330. No other domain in the enterprise uses this value as its domain identifier. The SID for
Contoso\Domain Admins is distinguished from the SIDs for other accounts and groups that are created in the Contoso domain by its
relative identifier, 512. No other account or group in the domain has a SID with a final value of 512.
Relative identifier allocation

When accounts and groups are stored in an account database that's managed by a local Security Accounts Manager (SAM), it's fairly easy
for the system to generate a unique relative identifier for each account and in a group that it creates on a standalone computer. The SAM
on a standalone computer can track the relative identifier values that it has used before and make sure that it never uses them again.
In a network domain, however, generating unique relative identifiers is a more complex process. Windows Server network domains can
have several domain controllers. Each domain controller stores Active Directory account information. This means that, in a network
domain, there are as many copies of the account database as there are domain controllers. In addition, every copy of the account
database is a master copy.
New accounts and groups can be created on any domain controller. Changes that are made to Active Directory on one domain controller
are replicated to all other domain controllers in the domain. The process of replicating changes in one master copy of the account
database to all other master copies is called a multimaster operation.
The process of generating unique relative identifiers is a single-master operation. One domain controller is assigned the role of RID
master, and it allocates a sequence of relative identifiers to each domain controller in the domain. When a new domain account or group
is created in one domain controller's replica of Active Directory, it's assigned a SID. The relative identifier for the new SID is taken from the
domain controller's allocation of relative identifiers. When its supply of relative identifiers begins to run low, the domain controller
requests another block from the RID master.
Each domain controller uses each value in a block of relative identifiers only once. The RID master allocates each block of relative identifier
values only once. This process assures that every account and group created in the domain has a unique relative identifier.
Security identifiers and globally unique identifiers

When a new domain user or group account is created, Active Directory stores the account's SID in the ObjectSID property of a User or
Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that's unique not only in the
enterprise, but also across the world. GUIDs are assigned to every object that's created by Active Directory and not only in User and Group
objects. Each object's GUID is stored in its ObjectGUID property.
Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that's published in the
global catalog. Searching the global catalog for a User object GUID produces results if the user has an account somewhere in the
enterprise. In fact, searching for any object by ObjectGUID might be the most reliable way of finding the object you want to locate. The
values of other object properties can change, but the ObjectGUID property never changes. When an object is assigned a GUID, it keeps
that value for life.
If a user moves from one domain to another, the user gets a new SID. The SID for a group object doesn't change, because groups stay in
the domain where they were created. However, if people move, their accounts can move with them. If an employee moves from North
America to Europe, but stays in the same company, an administrator for the enterprise can move the employee's User object from, for
example, Contoso\NoAm to Contoso\Europe. If the administrator does this, the User object for the account needs a new SID. The domain
identifier portion of a SID that's issued in NoAm is unique to NoAm, so the SID for the user's account in Europe has a different domain
identifier. The relative identifier portion of a SID is unique relative to the domain, so if the domain changes, the relative identifier also
changes.
When a User object moves from one domain to another, a new SID must be generated for the user account and stored in the ObjectSID
property. Before the new value is written to the property, the previous value is copied to another property of a User object, SIDHistory .
This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the
ObjectSID property, and another value is added to the list of old SIDs in SIDHistory . When a user signs in and is successfully
authenticated, the domain authentication service queries Active Directory for all the SIDs that are associated with the user, including the
user's current SID, the user's old SIDs, and the SIDs for the user's groups. All these SIDs are returned to the authentication client, and
they're included in the user's access token. When the user tries to gain access to a resource, any one of the SIDs in the access token
(including one of the SIDs in SIDHistory ), can allow or deny the user access.
If you allow or deny users' access to a resource based on their jobs, you should allow or deny access to a group, not to an individual. That
way, when users change jobs or move to other departments, you can easily adjust their access by removing them from certain groups and
adding them to others.
However, if you allow or deny an individual user access to resources, you probably want that user's access to remain the same no matter
how many times the user's account domain changes. The SIDHistory property makes this possible. When a user changes domains, there's
no need to change the access control list (ACL) on any resource. If an ACL has the user's old SID, but not the new one, the old SID is still in
the user's access token. It's listed among the SIDs for the user's groups, and the user is granted or denied access based on the old SID.
Well-known SIDs
The values of certain SIDs are constant across all systems. They're created when the operating system or domain is installed. They're called
well-known SIDs because they identify generic users or generic groups.
There are universal well-known SIDs that are meaningful on all secure systems that use this security model, including operating systems
other than Windows. In addition, there are well-known SIDs that are meaningful only on Windows operating systems.
The universal well-known SIDs are listed in the following table:
Value Universal Identifies

well-known
SID
S-1- Null SID A group with no members. This is often used when a SID value isn't known.
0-0
S-1- World A group that includes all users.

1-0
S-1- Local Users who sign in to terminals that are locally (physically) connected to the system.
2-0
S-1- Console Logon A group that includes users who are signed in to the physical console.
2-1
S-1- Creator Owner A security identifier to be replaced by the security identifier of the user who created a new object. This SID is used in inheritable
3-0 ID access control entries (ACEs).
S-1- Creator Group A security identifier to be replaced by the primary-group SID of the user who created a new object. Use this SID in inheritable
3-1 ID ACEs.
S-1- Owner Server A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the object's owner
3-2 server and stores information about who created a given object or file.
S-1- Group Server A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the object's group
3-3 server and stores information about the groups that are allowed to work with the object.
S-1- Owner Rights A group that represents the current owner of the object. When an ACE that carries this SID is applied to an object, the system
3-4 ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner.
S-1-4 Non-unique A SID that represents an identifier authority.

Authority
Value Universal Identifies
well-known
SID
S-1-5 NT Authority A SID that represents an identifier authority.
S-1- All Services A group that includes all service processes configured on the system. Membership is controlled by the operating system.
5-80-
0
The following table lists the predefined identifier authority constants. The first four values are used with universal well-known SIDs, and the
rest of the values are used with well-known SIDs in the Windows operating systems in the "Applies to" list at the beginning of the article.
Identifier authority Value SID string prefix
SECURITY_NULL_SID_AUTHORITY 0 S-1-0
SECURITY_WORLD_SID_AUTHORITY 1 S-1-1
SECURITY_LOCAL_SID_AUTHORITY 2 S-1-2
SECURITY_CREATOR_SID_AUTHORITY 3 S-1-3
SECURITY_NT_AUTHORITY 5 S-1-5
SECURITY_AUTHENTICATION_AUTHORITY 18 S-1-18
The following RID values are used with universal well-known SIDs. The Identifier authority column shows the prefix of the identifier
authority with which you can combine the RID to create a universal well-known SID.
Relative identifier authority Value Identifier authority
SECURITY_NULL_RID 0 S-1-0
SECURITY_WORLD_RID 0 S-1-1
SECURITY_LOCAL_RID 0 S-1-2
SECURITY_CREATOR_OWNER_RID 0 S-1-3
SECURITY_CREATOR_GROUP_RID 1 S-1-3
The SECURITY_NT_AUTHORITY (S-1-5) predefined identifier authority produces SIDs that aren't universal and are meaningful only in
installations of the Windows operating systems in the "Applies to" list at the beginning of this article.
The well-known SIDs are listed in the following table:
SID Display name Description
S-1-5-1 Dialup A group that includes all users who are signed in to the system via dial-up connection.
S-1-5-113 Local account You can use this SID when you're restricting network sign-in to local accounts instead of "administrator" or
equivalent. This SID can be effective in blocking network sign-in for local users and groups by account type
regardless of what they're named.
S-1-5-114 Local account and You can use this SID when you're restricting network sign-in to local accounts instead of "administrator" or
member of equivalent. This SID can be effective in blocking network sign-in for local users and groups by account type
Administrators group regardless of what they're named.
S-1-5-2 Network A group that includes all users who are signed in via a network connection. Access tokens for interactive users
don't contain the Network SID.
S-1-5-3 Batch A group that includes all users who have signed in via batch queue facility, such as task scheduler jobs.
S-1-5-4 Interactive A group that includes all users who sign in interactively. A user can start an interactive sign-in session by opening
a Remote Desktop Services connection from a remote computer, or by using a remote shell such as Telnet. In each
case, the user's access token contains the Interactive SID. If the user signs in by using a Remote Desktop Services
connection, the user's access token also contains the Remote Interactive Logon SID.
S-1-5-5- X-Y Logon Session The X and Y values for these SIDs uniquely identify a particular sign-in session.
S-1-5-6 Service A group that includes all security principals that have signed in as a service.
S-1-5-7 Anonymous Logon A user who has connected to the computer without supplying a user name and password.
The Anonymous Logon identity is different from the identity that's used by Internet Information Services (IIS) for
anonymous web access. IIS uses an actual account—by default, IUSR_ComputerName, for anonymous access to
resources on a website. Strictly speaking, such access isn't anonymous, because the security principal is known
even though unidentified people are using the account. IUSR_ComputerName (or whatever you name the account)
has a password, and IIS signs in to the account when the service starts. As a result, the IIS "anonymous" user is a
member of Authenticated Users but Anonymous Logon isn't.
S-1-5-8 Proxy Doesn't currently apply: this SID isn't used.
S-1-5-9 Enterprise Domain A group that includes all domain controllers in a forest of domains.
Controllers
S-1-5-10 Self A placeholder in an ACE for a user, group, or computer object in Active Directory. When you grant permissions to
Self, you grant them to the security principal that's represented by the object. During an access check, the
operating system replaces the SID for Self with the SID for the security principal that's represented by the object.
S-1-5-11 Authenticated Users A group that includes all users and computers with identities that have been authenticated. Authenticated Users
doesn't include Guest even if the Guest account has a password.
This group includes authenticated security principals from any trusted domain, not only the current domain.
S-1-5-12 Restricted Code An identity that's used by a process that's running in a restricted security context. In Windows and Windows Server
operating systems, a software restriction policy can assign one of three security levels to code:
Unrestricted
Restricted
Disallowed
When code runs at the restricted security level, the Restricted SID is added to the user's access token.
S-1-5-13 Terminal Server User A group that includes all users who sign in to a server with Remote Desktop Services enabled.
S-1-5-14 Remote Interactive A group that includes all users who sign in to the computer by using a remote desktop connection. This group is a
Logon subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the
Interactive SID.
S-1-5-15 This Organization A group that includes all users from the same organization. Included only with Active Directory accounts and
added only by a domain controller.
S-1-5-17 IUSR An account that's used by the default Internet Information Services (IIS) user.
S-1-5-18 System (or An identity that's used locally by the operating system and by services that are configured to sign in as
LocalSystem) LocalSystem.
System is a hidden member of Administrators. That is, any process running as System has the SID for the built-in
Administrators group in its access token.
When a process that's running locally as System accesses network resources, it does so by using the computer's
domain identity. Its access token on the remote computer includes the SID for the local computer's domain
account plus SIDs for security groups that the computer is a member of, such as Domain Computers and
Authenticated Users.
S-1-5-19 NT Authority An identity that's used by services that are local to the computer, have no need for extensive local access, and
(LocalService) don't need authenticated network access. Services that run as LocalService access local resources as ordinary
users, and they access network resources as anonymous users. As a result, a service that runs as LocalService has
significantly less authority than a service that runs as LocalSystem locally and on the network.
S-1-5-20 Network Service An identity that's used by services that have no need for extensive local access but do need authenticated network
access. Services running as NetworkService access local resources as ordinary users and access network resources
by using the computer's identity. As a result, a service that runs as NetworkService has the same network access as
a service that runs as LocalSystem, but it has significantly reduced local access.
S-1-5- Administrator A user account for the system administrator. Every computer has a local Administrator account and every domain
domain-500 has a domain Administrator account.
The Administrator account is the first account created during operating system installation. The account can't be
deleted, disabled, or locked out, but it can be renamed.
By default, the Administrator account is a member of the Administrators group, and it can't be removed from that
group.
S-1-5- Guest A user account for people who don't have individual accounts. Every computer has a local Guest account, and
domain-501 every domain has a domain Guest account.
By default, Guest is a member of the Everyone and the Guests groups. The domain Guest account is also a
member of the Domain Guests and Domain Users groups.
Unlike Anonymous Logon, Guest is a real account, and it can be used to sign in interactively. The Guest account
doesn't require a password, but it can have one.
S-1-5- KRBTGT A user account that's used by the Key Distribution Center (KDC) service. The account exists only on domain
domain-502 controllers.
S-1-5- Domain Admins A global group with members that are authorized to administer the domain. By default, the Domain Admins group
domain-512 is a member of the Administrators group on all computers that have joined the domain, including domain
controllers.
Domain Admins is the default owner of any object that's created in the domain's Active Directory by any member
of the group. If members of the group create other objects, such as files, the default owner is the Administrators
group.
S-1-5- Domain Users A global group that includes all users in a domain. When you create a new User object in Active Directory, the user
domain-513 is automatically added to this group.
S-1-5- Domain Guests A global group that, by default, has only one member: the domain's built-in Guest account.
domain-514
S-1-5- Domain Computers A global group that includes all computers that have joined the domain, excluding domain controllers.
domain-515
S-1-5- Domain Controllers A global group that includes all domain controllers in the domain. New domain controllers are added to this
domain-516 group automatically.
S-1-5- Cert Publishers A global group that includes all computers that host an enterprise certification authority.
domain-517 Cert Publishers are authorized to publish certificates for User objects in Active Directory.
S-1-5-root Schema Admins A group that exists only in the forest root domain. It's a universal group if the domain is in native mode, and it's a
domain-518 global group if the domain is in mixed mode. The Schema Admins group is authorized to make schema changes in
Active Directory. By default, the only member of the group is the Administrator account for the forest root domain.
S-1-5-root Enterprise Admins A group that exists only in the forest root domain. It's a universal group if the domain is in native mode, and it's a
domain-519 global group if the domain is in mixed mode.
The Enterprise Admins group is authorized to make changes to the forest infrastructure, such as adding child
domains, configuring sites, authorizing DHCP servers, and installing enterprise certification authorities.
By default, the only member of Enterprise Admins is the Administrator account for the forest root domain. The
group is a default member of every Domain Admins group in the forest.
S-1-5- Group Policy Creator A global group that's authorized to create new Group Policy Objects in Active Directory. By default, the only
domain-520 Owners member of the group is Administrator.
Objects that are created by members of Group Policy Creator Owners are owned by the individual user who
creates them. In this way, the Group Policy Creator Owners group is unlike other administrative groups (such as
Administrators and Domain Admins). Objects that are created by members of these groups are owned by the
group rather than by the individual.
S-1-5- Read-only Domain A global group that includes all read-only domain controllers.
domain-521 Controllers
S-1-5- Clonable Controllers A global group that includes all domain controllers in the domain that can be cloned.
domain-522
S-1-5- Protected Users A global group that is afforded additional protections against authentication security threats.
domain-525
S-1-5-root Key Admins This group is intended for use in scenarios where trusted external authorities are responsible for modifying this
domain-526 attribute. Only trusted administrators should be made a member of this group.
S-1-5- Enterprise Key This group is intended for use in scenarios where trusted external authorities are responsible for modifying this
domain-527 Admins attribute. Only trusted enterprise administrators should be made a member of this group.
S-1-5-32-544 Administrators A built-in group. After the initial installation of the operating system, the only member of the group is the
Administrator account. When a computer joins a domain, the Domain Admins group is added to the
Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to
the Administrators group.
S-1-5-32-545 Users A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users
group.
S-1-5-32-546 Guests A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-
time users to sign in with limited privileges to a computer's built-in Guest account.
S-1-5-32-547 Power Users A built-in group. By default, the group has no members. Power users can create local users and groups; modify
and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups.
Power users also can install programs; create, manage, and delete local printers; and create and delete file shares.
S-1-5-32-548 Account Operators A built-in group that exists only on domain controllers. By default, the group has no members. By default, Account
Operators have permission to create, modify, and delete accounts for users, groups, and computers in all
containers and organizational units of Active Directory except the Builtin container and the Domain Controllers
OU. Account Operators don't have permission to modify the Administrators and Domain Admins groups, nor do
they have permission to modify the accounts for members of those groups.
S-1-5-32-549 Server Operators Description: A built-in group that exists only on domain controllers. By default, the group has no members. Server
Operators can sign in to a server interactively; create and delete network shares; start and stop services; back up
and restore files; format the hard disk of the computer; and shut down the computer.
S-1-5-32-550 Print Operators A built-in group that exists only on domain controllers. By default, the only member is the Domain Users group.
Print Operators can manage printers and document queues.
S-1-5-32-551 Backup Operators A built-in group. By default, the group has no members. Backup Operators can back up and restore all files on a
computer, regardless of the permissions that protect those files. Backup Operators also can sign in to the
computer and shut it down.
S-1-5-32-552 Replicators A built-in group that's used by the File Replication service on domain controllers. By default, the group has no
members. Don't add users to this group.
S-1-5- RAS and IAS Servers A local domain group. By default, this group has no members. Computers that are running the Routing and
domain-553 Remote Access service are added to the group automatically.
Members of this group have access to certain properties of User objects, such as Read Account Restrictions, Read
Logon Information, and Read Remote Access Information.
S-1-5-32-554 Builtin\Pre-Windows An alias added by Windows 2000. A backward compatibility group that allows read access on all users and groups
2000 Compatible in the domain.
Access
S-1-5-32-555 Builtin\Remote An alias. Members of this group are granted the right to sign in remotely.
Desktop Users
S-1-5-32-556 Builtin\Network An alias. Members of this group can have some administrative privileges to manage configuration of networking
Configuration features.
Operators
S-1-5-32-557 Builtin\Incoming An alias. Members of this group can create incoming, one-way trusts to this forest.
Forest Trust Builders
S-1-5-32-558 Builtin\Performance An alias. Members of this group have remote access to monitor this computer.
Monitor Users
S-1-5-32-559 Builtin\Performance An alias. Members of this group have remote access to schedule logging of performance counters on this
Log Users computer.
S-1-5-32-560 Builtin\Windows An alias. Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User
Authorization Access objects.
Group
S-1-5-32-561 Builtin\Terminal An alias. A group for Terminal Server License Servers. When Windows Server 2003 Service Pack 1 is installed, a new
Server License local group is created.
Servers
S-1-5-32-562 Builtin\Distributed An alias. A group for COM to provide computer-wide access controls that govern access to all call, activation, or
COM Users launch requests on the computer.
S-1-5-32-568 Builtin\IIS_IUSRS An alias. A built-in group account for IIS users.
S-1-5-32-569 Builtin\Cryptographic A built-in local group. Members are authorized to perform cryptographic operations.
Operators
S-1-5- Allowed RODC Members in this group can have their passwords replicated to all read-only domain controllers in the domain.
domain-571 Password Replication
Group
S-1-5- Denied RODC Members in this group can't have their passwords replicated to all read-only domain controllers in the domain.
domain-572 Password Replication
Group
S-1-5-32-573 Builtin\Event Log A built-in local group. Members of this group can read event logs from a local computer.
Readers
S-1-5-32-574 Builtin\Certificate A built-in local group. Members of this group are allowed to connect to Certification Authorities in the enterprise.
Service DCOM
Access
S-1-5-32-575 Builtin\RDS Remote A built-in local group. Servers in this group enable users of RemoteApp programs and personal virtual desktops
Access Servers 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 that are running RD Connection Broker. RD Gateway servers and RD
Web Access servers used in the deployment need to be in this group.
S-1-5-32-576 Builtin\RDS Endpoint A built-in local group. Servers in this group run virtual machines and host sessions where users RemoteApp
Servers 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.
S-1-5-32-577 Builtin\RDS A built-in local group. Servers in this group can perform routine administrative actions on servers running Remote
Management Servers 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.
S-1-5-32-578 Builtin\Hyper-V A built-in local group. Members of this group have complete and unrestricted access to all features of Hyper-V.
Administrators
S-1-5-32-579 Builtin\Access A built-in local group. Members of this group can remotely query authorization attributes and permissions for
Control Assistance resources on this computer.
Operators
S-1-5-32-580 Builtin\Remote A built-in local group. Members of this group can access Windows Management Instrumentation (WMI) resources
Management Users 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.
S-1-5-64-10 NTLM Authentication A SID that's used when the NTLM authentication package authenticates the client.
S-1-5-64-14 SChannel A SID that's used when the SChannel authentication package authenticates the client.
Authentication
S-1-5-64-21 Digest A SID that's used when the Digest authentication package authenticates the client.
Authentication
S-1-5-80 NT Service A SID that's used as an NT Service account prefix.
S-1-5-80-0 All Services A group that includes all service processes that are configured on the system. Membership is controlled by the
operating system. SID S-1-5-80-0 equals NT SERVICES\ALL SERVICES. This SID was introduced in Windows Server
2008 R2.
S-1-5-83-0 NT VIRTUAL A built-in group. The group is created when the Hyper-V role is installed. Membership in the group is maintained
MACHINE\Virtual by the Hyper-V Management Service (VMMS). This group requires the Create Symbolic Links right
Machines (SeCreateSymbolicLinkPrivilege) and the Log on as a Service right (SeServiceLogonRight).
The following RIDs are relative to each domain:
RID Decimal Identifies

value
DOMAIN_USER_RID_ADMIN 500 The administrative user account in a domain.
DOMAIN_USER_RID_GUEST 501 The guest-user account in a domain. Users who don't have an account can automatically sign in
to this account.
DOMAIN_GROUP_RID_USERS 513 A group that contains all user accounts in a domain. All users are automatically added to this
group.
DOMAIN_GROUP_RID_GUESTS 514 The group Guest account in a domain.
DOMAIN_GROUP_RID_COMPUTERS 515 The Domain Computer group. All computers in the domain are members of this group.
DOMAIN_GROUP_RID_CONTROLLERS 516 The Domain Controller group. All domain controllers in the domain are members of this group.
DOMAIN_GROUP_RID_CERT_ADMINS 517 The certificate publishers group. Computers running Active Directory Certificate Services are
members of this group.
DOMAIN_GROUP_RID_SCHEMA_ADMINS 518 The schema administrators group. Members of this group can modify the Active Directory
schema.
DOMAIN_GROUP_RID_ENTERPRISE_ADMINS 519 The enterprise administrators group. Members of this group have full access to all domains in
the Active Directory forest. Enterprise administrators are responsible for forest-level operations
such as adding or removing new domains.
DOMAIN_GROUP_RID_POLICY_ADMINS 520 The policy administrators group.
Examples of domain-relative RIDs that are used to form well-known SIDs for local groups are listed in the following table:

value
value
DOMAIN_ALIAS_RID_ADMINS 544 Administrators of the domain.
DOMAIN_ALIAS_RID_USERS 545 All users in the domain.
DOMAIN_ALIAS_RID_GUESTS 546 Guests of the domain.
DOMAIN_ALIAS_RID_POWER_USERS 547 A user or a set of users who expect to treat a system as if it were their personal computer rather than as a
workstation for multiple users.
DOMAIN_ALIAS_RID_BACKUP_OPS 551 A local group that's used to control the assignment of file backup-and-restore user rights.
DOMAIN_ALIAS_RID_REPLICATOR 552 A local group that's responsible for copying security databases from the primary domain controller to the
backup domain controllers. These accounts are used only by the system.
DOMAIN_ALIAS_RID_RAS_SERVERS 553 A local group that represents remote access and servers that are running Internet Authentication Service
(IAS). This group permits access to various attributes of User objects.
Changes in security identifier functionality

Changes in SID implementation in the Windows operating systems are described in the following table:
Change Operating Description and resources

system
version
Most of the operating system files Windows The purpose of this change is to prevent a process that's running as an administrator or under the
are owned by the TrustedInstaller Server 2008, LocalSystem account from automatically replacing the operating system files.
security identifier (SID) Windows
Vista
Restricted SID checks are Windows When restricting SIDs are present, Windows performs two access checks. The first is the normal access
implemented Server 2008, check, and the second is the same access check against the restricting SIDs in the token. Both access
Windows checks must pass to allow the process to access the object.
Vista
Capability SIDs
Capability security identifiers are used to uniquely and immutably identify capabilities that represent an unforgettable token of authority,
which grants access to resources (for example, documents, camera, and location) to Universal Windows Applications. An app that has a
capability is granted access to the resource that the capability is associated with, and one that doesn't have a capability is denied access to
the resource.
All capability SIDs that the operating system is aware of are stored in the Windows Registry in the path
'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities'. Any capability SID that's added
to Windows by first-party or third-party applications are added to this location.
Examples of registry keys taken from Windows 10, version 1909, 64-bit
Enterprise edition
You might see the following registry keys under AllCachedCapabilities:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock_Internal
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Enterprise
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_General
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Restricted
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Windows
All capability SIDs are prefixed by S-1-15-3.
Examples of registry keys taken from Windows 11, version 21H2, 64-bit
Enterprise edition
You might see the following registry keys under AllCachedCapabilities:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock_I
nternal
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Enterprise
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_General
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Restricted
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Windows
All capability SIDs are prefixed by S-1-15-3.
See also
Guidance about how to configure
protected accounts
Article • 07/29/2021
Through Pass-the-hash (PtH) attacks, an attacker can authenticate to a remote server or

service by using the underlying NTLM hash of a user's password (or other credential
derivatives). Microsoft has previously published guidance to mitigate pass-the-hash
attacks. Windows Server 2012 R2 includes new features to help mitigate such attacks
further. For more information about other security features that help protect against
credential theft, see Credentials Protection and Management. This topic explains how to
configure the following new features:
Protected Users
Authentication policies
Authentication policy silos
There are additional mitigations built in to Windows 8.1 and Windows Server 2012 R2 to
help protect against credential theft, which are covered in the following topics:
Restricted Admin mode for Remote Desktop
LSA Protection
Protected Users
Protected Users is a new global security group to which you can add new or existing
users. Windows 8.1 devices and Windows Server 2012 R2 hosts have special behavior
with members of this group to provide better protection against credential theft. For a
member of the group, a Windows 8.1 device or a Windows Server 2012 R2 host does
not cache credentials that are not supported for Protected Users. Members of this group
have no additional protection if they are logged on to a device that runs a version of
Windows earlier than Windows 8.1.
Members of the Protected Users group who are signed-on to Windows 8.1 devices and
Windows Server 2012 R2 hosts can no longer use:
Default credential delegation (CredSSP) - plaintext credentials are not cached even
when the Allow delegating default credentials policy is enabled
Windows Digest - plaintext credentials are not cached even when they are enabled
NTLM - NTOWF is not cached
Kerberos long term keys - Kerberos ticket-granting ticket (TGT) is acquired at logon
and cannot be re-acquired automatically
Sign-on offline - the cached logon verifier is not created
If the domain functional level is Windows Server 2012 R2 , members of the group can no
longer:
Authenticate by using NTLM authentication
Use Data Encryption Standard (DES) or RC4 cipher suites in Kerberos pre-
authentication
Be delegated by using unconstrained or constrained delegation
Renew user tickets (TGTs) beyond the initial 4-hour lifetime
To add users to the group, you can use UI tools such as Active Directory Administrative
Center (ADAC) or Active Directory Users and Computers, or a command-line tool such as
Dsmod group, or the Windows PowerShellAdd-ADGroupMember cmdlet. Accounts for
services and computers should not be members of the Protected Users group.
Membership for those accounts provides no local protections because the password or
certificate is always available on the host.
２ Warning
The authentication restrictions have no workaround, which means that members of

highly privileged groups such as the Enterprise Admins group or the Domain
Admins group are subject to the same restrictions as other members of the
Protected Users group. If all members of such groups are added to the Protected
Users group, it is possible for all of those accounts to be locked out. You should
never add all highly privileged accounts to the Protected Users group until you
have thoroughly tested the potential impact.
Members of the Protected Users group must be able to authenticate by using Kerberos
with Advanced Encryption Standards (AES). This method requires AES keys for the
account in Active Directory. The built-in Administrator does not have an AES key unless
the password was changed on a domain controller that runs Windows Server 2008 or
later. Additionally, any account, which has a password that was changed at a domain
controller that runs an earlier version of Windows Server, is locked out. Therefore, follow
these best practices:
Do not test in domains unless all domain controllers run Windows Server 2008 or
later.
Change password for all domain accounts that were created before the domain
was created. Otherwise, these accounts cannot be authenticated.
Change password for each user before adding the account to the Protected Users
group or ensure that the password was changed recently on a domain controller
that runs Windows Server 2008 or later.
Requirements for using protected accounts

Protected accounts have the following deployment requirements:
To provide client-side restrictions for Protected Users, hosts must run Windows 8.1
or Windows Server 2012 R2 . A user only has to sign-on with an account that is a
member of a Protected Users group. In this case, the Protected Users group can be
created by transferring the primary domain controller (PDC) emulator role to a
domain controller that runs Windows Server 2012 R2 . After that group object is
replicated to other domain controllers, the PDC emulator role can be hosted on a
domain controller that runs an earlier version of Windows Server.
To provide domain controller-side restrictions for Protected Users, that is to restrict

usage of NTLM authentication, and other restrictions, the domain functional level
must be Windows Server 2012 R2 . For more information about functional levels,
see Understanding Active Directory Domain Services (AD DS) Functional Levels.
Troubleshoot events related to Protected Users

This section covers new logs to help troubleshoot events that are related to Protected
Users and how Protected Users can impact changes to troubleshoot either ticket-
granting tickets (TGT) expiration or delegation issues.
New logs for Protected Users
Two new operational administrative logs are available to help troubleshoot events that
are related to Protected Users: Protected User - Client Log and Protected User Failures -
Domain Controller Log. These new logs are located in Event Viewer and are disabled by
default. To enable a log, click Applications and Services Logs, click Microsoft, click
Windows, click Authentication, and then click the name of the log and click Action (or
right-click the log) and click Enable Log.
For more information about events in these logs, see Authentication Policies and
Authentication Policy Silos.
Troubleshoot TGT expiration

Normally, the domain controller sets the TGT lifetime and renewal based on the domain
policy as shown in the following Group Policy Management Editor window.
For Protected Users, the following settings are hard-coded:
Maximum lifetime for user ticket: 240 minutes
Maximum lifetime for user ticket renewal: 240 minutes
Troubleshoot delegation issues
Previously, if a technology that uses Kerberos delegation was failing, the client account
was checked to see if Account is sensitive and cannot be delegated was set. However, if
the account is a member of Protected Users, it might not have this setting configured in
Active Directory Administrative Center (ADAC). As a result, check the setting and group
membership when you troubleshoot delegation issues.
Audit authentication attempts
To audit authentication attempts explicitly for the members of the Protected Users
group, you can continue to collect security log audit events or collect the data in the
new operational administrative logs. For more information about these events, see
Authentication Policies and Authentication Policy Silos
Provide DC-side protections for services and computers

Accounts for services and computers cannot be members of Protected Users. This
section explains which domain controller-based protections can be offered for these
accounts:
Reject NTLM authentication: Only configurable via NTLM block policies
Reject Data Encryption Standard (DES) in Kerberos pre-authentication: Windows

Server 2012 R2 domain controllers do not accept DES for computer accounts
unless they are configured for DES only because every version of Windows
released with Kerberos also supports RC4.
Reject RC4 in Kerberos pre-authentication: not configurable.
７ Note
Although it is possible to change the configuration of supported encryption

types, it is not recommended to change those settings for computer accounts
without testing in the target environment.
Restrict user tickets (TGTs) to an initial 4-hour lifetime: Use Authentication Policies.
Deny delegation with unconstrained or constrained delegation: To restrict an
account, open Active Directory Administrative Center (ADAC) and select the
Account is sensitive and cannot be delegated check box.
Authentication policies
Authentication Policies is a new container in AD DS that contains authentication policy
objects. Authentication policies can specify settings that help mitigate exposure to
credential theft, such as restricting TGT lifetime for accounts or adding other claims-
related conditions.
In Windows Server 2012 , Dynamic Access Control introduced an Active Directory forest-
scope object class called Central Access Policy to provide an easy way to configure file
servers across an organization. In Windows Server 2012 R2 , a new object class called
Authentication Policy (objectClass msDS-AuthNPolicies) can be used to apply
authentication configuration to account classes in Windows Server 2012 R2 domains.
Active Directory account classes are:
User
Computer
Managed Service Account and group Managed Service Account (GMSA)
Quick Kerberos refresher

The Kerberos authentication protocol consists of three types of exchanges, also known
as subprotocols:
The Authentication Service (AS) Exchange (KRB_AS_*)
The Ticket-Granting Service (TGS) Exchange (KRB_TGS_*)
The Client/Server (AP) Exchange (KRB_AP_*)
The AS exchange is where the client uses the account's password or private key to
create a pre-authenticator to request a ticket-granting ticket (TGT). This happens at user
sign-on or the first time a service ticket is needed.
The TGS exchange is where the account's TGT is used to create an authenticator to
request a service ticket. This happens when an authenticated connection is needed.
The AP exchange occurs as typically as data inside the application protocol and is not
impacted by authentication policies.
For more detailed information, see How the Kerberos Version 5 Authentication Protocol
Works.
Overview
Authentication policies complement Protected Users by providing a way to apply
configurable restrictions to accounts and by providing restrictions for accounts for
services and computers. Authentication policies are enforced during either the AS
exchange or the TGS exchange.
You can restrict initial authentication or the AS exchange by configuring:
A TGT lifetime
Access control conditions to restrict user sign-on, which must be met by devices
from which the AS exchange is coming
You can restrict service ticket requests through a ticket-granting service (TGS) exchange
by configuring:
Access control conditions which must be met by the client (user, service, computer)
or device from which the TGS exchange is coming
Requirements for using authentication policies
Policy Requirements
Provide custom TGT lifetimes Windows Server 2012 R2 domain functional level
account domains
Restrict user sign-on - Windows Server 2012 R2 domain functional level

account domains with Dynamic Access Control
support
- Windows 8, Windows 8.1, Windows Server 2012 or

Windows Server 2012 R2 devices with Dynamic
Access Control support
Restrict service ticket issuance that is Windows Server 2012 R2 domain functional level
based on user account and security resource domains
groups
Restrict service ticket issuance based on Windows Server 2012 R2 domain functional level
user claims or device account, security resource domains with Dynamic Access Control
groups, or claims support
Restrict a user account to specific devices and hosts

A high-value account with administrative privilege should be a member of the Protected
Users group. By default, no accounts are members of the Protected Users group. Before
you add accounts to the group, configure domain controller support and create an audit
policy to ensure that there are no blocking issues.
Configure domain controller support
The user's account domain must be at Windows Server 2012 R2 domain functional level
(DFL). Ensure all the domain controllers are Windows Server 2012 R2 , and then use
Active Directory Domains and Trusts to raise the DFL to Windows Server 2012 R2 .
To configure support for Dynamic Access Control
1. In the Default Domain Controllers Policy, click Enabled to enable Key Distribution
Center (KDC) client support for claims, compound authentication and Kerberos
armoring in Computer Configuration | Administrative Templates | System | KDC.
2. Under Options, in the drop-down list box, select Always provide claims.
７ Note
Supported can also be configured, but because the domain is at Windows

Server 2012 R2 DFL, having the DCs always provide claims will allow user
claims-based access checks to occur when using non-claims aware devices
and hosts to connect to claims-aware services.
２ Warning
Configuring Fail unarmored authentication requests will result in

authentication failures from any operating system which does not support
Kerberos armoring, such as Windows 7 and previous operating systems, or
operating systems beginning with Windows 8, which have not been explicitly
configured to support it.
Create a user account audit for authentication policy with ADAC
1. Open Active Directory Administrative Center (ADAC).

７ Note
The selected Authentication node is visible for domains which are at

Windows Server 2012 R2 DFL. If the node does not appear, then try again by
using a domain administrator account from a domain that is at Windows
Server 2012 R2 DFL.
2. Click Authentication Policies, and then click New to create a new policy.
Authentications Policies must have a display name and are enforced by default.
3. To create an audit-only policy, click Only audit policy restrictions.
Authentication policies are applied based on the Active Directory account type. A
single policy can apply to all three account types by configuring settings for each
type. Account types are:
User
Computer
Managed Service Account and Group Managed Service Account
If you have extended the schema with new principals that can be used by the Key
Distribution Center (KDC), then the new account type is classified from the closest
derived account type.
4. To configure a TGT lifetime for user accounts, select the Specify a Ticket-Granting
Ticket lifetime for user accounts check box and enter the time in minutes.
For example, if you want a 10-hour maximum TGT lifetime, enter 600 as shown. If
no TGT lifetime is configured, then if the account is a member of the Protected
Users group, the TGT lifetime and renewal is 4 hours. Otherwise, TGT lifetime and
renewal are based on the domain policy as seen in the following Group Policy
Management Editor window for a domain with default settings.
5. To restrict the user account to select devices, click Edit to define the conditions
that are required for the device.
6. In the Edit Access Control Conditions window, click Add a condition.
Add computer account or group conditions
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.
Add computer claim conditions
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.
Troubleshoot missing computer claims
If the claim has been provisioned, but is not available, it might only be configured for
Computer classes.
Let's say you wanted to restrict authentication based on the organizational unit (OU) of
the computer, which was already configured, but only for Computer classes.
For the claim to be available to restrict User sign-on to the device, select the User check
box.
Provision a user account with an authentication policy with ADAC
1. From the User account, click Policy.

2. Select the Assign an authentication policy to this account check box.
3. Then select the authentication policy to apply to the user.
Configure Dynamic Access Control support on devices and hosts

You can configure TGT lifetimes without configuring Dynamic Access Control (DAC). DAC
is only needed for checking AllowedToAuthenticateFrom and AllowedToAuthenticateTo.
Using either Group Policy or Local Group Policy Editor, enable Kerberos client support
for claims, compound authentication and Kerberos armoring in Computer
Configuration | Administrative Templates | System | Kerberos:
Troubleshoot Authentication Policies
Determine the accounts that are directly assigned an

Authentication Policy
The accounts section in the Authentication Policy shows the accounts that have directly
applied the policy.
Use the Authentication Policy Failures - Domain Controller
administrative log
A new Authentication Policy Failures - Domain Controller administrative log under

Applications and Services Logs > Microsoft > Windows > Authentication has been
created to make it easier to discover failures due to Authentication Policies. The log is
disabled by default. To enable it, right-click the log name and click Enable Log. The new
events are very similar in content to the existing Kerberos TGT and service ticket auditing
events. For more information about these events, see Authentication Policies and
Authentication Policy Silos.
Manage authentication policies by using Windows

PowerShell
This command creates an authentication policy named TestAuthenticationPolicy. The
UserAllowedToAuthenticateFrom parameter specifies the devices from which users can
authenticate by an SDDL string in the file named someFile.txt.
PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -

UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl
This command gets all authentication policies that match the filter that the Filter
parameter specifies.
PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like

'testADAuthenticationPolicy*'" -Server Server02.Contoso.com
This command modifies the description and the UserTGTLifetimeMins properties of the
specified authentication policy.
PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -

Description "Description" -UserTGTLifetimeMins 45
This command removes the authentication policy that the Identity parameter specifies.
PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1
This command uses the Get-ADAuthenticationPolicy cmdlet with the Filter parameter
to get all authentication policies that are not enforced. The result set is piped to the
Remove-ADAuthenticationPolicy cmdlet.
PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-

ADAuthenticationPolicy
Authentication policy silos

Authentication Policy Silos is a new container (objectClass msDS-AuthNPolicySilos) in AD
DS for user, computer, and service accounts. They help protect high-value accounts.
While all organizations need to protect members of Enterprise Admins, Domain Admins
and Schema Admins groups because those accounts could be used by an attacker to
access anything in the forest, other accounts may also need protection.
Some organizations isolate workloads by creating accounts that are unique to them and
by applying Group Policy settings to limit local and remote interactive logon and
administrative privileges. Authentication policy silos complement this work by creating a
way to define a relationship between User, Computer and managed Service accounts.
Accounts can only belong to one silo. You can configure authentication policy for each
type of account in order to control:
1. Non-renewable TGT lifetime
2. Access control conditions for returning TGT (Note: cannot apply to systems
because Kerberos armoring is required)
3. Access control conditions for returning service ticket
Additionally, accounts in an authentication policy silo have a silo claim, which can be
used by claims-aware resources such as file servers to control access.
A new security descriptor can be configured to control issuing service ticket based on:
User, user's security groups, and/or user's claims
Device, device's security group, and/or device's claims
Getting this information to the resource's DCs requires Dynamic Access Control:
User claims:
Windows 8 and later clients supporting Dynamic Access Control
Account domain supports Dynamic Access Control and claims
Device and/or device security group:
Resource configured for compound authentication
Device claims:
Device domain supports Dynamic Access Control and claims
Resource configured for compound authentication
Authentication policies can be applied to all members of an authentication policy silo

instead of to individual accounts, or separate authentication policies can be applied to
different types of accounts within a silo. For example, one authentication policy can be
applied to highly privileged user accounts, and a different policy can be applied to
services accounts. At least one authentication policy must be created before an
authentication policy silo can be created.
７ Note
An authentication policy can be applied to members of an authentication policy

silo, or it can be applied independently of silos to restrict specific account scope.
For example, to protect a single account or a small set of accounts, a policy can be
set on those accounts without adding the accounts to a silo.
You can create an authentication policy silo by using Active Directory Administrative
Center or Windows PowerShell. By default, an authentication policy silo only audits silo
policies, which is equivalent to specifying the WhatIf parameter in Windows PowerShell
cmdlets. In this case, policy silo restrictions do not apply, but audits are generated to
indicate whether failures occur if the restrictions are applied.
To create an authentication policy silo by using Active Directory

1. Open Active Directory Administrative Center, click Authentication, right-click
Authentication Policy Silos, click New, and then click Authentication Policy Silo.
2. In Display name, type a name for the silo. In Permitted Accounts, click Add, type
the names of the accounts, and then click OK. You can specify users, computers, or
service accounts. Then specify whether to use a single policy for all principals or a
separate policy for each type of principal, and the name of the policy or policies.
Manage authentication policy silos by using Windows
PowerShell
This command creates an authentication policy silo object and enforces it.
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
This command gets all the authentication policy silos that match the filter that is
specified by the Filter parameter. The output is then passed to the Format-Table cmdlet
to display the name of the policy and the value for Enforce on each policy.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' |

Format-Table Name, Enforce -AutoSize
Name Enforce
---- -------
silo True
silos False
This command uses the Get-ADAuthenticationPolicySilo cmdlet with the Filter

parameter to get all authentication policy silos that are not enforced and pipe the result
of the filter to the Remove-ADAuthenticationPolicySilo cmdlet.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-

ADAuthenticationPolicySilo
This command grants access to the authentication policy silo named Silo to the user
account named User01.
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01
This command revokes access to the authentication policy silo named Silo for the user
account named User01. Because the Confirm parameter is set to $False, no confirmation
message appears.
PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account
User01 -Confirm:$False
This example first uses the Get-ADComputer cmdlet to get all computer accounts that
match the filter that the Filter parameter specifies. The output of this command is
passed to Set-ADAccountAuthenticatinPolicySilo to assign the authentication policy
silo named Silo and the authentication policy named AuthenticationPolicy02 to them.
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-

ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -
AuthenticationPolicy AuthenticationPolicy02
How LDAP server cookies are handled

Article • 05/04/2023
In LDAP, some queries result in a large result set. Such queries pose certain challenges
to Windows Server.
Collecting and building these large 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 require enormous
amounts of storage space, easily several hundred Mega-Bytes. These then require lots of
virtual address space. The transfer over network encounters issues because the whole
effort is lost when the TCP session breaks down in transit.
These capacity and logistic issues encouraged the Microsoft LDAP developers to create
an LDAP extension known as "Paged Query". Paged Query implements an LDAP control
to separate one huge query into chunks of smaller result sets. Paged Query is an RFC
standard: 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 an 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.
To continue the search. the client sends the same query to the LDAP server, including
the cookie value from 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 the server doesn't return a cookie, the client must
consider the paged search to be successfully complete.
If the server returns an error, the client must consider the paged search to be
unsuccessful. Retrying the search results 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, Windows Server uses the client cookie and any related information from
the server cookie cache to continue the search. If the server can't 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. Also, more than
one client at a time can launch queries that require the use of server cookie cache.
Therefore in the Windows Server implementation there's a tracking of cookie pool usage
and limits are put into place so the cookie pool isn't taking up too much resources.
Administrators can set limits using the following settings in LDAP Policy. The defaults
and explanations are as follows.
MinResultSets: 4
The LDAP server doesn't look at the maximum pool size, if there are fewer 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. When using the 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 doesn't 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 can go through a page search and never complete it. This
uncompleted search can leave entries in the LDAP server cookie cache, which are
handled through the mechanism described earlier. This mechanism 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 doesn't find the cookie in the server
cookie cache and returns an error for the query. The error response is 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:
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 doesn't 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 because of the
control processing error, you should consider increasing limits on one or more of the
LDAP Policy settings. You can find the limits in the How the cookie pool is managed
section, depending on which event you're getting.
If you're 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 isn't 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 more paged results, leaves the cookie pending and
restarts a new query. 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're still seeing events 2899 with a pool of 250MB or more, you're likely having
many clients with very high number of objects returned, queried in a 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 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. If there are applications for which you have source code access, see Creating
efficient AD-Enabled Applications for help with understanding 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. Replicating the
instance and distributing the client can reduce the load on the individual LDAP Servers.
Active Directory DC locator changes
Article • 08/15/2023
Applies to: Windows Insider Preview Build 25921 and later
This article discusses changes to the Active Directory domain controller (DC) location
algorithm, including deprecation announcements.
Overview
Authentication is the first step in virtually all functional scenarios in an Active Directory
enterprise environment. Authentication, in turn, can't occur unless the client can first
communicate with an Active Directory DC.
DC location refers to the algorithm by which a client machine finds a suitable domain
controller. DC location is a critical baseline functionality in all enterprise environments.
Active Directory domains always have two distinct names: the DNS fully qualified
domain name (FQDN) and the NetBIOS domain name. NetBIOS domain names have
legacy length and other constraints. For example, NetBIOS domains are limited to 15
characters.
The NetBIOS domain name of an Active Directory domain isn't required to be related in
any way to the first component of the Active Directory domain's FQDN. For example, an
Active Directory domain's FQDN might be contoso.com with a NetBIOS domain name of
fabrikam .
DC location in Windows can operate in two basic modes:
DNS-based discovery: This mode is based on domain controller advertisement via

DNS.
Domain controllers register various SRV records in DNS. Examples include records
that represent key capabilities (Key Distribution Center or Global Catalog) or
records that describe locality (Active Directory site records). Clients query DNS for
the appropriate SRV records and then ping those servers by using UDP-based
LDAP pings.
This mode is supported only when you use DNS domain names. This mode is
supported with Windows 2000 and later domain controllers. Windows 2000 and
later clients prefer this mode, but they can fall back to the other mode under some
circumstances.
NetBIOS-based discovery: This mode is based on domain controllers first

registering records in Windows Internet Name Service (WINS). Clients query WINS
for the appropriate records, followed by pinging the possible target candidate DCs.
A variant of this mode uses a broadcast mechanism supported by mailslot

messages. In this mechanism, the client broadcasts packets on its local network to
look for DCs. This mode is supported with legacy Windows NT 4 and earlier
domain controllers, and it works only when you use short NetBIOS domain names.
Organizations prefer DNS-based discovery over NetBIOS-based discovery, for both

reliability and security reasons.
DsGetDcName is the primary DC location API.
This description is only a brief overview. For more information about the DC location
process, see How domain controllers are located in Windows.
Deprecation of WINS and mailslots

Microsoft previously announced the deprecation of both WINS and mailslots . These
legacy technologies are no longer secure in today's environments.
This deprecation affects DC location. Later sections in this article describe mitigation
steps.
Mapping of NetBIOS domain names to DNS

domain names
When an application requests a DC but specifies a short NetBIOS-style domain name,
DC location always tries to map that short domain name to a DNS domain name. If DC
location finds such a mapping, it then uses DNS-based discovery with the mapped DNS
domain name.
NetBIOS-style domain names are historically mapped to DNS domain names via
multiple sources in the following order:
1. Cached information from a previous lookup
2. All domains in the current forest

3. Top-level names (TLNs) for all trusting forest trusts and external trusts
4. Sign-in sessions on the client machine
When none of these sources can find a DNS domain name, DC location can proceed
with NetBIOS-based discovery by using the original NetBIOS-style short domain name.
） Important
We recommend that you migrate all applications to use only Active Directory DNS
domain names for authentication or other purposes.
DC locator improvements to accommodate

WINS and mailslot deprecation
The deprecation of WINS and mailslot messages means that those mechanisms are
longer available as a fallback option when applications specify short NetBIOS-style
domain names. This deprecation can therefore cause disruption in some environments.
The following sections describe improvements in Windows Insider Preview Release build
25921.
BlockNetBIOSDiscovery Netlogon policy setting

BlockNetBIOSDiscovery is a new Boolean Group Policy setting for the Netlogon service.
To access the policy in Group Policy Management Editor, go to Computer Configuration

> Administrative Templates > System > Net Logon > DC Locator DNS Records >
Block NetBIOS-based discovery for domain controller location.
The following settings apply to BlockNetBIOSDiscovery :
TRUE (default): DC locator doesn't allow the use of NetBIOS-style DC location.

FALSE : DC locator allows the use of WINS/mailslot-based discovery, if all legacy
constraints also allow it.
You use the BlockNetBIOSDiscovery setting to enforce a secure-by-default posture for

DC location. We recommend that you keep it set to TRUE . Disable it only for temporary
periods while you're pursuing other mitigations.
The new policy setting looks like this:

 Tip
You separately enable or disable the ability to use mailslots on a machine-wide

basis by using the SMB EnableMailslots policy setting. For DC locator to be able to
use mailslots for DC discovery, you must enable mailslots at the SMB level, and you
must disable BlockNetBIOSDiscovery . You can query and set the EnableMailslots
setting by using the Get-SmbClientConfiguration and Set-SmbClientConfiguration
PowerShell cmdlets.
Downloading and caching of full domain information

Netlogon downloads and caches naming information about domains and child domains
in all trusting forests. This information is used when you're mapping NetBIOS-style
domain names to DNS domain names.
Downloading and caching of administrator-configured

domain name mappings
If an application or environment requires other domain name mappings that other
sources don't automatically provide, forest administrators can configure custom
mappings from DNS domain name to NetBIOS domain name at the forest level.
Administrator-configured mappings are an optional mechanism that you should use
only when all other options are insufficient.
The custom domain name mappings are stored in a serviceConnectionPoint object

located in the naming context for the Active Directory configuration. For example:
CN=DCLocatorDomainNameMappings,CN=Windows
NT,CN=Services,CN=Configuration,DC=contoso,DC=com
The msDS-Setting s attribute of this serviceConnectionPoint object can contain one or

more values. Each value contains the DNS domain name and the NetBIOS domain name,
separated by a semicolon:
dnsdomainname.com:NetBIOSdomainname
For example:
contoso.com:fabrikam tatertots.contoso.com:tots tailspintoys.com:tailspintoys
You can configure these mappings by using the Active Directory Domains and Trusts
management snap-in as follows:
1. Right-click the domain.

2. Select Properties.
3. Select the DC locator mappings tab.
The Netlogon service on clients then downloads and caches the custom mappings in the
DCLocatorDomainNameMappings object every 12 hours. This information is then
automatically used when you're mapping NetBIOS-style domain names to DNS domain
names.
The new Active Directory Domains and Trusts management page looks like this:
） Important
Configure administrator-configured forest-level domain name mappings only when

you're sure that all other name mapping sources are insufficient. As a general rule,
such arbitrary mappings are necessary only when no trust relationship exists
between clients and the target domains, and client applications can't be migrated
over to specifying DNS-style domain names.
New mapping of NetBIOS domain names to

DNS domain names
When an application requests a DC but specifies a short NetBIOS-style domain name,
DC location always tries to map that short domain name to a DNS domain name. If DC
location finds such a mapping, it then uses DNS-based discovery with the mapped DNS
domain name.
With the improvements described in this article, NetBIOS-style domain names are
mapped to DNS domain names by using multiple sources in the following order:
1. Cached information from a previous lookup
2. All domains in the current forest
3. TLNs for all trusting forest trusts and external trusts
4. Administrator-configured domain name mappings
5. Domain name mappings for all forests and child domains in trusting forest trusts
6. Sign-in sessions on the client machine
When none of these sources can find a DNS domain name, DC location can proceed
with NetBIOS-based discovery by using the original NetBIOS-style short domain name.
Troubleshooting
You can use standard troubleshooting steps for DC location. See ETW Tracing in
DsGetDcName.
See also
DsGetDcName
How domain controllers are located in Windows
How to verify that SRV DNS records have been created for a domain controller
The Beginning of the end of Remote Mailslots
Windows Internet Name Service (WINS)
About mailslots
AD DS Troubleshooting
Article • 07/29/2021
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
Configuring a Computer for
Troubleshooting
Article • 07/29/2021
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
For information about installing RSAT, see the article Remote Server Administration
Tools.
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 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\Services\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 Start > Run > type regedit > click OK.
2. Navigate to the entry for which you want to set logging in.
EXAMPLE:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostics
3. Double-click the entry, and in Base, click Decimal.

4. In Value, type an integer from 0 through 5, and then click OK.
Using ETW to troubleshoot LDAP
connections
Article • 05/19/2022
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\Services\ldap\Tracing\Proces
sName
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 start a tracing session
Open a Command Prompt window, and run the following command:
Windows Command Prompt
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 -start command.
To turn off ETW
In Registry Editor, delete the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\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 -start 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 Flag value Flag description

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\Services\ldap\Tracing\App1.e
xe
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\Services\ldap\Tracing\App1.e
xe 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
Article • 04/04/2022
Try our Virtual Agent - It can help you quickly identify and fix common Active
Directory replication issues
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.
Repadmin Root Cause Solution

error
The time since A domain controller has failed inbound Event ID 2042: It has been too
last replication replication with the named source domain long since this machine
with this server controller long enough for a deletion to replicated
has exceeded have been tombstoned, replicated, and
the tombstone garbage-collected from AD DS.
lifetime.
No inbound If no items appear in the "Inbound Fixing Replication Connectivity

neighbors. Neighbors" section of the output that is Problems (Event ID 1925)
generated by repadmin /showrepl, the
domain controller was not able to establish
replication links with another domain
controller.
Repadmin Root Cause Solution
error
Access is A replication link exists between two domain Fixing Replication Security
denied. controllers, but replication cannot be Problems
performed properly as a result of an
authentication failure.
Last attempt at This problem can be related to connectivity, Fixing Replication DNS Lookup
<date - time> DNS, or authentication issues. If this is a Problems (Event IDs 1925, 2087,
failed with the DNS error, the local domain controller could 2088) Fixing Replication Security
"Target not resolve the globally unique identifier Problems Fixing Replication
account name (GUID)-based DNS name of its replication Connectivity Problems (Event ID
is incorrect." partner. 1925)
LDAP Error 49. The domain controller computer account Fixing Replication Security
might not be synchronized with the Key Problems
Distribution Center (KDC).
Cannot open The administration tool could not contact Fixing Replication DNS Lookup
LDAP AD DS. Problems (Event IDs 1925, 2087,
connection to 2088)
local host
Active The progress of inbound replication was Wait for replication to complete.
Directory interrupted by a higher-priority replication This informational message
replication has request, such as a request that was indicates normal operation.
been generated manually with the repadmin /sync
preempted. command.
Replication The domain controller posted a replication Wait for replication to complete.
posted, request and is waiting for an answer. This informational message
waiting. Replication is in progress from this source. indicates normal operation.
The following table lists common events that might indicate problems with Active
Directory replication, along with root causes of the problems and links to topics that
provide solutions for the problems.
Event ID Root cause Solution

and
source
1311 The replication configuration information in AD DS does Fixing Replication

NTDS KCC not accurately reflect the physical topology of the network. Topology Problems
(Event ID 1311)
Event ID Root cause Solution
and
source
1388 Strict replication consistency is not in effect, and a Fixing Replication

NTDS lingering object has been replicated to the domain Lingering Object
Replication controller. Problems (Event IDs
1388, 1988, 2042)
1925 The attempt to establish a replication link for a writable Fixing Replication
NTDS KCC directory partition failed. This event can have different Connectivity Problems
causes, depending on the error. (Event ID 1925) Fixing
Replication DNS
Lookup Problems
(Event IDs 1925, 2087,
2088)
1988 The local domain controller has attempted to replicate an Fixing Replication
NTDS object from a source domain controller that is not present Lingering Object
Replication on the local domain controller because it may have been Problems (Event IDs
deleted and already garbage-collected. Replication does 1388, 1988, 2042)
not proceed for this directory partition with this partner
until the situation is resolved.
2042 Replication has not occurred with this partner for a Fixing Replication
NTDS tombstone lifetime, and replication cannot proceed. Lingering Object
Replication Problems (Event IDs
1388, 1988, 2042)
2087 AD DS could not resolve the DNS host name of the source Fixing Replication
NTDS domain controller to an IP address, and replication failed. DNS Lookup
Replication Problems (Event IDs
1925, 2087, 2088)
2088 AD DS could not resolve the DNS host name of the source Fixing Replication
NTDS domain controller to an IP address, but replication DNS Lookup
Replication succeeded. Problems (Event IDs
1925, 2087, 2088)
5805 Net A machine account failed to authenticate, which is usually Fixing Replication
Logon caused by either multiple instances of the same computer Security Problems
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
Article • 08/15/2022
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
Article • 01/10/2023
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 Decommission
AD FS Overview
Article • 08/15/2023
） Important
Instead of upgrading to the latest version of AD FS, Microsoft highly recommends

migrating to Azure AD. For more information, see Resources for decommissioning
AD FS
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 OpenID Connect/OAuth flows and Application Scenarios
AD FS Requirements
AD FS FAQ
What's new in Active Directory
Federation Services
Article • 06/16/2023
What's new in Active Directory Federation

This article describes the new changes made to Active Directory Federation Services (AD
FS).
Protected sign ins

The following points are a brief summary of updates to protected sign ins available in
Active Directory Federation Services (AD FS) 2019:
External Auth Providers as Primary. Customers can now use third-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 two factors, it can
claim MFA.
Password Authentication as extra Authentication. Customers have a fully
supported in-box option to use passwords only as an extra factor after a
password-less option is used as the first factor. This option improves the customer
experience from AD FS 2016 where customers had to download a GitHub adapter
that's supported as-is.
Pluggable Risk Assessment Module. Customers can now build their own plug-in
modules to block certain types of requests during the preauthentication stage. This
feature makes it easier for customers to use cloud intelligence such as identity
protection to block sign in 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 quick-fix engineering (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 AD FS 2012R2. Currently 2016
customers would have no protection while in audit mode.
Enables independent lockout threshold for familiar locations. This feature makes
it possible for multiple instances of apps running with a common service
account to roll over passwords with the least amount of effect.
Other security improvements
The following security improvements are available in AD FS 2019:
Remote PowerShell using SmartCard Sign-in. Customers can now use SmartCards
to remote connect to AD FS via PowerShell and use that to manage all PowerShell
functions including multi-node cmdlets.
HTTP Header customization. Customers can now customize HTTP headers emitted
during AD FS responses, including the following headers:
HSTS: This header conveys that AD FS endpoints can only be used on HTTPS
endpoints for a compliant browser to enforce.
x-frame-options: Allows AD FS admins to allow specific relying parties to embed
iFrames for AD FS interactive sign-in pages. This header should be used with
care and only on HTTPS hosts.
Future header: Other 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 other auth per RP. Customers can now use claims rules
to decide which other authentication provider to invoke for their extra
authentication. This feature is useful for two use cases:
Customers are transitioning from one other authentication provider to another.
This way as they onboard users to a newer authentication provider they can use
groups to control which extra authentication provider is called.
Customers have needs for a specific extra authentication provider (for example,
certificate) for certain applications.
Restrict Transport Layer Security (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 option
prevents any unwanted prompts for device authentication (or failures if the client
application can't handle) for applications that don't require TLS-based device
authentication.
Multi-factor authentication (MFA) freshness support. AD FS now supports the
ability to redo second factor credential based on the freshness of the second factor
credential. This feature allows customers to do an initial transaction with two
factors and only prompt for the second factor on a periodic basis. This feature is
only available to applications that can provide an extra parameter in the request
and isn't a configurable setting in AD FS. Azure AD supports this parameter when
you configure "Remember my MFA for X days" and set the 'supportsMFA' flag to
true on the Azure AD federated domain trust settings.
Single sign-on improvements

The following single sign-on SSO improvements have been made in AD FS 2019:
Paginated UX with Centered Theme. AD FS now has moved to a paginated UX

flow that allows AD FS to validate and provide a more smoother sign-in
experience. AD FS now uses a centered UI (instead of the right side of the screen).
You might need newer logo and background images to align with this experience.
This change also mirrors functionality offered in Azure AD.
Bug fix: Persistent SSO state for Win10 devices when doing Primary Refresh
Token (PRT) auth. This change resolves an issue where MFA state didn't persist
when using PRT authentication for Windows 10 devices. The result of the issue was
that end users would get prompted for second 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 line-of-business LOB apps has been added
to AD FS 2019:
Oauth Device flow/profile. AD FS now supports the OAuth device flow profile to
sign in on devices that don't have a UI surface area to support rich sign-in
experiences. This feature allows the user to complete the sign-in experience on a
different device. This functionality is required for the 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.
Cross-origin resource sharing (CORS) headers in AD FS responses. Customers can
now build single page applications that allow client-side JavaScript libraries to
validate the signature of the id_token by querying for the signing keys from the
OpenID Connect (OIDC) discovery document on AD FS.
Proof Key for Code Exchange (PKCE) support. AD FS adds PKCE support to
provide a secure auth code flow within OAuth. This feature adds an extra 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 change 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 the "x5t" claim.
Supportability improvements
The following improvements to supportability are now 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 a Simple Mail Transfer
Protocol (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's a new farm behavior level
version that's required to enable new functionality discussed later in the article.
This update allows going from:
AD FS on Windows Server 2012 R2 to AD FS on Windows Server 2016.
AD FS on Windows Server 2016 to AD FS on Windows Server 2019.
SAML updates
The following Security Assertion Markup Language (SAML) update is in AD FS 2019:
Bug fix: Fix bugs in aggregated federation. There have been numerous bug fixes
around aggregated federation support (for example, InCommon). The following
areas have received fixes:
Improved scaling for a large number of entities in the aggregated federation
metadata doc. Previously, scaling would fail with an "ADMIN0017" error.
Query using 'ScopeGroupID' parameter via Get-AdfsRelyingPartyTrustsGroup
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, the following OAuth request might look like
you'd typically send:
HTTP
https://fs.contoso.com/adfs/oauth2/authorize?
response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:cl
aimsxray&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 change 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 returns an error and authentication
doesn't 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 use the PKCE support, this specification adds more 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"). The secret is
sent in the OAuth 2.0 Authorization Request along with the "t_m" transformation
method.
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 aren't equal.
How to choose extra auth providers in 2019

AD FS already supports triggering extra authentication based on a claim rule policy.
Those policies can be set on a particular RP or at global level. You can set an extra auth
policy for a particular RP by using the cmdlet Set-AdfsRelyingPartyTrust (AD FS) |
Microsoft Docs by passing either the AdditionalAuthenticationRules or
AdditionalAuthenticationRulesFile parameter. To set it globally, an admin can use the
cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs.
For example, 2012 R2 onwards admin can already write the following rule to prompt
extra authentication if the request comes from extranet.
PowerShell
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/authenticationmeth
od", value = "https://schemas.microsoft.com/claims/multipleauthn" );'
In 2019, customers can now use claims rules to decide which other authentication
provider to invoke for extra authentication. This feature is useful for two scenarios:
Customers are transitioning from one other authentication provider to another. This way
as they onboard users to a newer authentication provider they can use groups to
control which extra authentication provider is called.
Customers have a need for a specific extra authentication provider (for example,
certificate) for certain applications but different method (Azure AD Multi-Factor
Authentication) for other applications.
This configuration could be achieved by issuing the claim

https://schemas.microsoft.com/claims/authnmethodsproviders from other
authentication policies. The value of this claim should be the Name of the authentication
provider.
Now in 2019 they can modify the previous claim rule to choose auth providers based on
their scenarios.
Transitioning from one other authentication provider to another:

You can modify the
previously mentioned rule to choose Azure AD Multi-Factor Authentication for users
that are in group SID S-1-5-21-608905689-872870963-3921916988-12345. For example
you could use this modification for a group you manage by enterprise, which tracks the
users that have registered for Azure AD Multi-Factor Authentication. This modification
also works for the rest of the users that an admin wants to use certificate auth.
PowerShell
'c:[type ==
"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value ==
"false"] => issue(type =
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmetho
d", 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");’
This example shows how to set two different auth providers for two different
applications:
Set Application A to use Azure AD Multi-Factor Authentication as an extra auth provider:
PowerShell
Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules

'c:[type ==
od", Value = "https://schemas.microsoft.com/claims/multipleauthn" );
c:[] => issue(Type =

"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaAuthentication");'
Set Application B to use Certificate as an extra auth provider:
PowerShell
Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules

'c:[type ==
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value ==
d", Value = "http://schemas.microsoft.com/claims/multipleauthn" );

"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"CertificateAuthentication");'
Admins can also make rules to allow more than one extra authentication provider. In
this case AD FS shows the issued auth methods providers, and a user can choose any of
them. To allow multiple extra authentication providers, they should issue multiple claims
https://schemas.microsoft.com/claims/authnmethodsproviders .
If the claim evaluation returns none of the auth providers, AD FS falls back to show all
the extra auth providers configured by the admin on AD FS. The user needs to then
select the appropriate auth provider.
To get all the other authentication providers allowed, admin can use the cmdlet (Get-
AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider. The value of the
https://schemas.microsoft.com/claims/authnmethodsproviders claim should be one of
the provider names returned by previously mentioned cmdlet.
There's no support to trigger a particular extra auth provider if the RP is using Access
Control Policies in AD FS Windows Server 2016 | Microsoft Docs. When you move an
application away from Access control policy, AD FS copies the corresponding policy
from Access Control Policy to AdditionalAuthenticationRules and
IssuanceAuthorizationRules. So if an admin wants to use a particular auth provider, they
can move away from not using access control policy and then modify
AdditionalAuthenticationRules to trigger a specific auth provider.
FAQ
How do I resolve the AD FS Admin event logs error, “Received

invalid Oauth request. The client 'NAME' is forbidden to access the
resource with scope 'ugs'."?
Follow these steps to remediate the issue:
1. Launch AD FS management console. Go to Services > Scope Descriptions.

2. Select more options on "Scope Descriptions, and select Add Scope Description.
3. Under name, enter "ugs" and Select Apply > OK.
4. Launch PowerShell as Administrator.
5. Run the command Get-AdfsApplicationPermission . Look for the ScopeNames :
{openid, aza} that has the ClientRoleIdentifier . Make a note of the
ObjectIdentifier .
6. Run the command Set-AdfsApplicationPermission -TargetIdentifier
<ObjectIdentifier from step 5> -AddScope 'ugs' .
7. Restart the AD FS service.

8. On the client, restart the client. You should be prompted to configure Windows
Hello for Business (WHFB).
9. If the configuration window doesn't pop up, then you need to collect trace logs
and troubleshoot further.
Can I pass a resource value as part of the scope value like how
requests are done against Azure AD?
With AD FS on Server 2019, you can now pass the resource value embedded in the
scope parameter. The scope parameter can now be organized as a space separated list
where each entry is structure as resource/scope. For example:
<create a valid sample
request>
Does AD FS support PKCE extension?
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

If you're looking for information on earlier versions of AD FS, see the following articles:
AD FS in Windows Server 2012 or 2012 R2 and AD FS 2.0.
AD FS 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 any machine, 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.
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 Active Directory multi-factor

authentication
AD FS 2016 builds upon the multi-factor authentication (MFA) capabilities of AD FS in
Windows Server 2012 R2. You can now allow sign-on by using only an Azure AD Multi-
Factor Authentication code, without first entering a username and password.
With Azure AD Multi-Factor Authentication as the primary authentication method,
the user is prompted for their username and the OTP code from the Azure
Authenticator app.
With Azure AD Multi-Factor Authentication as the secondary or extra
authentication method, the user provides primary authentication credentials. They
can do sign in by using Windows Integrated Authentication, with their username
and password, smart card, or a user or device certificate. Then they see a prompt
for text, voice, or OTP-based Azure AD Multi-Factor Authentication sign-in.
With the new built-in Azure AD Multi-Factor Authentication adapter, setup and
configuration for Azure AD Multi-Factor Authentication with AD FS has never been
simpler.
Organizations can take advantage of Azure AD Multi-Factor Authentication without
the need for an on premises Azure AD Multi-Factor Authentication server.
Azure AD Multi-Factor Authentication can be configured for intranet or extranet, or
as part of any access control policy.
For more information about Azure AD Multi-Factor Authentication with AD FS, see
Configure AD FS 2016 and Azure AD Multi-Factor Authentication.
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 reevaluated when device attributes change so that you can
always ensure policies are being enforced. This feature 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 aren't 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, see
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 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 an intranet or extranet without providing password.
For more information about using Windows Hello for Business in your organization, see
Enable Windows Hello for Business in your organization.
Secure access to applications

The following changes affect secure access to applications in AD FS.
Modern authentication
AD FS 2016 supports the latest modern protocols that provide a better user experience
for Windows 10 and 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 by 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 by using a wizard driven process to add exceptions
or extra 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 Lightweight
Directory Access Protocol (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 isn't
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

The following changes improve the sign-in experience for AD FS.
Customize sign in experience for AD FS applications

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 themes 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 sign-in or token issuance activity
was either absent 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 more SAML protocol support, including support for importing
trusts based on metadata that contains multiple entities. This change 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

Microsoft 365 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 easier. Add a new Windows Server 2016 server to a Windows Server
2012 R2 farm, and the farm acts at the Windows Server 2012 R2 farm behavior level.
Your server now 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. After all farm nodes are running
Windows Server 2016, you're 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
Article • 08/15/2023
The following are the requirements for deploying Active Directory Federation Services
(AD FS):
Certificate requirements
Hardware requirements
Proxy requirements
AD DS requirements
Configuration database requirements
Browser requirements
Network requirements
Permissions requirements
TLS/SSL Certificates
Each AD FS and Web Application Proxy server has a TLS/SSL certificate to service HTTPS
requests to the federation service. The Web Application Proxy can have extra certificates
to service requests to published applications.
Recommendations for TLS/SSL Certificates

Use the same TLS/SSL certificate for all AD FS federation servers and Web Application
proxies.
Requirements for TLS/SSL Certificates

TLS/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 User Principal Name (UPN) suffix in use in your
organization.
TLS/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 TLS/SSL certificate must be the same (use the same key)
as the federation server TLS/SSL certificate.
If the AD FS property, ExtendedProtectionTokenCheck, is enabled (the default
setting in AD FS), the proxy TLS/SSL certificate must be the same (use the same
key) as the federation server TLS/SSL certificate.
Otherwise, the requirements for the proxy TLS/SSL certificate are the same as the
requirements for the federation server TLS/SSL certificate.
Service Communication Certificate

This certificate isn't required for most AD FS scenarios including Azure AD and Office
365. By default, AD FS configures the TLS/SSL certificate provided upon initial
configuration as the service communication certificate.
Recommendation for Service Communication Certificate
Use the same certificate as you use for TLS/SSL.
Token Signing Certificate

This certificate is used to sign issued tokens to relying parties, so relying party
applications must recognize the certificate and its 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 for Token Signing Certificate

Use the AD FS default, internally generated, self-signed token signing certificates.
Requirements for Token Signing Certificate
If your organization requires that certificates from the enterprise public key
infrastructure (PKI) be used for token signing, you can meet this requirement by
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, those
relying parties can't sign in.
Token Encrypting/Decrypting Certificate

This certificate is used by claims providers who encrypt tokens issued to AD FS.
Recommendation for Token Encrypting/Decrypting Certificate
Use the AD FS default, internally generated, self-signed token decrypting certificates.
Requirements for Token Encrypting/Decrypting Certificate
If your organization requires that certificates from the enterprise PKI be used for
token signing, you can meet this requirement by 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, sign
ins using any claims providers not updated fail.
Ｕ Caution
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 you use x509 user certificate authentication with AD FS, all user certificates
must chain up to a root certification authority that the AD FS and Web Application
Proxy servers trust.
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 need.
The memory and disk requirements for AD FS are fairly static. The requirements are
shown in the following table:
Hardware requirement Minimum requirement Recommended requirement
RAM 2 GB 4 GB
Disk space 32 GB 100 GB
SQL Server Hardware Requirements

If you're using Azure SQL for your AD FS configuration database, size the SQL Server
according to the most basic SQL Server recommendations. The AD FS database size is
small, and AD FS doesn't 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 isn't 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 third-party vendors, see the Frequently asked questions
(FAQ) about AD FS.
AD FS 2016 requires Web Application Proxy servers on Windows Server 2016. A

downlevel proxy can't 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 can't 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 Windows Hello
for Business.
７ Note
All support for environments with Windows Server 2003 domain controllers has
ended. For more information, see the Microsoft lifecycle information .
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 later.
A Windows Server 2008 domain functional level or later is required for client
certificate authentication if the certificate is explicitly mapped to a user's account in
AD DS.
Schema requirements
New installations of AD FS 2016 require the Active Directory 2016 schema
(minimum version 85).
Raising the AD FS farm behavior level (FBL) to the 2016 level requires the Active
Directory 2016 schema (minimum version 85).
Service account requirements

Any standard domain account can be used as a service account for AD FS. Group
Managed Service Accounts are also supported. The permissions required at
runtime are automatically added back when you configure AD FS.
The User Rights Assignment required for the AD service account is Sign-in as a
Service.
The User Rights Assignments required for the NT Service\adfssrv and NT
Service\drs are Generate Security Audits and Sign-in as a Service.
Group managed service accounts require at least one domain controller running
Windows Server 2012 or later. The group Managed Service Account 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 configures this requirement when creating a new AD FS farm. If this
process fails, such as if there's a collision or insufficient permissions, you 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 sign-
in 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 isn't supported in a WID farm.
Token replay detection isn't supported in a WID farm. This functionality is only
used 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 Trusts More than 100 RP Trusts
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 More than 30 AD FS Nodes: Not supported
using WID - SQL Required using WID - SQL Required
SQL Server
For AD FS in Windows Server 2016, SQL Server 2008 and later 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 with 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
TLS/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 firewalls located between the Web Application Proxy and the federation server
farm and between the clients and the Web Application Proxy must have TCP port 443
enabled inbound.
Also, if you need client user certificate authentication (clientTLS authentication using
X509 user certificates) and you don't have port 443 on the certauth endpoint enabled.
AD FS 2016 requires that you enable TCP port 49443 inbound on the firewall between
the clients and the Web Application Proxy. This requirement doesn't apply to the firewall
between the Web Application Proxy and the federation servers.
For more information on hybrid port requirements, see Hybrid Identity Required Ports
and Protocols.
For more 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 demilitarized zone (DMZ) must be able to
resolve AD FS service name to the load balancer for the AD FS servers or the AD FS
server. You can create this configuration by using an alternate Domain Name
System (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, you must configure them to resolve to the
federation server or Web Application Proxy.
Load Balancer requirements

The load balancer must not terminate TLS/SSL. AD FS supports multiple use cases
with certificate authentication, which breaks when terminating TLS/SSL.
Terminating TLS/SSL at the load balancer isn't supported for any use case.
Use a load balancer that supports SNI. In the event it doesn't, using the 0.0.0.0
fallback binding on your AD FS or Web Application Proxy server should provide a
workaround.
Use the HTTP (not HTTPS) health probe endpoints to perform load balancer health
checks for routing traffic. This requirement 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://<AD FS server name>/adfs/probe
http://<Web Application Proxy IP address>/adfs/probe

http://<AD FS IP address>/adfs/probe
It's not recommended to use DNS round robin as a way to load balance. Using this
type of load balancing doesn't provide an automated way to remove a node from
the load balancer using health probes.
It's not recommended to use IP-based session affinity or sticky sessions for
authentication traffic to AD FS within the load balancer. You could 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
doesn't 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
Article • 08/15/2023
This article lists documentation for designing for Active Directory Federation Services in
Windows Server.
AD FS design guide
See also
For capacity planning for AD FS in Windows Server 2016, see the AD FS capacity
planning worksheet .
To learn more, see the Active Directory Federation Services overview.
AD FS design guide
Article • 08/15/2023
The Active Directory Federation Services design guide is a comprehensive guide for
designing AD FS in Windows Server. This guide has the following sections:
AD FS design guide in Windows Server 2012 R2

AD FS design guide in Windows Server 2012
See also
For capacity planning for AD FS in Windows Server 2016, see the AD FS capacity
planning worksheet .
To learn more, see the Active Directory Federation Services overview.
AD FS Design Guide in Windows Server
Article • 08/15/2023
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
Identify Your AD FS Deployment Goals
Plan Your AD FS Deployment Topology
AD FS Requirements
See Also
AD FS Design
Identify Your AD FS Deployment Goals
Article • 08/15/2023
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
AD FS Design Guide in Windows Server 2012 R2
Plan Your AD FS Deployment Topology
Article • 02/08/2023
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 article, 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.
Description Feature Supported by WID? Supported by
SQL Server?
AD FS Federation server farm deployment Yes. A WID farm has a Yes. There is no
features limit of 30 federation enforced limit
servers if you have 100 for the number
or fewer relying party of federation
trusts.
servers that you
can deploy in a
A WID farm does not single farm
support token replay
detection or artifact
resolution (part of the
Security Assertion
Markup Language
(SAML) protocol).
AD FS SAML artifact resolution

No Yes
features
Note: This feature is not required for
Microsoft Online Services, Microsoft
Office 365, Microsoft Exchange, or
Microsoft Office SharePoint
scenarios.
AD FS SAML/WS-Federation token replay No Yes

features detection
Database Basic database redundancy using Yes No

features 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 Database redundancy using high- No Yes

features availability solutions, such as failover
clustering or mirroring (at the
database layer only) Note: All AD FS
deployment topologies support
clustering at the AD FS service layer.
SQL Server considerations

You should consider the following deployment facts if you select SQL Server as the
configuration database for your AD FS deployment.
SAML features and their effect on database size and growth. When either the
SAML artifact resolution or SAML token replay detection features are enabled,
AD FS stores information in the SQL Server configuration database for each AD FS
token that is issued. The growth of the SQL Server database as a result of this
activity is not considered to be significant, and it depends on the configured token
replay retention period. Each artifact record has a size of approximately 30
kilobytes (KB).
Number of servers required for your deployment. You will need to add at least
one additional server (to the total number of servers required to deploy your AD
FS infrastructure) that will act as a dedicated host of the SQL Server instance. If you
plan to use failover clustering or mirroring to provide fault tolerance and scalability
for the SQL Server configuration database, a minimum of two SQL servers is
required.
How the configuration database type you

select may impact hardware resources
The impact to hardware resources on a federation server that is deployed in a farm
using WID as opposed to a federation server that is deployed in a farm using the
SQL Server database is not significant. However, it is important to consider that when
you use WID for the farm, each federation server in that farm must store, manage, and
maintain replication changes for its local copy of the AD FS configuration database while
also continuing to provide the normal operations that the Federation Service requires.
In comparison, federation servers that are deployed in a farm that uses the SQL Server
database do not necessarily contain a local instance of the AD FS configuration
database. Therefore, they may make slightly fewer demands on hardware resources.
Where to place a federation server

As a security best practice, place AD FS federation servers 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 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 articles 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.
See Also
Federation Server Farm Using WID
Federation Server Farm Using WID and Proxies
Federation Server Farm Using SQL Server

Legacy AD FS Federation Server Farm
Using WID
Article • 08/15/2023
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.
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 Microsoft Office 365
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.
SQL 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
Using WID and Proxies
Article • 08/15/2023
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
both their internal users and external users (who are logged on to computers that
are physically located outside the corporate network) with single sign-on (SSO)
access to federated applications or services
Organizations that need to provide both their internal users and external users
with SSO access to Microsoft Office 365
Smaller organizations that have external users and require redundant, scalable
services

The same benefits as listed for the Federation Server Farm Using WID topology,
plus the benefit of providing additional access for external users

The same limitations as listed for the Federation Server Farm Using WID topology
1-30 AD FS Nodes: WID supported 1-30 AD FS Nodes: Not supported using

WID - SQL Required

recommendations
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.
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
Using SQL Server
Article • 08/15/2023
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

recommendations
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).
federation servers or web application proxies, see "Name Resolution Requirements"
section in AD FS Requirements and Plan the Web Application Proxy Infrastructure (WAP).
High Availability Options for SQL Server Farms

In Windows Server 2012 R2, AD FS there are two new options to support high
availability in AD FS farms using SQL Server.
Support for SQL Server AlwaysOn Availability Groups
Support for geographically distributed high availability using SQL Server merge
replication
This section describes each of these options, what problems they respectively solve, and
some key considerations for deciding which options to deploy.
７ Note
AD FS farms that use Windows Internal Database (WID) provide basic data
redundancy with read/write access on the primary federation server node and read-
only access on secondary nodes. This can be used in a geographically local or a
geographically distributed topology.
When using WID be aware of the following limitations:
A WID farm 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:
SQL Required
AlwaysOn Availability Groups

Overview
AlwaysOn Availability groups were introduced in SQL Server 2012 and provide a new
way to create a high availability SQL Server instance. AlwaysOn Availability groups
combine elements of clustering and database mirroring for redundancy and failover at
both the SQL instance layer and the database layer. Unlike previous high availability
options, AlwaysOn Availability groups do not require a common storage (or storage
area network) at the database layer.
An availability group is comprised of a primary replica (a set of read-write primary

databases) and one to four availability replicas (sets of corresponding secondary
databases). The availability group supports a single read-write copy (the primary
replica), and one to four read-only availability replicas. Each availability replica must
reside on a different node of a single Windows Server Failover Clustering (WSFC)
cluster. For more information on AlwaysOn Availability groups see Overview of
AlwaysOn Availability Groups (SQL Server).
From the perspective of the nodes of an AD FS SQL Server farm, the AlwaysOn
Availability group replaces the single SQL Server instance as the policy / artifact
database. The availability group listener is what the client (the AD FS security token
service) uses to connect to SQL.
The following diagram shows an AD FS SQL Server Farm with AlwaysOn Availability
group.
７ Note
AlwaysOn Availability groups require that the SQL Server instances reside on
Windows Server Failover Clustering (WSFC) nodes.
７ Note
Only one availability replica can act as an automatic failover target, the other three
will rely on manual failovers.
Key Deployment Considerations
If you plan to use AlwaysOn Availability groups in combination with SQL Server merge
replication, please take note of the issues described under "Key Deployment
Considerations for using AD FS with SQL Server Merge Replication" below. In particular,
when an AlwaysOn availability group containing a database that is a replication
subscriber fails over, the replication subscription fails. To resume replication, a
replication administrator must manually reconfigure the subscriber. See the SQL Server
description of specific issue at Replication Subscribers and AlwaysOn Availability Groups
(SQL Server) and overall support statements for AlwaysOn Availability groups with
replication options at Replication, Change Tracking, Change Data Capture, and
AlwaysOn Availability Groups (SQL Server).
Configuring AD FS to use an AlwaysOn Availability group
Configuring an AD FS farm with AlwaysOn Availability groups requires a slight

modification to the AD FS deployment procedure:
1. The databases you wish to back up must be created before the AlwaysOn
Availability groups can be configured. AD FS creates its databases as part of the
setup and initial configuration of the first federation service node of a new AD FS
SQL Server farm. As part of the AD FS configuration, you must specify an SQL
connection string, so you will have to configure the first AD FS farm node to
connect to a SQL instance directly (this is only temporary). For specific guidance
on configuring an AD FS farm, including configuring an AD FS farm node with a
SQL server connection string, see Configure a Federation Server.
2. Once the AD FS databases have been created, assign them to AlwaysOn

Availability groups and create the common TCPIP listener using SQL Server tools
and process at Creation and Configuration of Availability Groups (SQL Server).
3. Finally, use PowerShell to edit the AD FS properties to update the SQL connection
string to use the DNS address of the AlwaysOn Availability group's listener.
Example PSH commands to update the SQL connection string for the AD FS
configuration database:
PS:\>$temp= Get-WmiObject -namespace root/ADFS -class

SecurityTokenService
PS:\>$temp.ConfigurationdatabaseConnectionstring="data source=
<SQLCluster\SQLInstance>; initial catalog=adfsconfiguration;integrated
security=true"
PS:\>$temp.put()
4. Example PSH commands to update the SQL connection string for the AD FS
artifact resolution service database:
PS:\> Set-AdfsProperties –artifactdbconnection "Data source=

<SQLCluster\SQLInstance >;Initial Catalog=AdfsArtifactStore;Integrated
Security=True"
SQL Server Merge Replication

Also introduced in SQL Server 2012, merge replication allows for AD FS policy data
redundancy with the following characteristics:
Read and write capability on all nodes (not just the primary)
Smaller amounts of data replicated asynchronously to avoid introducing latency to

the system
The following diagram shows a geographically redundant AD FS SQL Server farms with
merge replication (1 publisher, 2 subscribers):
Key Deployment Considerations for using AD FS with SQL Server Merge Replication
(note numbers in the diagram above)
The distributor database is not supported for use with AlwaysOn Availability
Groups or database mirroring. See SQL Server support statements for AlwaysOn
Availability groups with replication options at Replication, Change Tracking,
Change Data Capture, and AlwaysOn Availability Groups (SQL Server).
When an AlwaysOn availability group containing a database that is a replication
subscriber fails over, the replication subscription fails. To resume replication, a
replication administrator must manually reconfigure the subscriber. See the SQL
Server description of specific issue at Replication Subscribers and AlwaysOn
Availability Groups (SQL Server) and overall support statements for AlwaysOn
Availability groups with replication options Replication, Change Tracking, Change
Data Capture, and AlwaysOn Availability Groups (SQL Server).
For more detailed instructions on how to configure AD FS to use a SQL Server merge
replication, see Setup Geographic Redundancy with SQL Server Replication.
See Also
AD FS Requirements for Windows
Server
Article • 08/15/2023
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're setting up a federation
server or a proxy computer, as described in this section.
Federation server certificates

Certificate type Requirements, Support & Things to Know
Secure Sockets Layer (SSL) - This certificate must be a publicly trusted* X509 v3
certificate: This is a standard SSL certificate.
certificate that is used for - All clients that access any AD FS endpoint must trust this
securing communications certificate. It's strongly recommended to use certificates that
between federation servers and are issued by a public (third-party) certification authority (CA).
clients. 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.
- Doesn't 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'll be prompted to provide the service name
for the AD FS service (for example, adfs.contoso.com.
- It's strongly recommended to use the same SSL certificate
for the Web Application Proxy. This is however required to be
the same when supporting Windows Integrated
Authentication endpoints through the Web Application Proxy
and when Extended Protection Authentication is turned on
(default setting).
- The Subject name of this certificate is used to represent the
Federation Service name for each instance of AD FS that you
deploy. For this reason, you may want to consider choosing a
Subject name on any new CA-issued certificates that best
represents the name of your company or organization to
partners.
The identity of the certificate must match the federation
service name (for example, fs.contoso.com).The identity is
either a subject alternative name extension of type dNSName
or, if there are no subject alternative name entries, the subject
name specified as a common name. Multiple subject
alternative name entries can be present in the certificate,
provided one of them matches the federation service name.
- Important: it's strongly recommended to use the same SSL
certificate across all nodes of your AD FS farm as well as all
Web Application proxies in your AD FS farm.
Service communication - By default, the SSL certificate is used as the service

certificate: This certificate communications certificate. But you also have the option to
enables WCF message security configure another certificate as the service communication
for securing communications certificate.

between federation servers. - Important: if you're 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 doesn't 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 can't be a certificate
that uses CNG keys.
- This certificate can be managed using the AD FS
Management console.
Token-signing certificate: This is - By default, AD FS creates a self-signed certificate with 2048

a standard X509 certificate that bit keys.
is used for securely signing all - CA issued certificates are also supported and can be
tokens that the federation server changed using the AD FS Management snap-in
issues. - CA issued certificates must be stored & accessed through a
CSP Crypto Provider.
- The token signing certificate can't be a certificate that uses
CNG keys.
- AD FS doesn't 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 doesn't perform automatic certificate renewal
or rollover. This process must be performed by an
administrator.
To allow for certificate rollover when one certificate is close to
expiring, a secondary token signing certificate can be
configured in AD FS. By default, all token signing certificates
are published in federation metadata, but only the primary
token-signing certificate is used by AD FS to actually sign

tokens.
Token-decryption/encryption - By default, AD FS creates a self-signed certificate with 2048

certificate: This is a standard bit keys.
X509 certificate that is used to - CA issued certificates are also supported and can be
decrypt/encrypt any incoming changed using the AD FS Management snap-in
tokens. It's also published in - CA issued certificates must be stored & accessed through a
federation metadata. CSP Crypto Provider.
- The token-decryption/encryption certificate can't 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 doesn't require externally enrolled certificates for this
purpose.
In addition, AD FS automatically renews these self-signed
certificates before they expire.
We recommend that you use the default, automatically
generated certificates for token decryption.
If your organization has policies that require different
certificates to be configured for token decryption, you can
specify the certificates at installation time using PowerShell
(use the –DecryptionCertificateThumbprint parameter of the
Install-AdfsFarm cmdlet). After installation, you can view and
manage token decryption certificates using the AD FS
Management console or PowerShell cmdlets Set-
AdfsCertificate and Get-AdfsCertificate.
When externally enrolled certificates are used for token
decryption, AD FS doesn't perform automatic certificate
renewal. This process must be performed by an
administrator.
- The AD FS service account must have access to the token-
signing certificate's private key in the personal store of the
local computer. This is taken care of by Setup. You can also
use the AD FS Management snap-in to ensure this access if
you subsequently change the token-signing certificate.
Ｕ Caution
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 doesn't 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 doesn't 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 can't 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 doesn't 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.
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
A WID farm has a limit of 30 federation servers if you've 100 or fewer relying party
trusts.
Artifact resolution profile in SAML 2.0 isn't supported in the WID configuration
database. Token Replay Detection isn't 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 doesn't exceed 30.
The following table provides a summary for using a WID farm. Use it to plan your
implementation.
SQL Required
SQL Server
For AD FS in Windows Server 2012 R2, you can use SQL Server 2008 and higher
When AD FS authentication is performed via a browser or browser control, your browser
must comply to the following requirements:
JavaScript must be enabled
Cookies must be turned on
Server Name Indication (SNI) must be supported
For user certificate & device certificate authentication (workplace join

functionality), the browser must support SSL client certificate authentication
Several key browsers and platforms have undergone validation for rendering and
functionality the details of which are listed below. Browsers and devices that not covered
in this table are still supported if they meet the requirements listed above:
Browsers Platforms
IE 10.0 Windows 7, Windows 8.1, Windows Server 2008 R2, Windows

Browsers Platforms
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 Windows 8.1

Authentication Broker
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 isn't functional on Windows platforms. Firefox doesn't 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 isn't configured
to allow these cookies, AD FS can't 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. `
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 isn't required on the firewall between the Web Application Proxy and the
federation servers).
７ Note
Also make sure that port 49443 isn't 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's also required that the service account for the AD FS service has the right to retrieve
user information in the LDAP attribute store.
SQL Server Attribute Stores
For AD FS in Windows Server 2012 R2 to operate successfully, computers that host the
SQL Server attribute store must be running either Microsoft SQL Server 2008 or higher.
When you work with SQL-based attribute stores, you also must configure a connection
string.
Custom Attribute Stores
You can develop custom attribute stores to enable advanced scenarios.
The policy language that is built into AD FS can reference custom attribute stores
so that any of the following scenarios can be enhanced:
Creating claims for a locally authenticated user
Supplementing claims for an externally authenticated user
Authorizing a user to obtain a token
Authorizing a service to obtain a token on behavior of a user
Issuing additional data in security tokens issued by AD FS to relying parties.
All custom attribute stores must be built on top of .NET 4.0 or higher.
When you work with a custom attribute store, you might also have to configure a
connection string. In that case, you can enter a custom code of your choice that enables
a connection to your custom attribute store. The connection string in this situation is a
set of name/value pairs that are interpreted as implemented by the developer of the
custom attribute store.For more information about developing and using custom
attribute stores, see Attribute Store Overview.
AD FS supports claims-aware applications that use the following protocols:
WS-Federation
WS-Trust
SAML 2.0 protocol using IDPLite, SPLite & eGov1.5 profiles.
OAuth 2.0 Authorization Grant Profile
AD FS also supports authentication and authorization for any non-claims-aware

applications that are supported by the Web Application Proxy.
AD DS Authentication (Primary Authentication)
For intranet access, the following standard authentication mechanisms for AD DS are
supported:
Windows Integrated Authentication using Negotiate for Kerberos & NTLM
Forms Authentication using username/passwords
Certificate Authentication using certificates mapped to user accounts in AD DS
For extranet access, the following authentication mechanisms are supported:
Forms Authentication using username/passwords
Certificate Authentication using certificates that are mapped to user accounts in

AD DS
Windows Integrated Authentication using Negotiate (NTLM only) for WS-Trust

endpoints that accept Windows Integrated Authentication.
For Certificate Authentication:
Extends to smartcards that can be pin protected.
The GUI for the user to enter their pin isn't 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
For seamless Windows Integrated Authentication using Kerberos in the intranet,
It's 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 Windows Server 2012 R2.
The subject alternative name of the SSL certificate for AD FS service must contain
the value enterpriseregistration that is followed by the User Principal Name (UPN)
suffix of your organization, for example, enterpriseregistration.corp.contoso.com.
Cryptography requirements
The following table provides additional cryptography support information on the AD FS
token signing, token encryption/decryption functionality:
Algorithm Key Protocols/Applications/Comments
lengths
TripleDES – Default 192 (Supported 192 – 256) - >= 192 Supported algorithm for
http://www.w3.org/2001/04/xmlenc#tripledes- Decrypting the security token.
cbc Encrypting the security token with
this algorithm isn't supported.
AES128 - 128 Supported algorithm for

http://www.w3.org/2001/04/xmlenc#aes128- Decrypting the security token.
AES192 - 192 Supported algorithm for

http://www.w3.org/2001/04/xmlenc#aes192- Decrypting the security token.
AES256 - 256 Default. Supported algorithm for

http://www.w3.org/2001/04/xmlenc#aes256- Encrypting the security token.
cbc
TripleDESKeyWrap - All Key Supported algorithm for

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

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


RsaV15KeyWrap - 1024 Supported algorithm for

http://www.w3.org/2001/04/xmlenc#rsa-1_5 Encrypting the symmetric key that
RsaOaepKeyWrap - 1024 Default. Supported algorithm for

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

http://www.w3.org/PICS/DSig/SHA1_1_0.html SourceId generation: In this
scenario, the STS uses SHA1 (per
Algorithm Key Protocols/Applications/Comments
lengths
the recommendation in the SAML

2.0 standard) to create a short 160
bit value for the artifact sourceiD.
Also used by the AD FS 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) can't
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
Article • 08/15/2023
７ 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
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

Identifying Your AD FS Deployment
Goals
Article • 08/15/2023
Correctly identifying your Active Directory Federation Services (AD FS) deployment goals

is essential for the success of your AD FS design project. Depending on the size of your
organization and the level of involvement that you want to provide for the information
technology (IT) staff in any partner organizations, form a project team that can clearly
articulate real-world deployment issues in a vision statement. Make sure that the
members of this team understand the direction in which your deployment project must
move in order to reach your AD FS deployment goals.
When you write your vision statement, identify, clarify, and refine your deployment
goals. Prioritize and, possibly, combine your deployment goals so that you can design
and deploy AD FS by using an iterative approach. You can take advantage of existing,
documented, and predefined AD FS deployment goals that are relevant to the AD FS
designs and develop a working solution for your situation.
The following table lists the tasks for articulating, refining, and documenting your AD FS
deployment goals.
Task Reference links
Evaluate predefined AD FS deployment goals that are - Provide Your Active Directory Users
provided in this section of the guide, and combine one Access to Your Claims-Aware
or more goals to reach your organizational objectives 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
Map one goal or a combination of any of the predefined - Mapping Your Deployment Goals to
AD FS deployment goals to an existing AD FS design an AD FS Design
See Also
AD FS Design Guide in Windows Server 2012
Provide Your Active Directory Users
Access to Your Claims-Aware
Applications and Services
Article • 08/15/2023
When you are an administrator in the account partner organization in an

Active Directory Federation Services (AD FS) deployment and you have a deployment
goal to provide single-sign-on (SSO) access for employees on the corporate network to
your hosted resources:
Employees who are logged on to an Active Directory forest in the corporate

network can use SSO to access multiple applications or services in the perimeter
network in your own organization. These applications and services are secured by
AD FS.
For example, Fabrikam may want corporate network employees to have federated
access to Web-based applications that are hosted in the perimeter network for
Fabrikam.
Remote employees who are logged on to an Active Directory domain can obtain

AD FS tokens from the federation server in your organization to gain federated
access to AD FS-secured Web-based applications or services that also reside in
your organization.
Information in the Active Directory attribute store can be populated into the

employees' AD FS tokens.
The following components are required for this deployment goal:
Active Directory Domain Services (AD DS): AD DS contains the employees' user

accounts that are used to generate AD FS tokens. Information, such as group
memberships and attributes, is populated into AD FS tokens as group claims and
custom claims.
７ Note
You can also use Lightweight Directory Access Protocol (LDAP) or Structured
Query Language (SQL) to contain the identities for AD FS token generation.
Corporate DNS: This implementation of Domain Name System (DNS) contains a
simple host (A) resource record so that intranet clients can locate the account
federation server. This implementation of DNS may also host other DNS records
that are required in the corporate network. For more information, see Name
Resolution Requirements for Federation Servers.
Account partner federation server: This federation server is joined to a domain in

the account partner forest. It authenticates employee user accounts and generates
AD FS tokens. The client computer for the employee performs Windows Integrated
Authentication against this federation server to generate an AD FS token. For more
information, see Review the Role of the Federation Server in the Account Partner.
The account partner federation server can authenticate the following users:
Employees with user accounts in this domain
Employees with user accounts anywhere in this forest
Employees with user accounts anywhere in forests that are trusted by this forest
(through a two-way Windows trust)
Employee: An employee accesses a Web-based service (through an application) or

a Web-based application (through a supported Web browser) while he or she is
logged on to the corporate network. The employee's client computer on the
corporate network communicates directly with the federation server for
authentication.
After reviewing the information in the linked topics, you can begin deploying this goal
by following the steps in Checklist: Implementing a Federated Web SSO Design.
The following illustration shows each of the required components for this AD FS
deployment goal.
See Also
Provide Your Active Directory Users
Access to the Applications and Services
of Other Organizations
Article • 08/15/2023
This Active Directory Federation Services (AD FS) deployment goal builds on the goal in
Provide Your Active Directory Users Access to Your Claims-Aware Applications and
Services.
When you are an administrator in the account partner organization and you have a
deployment goal to provide federated access for employees to hosted resources in
another organization:
Employees who are logged on to an Active Directory domain in the corporate

network can use single-sign-on (SSO) functionality to access multiple Web-based
applications or services, which are secured by AD FS, when the applications or
services are in a different organization. For more information, see Federated Web
SSO Design.
For example, Fabrikam may want corporate network employees to have federated
access to Web services that are hosted in Contoso.
Remote employees who are logged on to an Active Directory domain can obtain

AD FS tokens from the federation server in your organization to gain federated
access to AD FS–secured Web-based applications or services that are hosted in
another organization.
For example, Fabrikam may want its remote employees to have federated access to
AD FS–secured services that are hosted in Contoso, without requiring the Fabrikam
employees to be on the Fabrikam corporate network.
In addition to the foundational components that are described in Provide Your Active
Directory Users Access to Your Claims-Aware Applications and Services and that are
shaded in the following illustration, the following components are required for this
deployment goal:
Account partner federation server proxy: Employees that access the federated
service or application from the Internet can use this AD FS component to perform
authentication. By default, this component performs forms authentication, but it
can also perform basic authentication. You can also configure this component to
perform Secure Sockets Layer (SSL) client authentication if employees at your
organization have certificates to present. For more information, see Where to Place
a Federation Server Proxy.
Perimeter DNS: This implementation of Domain Name System (DNS) provides the
host names for the perimeter network. For more information about how to
configure perimeter DNS for a federation server proxy, see Name Resolution
Requirements for Federation Server Proxies.
Remote employee: The remote employee accesses a Web-based application

(through a supported Web browser) or a Web-based service (through an
application), using valid credentials from the corporate network, while the
employee is offsite using the Internet. The employee's client computer in the
remote location communicates directly with the federation server proxy to
generate a token and authenticate to the application or service.
by following the steps in Checklist: Implementing a Federated Web SSO Design.
deployment goal.
See Also
Provide Users in Another Organization
Access to Your Claims-Aware
Applications and Services
Article • 08/15/2023
When you are an administrator in the resource partner organization in Active Directory

Federation Services (AD FS) and you have a deployment goal to provide federated
access for users in another organization (the account partner organization) to a claims-
aware application or a Web-based service that is located in your organization (the
resource partner organization):
Federated users both in your organization and in organizations who have

configured a federation trust to your organization (account partner organizations)
can access the AD FS secured application or service that is hosted by your
organization. For more information, see Federated Web SSO Design.
For example, Fabrikam may want its corporate network employees to have
federated access to Web services that are hosted in Contoso.
Federated users who have no direct association with a trusted organization (such
as individual customers), who are logged on to an attribute store that is hosted in
your perimeter network, can access multiple AD FS-secured applications, which are
also hosted in your perimeter network, by logging on one time from client
computers that are located on the Internet. In other words, when you host
customer accounts to enable access to applications or services in your perimeter
network, customers that you host in an attribute store can access one or more
applications or services in the perimeter network simply by logging on once. For
more information, see Web SSO Design.
For example, Fabrikam may want its customers to have single-sign-on (SSO) access
to multiple applications or services that are hosted in its perimeter network.
The following components are required for this deployment goal:
Active Directory Domain Services (AD DS): The resource partner federation server

must be joined to an Active Directory domain.
Perimeter DNS: Domain Name System (DNS) should contain a simple host (A)
resource record so that client computers can locate the resource partner
federation server and the Web server. The DNS server may host other DNS records
that are also required in the perimeter network. For more information, see Name
Resource partner federation server: The resource partner federation server

validates AD FS tokens that the account partners send. Account partner discovery
is performed through this federation server. For more information, see Review the
Role of the Federation Server in the Resource Partner.
Web server: The Web server can host either a Web application or a Web service.
The Web server confirms that it receives valid AD FS tokens from federated users
before it allows access to the protected Web application or Web service.
By using Windows Identity Foundation (WIF), you can develop your Web
application or service so that it accepts federated user logon requests that are
made with any standard logon method, such as user name and password.
by following the steps in Checklist: Implementing a Federated Web SSO Design and
Checklist: Implementing a Web SSO Design.
deployment goal.
See Also
Mapping Your Deployment Goals to an
AD FS Design
Article • 08/15/2023
After you finish reviewing the existing Active Directory Federation Services (AD FS)
deployment goals and you determine which goals are related to your deployment, you
can map those goals to a specific AD FS design. For more information about AD FS
predefined deployment goals, see Identifying Your AD FS Deployment Goals.
Use the following table to determine which AD FS design maps to the appropriate
combination of AD FS deployment goals for your organization. This table refers only to
the two primary AD FS designs, as described in this guide. However, you can create a
hybrid or custom AD FS design by using any combination of the AD FS deployment
goals to meet the needs of your organization.
AD FS deployment goal Web SSO Federated Web SSO

Design Design
Provide Your Active Directory Users Access to Your No Yes, in the account
Claims-Aware Applications and Services partner
Provide Your Active Directory Users Access to the No Yes, optional in the
Applications and Services of Other Organizations account partner
Provide Users in Another Organization Access to Your Yes Yes

Claims-Aware Applications and Services
See Also
Web SSO Design
Article • 08/15/2023
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
Article • 08/15/2023
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
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
Determine Your AD FS Deployment
Topology
Article • 08/15/2023
The first step in planning a deployment of Active Directory Federation Services (AD FS) is

to determine the right deployment topology to meet the single sign-on (SSO) needs of
your organization. The topics in this section describe the various deployment topologies
that you can use with AD FS. They also describe the benefits and limitations associated
with each deployment topology so that you can select the most appropriate topology
for your specific business needs.
Before you read this deployment topology topic, we recommend that you first complete
the tasks in the order shown in the following table.
Recommended task Description Reference
Review how AD FS data is Understand the purpose of and the replication The Role of the
stored and replicated to methods that can be used for the underlying AD FS
other federation servers data that is stored in the AD FS configuration Configuration
in a federation server database. This topic introduces the concepts of Database
farm. the configuration database and describes the
two database types: Windows Internal Database
(WID) and Microsoft SQL Server.
Select the type of AD FS Review the various benefits and limitations that AD FS
configuration database are associated with using either WID or SQL Deployment
that you will deploy in Server as the AD FS configuration database, Topology
your organization. along with the various application scenarios that Considerations
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

Federation Server Farm Using WID and Proxies
Federation Server Farm Using SQL Server
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
Article • 08/15/2023
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
Feature Supported by Supported by SQL More information

WID? Server? about this feature
Federation server farm Yes, with a limit Yes. There is no Determine Your AD
deployment of 30 federation enforced limit for the FS Deployment
servers for each number of federation Topology
farm servers that you can
deploy in a single
farm
SAML artifact resolution Note: No Yes The Role of the AD

This feature is not required for FS Configuration
Microsoft Online Services, Database
Microsoft Office 365, Microsoft
Feature Supported by Supported by SQL More information
WID? Server? about this feature
Exchange, or Microsoft Office Best Practices for

SharePoint scenarios. Secure Planning
and Deployment of
AD FS
SAML/WS-Federation token No Yes The Role of the AD

replay detection FS Configuration
Database
Best Practices for

Secure Planning
and Deployment of
AD FS
Database features
Feature Supported Supported More

by WID? by SQL information
Server? about this
feature
Basic database redundancy using pull Yes No The Role of the AD

replication, where one or more servers FS Configuration
hosting a read-only copy of the database Database
request changes that are made on a source
server that hosts a read/write copy of the
database
Database redundancy using high-availability No Yes The Role of the AD

solutions, such as failover clustering or FS Configuration
mirroring (at the database layer only) Note: Database
All AD FS deployment topologies support
clustering at the AD FS service layer. High Availability
Solutions
Overview
SQL Server considerations

You should consider the following deployment facts if you select SQL Server as the
configuration database for your AD FS deployment.
SAML features and their effect on database size and growth. When either the
SAML artifact resolution or SAML token replay detection features are enabled, AD
FS stores information in the SQL Server configuration database for each AD FS
token that is issued. The growth of the SQL Server database as a result of this
activity is not considered to be significant, and it depends on the configured token
replay retention period. Each artifact record has a size of approximately 30
kilobytes (KB).
Number of servers required for your deployment. You will need to add at least
one additional server (to the total number of servers required to deploy your AD
FS infrastructure) that will act as a dedicated host of the SQL Server instance. If you
plan to use failover clustering or mirroring to provide fault tolerance and scalability
for the SQL Server configuration database, a minimum of two SQL servers is
required.
How the configuration database type you select may

impact hardware resources
The impact to hardware resources on a federation server that is deployed in a farm
using WID as opposed to a federation server that is deployed in a farm using the SQL
Server database is not significant. However, it is important to consider that when you
use WID for the farm, each federation server in that farm must store, manage, and
maintain replication changes for its local copy of the AD FS configuration database while
also continuing to provide the normal operations that the Federation Service requires.
In comparison, federation servers that are deployed in a farm that uses the SQL Server
database do not necessarily contain a local instance of the AD FS configuration
database. Therefore, they may make slightly fewer demands on hardware resources.
Verifying that your production environment

can support an AD FS deployment
In addition to the federation servers that you will deploy, and depending on how your
existing production environment is set up, the following additional servers may be
required to provide the necessary infrastructure to support your new AD FS deployment:
Active Directory domain controller
Certification authority (CA)
Web server to host federation metadata
Network load balancing (NLB)
See Also
Stand-Alone Federation Server Using
WID
Article • 08/15/2023
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

limitations that are 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
Article • 02/08/2023
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.
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.
７ Note
We recommend the use of at least two federation servers in a load-balanced

configuration.

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 Microsoft Office 365
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 30 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).

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.
federation servers, see Name Resolution Requirements for Federation Servers in the AD
FS Design Guide.
See Also
Federation Server Farm Using WID and
Proxies
Article • 08/15/2023
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.

both their internal users and external users (who are logged on to computers that
are physically located outside the corporate network) with single sign-on (SSO)
access to federated applications or services
Organizations that need to provide both their internal users and external users
with SSO access to Microsoft Office 365
Smaller organizations that have external users and require redundant, scalable
services

The same benefits as listed for the Federation Server Farm Using WID topology,
plus the benefit of providing additional access for external users

The same limitations as listed for the Federation Server Farm Using WID topology
recommendations
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 servers or federation server proxies, see either Name Resolution
Requirements for Federation Servers or Name Resolution Requirements for Federation
Server Proxies.
See Also
Federation Server Farm Using SQL
Server
Article • 08/15/2023
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

recommendations
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 servers or federation server proxies, see either Name Resolution
Requirements for Federation Servers or Name Resolution Requirements for Federation
Server Proxies.
See Also
Planning Your Deployment
Article • 08/15/2023
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
Article • 08/15/2023
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
Article • 08/15/2023
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 complement 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
Because AD FS is fundamentally an authentication system, it should be treated as a

"Tier 0" system like other identity systems on your network. For more information,
see Active Directory administrative tier model.
Use the Security Configuration Wizard to apply AD FS-specific security best

practices to federation servers and federation server proxy computers
The Security Configuration Wizard (SCW) is a tool that comes preinstalled on all
Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012
computers. You can use it to apply security best practices that can help reduce the
attack surface for a server, based on the server roles that you are installing.
When you install AD FS, the setup program creates role extension files that you can
use with the SCW to create a security policy that will apply to the specific AD FS
server role (either federation server or federation server proxy) that you choose
during setup.
Each role extension file that is installed represents the type of role and subrole for
which each computer is configured. The following role extension files are installed
in the C:WindowsADFSScw directory:
Farm.xml
SQLFarm.xml
StandAlone.xml
Proxy.xml (This file is present only if you configured the computer in the
federation server proxy role.)
To apply the AD FS role extensions in the SCW, complete the following steps in
order:
1. Install AD FS and choose the appropriate server role for that computer. For
more information, see Install the Federation Service Proxy Role Service in the
AD FS Deployment Guide.
2. Register the appropriate role extension file using the Scwcmd command-line
tool. See the following table for details about using this tool in the role for
which your computer is configured.
3. Verify that the command has completed successfully by examining the

SCWRegister_log.xml file, which is located in the WindowssecurityMsscwLogs
directory.
You must perform all these steps on each federation server or federation server
proxy computer to which you want to apply AD FS–based SCW security policies.
The following table explains how to register the appropriate SCW role extension,
based on the AD FS server role that you chose on the computer where you
installed AD FS.
AD FS server AD FS Type the following command at a command

role configuration prompt:
database used
Stand-alone Windows Internal scwcmd register /kbname:ADFS2Standalone

federation Database /kbfile:"WindowsADFSscwStandAlone.xml"
server
Farm-joined Windows Internal scwcmd register /kbname:ADFS2Standalone

federation Database /kbfile:"WindowsADFSscwFarm.xml"
server
Farm-joined SQL Server scwcmd register /kbname:ADFS2Standalone

federation /kbfile:"WindowsADFSscwSQLFarm.xml"
server
Federation N/A scwcmd register /kbname:ADFS2Standalone

server proxy /kbfile:"WindowsADFSscwProxy.xml"
For more information about the databases that you can use with AD FS, see The
Role of the AD FS Configuration Database.
Use token replay detection in situations in which security is a very important

concern, for example, when kiosks are used. Token replay detection is a feature of
AD FS that ensures that any attempt to replay a token request that is made to the
Federation Service is detected and the request is discarded. Token replay detection
is enabled by default. It works for both the WS-Federation passive profile and the
Security Assertion Markup Language (SAML) WebSSO profile by ensuring that the
same token is never used more than once.
When the Federation Service starts, it begins to build a cache of any token
requests that it fulfills. Over time, as subsequent token requests are added to the
cache, the ability to detect any attempts to replay a token request multiple times
increases for the Federation Service. If you disable token replay detection and later
choose to enable it again, remember that the Federation Service will still accept
tokens for a period of time that may have been used previously, until the replay
cache has been allowed enough time to rebuild its contents. For more information,
see The Role of the AD FS Configuration Database.
Use token encryption, especially if you are using supporting SAML artifact
resolution.
Encryption of tokens is strongly advised to increase security and protection against

potential man-in-the-middle (MITM) attacks that might be tried against your AD
FS deployment. Using use encryption might have a slight impact on throughout
but in general, it should not be usually noticed and in many deployments the
benefits for greater security exceed any cost in terms of server performance.
To enable token encryption, first set add an encryption certificate for your relying
party trusts. You can configure an encryption certificate either when creating a
relying party trust or later. To add an encryption certificate later to an existing
relying party trust, you can set a certificate for use on the Encryption tab within
trust properties while using the AD FS snap-in. To specify a certificate for an
existing trust using the AD FS cmdlets, use the EncryptionCertificate parameter of
either the Set-ClaimsProviderTrust or Set-RelyingPartyTrust cmdlets. To set a
certificate for the Federation Service to use when decrypting tokens, use the Set-
ADFSCertificate cmdlet and specify " Token-Encryption " for the CertificateType
parameter. Enabling and disabling encryption for specific relying party trust can be
done by using the EncryptClaims parameter of the Set-RelyingPartyTrust cmdlet.
Utilize extended protection for authentication

To help secure your deployments, you can set and use the extended protection for
authentication feature with AD FS. This setting specifies the level of extended
protection for authentication supported by a federation server.
Extended protection for authentication helps protect against man-in-the-middle

(MITM) attacks, in which an attacker intercepts client credentials and forwards
them to a server. Protection against such attacks is made possible through a
Channel Binding Token (CBT) which can be either required, allowed, or not required
by the server when it establishes communications with clients.
To enable the extended protection feature, use the

ExtendedProtectionTokenCheck parameter on the Set-ADFSProperties cmdlet.
Possible values for this setting and the level of security that the values provide are
Parameter Security level Protection setting

Value
Require Server is fully Extended protection is enforced and always

hardened. required.
Allow Server is partially Extended protection is enforced where systems

hardened. involved have been patched to support it.
None Server is Extended protection is not enforced.

vulnerable.
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 login, or filter out any PII or sensitive data in your logs before you
share them with others.
The following tips can help you prevent the content of a log file from being
exposed unintentionally:
Ensure that the AD FS event log and trace log files are protected by access
control lists (ACL) that limit access to only those trusted administrators who
require access to them.
Do not copy or archive log files using file extensions or paths that can be easily
served using a Web request. For example, the .xml file name extension is not a
safe choice. You can check the Internet Information Services (IIS) administration
guide to see a list of extensions that can be served.
If you revise the path to the log file, be sure to specify an absolute path for the
log file location, which should be outside of the Web host virtual root (vroot)
public directory to prevent it from being accessed by an external party using a
Web browser.
AD FS Extranet Soft Lockout and AD FS Extranet Smart Lockout Protection
In case of an attack in the form of authentication requests with invalid(bad)

passwords that come through the Web Application Proxy, AD FS extranet lockout
enables you to protect your users from an AD FS account lockout. In addition to
protecting your users from an AD FS account lockout, AD FS extranet lockout also
protects against brute force password guessing attacks.
For Extranet Soft Lockout for AD FS on Windows Server 2012 R2 see AD FS

Extranet Soft Lockout Protection.
For Extranet Smart Lockout for AD FS on Windows Server 2016 see AD FS Extranet
Smart Lockout Protection.
SQL Server–specific security best practices for

AD FS
The following security best practices are specific to the use of Microsoft SQL Server® or
Windows Internal Database (WID) when these database technologies are used to
manage data in AD FS design and deployment.
７ Note
These recommendations are meant to extend, but not replace, SQL Server product
security guidance. For more information about planning a secure SQL Server
installation, see Security Considerations for a Secure SQL Installation
(https://go.microsoft.com/fwlink/?LinkID=139831 ).
Always deploy SQL Server behind a firewall in a physically secure network
environment.
A SQL Server installation should never be exposed directly to the Internet. Only

computers that are inside your datacenter should be able to reach your SQL server
installation that supports AD FS. For more information, see Security Best Practices
Checklist (https://go.microsoft.com/fwlink/?LinkID=189229 ).
Run SQL Server under a service account instead of using the built-in default
system service accounts.
By default, SQL Server is often installed and configured to use one of the
supported built-in system accounts, such as the LocalSystem or NetworkService
accounts. To enhance the security of your SQL Server installation for AD FS,
wherever possible use a separate service account for accessing your SQL Server
service and enable Kerberos authentication by registering the security principal
name (SPN) of this account in your Active Directory deployment. This enables
mutual authentication between client and server. Without SPN registration of a
separate service account, SQL Server will use NTLM for Windows-based
authentication, where only the client is authenticated.
Minimize the surface area of SQL Server.
Enable only those SQL Server endpoints that are necessary. By default, SQL Server
provides a single built-in TCP endpoint that cannot be removed. For AD FS, you
should enable this TCP endpoint for Kerberos authentication. To review the current
TCP endpoints to see if additional user-defined TCP ports are added to a SQL
installation, you can use the "SELECT * FROM sys.tcp_endpoints" query statement
in a Transact-SQL (T-SQL) session. For more information about SQL Server
endpoint configuration, see How To: Configure the Database Engine to Listen on
Multiple TCP Ports (https://go.microsoft.com/fwlink/?LinkID=189231 ).
Avoid using SQL-based authentication.
To avoid having to transfer passwords as clear text over your network or storing
passwords in configuration settings, use Windows authentication only with your
SQL Server installation. SQL Server authentication is a legacy authentication mode.
Storing Structured Query Language (SQL) login credentials (SQL user names and
passwords) when you are using SQL Server authentication is not recommended.
For more information, see Authentication Modes
(https://go.microsoft.com/fwlink/?LinkID=189232 ).
Evaluate the need for additional channel security in your SQL installation
carefully.
Even with Kerberos authentication in effect, the SQL Server Security Support

Provider Interface (SSPI) does not provide channel-level security. However, for
installations in which servers are securely located on a firewall-protected network,
encrypting SQL communications may not be necessary.
Although encryption is a valuable tool to help ensure security, it should not be

considered for all data or connections. When you are deciding whether to
implement encryption, consider how users will access data. If users access data
over a public network, data encryption might be required to increase security.
However, if all access of SQL data by AD FS involves a secure intranet
configuration, encryption might not be required. Any use of encryption should also
include a maintenance strategy for passwords, keys, and certificates.
If there is a concern that any SQL data might be seen or tampered with over your
network, use Internet Protocol security (IPsec) or Secure Sockets Layer (SSL) to help
secure your SQL connections. However, this might have a negative effect on
SQL Server performance, which might affect or limit AD FS performance in some
situations. For example, AD FS performance in token issuance might degrade when
attribute lookups from a SQL-based attribute store are critical for token issuance.
You can better eliminate a SQL tampering threat by having a strong perimeter
security configuration. For example, a better solution for securing your SQL Server
installation is to ensure that it remains inaccessible for Internet users and
computers and that it remains accessible only by users or computers within your
datacenter environment.
For more information, see Encrypting Connections to SQL Server or SQL Server
Encryption.
Configure securely designed access by using stored procedures to perform all

SQL-based lookups by AD FS of SQL-stored data.
To provide better service and data isolation, you can create stored procedures for
all attribute store lookup commands. You can create a database role to which you
then grant permission to run the stored procedures. Assign the service identity of
the AD FS Windows service to this database role. The AD FS Windows service
should not be able to run any other SQL statement, other than the appropriate
stored procedures that are used for attribute lookup. Locking down access to the
SQL Server database in this way reduces the risk of an elevation-of-privilege attack.
See Also
Planning for Interoperability with AD FS
1.x
Article • 08/15/2023
Active Directory Federation Services (AD FS) federation servers running Windows
Server® 2012 can interoperate with both an AD FS 1.0 (installed with Windows Server
2003 R2) Federation Service and an AD FS 1.1 (installed with Windows Server 2008 or
Windows Server 2008 R2) Federation Service. Any of the following interoperability
combinations are supported:
Any AD FS 1.x Federation Service can send a claim that can be consumed by an AD
FS Federation Service in Windows Server 2012 . For more information, see
Checklist: Configuring AD FS to Consume Claims from AD FS 1.x.
Any AD FS Federation Service in Windows Server 2012 can send an AD FS 1.x-

compatible claim that can be consumed by an AD FS 1.x Federation Service. For
more information, see Checklist: Configuring AD FS to Send Claims to an AD FS 1.x
Federation Service.
Any AD FS Federation Service in Windows Server 2012 can send an AD FS 1.x-

compatible claim that can be consumed by one or more Web servers running the
AD FS 1.x claims-aware Web agent. For more information, see Checklist:
Configuring AD FS to Send Claims to an AD FS 1.x Claims-Aware Web Agent.
７ Note
AD FS does not support or interoperate with the AD FS 1.x Windows NT token–

based Web agent.
An AD FS 1.x-compatible claim is a claim that can be sent by an AD FS Federation

Service in Windows Server 2012 and understood by an AD FS 1.x Federation Service. So
that an AD FS 1.x Federation Service can consume the claims that an AD FS Federation
Service sends, a Name Identifier (ID) claim type must be sent.
Understanding the Name ID claim type

The Name ID claim type is the equivalent of the identity claim type that AD FS 1.x uses.
It must be used whenever you want to interoperate with AD FS 1.x. The Name ID claim
type enables either an AD FS 1.x Federation Service or the AD FS 1.x claims-aware Web
agent to consume claims that AD FS in Windows Server 2012 sends, as long as these
claims are sent in one of the Name ID formats in the following table.
Name ID format Corresponding URI
AD FS 1.x Email Address http://schemas.xmlsoap.org/claims/EmailAddress
AD FS 1.x Email UPN http://schemas.xmlsoap.org/claims/UPN
Common Name http://schemas.xmlsoap.org/claims/CommonName
Group http://schemas.xmlsoap.org/claims/Group
Only one Name ID claim in the appropriate format must be sent. When that criterion is
satisfied, many other claims may be sent as well, assuming that they conform to the
restrictions described in the table.
７ Note
An AD FS 1.x Federation Service can interpret only incoming claim types that begin
with the Uniform Resource Identifier (URI) of http://schemas.xmlsoap.org/claims/ .
See Also
When to Use Identity Delegation
Article • 08/15/2023
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
Article • 08/15/2023
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
Article • 08/15/2023
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
Server Proxy in the Account Partner
Article • 08/15/2023
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.
Ｕ Caution
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
Article • 08/15/2023
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
Article • 08/15/2023
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
Server in the Resource Partner
Article • 08/15/2023
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
Server Proxy in the Resource Partner
Article • 08/15/2023
A federation server proxy in Active Directory Federation Services (AD FS) can function in

one or more of the following roles, depending on how you configure the server to meet
the needs of the resource partner organization:
Account partner discovery: An Internet client computer must identify which

account partner will authenticate it. The client finds the account partner by using
an account partner discovery Web form (discoverclientrealm.aspx), which is stored
on the federation server proxy in the resource partner. If more than one account
partner is configured in the AD FS Management snap-in, a drop-down menu
appears to the client with all the available account partners that are visible to
Internet client computers that access the account partner discovery Web form. You
can change how the account partner discovery Web form is presented to client
computers by customizing the discoverclientrealm.aspx file.
Security token redirection: The federation server proxy in the account partner
sends the security tokens to the resource partner. The resource federation server
proxy accepts these tokens and passes them on to the federation server in the
resource partner. The resource federation server then issues a security token that is
bound for a specific resource Web server. The resource federation server proxy
then redirects the token to the client.
To summarize, a resource federation server proxy facilitates the federated logon process
by redirecting client computers to a federation server that can authenticate the clients. A
resource federation server proxy also acts as a proxy for client security tokens to
resource federation servers.
７ Note
When it is necessary to help reduce the amount of hardware and the number of
required certificates, the federation server proxy can be located on the same
computer as the Web server.
See Also
Determine Your Federated Application
Strategy in the Resource Partner
Article • 08/15/2023
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:
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
Article • 08/15/2023
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
Article • 08/15/2023
When you create a federation server in 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.
Ｕ Caution
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
Article • 08/15/2023
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
Farm
Article • 08/15/2023
Consider creating a federation server farm in Active Directory Federation Services

(AD FS) when you have a larger AD FS deployment and you want to provide fault
tolerance, load-balancing, or scalability to your organization's Federation Service. The
act of creating two or more federation servers in the same network, configuring each of
them to use the same Federation Service, and adding the public key of each server's
token-signing certificates to the AD FS Management snap-in creates a federation server
farm.
You can create a federation server farm or install additional federation servers to an
existing farm by using the AD FS Federation Server Configuration Wizard. For more
information, see When to Create a Federation Server.
７ Note
When you choose the option to create a New federation server farm using the AD
FS Federation Server Configuration Wizard, the wizard will attempt to create a
container object (for sharing certificates) in Active Directory. Therefore, it is
important that you first log on to the computer, where you are setting up the
federation server role, with an account that has sufficient permissions in Active
Directory to create this container object.
Before federation servers can be grouped as a farm, they must first be clustered so that
requests that arrive at a single fully qualified domain name (FQDN) are routed to the
various federation servers in the server farm. You can create the server cluster by
deploying Network Load Balancing (NLB) inside the corporate network. This guide
assumes that NLB has been configured appropriately to cluster each of the federation
servers in the farm.
For more information about how to configure a cluster FQDN using Microsoft NLB
technology, see Specifying the Cluster Parameters.
Best practices for deploying a federation server

farm
We recommend the following best practices for deploying a federation server in a
production environment:
If you will be deploying multiple federation servers at the same time or you know
that you will be adding more servers to the farm over time, consider creating a
server image of an existing federation server in the farm and then installing from
that image when you need to create additional federation servers quickly.
７ Note
If you do decide to use the server image method for deploying additional
federation servers, you do not have to complete the tasks in Checklist: Setting
Up a Federation Server every time that you want to add a new server to the
farm.
Use NLB or some other form of clustering to allocate a single IP address for many
federation server computers.
Reserve a static IP address for each federation server in the farm and, depending
on your Domain Name System (DNS) configuration, insert an exclusion for each IP
address in Dynamic Host Configuration Protocol (DHCP). Microsoft NLB
technology requires that each server that participates in the NLB cluster be
assigned a static IP address.
If the AD FS configuration database will be stored in a SQL database, avoid editing
the SQL database from multiple federation servers at the same time.
Configuring federation servers for a farm

The following table describes the tasks that must be completed so that each federation
server can participate in a farmed environment.
Task Description
If you are using A federation server farm consists of two or more federation servers that share
SQL Server to the same AD FS configuration database and token-signing certificates. The
store the AD FS configuration database can be stored in either Windows Internal Database or
configuration in a SQL Server database. If you plan to store the configuration database in a
database 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
Task Description
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 configuration
database.
Obtain and share You can obtain a single server authentication certificate from a public
certificates 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 If the AD FS configuration database will be stored in a SQL database, the new
same SQL Server federation server must point to the same SQL Server instance that is used by
instance other federation servers in the farm so that the new server can participate in
the farm.
See Also
Certificate Requirements for Federation
Servers
Article • 08/15/2023
In any Active Directory Federation Services (AD FS) design, various certificates must be

used to secure communication and facilitate user authentications between Internet
clients and federation servers. Each federation server must have a service
communication certificate and a token-signing certificate before it can participate in AD
FS communications. The following table describes the certificate types that are
associated with federation server.
Certificate type Description
Token-signing A token-signing certificate is an X509 certificate. Federation servers use

certificate 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 Federation servers use a server authentication certificate, also known as a

communication service communication for Windows Communication Foundation (WCF)
certificate 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 Federation servers use an SSL certificate to secure Web services traffic for SSL
Layer (SSL) communication with Web clients and with federation server proxies.
certificate 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
Certificate type Description
certificates that you select must have a corresponding private key.
Token-decryption This certificate is used to decrypt tokens that are received by this federation
certificate 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
Article • 08/15/2023
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 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
Article • 08/15/2023
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. Any
federation server proxies and Web servers that trust this federation server must
also trust the root CA.
The subject name that's 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're deploying the Federated Web Single-Sign-On (SSO) design, we
recommend that a public CA issue your service communication certificate. 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.
Reasons why you shouldn't use self-signed, service communication certificates for a live
deployment include:
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 a self-signed
certificate alone doesn't enable an attacker to compromise a resource federation
server, trusting self-signed certificates does increase the attack surface of a
computer. If the certificate signer isn't trustworthy, it can lead to security
vulnerabilities.
A self-signed, service communication certificate creates a bad user experience.

Clients 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 message is expected, because the
self-signed certificate isn't 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 attempts to access an AD FS site.
CAs provide more certificate-based features, such as private key archive, renewal,
and revocation that aren't provided by self-signed certificates.
Name Resolution Requirements for
Federation Servers
Article • 08/15/2023
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
Planning Federation Server Proxy
Placement
Article • 08/15/2023
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
Proxy
Article • 08/15/2023
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
Proxy
Article • 08/15/2023
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

For the federation server proxy redirection process to be successful, all firewall servers
must be configured to allow Secure Hypertext Transfer Protocol (HTTPS) traffic. The use
of HTTPS is required because the firewall servers must publish the federation server
proxy, using port 443, so that the federation server proxy in the perimeter network can
access the federation server in the corporate network.
７ Note
All communications to and from client computers also occur over HTTPS.
In addition, the Internet-facing firewall server, such as a computer running Microsoft

Internet Security and Acceleration (ISA) Server, uses a process known as server
publishing to distribute Internet client requests to the appropriate perimeter and
corporate network servers, such as federation server proxies or federation servers.
Server publishing rules determine how server publishing works—essentially, filtering all
incoming and outgoing requests through the ISA Server computer. Server publishing
rules map incoming client requests to the appropriate servers behind the ISA Server
computer. For information about how to configure ISA Server to publish a server, see
Create a Secure Web Publishing Rule.
In the federated world of AD FS, these client requests are typically made to a specific
URL, for example, a federation server identifier URL such as http://fs.fabrikam.com.
Because these client requests come in from the Internet, the Internet-facing firewall
server must be configured to publish the federation server identifier URL for each
federation server proxy that is deployed in the perimeter network.
Configuring ISA Server to allow SSL

To facilitate secure AD FS communications, you must configure ISA Server to allow
Secure Sockets Layer (SSL) communications between the following:
Federation servers and federation server proxies. An SSL channel is required for
all communications between federation servers and federation server proxies.
Therefore, you must configure ISA Server to allow an SSL connection between the
corporate network and the perimeter network.
Client computers, federation servers, and federation server proxies. So that

communications can occur between client computers and federation servers or
between client computers and federation server proxies, you can place a computer
running ISA Server in front of the federation server or federation server proxy.
If your organization performs SSL client authentication on the federation server or

federation server proxy, when you place a computer running ISA Server in front of
the federation server or federation server proxy, the server must be configured for
pass-through of the SSL connection because the SSL connection must terminate at
the federation server or federation server proxy.
If your organization does not perform SSL client authentication on the federation
server or federation server proxy, an additional option is to terminate the SSL
connection at the computer running ISA Server and then re-establish an SSL
connection to the federation server or federation server proxy.
７ Note
The federation server or federation server proxy requires that the connection be
secured by SSL to protect the contents of the security token.
See Also
Proxy Farm
Article • 08/15/2023
Consider installing additional federation server proxies when you have a large
Active Directory Federation Services (AD FS) deployment and you want to provide fault
tolerance, load-balancing, and scalability for your proxy deployment. The act of creating
two or more federation server proxies in the same perimeter network and configuring
each of them to protect the same AD FS Federation Service creates a federation server
proxy farm.
You can create a federation server proxy farm or install additional federation server
proxies to an existing farm by using the AD FS Federation Server Proxy Configuration
Wizard. For more information, see When to Create a Federation Server Proxy.
Before all the federation server proxies can function together as a farm, you must first
cluster them under one IP address and one Domain Name System (DNS) fully qualified
domain name (FQDN). You can cluster the servers by deploying Microsoft Network Load
Balancing (NLB) inside the perimeter network. The tasks in the following table require
NLB to be configured appropriately to cluster the federation server proxies in the farm.
For more information about how to configure an FQDN for a cluster using Microsoft
NLB technology, see Specifying the Cluster Parameters.
Configuring federation server proxies for a

farm
The following table describes the tasks that must be completed so that each federation
server proxy can participate in a farm.
Task Description
Point all proxies When you create the federation server proxies, you must type the same
in the farm to the Federation Service name in the AD FS Federation Server Proxy Configuration
same AD FS Wizard for all the federation server proxies that will participate in the farm.
Federation The federation server proxy uses the URL that makes up this DNS host name
Service name to determine which AD FS Federation Service instance it contacts.
For more information, see Configure a Computer for the Federation Server
Proxy Role.
Obtain and share You can obtain a server authentication certificate from a public certification
certificates authority (CA)—for example, VeriSign—and then configure the certificate so
Task that all federation server proxies share the same private key portion of the
Description
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
Article • 08/15/2023
Servers that are running in the federation server proxy role in Active Directory
Federation Services (AD FS) are required to use Secure Sockets Layer (SSL) server
authentication certificates. Federation server proxies use SSL server authentication
certificates to secure Web server traffic communication with Web clients.
Federation server proxies are usually exposed to computers on the Internet that are not
included in your enterprise public key infrastructure (PKI). Therefore, use a server
authentication certificate that is issued by a public (third-party) certification authority
(CA), for example, VeriSign.
When you have a federation server proxy farm, all federation server proxy computers
must use the same server authentication certificate. For more information, see When to
Create a Federation Server Proxy Farm.
It is important to verify that the subject name in the server authentication certificate
matches the Federation Service name value that is specified in the AD FS Management
snap-in. To locate this value, open the snap-in, right-click Service, click Edit Federation
Service Properties, and then find the value in Federation Service name text box.
For general information about using SSL certificates, see Configuring Secure Sockets
Layer in IIS 7.0 (http://go.microsoft.com/fwlink/?LinkID=108544) and Configuring Server
Certificates in IIS 7.0 (http://go.microsoft.com/fwlink/?LinkID=108545).
７ Note
Client authentication certificates are not required for AD FS federation server

proxies.
If any certificate that you use has certificate revocation lists (CRLs), the server with the
configured certificate must be able to contact the server that distributes the CRLs. The
type of CRL determines what ports are used.
See Also
Name Resolution Requirements for
Federation Server Proxies
Article • 08/15/2023
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
Planning for AD FS Server Capacity
Article • 08/15/2023
７ 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 Review important hardware and software Appendix A:

requirements for requirements necessary for deploying Reviewing AD FS
deploying AD FS federation server and federation server Requirements
federation servers and proxies.
federation server proxies
Select the type of AD FS Before you can begin using capacity planning The Role of the AD
configuration database data in this section, you first have to FS Configuration
that you will deploy in determine which AD FS configuration Database;
your organization database type you will deploy, either
Windows Internal Database (WID) or a
Structured Query Language (SQL) database.
AD FS Deployment
Topology
Considerations
Determine the type of Once you have decided on the type of AD FS Determine Your AD
topology layout to use configuration database to use in your FS Deployment
with your new AD FS deployment, you will need to consider which Topology
configuration database deployment topology most closely matches
selection where you will need to place federation
servers and federation server proxies within
your production environment.
Understand key AD FS– Review the definitions of common capacity See the section
related capacity planning planning terms that are used throughout the titled AD FS capacity
terms AD FS capacity planning discussion. planning terms in
this topic
Once you have reviewed the content in the previous table, you can now complete the
prerequisite tasks in the next table.
Prerequisite task Description Reference
Download the AD FS Capacity The AD FS Capacity Planning Sizing AD FS Capacity

Planning Sizing Spreadsheet spreadsheet can help you to determine Planning
the number of federation servers Spreadsheet
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 This user data you collect will be used Estimate the
of users who will require single for the input values required within the number of
sign-on (SSO) access to the context of the AD FS Capacity Planning federation servers
target claims-aware application Sizing Spreadsheet. for your
and the expected peak usage organization
periods associated with this
access
AD FS Capacity Planning Updated Planning worksheet for AD FS Windows

Spreadsheet for Windows Windows Server 2016 Server 2016
Server 2016 Capacity Planning
AD FS capacity planning terms

The following table describes important terms that are used often in this capacity
planning section of the AD FS Design Guide. For a more complete list of AD FS terms,
see Understanding Key AD FS Concepts.
Term Definition
Concurrent users The estimated number of users that are expected to submit requests to
the service within a given period of time, usually a peak activity period.
Active users The approximate average number of users that are active on a system,
but not necessarily submitting requests, during a given period of time.
Defined users A theoretical maximum user count, usually based on the number of users
who have defined accounts in the system.
Requests per second The number of requests either submitted by clients (when talking about
the load on a system) or processed by servers (when talking about server
throughput) in a second. This metric is used in planning server processor
and memory capacity.
Target server Success metrics that bound the acceptable server performance range.
responsiveness and Generally, if responsiveness goes below or utilization goes above the
utilization target, the system is considered to be overloaded and more capacity is
required.
Windows Internal The default AD FS configuration database that can be used as an

Database (WID) 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
Article • 08/15/2023
Capacity planning for federation servers helps you estimate:
Which factors grow the size of the AD FS configuration database.
The appropriate hardware requirements for each federation server.
The number of federation servers to place in each organization.
Federation servers issue security tokens to users. These tokens are presented to a relying
party for consumption. Federation servers issue security tokens after authenticating a
user or after receiving a security token that was previously issued by a partner
Federation Service. A security token is requested from a Federation Service when users
initially sign in to federated applications or when their security tokens expire while they
are accessing federated applications.
Federation servers are designed to accommodate high-availability server farm

configurations that use Microsoft Network Load Balancing (NLB) technology. Federation
servers in a farm configuration can service requests independently, without accessing
any common farm components for each request. Therefore, there is little overhead
involved in scaling out a federation server deployment.
Recommendations:
For mission-critical or high-availability deployments, we recommend that you

create a small federation server farm in each partner organization, with at least two
federation servers per farm, to provide fault tolerance.
With the need for high availability and the ease of scaling out federation servers,
scaling out is the recommended method for handling high numbers of requests
per second for a particular Federation Service. Scaling up beyond the base
configuration in this guide is unlikely to produce significant capacity handling
gains.
AD FS configuration database size and growth

The size of the AD FS configuration database is generally considered to be small, and
database size does not tend to be a major consideration in AD FS deployments. The
precise size of the AD FS configuration database can depend largely on the number of
trust relationships and the associated trust-related metadata—such as claims, claim
rules, and monitoring settings configured for each trust. As the number of trust entries
in the configuration database grows, so does the need for more disk space.
For additional deployment information about the AD FS configuration database, see AD

FS Deployment Topology Considerations.
Memory, CPU and disk space requirements

Fortunately, memory, CPU and disk space requirements for federation servers are
modest, and they are not likely to be a driving factor in hardware decisions. For more
information about hardware requirements, see Appendix A: Reviewing AD FS
Requirements.
７ Note
In tests that were performed by the AD FS product team using a federation server
farm configured with a dedicated SQL Server to store the AD FS configuration
database, the overall load on the SQL Server tended to be low. In one test using a
four-federation-server farm that was configured to use a single SQL Server, CPU
utilization did not exceed 10% despite testing that brought the federation servers
to target utilization.
Estimate the number of federation servers for

your organization
In an effort to streamline the hardware planning process for federation servers, the AD
FS product team developed the AD FS Capacity Planning Sizing Spreadsheet. This Excel
spreadsheet includes calculator-like functionality that will take expected usage data that
you provide about users in your organization and return a recommended optimal
number of federation servers for your AD FS production environment.
７ Note
The number of federation servers that this spreadsheet will recommend is based on
the hardware and network specifications that the AD FS product team used during
testing. Therefore, the number of federation servers that the spreadsheet will
recommend must be understood within this context. For more information about
the specifications used during testing, see the topic titled Planning for AD FS
Server Capacity.
Using the AD FS Capacity Planning Sizing Spreadsheet
When you use this spreadsheet, you will need to select a value (either 40%, 60%, or
80%) that best represents the percentage of total users you expect will send
authentication requests to your federation servers during peak usage periods.
Then, you will need to select a value (either 1 minute, 15 minutes, or 1 hour) that best
represents the length of time you expect the peak usage period to last. For example,
you might estimate 40% as the value for the total number of users who will login within
a period of 15 minutes, or that 60% of users will login within a period of 1
hour. Together, these values define the peak load profile by which your sizing
recommendation will be calculated.
Next, you will need to specify the total number of users that will require single sign-on
access to the target claims-aware application, based on whether the users are:
Logging into Active Directory from a local computer that is physically connected to
your corporate network (through Windows integrated authentication)
Logging into Active Directory remotely from a computer that is not physically
connected to your corporate network (through Windows integrated authentication
or Username and password)
From another organization and are attempting to access the target claims-aware
application from a trusted partner
From a SAML 2.0 identity provider and are attempting to access the target claims-
aware application
How to use this spreadsheet

You can use the following steps for each federation server farm instance you plan to
deploy to determine the recommended number of federation servers.
1. Download and then open the AD FS Capacity Planning Sizing Spreadsheet For
Windows Server 2012 R2 or the AD FS Capacity Planning Sizing Spreadsheet For
Windows Server 2016 .
2. In the cell to the right of the During the peak system usage period, I expect this
percentage of my users to authenticate cell, click the cell and then use the drop-
down arrows to select your estimated system utilization level, either 40%, 60% or
80% for the deployment.
3. In the cell to the right of the within the following period of time cell, click the cell
and then use the drop-down arrows to select either 1 minute, 15 minutes, or 1
hour to select the duration of peak load.
4. In the cell to the right of the Enter estimated number of internal applications
(such as SharePoint (2007 or 2010) or claims aware web applications) cell, type
the number of internal applications you will use in your organization.
5. In the cell to the right of the Enter estimated number of online applications (such
as Office 365 Exchange Online, SharePoint Online or Lync Online) cell, type the
number of online applications or services you will used in your organization.
6. Under the cell titled Number of Users, type a number on each row that applies to
an example application scenario your users will need single sign-on access to. This
column should contain the number of defined users, not the peak users per
second. If access attempts made to the application must first go through the home
realm discovery page, type Y. If you are unsure of this selection, type Y.
7. Review the following recommended values that are provided:
a. For the total number of recommended federation servers, see the lower right
cell that is highlighted in gray.
b. For the number of servers recommended for each example application scenario,
see the cell on the row that is highlighted in gray.
７ Note
The value that will be automatically calculated in the cell to the right of the cell
titled Total number of federation servers recommended at the bottom of the
spreadsheet contains a formula which will add an additional 20% buffer to the sum
total of all the values in each of the individual rows preceding it. The formula added
to the Total number of federation servers recommended cell builds in this buffer
to your total recommended number of deployed federation servers to make it very
unlikely that the overall load on the farm will ever hit its saturation point.
See Also
Planning for Federation Server Proxy
Capacity
Article • 08/15/2023
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
Appendix A: Reviewing AD FS
Requirements
Article • 08/15/2023
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.
Certificate type Description What you need to know before deploying
Secure Sockets This is a standard Secure This certificate must be bound to the Default Web
Layer (SSL) Sockets Layer (SSL) Site in Internet Information Services (IIS) for a
certificate certificate that is used for Federation Server or a Federation Server Proxy.
securing communications For a Federation Server Proxy, the binding must
between federation be configured in IIS prior to running the
servers and clients. 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 This certificate enables By default, the SSL certificate is used as the
communication WCF message security for service communications certificate. This can be
certificate securing communications changed using the AD FS Management console.
between federation
servers.
Token-signing This is a standard X509 The token-signing certificate must contain a

certificate certificate that is used for private key, and it should chain to a trusted root
securely signing all in the Federation Service. By default, AD FS
tokens that the federation creates a self-signed certificate. However, you can
server issues. change this later to a CA-issued certificate by
using the AD FS Management snap-in, depending
on the needs of your organization.
Token- This is a standard SSL By default, AD FS creates a self-signed certificate.

decryption certificate that is used to However, you can change this later to a CA-
certificate decrypt any incoming issued certificate by using the AD FS
tokens that are encrypted
Certificate type Description What you need to know before deploying
by a partner federation Management snap-in, depending on the needs of

server. It is also published your organization.
in federation metadata.
Ｕ Caution
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.
Certificate Description What you need to know before deploying

type
Server This is a standard Secure This certificate must be bound to the Default
authentication Sockets Layer (SSL) certificate Web Site in Internet Information Services (IIS)
certificate that is used for securing before you can run the AD FS Federation
communications between a Server Proxy Configuration Wizard
federation server proxy and successfully.
Internet client computers. Recommendation: Because this certificate
must be trusted by clients of AD FS, use a
server authentication certificate that is issued
by a public (third-party) certification
authority (CA), for example, VeriSign.
Tip: The Subject name of this certificate is

used to represent the Federation Service
name for each instance of AD FS that you
deploy. For this reason, you may want to
consider choosing a Subject name that best
represents the name of your company or
organization to partners.
For more information about the certificates that federation server proxies use, see
Certificate Requirements for Federation Server Proxies.
Although any current Web browser with JavaScript capability can be made to work as an
AD FS client, the Web pages that are provided by default have been tested only against
Internet Explorer versions 7.0, 8.0 and 9.0, Mozilla Firefox 3.0, and Safari 3.1 on Windows.
JavaScript must be enabled, and cookies must be enabled for browser-based sign-in
and sign-out to work correctly.
The AD FS product team at Microsoft successfully tested the browser and operating
system configurations in the following table.
Browser Windows 7 Windows Vista
Internet Explorer 7.0 X X
Internet Explorer 8.0 X X
Internet Explorer 9.0 X Not Tested
FireFox 3.0 X X
Safari 3.1 X X
７ Note
AD FS supports both the 32bit and 64bit versions of all the browsers showing in the
above table.
Cookies
AD FS creates session-based and persistent cookies that must be stored on client
computers to provide sign-in, sign-out, single sign-on (SSO), and other functionality.
Therefore, the client browser must be configured to accept cookies. Cookies that are
used for authentication are always Secure Hypertext Transfer Protocol (HTTPS) session
cookies that are written for the originating server. If the client browser is not configured
to allow these cookies, AD FS cannot function correctly. Persistent cookies are used to
preserve user selection of the claims provider. You can disable them by using a
configuration setting in the configuration file for the AD FS sign-in pages.
Support for TLS/SSL is required for security reasons.
Configuring the following network services appropriately is critical for successful
deployment of AD FS in your organization.
TCP/IP network connectivity

For AD FS to function, TCP/IP network connectivity must exist between the client; a
domain controller; and the computers that host the Federation Service, the Federation
Service Proxy (when it is used), and the AD FS Web Agent.
DNS
The primary network service that is critical to the operation of AD FS, other than
Active Directory Domain Services (AD DS), is Domain Name System (DNS). When DNS is
deployed, users can use friendly computer names that are easy to remember to connect
to computers and other resources on IP networks.
Windows Server 2008 uses DNS for name resolution instead of the Windows Internet
Name Service (WINS) NetBIOS name resolution that was used in Windows NT 4.0–based
networks. It is still possible to use WINS for applications that require it. However, AD DS
and AD FS require DNS name resolution.
The process of configuring DNS to support AD FS varies, depending on whether:
Your organization already has an existing DNS infrastructure. In most scenarios,

DNS is already configured throughout your network so that Web browser clients in
your corporate network have access to the Internet. Because Internet access and
name resolution are requirements of AD FS, this infrastructure is assumed to be in
place for your AD FS deployment.
You intend to add a federated server to your corporate network. For the purpose
of authenticating users in the corporate network, internal DNS servers in the
corporate network forest must be configured to return the CNAME of the internal
server that is running the Federation Service. For more information, see Name
You intend to add a federated server proxy to your perimeter network. When you
want to authenticate user accounts that are located in the corporate network of
your identity partner organization, the internal DNS servers in the corporate
network forest must be configured to return the CNAME of the internal federation
server proxy. For information about how to configure DNS to accommodate the
addition of federation server proxies, see Name Resolution Requirements for
Federation Server Proxies.
You are setting up DNS for a test lab environment. If you plan to use AD FS in a
test lab environment where no single root DNS server is authoritative, it is
probable that you will have to set up DNS forwarders so that queries to names
between two or more forests will be forwarded appropriately. For general
information about how to set up an AD FS test lab environment, see AD FS Step-
by-Step and How To Guides.

AD FS requires at least one attribute store to be used for authenticating users and
extracting security claims for those users. For a list of attribute stores that AD FS
supports, see The Role of Attribute Stores in the AD FS Design Guide.
７ Note
AD FS automatically creates an Active Directory attribute store, by default.
Attribute store requirements depend on whether your organization is acting as the

account partner (hosting the federated users) or the resource partner (hosting the
federated application).
AD DS
For AD FS to operate successfully, domain controllers in either the account partner
organization or the resource partner organization must be running
Windows Server 2003 SP1, Windows Server 2003 R2, Windows Server 2008 , or Windows
Server 2012 .
When AD FS is installed and configured on a domain-joined computer, the

Active Directory user account store for that domain is made available as a selectable
attribute store.
） Important
Because AD FS requires the installation of Internet Information Services (IIS), we

recommend that you not install the AD FS software on a domain controller in a
production environment for security purposes. However, this configuration is
supported by Microsoft Customer Service Support.
Schema requirements
AD FS does not require schema changes or functional-level modifications to AD DS.
Functional-level requirements
Most AD FS features do not require AD DS functional-level modifications to operate

successfully. However, Windows Server 2008 domain functional level or higher is
required for client certificate authentication to operate successfully if the certificate is
explicitly mapped to a user's account in AD DS.

If you are creating a federation server farm, you must first create a dedicated domain-
based service account in AD DS that the Federation Service can use. Later, you configure
each federation server in the farm to use this account. For more information about how
to do this, see Manually Configure a Service Account for a Federation Server Farm in the
AD FS Deployment Guide.
LDAP
When you work with other Lightweight Directory Access Protocol (LDAP)-based attribute
stores, you must connect to an LDAP server that supports Windows Integrated
authentication. The LDAP connection string must also be written in the format of an
LDAP URL, as described in RFC 2255.
SQL Server
For AD FS to operate successfully, computers that host the Structured Query Language
(SQL) Server attribute store must be running either Microsoft SQL Server 2005 or
SQL Server 2008. When you work with SQL-based attribute stores, you also must
configure a connection string.
Custom attribute stores

You can develop custom attribute stores to enable advanced scenarios. The policy
language that is built into AD FS can reference custom attribute stores so that any of the
following scenarios can be enhanced:
Creating claims for a locally authenticated user

Supplementing claims for an externally authenticated user
Authorizing a user to obtain a token
Authorizing a service to obtain a token on behavior of a user
When you work with a custom attribute store, you may also have to configure a
connection string. In this situation, you can enter any custom code you like that enables
a connection to your custom attribute store. The connection string in this situation is a
set of name/value pairs that are interpreted as implemented by the developer of the
custom attribute store.
For more information about developing and using custom attribute stores, see Attribute
Store Overview.
Federation servers can communicate with and protect federation applications, such as
claims-aware applications.
AD FS integrates naturally with existing Windows authentication, for example, Kerberos
authentication, NTLM, smart cards, and X.509 v3 client-side certificates. Federation
servers use standard Kerberos authentication to authenticate a user against a domain.
Clients can authenticate by using forms-based authentication, smart card authentication,
and Windows Integrated authentication, depending on how you configure
authentication.
The AD FS federation server proxy role makes possible a scenario in which the user
authenticates externally using SSL client authentication. You can also configure the
federation server role to require SSL client authentication, although typically the most
seamless user experience is achieved by configuring the account federation server for
Windows Integrated authentication. In this situation, AD FS has no control over what
credentials the user employs for Windows desktop logon.
Smart card logon

Although AD FS can enforce the type of credentials that it uses for authentication
(passwords, SSL client authentication, or Windows Integrated authentication), it does
not directly enforce authentication with smart cards. Therefore, AD FS does not provide
a client-side user interface (UI) to obtain smart-card personal identification number
(PIN) credentials. This is because Windows-based clients intentionally do not provide
user credential details to federation servers or Web servers.
Smart card authentication

Smart card authentication uses the Kerberos protocol to authenticate to an account
federation server. AD FS cannot be extended to add new authentication methods. The
certificate in the smart card is not required to chain up to a trusted root on the client
computer. Use of a smart-card-based certificate with AD FS requires the following
conditions:
The reader and cryptographic service provider (CSP) for the smart card must work
on the computer where the browser is located.
The smart card certificate must chain up to a trusted root on the account
federation server and the account federation server proxy.
The certificate must map to the user account in AD DS by either of the following
methods:
The certificate subject name corresponds to the LDAP distinguished name of a

The certificate subject altname extension has the user principal name (UPN) of a
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
Article • 08/15/2023
） Important

AD FS
This document contains a list of all of the documentation for deploying AD FS for
Best Practices for Securing AD FS
Deploy Azure AD Connect Health to Monitor your on-premises identity

infrastructure in the cloud
Plan Device-based Conditional Access on-premises
Required Updates for AD FS and WAP
Set up Geographic Redundancy with SQL Server Replication
Set up the lab environment for AD FS in Windows Server 2012 R2
Upgrading to AD FS in Windows Server 2016 using a WID database
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
Article • 08/15/2023
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
Article • 08/15/2023
This document provides best practices for the secure planning and deployment of
Active Directory Federation Services (AD FS) and Web Application Proxy (WAP). It
contains recommendations for additional security configurations, 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 for either 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.

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, in front of the external
IP address, of the load balancer as needed.
７ 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
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.
Communication between Federation Servers

Federation servers on an AD FS farm communicate with other servers in the farm and
the Web Application Proxy (WAP) servers via HTTP port 80 for configuration
synchronization. Make sure that only these servers can communicate with each other
and no other is a measure of defense in depth.
Organizations can do achieve this state, by setting up firewall rules on each server. The
rules should only allow inbound communication from the IP addresses of the servers in
the farm and WAP servers. Some Network Load Balancers (NLB) use HTTP port 80 for
probing the health on individual federation servers. Make sure that you include the IP
addresses of the NLB in the configured firewall rules.
Azure AD Connect and Federation Servers/WAP
This table describes the ports and protocols that are required for communication
between the Azure AD Connect server and Federation/WAP servers.
Protocol Ports Description
HTTP 80 (TCP/UDP) Used to download CRLs (Certificate Revocation Lists) to verify SSL
certificates.
HTTPS 443(TCP/UDP) Used to synchronize with Azure AD.
WinRM 5985 WinRM Listener.
WAP and Federation Servers

between the Federation servers and WAP servers.
HTTPS 443(TCP/UDP) Used for authentication.
WAP and Users

between users and the WAP servers.
HTTPS 443(TCP/UDP) Used for device authentication.
TCP 49443 (TCP) Used for certificate authentication.
For information on required ports and protocols required for hybrid deployments, see
Hybrid reference connect ports.
For information about ports and protocols required for an Azure AD and Office 365
deployment, see the document Office 365 URL and IP address ranges .
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.
Min set of endpoints proxy enabled for Azure AD / Office

365 (optional)
Organizations deploying AD FS and WAP only for Azure AD and Office 365 scenarios
can limit even further the number of AD FS endpoints enabled on the proxy to achieve a
more minimal attack surface. Below is the list of endpoints that must be enabled on the
proxy in these scenarios:
Endpoint Purpose
/adfs/ls/ Browser based authentication flows and current

versions of Microsoft Office use this endpoint for
Azure AD and Office 365 authentication
/adfs/services/trust/2005/usernamemixed Used for Exchange Online with Office clients older

than Office 2013 May 2015 update. Later clients
use the passive \adfs\ls endpoint.
/adfs/services/trust/13/usernamemixed Used for Exchange Online with Office clients older

/adfs/oauth2/ Used for any modern apps (on-premises or in

cloud) you have configured to authenticate
directly to AD FS (i.e. not through Azure AD)
/adfs/services/trust/mex Used for Exchange Online with Office clients older

/federationmetadata/2007- Requirement for any passive flows; and used by

06/federationmetadata.xml Office 365 / Azure AD to check AD FS certificates.
AD FS endpoints can be disabled on the proxy using the following PowerShell cmdlet:
PowerShell
Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false
PowerShell
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. The setting can be verified
using the below PowerShell cmdlet:
PowerShell
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 AD FS 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 guidance on this capability, see Configure extranet access for AD FS on Windows
Server 2012 R2.
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.
To learn more about health monitoring for AD FS, see Azure AD Connect Health agent
installation.
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 set up alerts, see Monitor changes to federation
configuration.
Additional security configurations

The following additional capabilities can be configured to provide more protection.
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 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):
PowerShell
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15

-ExtranetObservationWindow ( new-timespan -Minutes 30 )
For reference, see Configuring AD FS Extranet Lockout to learn more about this feature.
Disable WS-Trust Windows endpoints on the proxy 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.
PowerShell
Set-AdfsEndpoint -TargetAddressPath
/adfs/services/trust/2005/windowstransport -Proxy $false
PowerShell
Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport

-Proxy $false
７ Note
If your AD FS farm runs on Windows Internal Databases (WID) and has a secondary
AD FS server, after disabling the endpoints on primary server, wait for the SYNC to
occur on secondary nodes before restarting the AD FS service on them. Use the
PowerShell command Get-AdfsSyncProperties on the secondary node to track last
SYNC process.
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
differentiation can be done per application or globally. For high business value
applications or applications with sensitive information, consider requiring multi factor
authentication. Multi factor authentication can be set up 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 MF 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 the Configure additional
authentication methods for AD FS page.
Enable protection to prevent by-passing of cloud Azure

AD Multi-Factor Authentication when federated with
Azure AD
Enable protection to prevent bypassing of cloud Azure AD Multi-Factor Authentication
when federated with Azure AD and using Azure AD Multi-Factor Authentication as your
multi factor authentication for your federated users.
Enabling the protection for a federated domain in your Azure AD tenant will ensure that
Azure AD Multi-Factor Authentication is always performed when a federated user
accesses an application that is governed by a conditional access policy requiring MFA.
This includes performing Azure AD Multi-Factor Authentication even when federated
identity provider has indicated (via federated token claims) that on-premises MFA has
been performed. Enforcing Azure AD Multi-Factor Authentication every time assures
that a compromised on-premises account cannot bypass Azure AD Multi-Factor
Authentication by imitating that a multi factor authentication has already been
performed by the identity provider, and is highly recommended unless you perform
MFA for your federated users using a third party MFA provider.
The protection can be enabled using a new security setting, federatedIdpMfaBehavior,

which is exposed as a part of the Internal Federation MS Graph API or MS Graph
PowerShell cmdlets. The federatedIdpMfaBehavior setting determines whether Azure AD
accepts the MFA performed by the federated identity provider when a federated user
accesses an application that is governed by a conditional access policy that requires
MFA.
Administrators can choose one of the following values:
Property Description
acceptIfMfaDoneByFederatedIdp Azure AD accepts MFA if performed by identity provider. If

not, performs Azure AD Multi-Factor Authentication.
enforceMfaByFederatedIdp Azure AD accepts MFA if performed by identity provider. If

not, it redirects request to identity provider to perform MFA.
rejectMfaByFederatedIdp Azure AD always performs Azure AD Multi-Factor

Authentication and rejects MFA if performed by identity
provider.
You can enable protection by setting federatedIdpMfaBehavior to

rejectMfaByFederatedIdp using the following command.
MS GRAPH API
PATCH
/domains/{domainsId}/federationConfiguration/{internalDomainFederationId}
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Example:
PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-
f373ee4cbc5a
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
Example:
PowerShell
Update-MgDomainFederationConfiguration -DomainId <domainsId> -

InternalDomainFederationId <internalDomainFederationId>
federatedIdpMfaBehavior "rejectMfaByFederatedIdp"
Example:
PowerShell
Update-MgDomainFederationConfiguration -DomainId “contoso.com” -

InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a”
federatedIdpMfaBehavior "rejectMfaByFederatedIdp"
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 more 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:
PowerShell
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)
Plan Device-based Conditional Access
on-Premises
Article • 08/15/2023
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.
Description Add Work or School Account Azure AD Join Windows 10
Domain Join
Description Users add their work or school Users join their Windows 10 domain
account to their BYOD device Windows 10 work joined devices
interactively. Note: Add Work or device to Azure AD. automatically
School Account is the register with Azure
replacement for Workplace Join AD.
in Windows 8/8.1
How users log No log in to Windows as the Log in to Windows Log in using AD
in to the device work or school account. Log in as the (work or account.
using a Microsoft account. school) account
that registered the
device.
How devices are MDM Policies (with additional MDM Policies (with Group Policy,
managed Intune enrollment) additional Intune Configuration
enrollment) Manager
Azure AD Trust Workplace joined Azure AD joined Domain joined

type
W10 Settings Settings > Accounts > Your Settings > System > Settings > System >
location account > Add a work or school About > Join Azure About > Join a
account AD domain
Also available Yes No No

for iOS and
Android
Devices?
For more information on the different ways to register devices, see also:
Using Windows devices in your workplace

Azure AD registered devices
Azure AD joined devices
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 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 Windows Hello
for Business, 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 multifactor authentication when a device is not registered
These rules can then be combined with other factors such as network access location
and multifactor authentication, creating rich conditional access policies such as:
Require multifactor 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
third 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
Updates and breaking changes - Microsoft identity platform |

Microsoft Docs
Complete list of new AD FS 2016 and device claims

https://schemas.microsoft.com/ws/2014/01/identity/claims/anchorclaimtype
https://schemas.xmlsoap.org/ws/2005/05/identity/Identity_Selector_Interoperabi
lity_Profile_V1.5.pdf
https://schemas.microsoft.com/2014/03/psso
https://schemas.microsoft.com/2015/09/prt
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
https://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid
https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
https://schemas.xmlsoap.org/ws/2005/05/identity/Identity_Selector_Interoperabi
lity_Profile_V1.5_Web_Guide.pdf
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
/dotnet/api/system.security.claims.claimtypes.windowsdeviceclaim
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
/dotnet/api/system.security.claims.claimtypes.windowsdeviceclaim
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/relyingpartytrusti
d
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)
Article • 08/15/2023
As of October 2016, all updates to all components of Windows Server are released only via Windows
Update (WU). There are no more hotfixes or individual downloads. This applies to Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012 and Windows Server 2008 R2 SP1.
This page lists rollup packages of particular interest for AD FS and WAP, as well as the historic list of
hotfix updates recommended for AD FS and WAP.
Updates for AD FS and WAP in Windows Server 2016

Updates for Windows Server 2016 are delivered monthly via Windows Update and are cumulative. The
update package listed below is recommended for all AD FS and WAP 2016 servers and includes all
previously required updates as well as the latest fixes.
KB # Description Date
Released
4534271 Addresses a potential AD FS chrome failure due to support of new SameSite cookie policies January
by default for release 80 of Google Chrome. For more information, please refer here. 2020
CVE-2019- This security update addresses a vulnerability in Active Directory Federation Services (AD FS) July 2019
1126 which could allow an attacker to bypass the extranet lockout policy.
4489889 (OS Addresses an issue in Active Directory Federation Services (AD FS) that causes a duplicate March
Build relying party trust to appear in the AD FS management console. This occurs when you create 2019
14393.2879) or view relying party trusts using the AD FS management console.
Addresses a high Active Directory Federation Services (AD FS) 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 Addresses an issue that causes updates to a relying party trust to fail when using PowerShell February
Build or the Active Directory Federation Services (AD FS) management console. This issue occurs if 2019
14393.2828) 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 Addresses interoperation issues between Active Directory Federation Services (AD FS) Extranet October
Build Smart Lockout (ESL) and Alternate Login ID. When Alternate Login ID is enabled, calls to AD FS 2018
14393.2580) 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 Addresses an Active Directory Federation Services (AD FS) issue where Multi-Factor August
Build Authentication doesn't work correctly with mobile devices that use custom culture definitions. 2018
Released
14393.2457)
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
AD FS Registration Authority (RA) certificate.
4338822 (OS Addresses an issue in AD FS that shows a duplicate Relying Party trust in the AD FS July 2018
Build management console when creating or viewing Relying Party Trusts from the console.
14393.2395)
Addresses an issue in AD FS 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 hasn't 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 Addresses an issue with AD FS that causes an IdP-initiated login to a SAML relying party to fail May 2018
Build when PreventTokenReplays is enabled.
14393.2273)
Addresses an AD FS 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) didn't 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 can't be serialized to JSON.
Addresses an AD FS Windows Hello for business issue in which new users aren't able to
provision their PIN. This occurs when no MFA provider is configured.
4093120 (OS Addresses an unhandled refresh token validation issue. It generates the following error: April 2018
Build "Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInvalidRefreshTokenException:
14393.2214) MSIS9312: Received invalid OAuth refresh token. The refresh token was received earlier than
the permitted time in the token."
4077525 (OS Addresses issue where an HTTP 500 error occurs when an AD FS farm has at least two servers February
Build using Windows Internal Database (WID). In this scenario, HTTP basic pre-authentication on the 2018
14393.2097) 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 'AD FS For Rich Clients'. The given user isn't 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 isn't 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
Released
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 won't be shown the
HRD page. Instead, the user will go directly to the associated IDP for authentication.
4041688 (OS This fix addresses an issue that intermittently misdirects AD Authority requests to the wrong October
Build Identity Provider because of incorrect caching behavior. This can effect authentication features 2017
14393.1794) like Multi Factor Authentication.
Added the ability for Azure AD Connect Health to report AD FS server health with correct
fidelity (using verbose auditing) on mixed WS2012R2 and WS2016 AD FS farms.
Fixed a problem where during upgrade of 2012 R2 AD FS farm to AD FS 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 Support added for OIDC logout using federated LDPs. This will allow "Kiosk Scenarios" where September
Build multiple users might be serially logged into a single device where there's federation with an 2017
14393.1737) 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 AD FS
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 AD FS servers. Also, if the WID primary role is
moved to a secondary node, application groups will no longer be manageable in the AD FS
management UX.
This update fixes an issues where Multi Factor Authentication doesn't work correctly with
Mobile devices that use custom culture definitions
4034661 (OS Fixes a problem where the caller IP address is nog logged by 411 events in the Security Event August
Build log of AD FS 4.0 \ Windows Server 2016 RS1 AD FS servers even after enabling "success 2017
14393.1613) 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 AD FS Proxy

server doesn't return an error to the user."
4034658 (OS Fix for 2016 AD FS server in order to support MFA certificate enrollment for Windows Hello For August
Build Business for on-premises deployments 2017
14393.1593)
4025334 (OS Addressed an issue where the PkeyAuth token handler could fail an authentication if the July 2017
Build pkeyauth request contains incorrect data. The authentication should still continue without
14393.1532) performing device authentication
Released
4022723 (OS [Web Application Proxy] Value of DisableHttpOnlyCookieProtection configuration property June 2017
Build isn't picked up by WAP 2016 in 2012R2/2016 mixed deployment
14393.1378)
[Web Application Proxy] Unable to obtain user access token from AD FS in EAS Pre-auth
scenarios.
AD FS 2016 : WSFED sign-out leads to an exception
3213986 Cumulative Update for Windows Server 2016 for x64-based Systems (KB3213986) January
2017
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.
KB # Description Date Released
4534309 Addresses a potential AD FS chrome failure due to support of new SameSite January 2020
cookie policies by default for release 80 of Google Chrome. For more information,
please refer here.
4507448 This security update addresses a vulnerability in Active Directory Federation Services July 2019
(AD FS) which could allow an attacker to bypass the extranet lockout policy.
4041685 Addressed an AD FS issue where MSISConext cookies in request headers can October 2017
eventually overflow the headers size limit and cause failure to authenticate with Preview of
HTTP status code 400 "Bad Request - Header Too Long". Update Rollup
Fixed a problem where AD FS can no longer ignore "prompt=login" during

authentication. A "Disabled" option was added to restore scenarios where non-
password authentication is used.
4019217 Work Folders clients using token broker do not work when using a Server 2012 R2 May 2017
AD FS Server Preview Update
Rollup
4015550 Fixed an issue with AD FS not authenticating External users and AD FS WAP April 2017
randomly failing to forward request Update Rollup
4015547 Fixed an issue with AD FS not authenticating External users and AD FS WAP April 2017
randomly failing to forward request Security Update
4012216 MS17-019 This security update resolves a vulnerability in Active Directory Federation March 2017
Services (AD FS). The vulnerability could allow information disclosure if an attacker Update Rollup
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 password update. August 2016

Update Rollup
3172614 Introduced prompt=login support, fixed issue with the AD FS management console July 2016
and AlwaysRequireAuthentication setting. Update Rollup
Active Directory Federation Services (AD FS) 3.0 can't connect to Lightweight June 2016
Directory Access Protocol (LDAP) attribute stores that are configured to use Secure Update Rollup
Sockets Layer (SSL) port 636 or 3269 in connection string.
3148533 MFA fallback authentication fails through AD FS Proxy in Windows Server 2012 R2 May 2016
3134787 AD FS logs don't contain client IP address for account lockout scenarios in Windows February 2016
Server 2012 R2
3134222 MS16-020: Security update for Active Directory Federation Services to address denial February 2016
of service: February 9, 2016
3105881 Can't access applications when device authentication is enabled in Windows Server October 2015
2012 R2-based AD FS server
3092003 Page loads repeatedly and authentication fails when users use MFA in Windows August 2015
Server 2012 R2 AD FS
3080778 AD FS doesn't call OnError when MFA adapter throws an exception in Windows July 2015
Server 2012 R2
3075610 Trust relationships are lost on secondary AD FS server after you add or remove July 2015
claims provider in Windows Server 2012 R2
3070080 Home Realm Discovering not working correctly for Non-claims Aware Relying Party June 2015
Trust
3052122 Update adds support for compound ID claims in AD FS tokens in Windows Server May 2015
2012 R2
3045711 MS15-040: Vulnerability in Active Directory Federation Services could allow April 2015
information disclosure
3042127 "HTTP 400 - Bad Request" error when you open a shared mailbox through WAP in March 2015
3042121 AD FS token replay protection for Web Application Proxy authentication tokens in March 2015
3035025 Hotfix for update password feature so that users aren't required to use registered January 2015
device in Windows Server 2012 R2
3033917 AD FS can't process SAML response in Windows Server 2012 R2 January 2015
3025080 Operation fails when you try to save an Office file through Web Application Proxy in January 2015
3025078 You aren't prompted for username again when you use an incorrect username to log January 2015
on to Windows Server 2012 R2
3020813 You're prompted for authentication when you run a web application in Windows January 2015
Server 2012 R2 AD FS
3020773 Time-out failures after initial deployment of Device Registration service in Windows January 2015
Server 2012 R2
3018886 You're prompted for a username and password two times when you access Windows January 2015
Server 2012 R2 AD FS server from intranet
3013769 Windows Server 2012 R2 Update Roll-up December 2014
3000850 Windows Server 2012 R2 Update Roll-up November 2014
2975719 Windows Server 2012 R2 Update Roll-up August 2014
2967917 Windows Server 2012 R2 Update Roll-up July 2014
2962409 Windows Server 2012 R2 Update Roll-up June 2014
2955164 Windows Server 2012 R2 Update Roll-up May 2014
2919355 Windows Server 2012 R2 Update Roll-up April 2014
Updates for AD FS in Windows Server 2012 (AD FS 2.1)

and AD FS 2.0
Below is the list of hotfixes and update rollups that have been released for AD FS 2.0 and 2.1.
KB # Description Date Released Applies

To:
3197878 Authentication through proxy fails in Windows Server 2012 (this is November 2016 AD FS 2.1
the general release of hotfix 3094446) Quality Rollup
3197869 Authentication through proxy fails in Windows Server 2008 R2 SP1 November 2016 AD FS 2.0
(this is the general release of hotfix 3094446) Quality Rollup
3094446 Authentication through proxy fails in Windows Server 2012 or September 2015 AD FS 2.0
Windows Server 2008 R2 SP1 and 2.1
3070078 AD FS 2.1 throws an exception when you authenticate against an July 2015 AD FS 2.1
encryption certificate in Windows Server 2012
3062577 MS15-062: Vulnerability in Active Directory federation services June 2015 AD FS 2.0
could allow elevation of privilege / 2.1
3003381 MS14-077: Vulnerability in Active Directory Federation Services November 2014 AD FS 2.0
could allow information disclosure: April 14, 2015 / 2.1
2987843 Memory usage of AD FS federation server keeps increasing when July 2014 AD FS 2.1
many users log on a web application in Windows Server 2012
2957619 The relying party trust in AD FS is stopped when a request is made May 2014 AD FS 2.1
to AD FS for a delegated token
2926658 AD FS SQL farm deployment fails if you do not have SQL October 2014 AD FS 2.1
permissions
2896713 or Update is available to fix several issues after you install security November 2013 AD FS 2.0
2989956 update 2843638 on an AD FS server / 2.1
September 2014
2877424 Update enables you to use one certificate for multiple Relying Party October 2013 AD FS 2.1
Trusts in an AD FS 2.1 farm
KB # Description Date Released Applies
To:
2873168 FIX: An error occurs when you use a third-party CSP and HSM and September 2013 AD FS 2.0
then configure a claims provider trust in Update Rollup 3 for AD FS
2.0 on Windows Server 2008 R2 Service Pack 1
A comma in the subject name of an encryption certificate causes an August 2013 AD FS 2.0
exception in Windows Server 2008 R2 SP1
2843639 [Security] Vulnerability in Active Directory Federation Services Could November 2013 AD FS 2.1
Allow Information Disclosure
2843638 MS13-066: Description of the security update for Active Directory August 2013 AD FS 2.0
Federation Services 2.0: August 13, 2013
2827748 Federationmetadata.xml file doesn't contain the MEX endpoint May 2013 AD FS 2.1
information for the WS-Trust and WS-Federation endpoints in
Windows Server 2012
2790338 Description of Update Rollup 3 for Active Directory Federation March 2013 AD FS 2.0
Services (AD FS) 2.0
Creating an AD FS Farm without domain
admin privileges
Article • 08/15/2023
Applies to: Windows Server 2022, 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 AD FS 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)
{
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 AD FS admin read
access
#######################################
if ($pscmdlet.ShouldProcess("$ou", "Creating DKM container and assigning

access"))
{
Write-Verbose ("Creating organizational unit with DN: " + $ou)
if ($AdfsAdministratorAccount.EndsWith("$"))
{
write-verbose "AD FS administrator account passed with $ suffix
indicating a computer account"
$userNameSplit = $AdfsAdministratorAccount.Split("\");
$strSID = (Get-ADServiceAccount -Identity $userNameSplit[1]).SID
}
else
{
write-verbose "AD FS 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}))

{
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"
System.Security.Principal.NTAccount($ServiceAccount)
$strSID =
}
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 "AD FS administrator account passed with $ suffix
indicating a gMSA"
$userNameSplit = $AdfsAdministratorAccount.Split("\");
}
else
{
write-verbose "AD FS administrator account is a standard AD user"
System.Security.Principal.NTAccount($AdfsAdministratorAccount)
$strSID =
}
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
Article • 08/15/2023
） Important
If you want to create an AD FS farm and use SQL Server to store your configuration
data, you can use SQL Server 2008 or higher.
If you are using SQL Server as your AD FS configuration database, you can set up geo-
redundancy for your AD FS farm using SQL Server replication. Geo-redundancy
replicates data between two geographically distant sites so that applications can switch
from one site to another. This way, in case of the failure of one site, you can still have all
the configuration data available at the second site. For more information, see the "SQL
Server geographic redundancy section" in Federation Server Farm Using SQL Server.
Prerequisites
Install and configure a SQL server farm. For more information, see
https://technet.microsoft.com/evalcenter/hh225126.aspx . On the initial SQL Server,
make sure that the SQL Server Agent service is running and set to automatic start.
Create the second (replica) SQL Server for geo-

redundancy
1. Install SQL Server (for more information, see
https://technet.microsoft.com/evalcenter/hh225126.aspx . Copy the resulting
CreateDB.sql and SetPermissions.sql script files to the replica SQL server.
2. Ensure SQL Server Agent service is running and set to automatic start
3. Run Export-AdfsDeploymentSQLScript on the primary AD FS node to create

CreateDB.sql and SetPermissions.sql files. For example: PS:\>Export-
AdfsDeploymentSQLScript -DestinationFolder . –ServiceAccountName
CONTOSO\gmsa1$ .
4. Copy the scripts to your secondary server. Open the CreateDB.sql script in SQL
Management Studio and click Execute.
5. Open the SetPermissions.sql script in SQL Management Studio and click Execute.
７ Note
You can also use the following from the command line.
c:\>sqlcmd –i CreateDB.sql
c:\>sqlcmd –i SetPermissions.sql
Create publisher settings on the initial SQL

Server
1. From the SQL Server Management studio, under Replication, right click Local
Publications and choose New Publication...
2. On the New Publication Wizard screen click Next.
3. On Distributor page, choose local server as distributor and click Next.
4. On the Snapshot folder page, enter \\SQL1\repldata in place of default folder.

(NOTE: You may have to create this share yourself).
5. Choose AdfsConfigurationV3 as the publication database and click Next.
6. On Publication Type, choose Merge publication and click Next.

7. On Subscriber Types, choose SQL Server 2008 or later and click Next.
8. On the Articles page select Tables node to select all tables, then un-check
SyncProperties table (this one should not be replicated)
9. On the Articles page, select User Defined Functions node to select all User
Defined Functions and click Next..
10. On the Article issues page click Next.

11. On the Filter Table Rows page, click Next.
12. On the Snapshot Agent page, choose defaults of Immediate and 14 days, click
Next.
You may need to create a domain account for the SQL agent. Use the steps in
Configure SQL login for the domain account CONTOSO\sqlagent to create SQL
login for this new AD user and assign specific permissions.
13. On the Agent Security page, click Security Settings and enter the
username/password of a domain account (not a GMSA) created for the SQL agent
and click OK. Click Next.
14. On the Wizard Actions page, click Next.
15. On the Complete the Wizard page, enter a name for your publication and click
Finish.
16. Once the publication is created you should see the status of success. Click Close.
17. Back in SQL Server Management Studio, right-click the new Publication and click
Launch Replication Monitor.
Create subscription settings on the replica SQL

Server
Make sure that you created the publisher settings on the initial SQL Server as described
above and then complete the following procedure:
1. On the replica SQL Server, from SQL Server Management studio, under
Replication, right click Local Subscriptions and choose New Subscription....
2. On the New Subscription Wizard page, click Next.
3. On the Publication page, select the publisher from the drop-down. Expand
AdfsConfigurationV3 and select the name of the publication created above and
click Next.
4. On the Merge Agent Location page, select Run each agent at its Subscriber (pull
subscriptions) (the default) and click Next.
This, along with Subscription Type below, determines the conflict resolution logic.
(For more information, see Detect and Resolve Merge Replication Conflicts.
5. On the Subscribers page, select AdfsConfigurationV3 as the subscriber database

and click Next.
6. On the Merge Agent Security page, click ... and enter the username and password
of a domain account (not a GMSA) created for the SQL agent by using the ellipses
box and click Next.
7. On Synchronization Schedule, choose Run Continuously and click Next.

8. On Initialize Subscriptions, click Next.
9. On Subscription Type, choose Client and click Next.
Implications of this are documented here and here. Essentially, we take the simple
"first to publisher wins" conflict resolution and we do not need to republish to
other subscribers.
10. On the Wizard Actions page, ensure Create the subscription is checked and click
Next.
11. On the Complete the Wizard page, click Finish.
12. Once the subscription has finished the creation process, you should see success.
Click Close.
Verify the process of initialization and
replication
1. On the primary SQL server, right-click the Replication node and click Launch
Replication Monitor.
2. In Replication Monitor, click the publication.
3. On the All Subscriptions tab, right click and View Details.
You should be able to see many entries under Actions for the initial replication.
4. Additionally, you can look under the SQL Server Agent\Jobs node to see the job(s)
scheduled to execute the operations of the publication/subscription. Only local
jobs are shown, so make sure to check on the publisher and the subscriber for
troubleshooting. Right-click a job and select View History to view execution
history and results.
Configure SQL login for the domain account

CONTOSO\sqlagent
1. Create a new login on the primary and replica SQL Server called
CONTOSO\sqlagent (the name of the new domain user created and configured on
the Agent Security page in the procedures above.)
2. In SQL Server, right-click the login you created, and select Properties, then under
the User Mapping tab, map this login to AdfsConfiguration and AdfsArtifact
databases with public and db_genevaservice roles. Also map this login to
distribution database and add db_owner role for both distribution and
adfsconfiguration tables. Do this as applicable on both primary and replica SQL
server. For more information, see Replication Agent Security Model.
3. Give the corresponding domain account read and write permissions on the share
configured as distributor. Make sure that you set read and write permissions both
on the share permissions and the local file permissions.
Configure AD FS node(s) to point to the SQL

Server replica farm
Now that you have set up geo redundancy, the AD FS farm nodes can be configured to
point to your replica SQL Server farm using the standard AD FS "join" farm capabilities,
either from the AD FS Configuration Wizard UI or using Windows PowerShell.
If you use the AD FS Configuration Wizard UI, select Add a federation server to a
federation server farm. Do NOT select Create the first federation server in a federation
server farm.
If you use Windows PowerShell, run Add-AdfsFarmNode. Do NOT run Install-AdfsFarm.
When prompted, provide the host and instance name of the replica SQL Server, NOT the
initial SQL server.
Set up the lab environment for AD FS in
Article • 08/15/2023
This topic outlines the steps to configure a test environment that can be used to
complete the walkthroughs in the following walkthrough guides:
Walkthrough: Workplace Join with an iOS Device
Walkthrough: Workplace Join with a Windows Device
Walkthrough Guide: Manage Risk with Conditional Access Control
Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for

Sensitive Applications
７ Note
We do not recommend that you install the web server and the federation server on
the same computer.
To set up this test environment, complete the following steps:
1. Step 1: Configure the domain controller (DC1)
2. Step 2: Configure the federation server (ADFS1) with Device Registration Service
3. Step 3: Configure the web server (WebServ1) and a sample claims-based

application
4. Step 4: Configure the client computer (Client1)
Step 1: Configure the domain controller (DC1)

For the purposes of this test environment, you can call your root Active Directory
domain contoso.com and specify pass@word1 as the administrator password.
Install the AD DS role service and install Active Directory Domain Services (AD DS)
to make your computer a domain controller in Windows Server 2012 R2 . This
action upgrades your AD DS schema as part of the domain controller creation. For
more information and step-by-step instructions,
seehttps://technet.microsoft.com/library/hh472162.aspx.
Create test Active Directory accounts
After your domain controller is functional, you can create a test group and test user
accounts in this domain and add the user account to the group account. You use these
accounts to complete the walkthroughs in the walkthrough guides that are referenced
earlier in this topic.
Create the following accounts:
User: Robert Hatley with the following credentials: User name: RobertH and
password: P@ssword
Group: Finance
For information about how to create user and group accounts in Active Directory (AD),
see https://technet.microsoft.com/library/cc783323%28v.aspx.
Add the Robert Hatley account to the Finance group. For information on how to add a
user to a group in Active Directory, see
https://technet.microsoft.com/library/cc737130%28v=ws.10%29.aspx.
Create a GMSA account

The group Managed Service Account (GMSA) account is required during the Active
Directory Federation Services (AD FS) installation and configuration.
To create a GMSA account
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 install the Federation Service role service
1. Log on to the server by using the domain administrator account

administrator@contoso.com.
2. Start Server Manager. To start Server Manager, click Server Manager on the
Windows Start screen, or click Server Manager on the Windows taskbar on the
Windows desktop. On the Quick Start tab of the Welcome tile on the Dashboard
page, click Add roles and features. Alternatively, you can click Add Roles and
Features on the Manage menu.

installation, and then click Next.
verify that the target computer is selected, and then click Next.
6. On the Select server roles page, click Active Directory Federation Services, and
then click Next.
8. On the Active Directory Federation Service (AD FS) page, click Next.
9. After you verify the information on the Confirm installation selections page, select
the Restart the destination server automatically if required check box, and then
click Install.
10. On the Installation progress page, verify that everything installed correctly, and
then click Close.
Configure the federation server

The next step is to configure the federation server.
To configure the federation server
1. On the Server Manager Dashboard page, click the Notifications flag, and then
click Configure the federation service on the server.
The Active Directory Federation Service Configuration Wizard opens.
2. On the Welcome page, select Create the first federation server in a federation
server farm, and then click Next.
3. On the Connect to AD DS page, specify an account with domain administrator

rights for the contoso.com Active Directory domain that this computer is joined to,
and then click Next.
4. On the Specify Service Properties page, do the following, and then click Next:
Import the SSL certificate that you have obtained earlier. This certificate is the
required service authentication certificate. Browse to the location of your SSL
certificate.
To provide a name for your federation service, type adfs1.contoso.com. This

value is the same value that you provided when you enrolled an SSL
certificate in Active Directory Certificate Services (AD CS).
To provide a display name for your federation service, type Contoso

Corporation.
5. On the Specify Service Account page, select Use an existing domain user account
or group Managed Service Account, and then specify the GMSA account fsgmsa
that you created when you created the domain controller.
6. On the Specify Configuration Database page, select Create a database on this
server using Windows Internal Database, and then click Next.
7. On the Review Options page, verify your configuration selections, and then click
Next.
8. On the Pre-requisite Checks page, verify that all prerequisite checks were
successfully completed, and then click Configure.
9. On the Results page, review the results, check whether the configuration has
completed successfully, and then click Next steps required for completing your
federation service deployment.
Configure Device Registration Service

The next step is to configure Device Registration Service on the ADFS1 server. For a
video, see Active Directory Federation Services How-To Video Series: Enabling the
Device Registration Service.
To configure Device Registration Service for Windows Server 2012

RTM
1. ） Important
The following step applies to the Windows Server 2012 R2 RTM build.
Open a Windows PowerShell command window and type:
Initialize-ADDeviceRegistration
When you are prompted for a service account, type contoso\fsgmsa$.
Now run the Windows PowerShell cmdlet.
Enable-AdfsDeviceRegistration
2. On the ADFS1 server, in the AD FS Management console, navigate to

Authentication Policies. Select Edit Global Primary Authentication. Select the
check box next to Enable Device Authentication, and then click OK.
Add Host (A) and Alias (CNAME) Resource Records to

DNS
On DC1, you must ensure that the following Domain Name System (DNS) records are
created for Device Registration Service.
Entry Type Address
adfs1 Host (A) IP address of the AD FS server
enterpriseregistration Alias (CNAME) adfs1.contoso.com
You can use the following procedure to add a host (A) resource record to corporate DNS
name servers for the federation server and Device Registration Service.
Membership in the Administrators group or an equivalent is the minimum requirement

to complete this procedure. Review details about using the appropriate accounts and
group memberships in the HYPERLINK "https://go.microsoft.com/fwlink/?
LinkId=83477 " Local and Domain Default Groups (https://go.microsoft.com/fwlink/p/?
LinkId=83477 ).
To add a host (A) and alias (CNAME) resource records to DNS for
your federation server
1. On DC1, from Server Manager, on the Tools menu, click DNS to open the DNS
snap-in.
2. In the console tree, expand DC1, expand Forward Lookup Zones, right-click
contoso.com, and then click New Host (A or AAAA).
3. In Name, type the name you want to use for your AD FS farm. For this
walkthrough, type adfs1.
4. In IP address, type the IP address of the ADFS1 server. Click Add Host.
5. Right-click contoso.com, and then click New Alias (CNAME).
6. In the New Resource Record dialog box, type enterpriseregistration in the Alias
name box.
7. In the Fully Qualified Domain Name (FQDN) of the target host box, type
adfs1.contoso.com, and then click OK.
） Important
In a real-world deployment, if your company has multiple user principal name

(UPN) suffixes, you must create multiple CNAME records, one for each of
those UPN suffixes in DNS.
Step 3: Configure the web server (WebServ1)

and a sample claims-based application
Set up a virtual machine (WebServ1) by installing the Windows Server 2012 R2 operating
system and connect it to the domain contoso.com. After it is joined to the domain, you
can proceed to install and configure the Web Server role.
To complete the walkthroughs that were referenced earlier in this topic, you must have a
sample application that is secured by your federation server (ADFS1).
You must complete the following steps to set up a web server with this sample claims-
based application.
７ Note
These steps have been tested on a web server that runs the Windows Server 2012
R2 operating system.
1. Install the Web Server Role and Windows Identity Foundation
2. Install Windows Identity Foundation SDK
3. Configure the simple claims app in IIS
4. Create a relying party trust on your federation server
Install the Web Server role and Windows Identity

Foundation
1. ７ Note
You must have access to the Windows Server 2012 R2 installation media.
Log on to WebServ1 by using administrator@contoso.com and the password
pass@word1.
2. From Server Manager, on the Quick Start tab of the Welcome tile on the
Dashboard page, click Add roles and features. Alternatively, you can click Add
Roles and Features on the Manage menu.

6. On the Select server roles page, select the check box next to Web Server (IIS),
click Add Features, and then click Next.
7. On the Select features page, select Windows Identity Foundation 3.5, and then
click Next.
8. On the Web Server Role (IIS) page, click Next.
9. On the Select role services page, select and expand Application Development.
Select ASP.NET 3.5, click Add Features, and then click Next.
10. On the Confirm installation selections page, click Specify an alternate source
path. Enter the path to the Sxs directory that is located in the Windows Server
2012 R2 installation media. For example D:\Sources\Sxs. Click OK, and then click
Install.
Install Windows Identity Foundation SDK

1. Run WindowsIdentityFoundation-SDK-3.5.msi to install Windows Identity
Foundation SDK 3.5. Choose all of the default options.
Configure the simple claims app in IIS

1. Install a valid SSL certificate in the computer certificate store. The certificate should
contain the name of your web server, webserv1.contoso.com.
2. Copy the contents of C:\Program Files (x86)\Windows Identity Foundation

SDK\v3.5\Samples\Quick Start\Web
Application\PassiveRedirectBasedClaimsAwareWebApp to C:\Inetpub\Claimapp.
3. Edit the Default.aspx.cs file so that no claim filtering takes place. This step is
performed to ensure that the sample application displays all the claims that are
issued by the federation server. Do the following:
a. Open Default.aspx.cs in a text editor.
b. Search the file for the second instance of ExpectedClaims .
c. Comment out the entire IF statement and its braces. Indicate comments by
typing "//" (without the quotes) at the beginning of a line.
d. Your FOREACH statement should now look like this code example.
Foreach (claim claim in claimsIdentity.Claims)

{
//Before showing the claims validate that this is an expected
claim
//If it is not in the expected claims list then don't show it
//if (ExpectedClaims.Contains( claim.ClaimType ) )
// {
writeClaim( claim, table );
//}
}
e. Save and close Default.aspx.cs.
f. Open web.config in a text editor.
g. Remove the entire <microsoft.identityModel> section. Remove everything

starting from including <microsoft.identityModel> and up to and including
</microsoft.identityModel> .
h. Save and close web.config.
4. Configure IIS Manager
a. Open Internet Information Services (IIS) Manager.
b. Go to Application Pools, right-click DefaultAppPool to select Advanced

Settings. Set Load User Profile to True, and then click OK.
c. Right-click DefaultAppPool to select Basic Settings. Change the .NET CLR

Version to .NET CLR Version v2.0.50727.
d. Right-click Default Web Site to select Edit Bindings.
e. Add an HTTPS binding to port 443 with the SSL certificate that you have
installed.
f. Right-click Default Web Site to select Add Application.
g. Set the alias to claimapp and the physical path to c:\inetpub\claimapp.
5. To configure claimapp to work with your federation server, do the following:
a. Run FedUtil.exe, which is located in C:\Program Files (x86)\Windows Identity

Foundation SDK\v3.5.
b. Set the application configuration location to C:\inetput\claimapp\web.config

and set the application URI to the URL for your site,
https://webserv1.contoso.com /claimapp/. Click Next.
c. Select Use an existing STS and browse to your AD FS server's metadata URL
https://adfs1.contoso.com/federationmetadata/2007-
06/federationmetadata.xml . Click Next.
d. Select Disable certificate chain validation, and then click Next.
e. Select No encryption, and then click Next. On the Offered claims page, click
Next.
f. Select the check box next to Schedule a task to perform daily WS-Federation
metadata updates. Click Finish.
g. Your sample application is now configured. If you test the application URL
https://webserv1.contoso.com/claimapp , it should redirect you to your
federation server. The federation server should display an error page because
you have not yet configured the relying party trust. In other words, you have not
secured this test application by AD FS.
You must now secure your sample application that runs on your web server with AD FS.
You can do this by adding a relying party trust on your federation server (ADFS1). For a
video, see Active Directory Federation Services How-To Video Series: Add a Relying Party
Trust.
Create a relying party trust on your federation server

1. On you federation server (ADFS1), in the AD FS Management console, navigate to
Relying Party Trusts, and then click Add Relying Party Trust.
2. On the Select Data Source page, select Import data about the relying party
published online or on a local network, enter the metadata URL for claimapp, and
then click Next. Running FedUtil.exe created a metadata .xml file. It is located at
https://webserv1.contoso.com/claimapp/federationmetadata/2007-
06/federationmetadata.xml .
3. On the Specify Display Name page, specify the display name for your relying
party trust, claimapp, and then click Next.
4. On the Configure Multi-factor Authentication Now? page, select I do not want to

specify multi-factor authentication setting for this relying party trust at this
time, and then click Next.
5. On the Choose Issuance Authorization Rules page, select Permit all users to
access this relying party, 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
Upgrade an existing AD FS farm by
using Windows Internal Database
Article • 06/30/2023
） Important

migrating to Azure AD.
For more information, see Resources for decommissioning
AD FS
In this article, you learn how to upgrade the farm behavior level for Active Directory
Federation Services (AD FS) by using Windows Internal Database (WID). Beginning in
Windows Server 2016, the farm behavior level (FBL) was introduced to AD FS. The FBL is
farm-wide setting that determines the features the AD FS farm can use.
Administrators can add new federation servers to an existing Windows Server farm in
"mixed mode." Mixed mode operates at the same farm behavior level as the original
farm to ensure consistent behavior. Features of the newer Windows Server AD FS
versions can't be configured or used.
Prerequisites
Before you can upgrade the farm behavior level, you must meet the following
prerequisites:
Determine which version of Windows Server to upgrade to.
Deploy the target Windows Server version on a new computer, apply all Windows
Updates, and install the Active Directory Federation Service server role. For more
information, see Add a federation server to an existing federation server farm.
If you're also using Windows Server Web Application Proxy, deploy the target
Windows Server version on a new computer, apply all Windows Updates, and
install the Remote Access server role and Web Application Proxy role service. For
more information, see Working with Web Application Proxy.
If you're upgrading to AD FS in Windows Server 2016 or later, the farm upgrade

requires the AD schema to be at least level 85. If you're upgrading to in Windows
Server AD FS 2019 or later, the AD schema must be at least 88. For more
information about upgrading your domain, see Upgrade domain controllers to a
newer version of Windows Server.
Have a defined time frame planned for completion. It's not recommended to
operate a mixed mode state for an extended period of time. Leaving AD FS in a
mixed mode state might cause issues with the farm.
Back up your AD FS configuration and federation servers.
Farm behavior levels

By default, the FBL in a new AD FS farm matches the value for the Windows Server
version of the first farm node installed.
You can join an AD FS server of a later version to a farm with a lower FBL. The farm
operates 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 "mixed." However, you can't take advantage of the features of the later versions
until you raise the FBL. If your organization is looking to test the new features prior to
raising the FBL, you need to deploy a separate farm.
The following table lists the possible FBL values and configuration database names by
Windows Server version.
Windows Server Version FBL value AD FS Configuration Database Name
2012 R2 1 AdfsConfiguration
2016 3 AdfsConfigurationV3
2019 and 2022 4 AdfsConfigurationV4
７ Note
Upgrading the FBL creates a new AD FS configuration database.
Now that you understand the purpose of the FBL and have completed the prerequisites,
you're ready to review your current FBL.
To find your current FBL:
1. Sign in to your federation server and open an elevated PowerShell session.

2. Run the following PowerShell command to return the current FBL and farm node
information.
PowerShell
Get-AdfsFarmInformation
3. Review the CurrentFarmBehavior and FarmNodes .
Migrate federation servers

After you've collected the current federation farm information, you're ready to begin the
upgrade process. To begin the upgrade:
1. Add the new federation server(s) to your existing farm. For more information, see
Add a federation server to an existing federation server farm.
2. Sign into your new federation server, then open an elevated PowerShell session. If
you have more than one server, only run this command on one server.
3. Set the federation server sync property to take the primary computer role by
running the following command. For more information, see Set-
AdfsSyncProperties.
PowerShell
Set-AdfsSyncProperties -Role PrimaryComputer
4. Sign into any other federation servers in the farm, open an elevated PowerShell
session.
5. Set the role to be the secondary computer by running the following command.
PowerShell
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName "

<primary-server-FQDN>"
6. Update any load balancer, DNS, or network configurations to use the new
federation servers, verifying the server is operational. For more information, see
Verify your Windows Server 2012 R2 Federation Server is Operational.
7. Uninstall the Active Directory Federation Service server role from the previous
servers, then run
the following command to remove the stale entries.
PowerShell
Set-AdfsFarmInformation -RemoveNode "<old-server-FQDN>"
Now that you have your new federations server to farm and removed the previous ones,
you're ready to upgrade the FBL. For more information about decommissioning, see
Steps to decommission your AD FS Servers.
Upgrade the Farm Behavior Level

After you've collected the current federation farm information, you're ready to begin the
upgrade process. To begin the upgrade:
1. Sign into your primary federation server, then open an elevated PowerShell
session.
2. Run the following command to test whether you can raise the behavior level of a
farm.
PowerShell
Test-AdfsFarmBehaviorLevelRaise
3. Ater you've reviewed the output, to upgrade the farm behavior level, run the
following command. You're prompted if you want to continue.
PowerShell
Invoke-AdfsFarmBehaviorLevelRaise
4. Review the command output to confirm the operation was successful. To verify the
new farm behavior level, run the following PowerShell command to return the
current FBL and farm node information.
PowerShell
Get-AdfsFarmInformation
You've now upgraded your FBL to match your target Windows Server version. If you're
also using the Windows Server Web Application Proxy role service, continue to the next
section.
Upgrade Web Application Proxy

Now that you've updated your FBL, you need to upgrade Web Application Proxy (WAP)
to the latest level.
1. Sign in to your newly deployed Web Application Proxy server and open an
elevated PowerShell session.
2. Import the certificate used by the federation certificate, and make a note of the
certificate thumbprint.
3. To configure WAP, run the following PowerShell command, replacing the

placeholder <value> with your own values. Repeat this step for any more Web
Application Proxy servers.
PowerShell
$trustcred = Get-Credential -Message "<Enter Domain Administrator

credentials>"
Install-WebApplicationProxy -CertificateThumbprint "

<SSLCertThumbprint>" -FederationServiceName "<FScomputername>" -
FederationServiceTrustCredential $trustcred
4. To review the current connected Web Application Proxy servers, run the following
command, note the ConnectedServerName and ConfigurationVersion values.
PowerShell
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 and
later.
5. Remove old Web Application Proxy servers, keeping only the new servers
configured in the previous steps by running the following PowerShell cmdlet:
PowerShell
Set-WebApplicationProxyConfiguration -ConnectedServersName
"WAPServerName1, WAPServerName2"
6. To upgrade the ConfigurationVersion of the WAP servers, run the following

PowerShell command:
PowerShell
Set-WebApplicationProxyConfiguration -UpgradeConfigurationVersion
You've now completed the upgrade of the Web Application Proxy.
Certificate trust model with Windows Hello for

Business
If you're using AD FS on Windows Server 2019 or later, and Windows Hello for Business
in a certificate trust model, you might encounter the following event log error message.
Received invalid Oauth request. The client 'NAME' is forbidden to access the
resource with scope 'ugs'.
To fix this error:
1. Open the AD FS management console. Go to Services > Scope Descriptions.
2. Right-click Scope Descriptions and select Add Scope Description.
3. Under name, enter ugs, and then select Apply > OK.
4. Launch PowerShell as Administrator and run the following commands.
PowerShell
$id = (Get-AdfsApplicationPermission -ServerRoleIdentifiers

'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{
$_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b'
}).ObjectIdentifier
Set-AdfsApplicationPermission -TargetIdentifier $id -AddScope 'ugs'

6. Restart the client. The user should be prompted to configure Windows Hello for
Business.
Next steps
Now that you've upgraded your AD FS deployment, here are some articles that you
might find useful.
Verify That a Federation Server Is Operational

Verify That a Federation Server Proxy Is Operational
AD FS Operations
Deploy Active Directory Federation Services in
Azure
Article • 08/15/2023
Active Directory Federation Services (AD FS) provides simplified, secured identity federation and web single
sign-on (SSO) capabilities. Federation with Azure AD or Microsoft 365 lets users authenticate using on-
premises credentials and access all cloud resources. 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:
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 with just a few
selections 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 easy and hassle-free.
Design principles
This diagram shows the recommended basic topology to start deploying your AD FS infrastructure in Azure.
The following are principles behind the various components of the topology:
DC/AD FS servers: If you have fewer than 1,000 users, you can install AD FS role on your domain
controllers (DCs). If you don't want any performance effect on the DCs, or if you have more than 1,000
users, deploy AD FS on separate servers.
WAP server – It's necessary to deploy web application proxy servers so that users can reach the AD FS
when they aren't on the company network.
DMZ: The web application proxy servers are 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, we recommend that you group
two or more virtual machines (VMs) in an availability set for similar workloads. This configuration
ensures that during either a planned or unplanned maintenance event, at least one VM is available.
Storage accounts: We recommend you have two storage accounts. Having a single storage account
can lead to creating a single point of failure. If you have only one storage account, it can cause the
deployment to become unavailable in the unlikely event where the storage account fails. Two storage
accounts 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
servers in an isolated subnet. You can configure the network security group settings for each subnet
and allow only required communication between the two subnets. More details are given per the
following deployment scenario.
Steps to deploy AD FS in Azure

This section outlines the steps to deploy an AD FS infrastructure in Azure.
Deploy the network

As outlined previously, you can either create two subnets in a single virtual network or create two different
virtual networks. This article focuses on deploying a single virtual network and dividing it into two subnets.
This approach is currently easier as two separate virtual networks would require a virtual network to virtual
network gateway for communications.
Create a virtual network

1. Sign in to the Azure portal with your Azure account.
2. In the portal, search for and select Virtual networks.
3. On the Virtual networks page, select Create.
4. In Create virtual network, enter or select this information in the Basics tab:
Setting Value
Project details
Subscription Select your subscription.
Resource group Select your resource group. Or select Create new to create one.
Instance details
Setting Value
Virtual network name Enter a name for your virtual network.
Region Choose a region.
5. Select Next.
6. In the Security tab, enable any security service you might want and select Next.
7. On the IP addresses tab, a default subnet is already created and ready for VMs to be added. For this
example, select default to edit the subnet.
a. On the Edit subnet page, rename the subnet to INT.
b. Enter IP address and Subnet size information as necessary to define an IP address space.
c. For Network security group, select Create new.
d. For this example, enter the name NSG_INT and select OK, then select Save. You've created your
first subnet.
e. To create your second subnet, select + Add a subnet.
f. On the Add a subnet page, enter DMZ for the second subnet name and enter information as
necessary to define an IP address space.
g. For Network security group, select Create new.
h. Enter the name NSG_DMZ, select OK, then select Add.
8. Select Review + create, and if everything looks okay, select Create.
You now have a virtual network that includes two subnets, each with an associated network security group.
Secure the virtual network
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.
The NSGs associated with your subnets automatically include some default inbound and outbound rules.
You can't delete default security rules, but you can override them with rules that have a higher priority. And,
you can add more inbound and outbound rules according to the level of security you want.
Now, add a couple of rules to each of our two security groups. For the first example, let's add an inbound
security rule to the NSG_INT security group.
1. On your virtual network's Subnets page, select NSG_INT.
2. On the left, select Inbound security rules, then select + Add.
3. In Add inbound security rule, enter or select this information:
Setting Value
Source 10.0.1.0/24.
Source port Leave (or select) asterisk. An asterisk (*) allows traffic on any port. For this example, choose
ranges asterisk for all of the rules you create.
Destination 10.0.0.0/24.
Service Select HTTPS.

The settings for Destination port ranges and Protocol are automatically filled based on the
specified Service.
Action Choose Allow.
Priority 1010.
Rules are processed in priority order; the lower the number, the higher the priority.
Name AllowHTTPSFromDMZ.
Description Allow the HTTPS communication from DMZ.
4. After you've made your choices, select Add.

The new inbound security rule is now added to the top of the list of rules for NSG_INT.
5. Repeat these steps with the values shown in the following table. In addition to the new rule you
created, you must add the following extra rules in the priority order listed to help secure your internal
and DMZ subnet.
NSG Type of Source Destination Service Action Priority Name Description

rule
NSG_INT Outbound Any Service Custom Deny 100 DenyInternetOutbound No access

Tag/Internet (80/Any) to internet.
NSG_DMZ Inbound Any Any Custom Allow 1010 AllowHTTPSFromInternet Allow

(Asterisk HTTPS from
(*)/Any) internet to
the DMZ.
NSG_DMZ Outbound Any Service Custom Deny 100 DenyInternetOutbound Anything

Tag/Internet (80/Any) except
HTTPS to
internet is
blocked.
After you've entered the values for each new rule, select Add and proceed to the next until two new
security rules are added for each NSG.
After configuration, the NSG pages look like this example:

７ 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.
Create connection to on-premises
You need a connection to on-premises to deploy the DC in Azure. Azure offers various options to connect
your on-premises infrastructure to your Azure infrastructure.
Point-to-site
Virtual Network site-to-site
ExpressRoute
We recommend you use ExpressRoute. ExpressRoute lets you create private connections between Azure
datacenters and infrastructure that's on your premises or in a colocation environment. ExpressRoute
connections don't go over the public internet. They offer more reliability, faster speeds, lower latencies and
higher security than typical connections over the internet.
While we recommend you use ExpressRoute, you can 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.
Create storage accounts

To maintain high availability and avoid dependence on a single storage account, create two storage
accounts. Divide the machines in each availability set into two groups, and then assign each group a
separate storage account.
To create your two storage accounts, search for and select Storage accounts in the Azure portal and choose
+ Create
1. In Create a storage account, enter or select this information in the Basics tab:
Setting Value
Project details
Instance details
Storage account name Enter a name for your storage account. For this example, enter contososac1.
Region Select your region.
Performance Select Premium for the performance level.
Premium account type Select the type of storage account you need: block blobs, file shares, or page blobs.
Redundancy Select Locally-redundant storage (LRS).
2. Continue through the remaining tabs. When ready, select Create on the Review tab.
3. Repeat the previous steps to create a second storage account with the name contososac2.
Create availability sets

For each role (DC/AD FS and WAP), create availability sets that contain at least two machines each. This
configuration helps achieve higher availability for each role. While creating the availability sets, you must
decide on the following domains:
Fault Domains: VMs in the same fault domain share the same power source and physical network
switch. We recommend a minimum of two fault domains. The default value is 2 and you can leave it
as-is for this deployment.
Update domains: Machines belonging to the same update domain are restarted together during an
update. We recommend a minimum of two update domains. The default value is 5, and you can leave
it as is for this deployment.
To create availability sets, search for and select Availability sets in the Azure portal and choose + Create
1. In Create availability set, enter or select this information in the Basics tab:
Setting Value
Project details
Instance details
Name Enter a name for your availability set. For this example, enter contosodcset.
Fault domains 2
Update domains 5
Use managed disks For this example, select No (Classic).
2. After you've made all your choices, select Review + Create and if everything looks good, select Create.
3. Repeat the previous steps to create a second availability set with the name contososac2.
Deploy virtual machines

The next step is to deploy VMs that host the different roles in your infrastructure. We recommend a
minimum of two machines in each availability set. So for this example, we create four VMs for the basic
deployment.
To create VMs, search for and select Virtual machines in the Azure portal.
1. On the Virtual machines page, select + Create, then choose Azure virtual machine.
2. In Create a virtual machine, enter or select this information in the Basics tab:
Setting Value
Project details
Instance details
Virtual machine Enter a name for your VM. For the first machine, enter contosodc1.
name
Availability options Select Availability set.
Availability set Select contosodcset.
Security type Select Standard.
Image Select your image. Then select Configure VM generation and select Gen 1. For this
example, you need to use a Gen 1 image.
Administrator
account
Authentication type Select SSH public key.
Username Enter a user name.
Key pair name Enter a key pair name.

For anything not specified, you can leave the defaults, and when ready, select Next : Disks.
3. On the Disks tab under Advanced, deselect Use managed disks and then select the contososac1
storage account that you created previously. When ready, select Next : Networking.
4. In the Networking tab, enter or select this information:
Setting Value
Virtual network Select your virtual network that contains the subnets you created previously.
Subnet For this first VM, select your INT subnet.
NIC network security group Select None.

For anything not specified, you can leave the defaults.
After you've made all your choices, select Review + Create and if everything looks good, select Create.
Repeat these steps using the information in this table to create the three remaining VMs:
Virtual machine name Subnet Availability options Availability set Storage account
contosodc2 INT Availability set contosodcset contososac2
contosowap1 DMZ Availability set contosowapset contososac1
contosowap2 DMZ Availability set contosowapset contososac2
As you might have noticed, no NSG is specified since 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 the
NIC object. For more information, see What is a network security group (NSG).
If you're managing the DNS, we recommend you use a static IP address. You can use Azure DNS and refer
to the new machines by their Azure FQDNs in the DNS records for your domain. For more information, see
Change a private IP address to static.
Your Virtual machines page should show all four VMs after the deployment completes.
Configure the DC / AD FS servers
To authenticate any incoming request, AD FS needs to contact the DC. To save the costly trip from Azure to
on-premises DC for authentication, we recommend you deploy a replica of the DC in Azure. In order to
attain high availability, it's better to create an availability set of at least two DCs.
Domain controller Role Storage account
contosodc1 Replica contososac1
contosodc2 Replica contososac2
Promote the two servers as replica DCs with DNS

Configure the AD FS servers by installing the AD FS role using the server manager.
Create and deploy the internal load balancer (ILB)

To create and deploy an ILB, search for and select Load Balancers in the Azure portal and choose + Create.
1. In Create load balancer, enter or select this information in the Basics tab:
Setting Value
Project details
Resource Select your resource group. Or select Create new to create one.
group
Instance
details
Name Enter a name for your load balancer.
Type Since this load balancer is placed in front of the AD FS servers and is meant for internal network
connections only, select Internal.
Leave SKU and Tier as their defaults and then select Next : Frontend IP Configuration
2. Select + Add a frontend IP configuration, then enter or select this information in the Add frontend IP
configuration page.
Setting Value
Name Enter a frontend IP configuration name.
Virtual network Select the virtual network where you're deploying your AD FS.
Subnet Choose the internal subnet INT.
Assignment Choose Static.
IP address Enter your IP address.

Leave Availability zone as the default and then select Add.
3. Select Next : Backend Pools, then select + Add a backend pool.
4. On the Add backend pool page, enter a Name and then in the IP configurations area, select + Add.
5. On the Add backend pool page, select a VM to align with the backend pool, select Add, then select
Save.
6. Select Next : Inbound Rules.
7. On the Inbound Rules tab, select Add a load balancing rule, then enter or select this information in
the Add load balancing rule page.
Setting Value
Name Enter a name for the rule.
Frontend IP Select the frontend IP address you created in an earlier step.

address
Backend pool Select the backend pool you created in an earlier step.
Protocol Select TCP.
Port Enter 443.
Backend port Enter 443.
Health probe Select Create new and then enter these values to create a health probe:
Name: Name of the health probe
Protocol: HTTP
Port: 80 (HTTP)
Path: /adfs/probe
Interval: 5 (default value) – The interval at which ILB probes the machines in the backend
pool
Select Save.
8. Select Save to save the inbound rule.
9. Select Review + Create and if everything looks good, select Create.
After you select Create and the ILB deploys, you can see it in the list of load balancers.
Update the DNS server 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, create an A record for fs.contoso.com pointing to
10.3.0.8.
This setting ensures that all data transmitted to fs.contoso.com ends up at the ILB and is appropriately
routed.
２ Warning
If you're using the Windows Internal Database (WID) for your AD FS database, set this value instead to
temporarily point to your primary AD FS server or else the web application proxy fails enrollment. After
you have successfully enrolled all web application proxy servers, change this DNS entry to point to the
load balancer.
７ Note
If your deployment is also using IPv6, create a corresponding AAAA record.
Configure the web application proxy servers to reach AD FS servers
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 file for the ILB. The distinguished name (DN)
should be the federation service name, such as fs.contoso.com. And the IP entry should be the ILB's IP
address (10.3.0.8, as shown in the example).
２ Warning
If you're using the Windows Internal Database (WID) for your AD FS database, set this value instead to
temporarily point to your primary AD FS server or else the web application proxy fails enrollment. After
you've successfully enrolled all web application proxy servers, change this DNS entry to point to the
load balancer.
Install 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 don't need to 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 guides you to complete the WAP installation.
For more information on how to deploy WAP, see Install and Configure the web application proxy Server.
Create and deploy the internet-facing (public) load balancer

1. In the Azure portal, select Load balancers and then choose Create.
2. In Create load balancer,enter or select this information in the Basics tab:
Setting Value
Project details

Setting Value
Instance details
Name Enter a name for your load balancer.
Type Since this load balancer requires a public IP address, select Public.
Leave SKU and Tier as their defaults and then select Next : Frontend IP Configuration
3. Select + Add a frontend IP configuration, then enter or select this information in the Add frontend IP
configuration page.
Setting Value
Name Enter a frontend IP configuration name.
IP type Select IP address.
Public IP Select a Public IP address from the drop-down list, or create a new one as needed, then select
address Add.
4. Select Next : Backend Pools, then select + Add a backend pool.
5. On the Add backend pool page, enter a Name and then in the IP configurations area, select + Add.
6. On the Add backend pool page, select a VM to align with the backend pool, select Add, then select
Save.
7. Select Next : Inbound Rules, select Add a load balancing rule, then enter or select this information in
the Add load balancing rule page.
Setting Value
Name Enter a name for the rule.

Setting
Frontend IP Value
Select the frontend IP address you created in an earlier step.
address
Backend pool Select the backend pool you created in an earlier step.
Protocol Select TCP.
Port Enter 443.
Backend port Enter 443.
Health probe Select Create new and then enter these values to create a health probe:
Name: Name of the health probe
Protocol: HTTP
Port: 80 (HTTP)
Path: /adfs/probe
Interval: 5 (default value) – The interval at which ILB probes the machines in the backend
pool
Select Save.
8. Select Save to save the inbound rule.
9. Select Review + Create and if everything looks good, select Create.
After you select Create and the public ILB deploys, you can see it in the list of load balancers.
Assign a DNS label to the public IP
Use the Search resources feature and search for Public IP addresses. Use the following steps to configure
the DNS label for the public IP.
1. Select your resource, under Settings, select Configuration.

2. Under Provide a DNS label (optional), add an entry in the text field (like fs.contoso.com) that resolves
to the DNS label of the external load balancer (like contosofs.westus.cloudapp.azure.com).
3. Select Save to complete assigning a DNS label.
Test the AD FS sign-in

The easiest way to test AD FS is by using the IdpInitiatedSignon.aspx page. To do that, you must enable the
IdpInitiatedSignOn on the AD FS properties. Use the following steps to verify your AD FS setup.
1. In PowerShell, run the following cmdlet on the AD FS server 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 following AD FS page:

On successful sign-in, it provides you with a success message as shown here:
Template for deploying AD FS in Azure

The template deploys a six-machine setup, two 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 virtual network while deploying this template. This
table lists the various parameters available for customizing the deployment including a description of how
to use the parameters in the deployment process.
Parameter Description
Location The region to deploy the resources into, for example, East US
StorageAccountType The type of the Storage Account that's created
VirtualNetworkUsage Indicates if a new virtual network gets created or to 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 you use an existing virtual network, this option is a mandatory
parameter so the deployment can find the ID of the existing virtual network.
VirtualNetworkAddressRange The address range of the new virtual network, 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 AD FS 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 is 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 is
statically assigned to the DC and must be a valid IP address within the Internal
subnet
ADFS01NICIPAddress The internal IP address of the first AD FS server, this IP address is statically
assigned to the AD FS server and must be a valid IP address within the Internal
subnet
ADFS02NICIPAddress The internal IP address of the second AD FS server, this IP address is statically
assigned to the AD FS server and must be a valid IP address within the Internal
subnet
WAP01NICIPAddress The internal IP address of the first WAP server, this IP address is 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 is statically
assigned to the WAP server and must be a valid IP address within the DMZ subnet
ADFSLoadBalancerPrivateIPAddress The internal IP address of the AD FS load balancer, this IP address is statically
assigned to the load balancer and must be a valid IP address within the Internal
subnet
ADDCVMNamePrefix VM name prefix for Domain Controllers

ADFSVMNamePrefix VM name prefix for AD FS servers
WAPVMNamePrefix VM name prefix for WAP servers
ADDCVMSize The VM size of the Domain Controllers
ADFSVMSize The VM size of the AD FS servers
WAPVMSize The VM size of the WAP servers
AdminUserName The name of the local Administrator of the VMs
AdminPassword The password for the local Administrator account of the VMs
Related links
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
Integrate your on-premises identities with Azure Active Directory
Configure 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
Article • 08/15/2023
AD FS deployment in Azure provides step-by-step guideline as to how you can deploy a

simple AD FS infrastructure for your organization in Azure. This article provides the next
steps to create a cross-geographic deployment of AD FS in Azure using Azure Traffic
Manager. Azure Traffic Manager helps create a geographically spread high availability
and high-performance AD FS infrastructure for your organization by making use of
range of routing methods available to suit different needs from the infrastructure.
A highly available cross-geographic AD FS infrastructure enables:
Elimination of single point of failure: With failover capabilities of Azure Traffic

Manager, you can achieve a highly available AD FS infrastructure even when one of
the data centers in a part of the globe goes down
Improved performance: You can use the suggested deployment in this article to
provide a high-performance AD FS infrastructure that can help users authenticate
faster.
Design principles
The basic design principles will be same as listed in Design principles in the article AD FS
deployment in Azure. The diagram above shows a simple extension of the basic
deployment to another geographical region. Below are some points to consider when
extending your deployment to new geographical region
Virtual network: You should create a new virtual network in the geographical
region you want to deploy additional AD FS infrastructure. In the diagram above
you see Geo1 VNET and Geo2 VNET as the two virtual networks in each
geographical region.
Domain controllers and AD FS servers in new geographical VNET: It is
recommended to deploy domain controllers in the new geographical region so
that the AD FS servers in the new region do not have to contact a domain
controller in another far away network to complete an authentication and thereby
improving the performance.
Storage accounts: Storage accounts are associated with a region. Since you will be
deploying machines in a new geographic region, you will have to create new
storage accounts to be used in the region.
Network Security Groups: As storage accounts, Network Security Groups created
in a region cannot be used in another geographical region. Therefore, you will
need to create new network security groups similar to those in the first
geographical region for INT and DMZ subnet in the new geographical region.
DNS Labels for public IP addresses: Azure Traffic Manager can refer to endpoints
ONLY via DNS labels. Therefore, you are required to create DNS labels for the
External Load Balancers' public IP addresses.
Azure Traffic Manager: Microsoft Azure Traffic Manager allows you to control the
distribution of user traffic to your service endpoints running in different
datacenters around the world. Azure Traffic Manager works at the DNS level. It
uses DNS responses to direct end-user traffic to globally-distributed endpoints.
Clients then connect to those endpoints directly. With different routing options of
Performance, Weighted and Priority, you can easily choose the routing option best
suited for your organization's needs.
V-net to V-net connectivity between two regions: You do not need to have
connectivity between the virtual networks itself. Since each virtual network has
access to domain controllers and has AD FS and WAP server in itself, they can work
without any connectivity between the virtual networks in different regions.
Steps to integrate Azure Traffic Manager
Deploy AD FS in the new geographical region

Follow the steps and guidelines in AD FS deployment in Azure to deploy the same
topology in the new geographical region.
DNS labels for public IP addresses of the Internet Facing

(public) Load Balancers
As mentioned above, the Azure Traffic Manager can only refer to DNS labels as
endpoints and therefore it is important to create DNS labels for the External Load
Balancers' public IP addresses. Below screenshot shows how you can configure your
DNS label for the public IP address.
Deploying Azure Traffic Manager
Follow the steps below to create a traffic manager profile. For more information, you
can also refer to Manage an Azure Traffic Manager profile.
1. Create a Traffic Manager profile: Give your traffic manager profile a unique name.
This name of the profile is part of the DNS name and acts as a prefix for the Traffic
Manager domain name label. The name / prefix is added to .trafficmanager.net to
create a DNS label for your traffic manager. The screenshot below shows the traffic
manager DNS prefix being set as mysts and resulting DNS label will be
mysts.trafficmanager.net.
2. Traffic routing method: There are three routing options available in traffic
manager:
Priority
Performance
Weighted
Performance is the recommended option to achieve highly responsive AD FS

infrastructure. However, you can choose any routing method best suited for
your deployment needs. The AD FS functionality is not impacted by the
routing option selected. See Traffic Manager traffic routing methods for more
information. In the sample screenshot above you can see the Performance
method selected.
3. Configure endpoints: In the traffic manager page, click on endpoints and select
Add. This will open an Add endpoint page similar to the screenshot below
For the different inputs, follow the guideline below:
Type: Select Azure endpoint as we will be pointing to an Azure public IP address.
Name: Create a name that you want to associate with the endpoint. This is not the
DNS name and has no bearing on DNS records.
Target resource type: Select Public IP address as the value to this property.
Target resource: This will give you an option to choose from the different DNS
labels you have available under your subscription. Choose the DNS label
corresponding to the endpoint you are configuring.
Add endpoint for each geographical region you want the Azure Traffic Manager to
route traffic to. For more information and detailed steps on how to add / configure
endpoints in traffic manager, refer to Add, disable, enable or delete endpoints
4. Configure probe: In the traffic manager page, click on Configuration. In the

configuration page, you need to change the monitor settings to probe at HTTP
port 80 and relative path /adfs/probe
７ Note
Ensure that the status of the endpoints is ONLINE once the configuration is
complete. If all endpoints are in 'degraded' state, Azure Traffic Manager will
do a best attempt to route the traffic assuming that the diagnostics is
incorrect and all endpoints are reachable.
5. Modifying DNS records for Azure Traffic Manager: Your federation service should
be a CNAME to the Azure Traffic Manager DNS name. Create a CNAME in the
public DNS records so that whoever is trying to reach the federation service
actually reaches the Azure Traffic Manager.
For example, to point the federation service fs.fabidentity.com to the Traffic

Manager, you would need to update your DNS resource record to be the
following:
fs.fabidentity.com IN CNAME mysts.trafficmanager.net
Test the routing and AD FS sign-in

Routing test
A very basic test for the routing would be to try ping the federation service DNS name
from a machine in each geographic region. Depending on the routing method chosen,
the endpoint it actually pings will be reflected in the ping display. For example, if you
selected the performance routing, then the endpoint nearest to the region of the client
will be reached. Below is the snapshot of two pings from two different region client
machines, one in EastAsia region and one in West US.
AD FS sign-in test
The easiest way to test AD FS is by using the IdpInitiatedSignon.aspx page. In order to
be able to do that, it is required to enable the IdpInitiatedSignOn on the AD FS
properties. Follow the steps below to verify your AD FS setup
1. Run the below cmdlet on the AD FS server, using PowerShell, to set it to enabled.
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
2. From any external machine access

https://<yourfederationservicedns>/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
Article • 08/15/2023
） Important

AD FS
７ Note
Only begin an upgrade with a definitive time frame planned for completion. It isn't
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're 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
feature 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've a
Windows Server 2016 AD FS server operating in this fashion, your farm is said to be
"mixed". However, you won't 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 can't be
configured or used in this mode.
Once all Windows Server 2012 R2 federation servers have been removed from the
mixed mode 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 won't 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's online and only incur the
relatively brief downtime involved in the FBL raise.
In mixed farm mode, the AD FS farm isn't capable of any new features or functionality
introduced in AD FS in Windows Server 2016. Organizations that want to try out new
features can't 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.
The remainder of the is document provides the steps for adding a Windows Server 2016
federation server to a Windows Server 2012 R2 environment. 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 can't 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.
７ Note
If AlwaysOnAvailability groups or merge replication are configured in AD FS,

remove all replication of any AD FS 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.
The following architectural diagram shows the setup that was used to validate and
record the steps below.
Join the Windows 2016 AD FS Server to the AD FS farm

1. Using Server Manager install the Active Directory Federation Services Role on the
Windows Server 2016
2. Using the AD FS Configuration wizard, join the new Windows Server 2016 server to
the existing AD FS farm. On the Welcome screen, click Next.
3. On the Connect to Active Directory Domain Services screen, specify an
administrator account with permissions to perform the federation services
configuration and click Next.
4. On the Specify Farm screen, enter the name of the SQL server and instance and
then click Next.
5. On the Specify SSL Certificate screen, specify the certificate and click Next.
6. On the Specify Service Account screen, specify the service account and click Next.
7. On the Review Options screen, review the options and click Next.
8. On the Pre-requisites Checks screen, ensure that all of the pre-requisite checks
have passed and click Configure.
9. On the Results screen, ensure that server was successfully configured and click
Close.
Remove the Windows Server 2012 R2 AD FS server
７ Note
You do not need to set the primary AD FS server using Set-AdfsSyncProperties -

Role when using SQL as the database. This is because all of the nodes are
considered primary in this configuration.
1. On the Windows Server 2012 R2 AD FS server in Server Manager use Remove

Roles and Features under Manage.
2. On the Before you Begin screen, click Next.
3. On the Server Selection Screen, click Next.
4. On the Server Roles screen, remove the check next to Active Directory Federation
Services and click Next.
5. On the Features Screen, click Next.

6. On the Confirmation Screen, click Remove.
7. Once feature removal completes, restart the server.
Raise the Farm Behavior Level (FBL)

Prior to this step you need to ensure that forest prep and domain prep 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 didn't
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 AD FS 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 with 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've successfully raised the FBL.
5. Now, if you go to AD FS Management, you will see the new nodes.

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:
PowerShell
$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.
PowerShell
Set-WebApplicationProxyConfiguration -ConnectedServersName
WAPServerName1, WAPServerName2
3. Check the WAP configuration by running the Get-

WebApplicationProxyConfiguration command. The ConnectedServersName will
reflect the server run from the prior command.
PowerShell
Get-WebApplicationProxyConfiguration
4. To upgrade the ConfigurationVersion of the WAP servers, run the following

PowerShell command.
PowerShell
Set-WebApplicationProxyConfiguration -UpgradeConfigurationVersion
5. Verify the ConfigurationVersion has been upgraded with the Get-

WebApplicationProxyConfiguration PowerShell command.
What is hybrid identity with Azure
Active Directory?
Article • 05/04/2023
Today, businesses, and corporations are becoming more and more a mixture of on-
premises and cloud applications. Users require access to those applications both on-
premises and in the cloud. Managing users both on-premises and in the cloud poses
challenging scenarios.
Microsoft’s identity solutions span on-premises and cloud-based capabilities. These

solutions create a common user identity for authentication and authorization to all
resources, regardless of location. We call this hybrid identity.

Hybrid identity is accomplished through provisioning and synchronization. Provisioning

is the process of creating an object based on certain conditions, keeping the object up
to date and deleting the object when conditions are no longer met. Synchronization is
responsible for making sure identity information for your on-premises users and groups
is matching the cloud.
For more information see What is provisioning? and What is inter-directory

provisioning?.
License requirements for using Azure AD

Connect
Using this feature is free and included in your Azure subscription.
Next Steps
What is Azure AD Connect and Connect Health?
What is password hash synchronization (PHS)?
What is pass-through authentication (PTA)?
What is federation?
What is single-sign on?
Windows Server AD FS deployment
guide
Article • 02/08/2023
Use Active Directory Federation Services (AD FS) with Windows Server to build a

federated identity management solution. With AD FS you can 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 beyond your network.
Deploying a Federation Server Farm

Deploying Federation Server Proxies
See also
AD FS Deployment
Integrating your on-premises identities with Azure Active Directory
Article • 08/15/2023
In order to deploy a federation server farm, complete the tasks in this checklist in order.
When a reference link takes you to a conceptual topic, return to this checklist after you
review the conceptual topic so that you can proceed with the remaining tasks in this
checklist.
Checklist: Deploying a Federation Server Farm
Task Reference
Review important concepts and AD FS Design Guide in Windows Server 2012 R2

considerations as you prepare to
deploy Active Directory Federation Understanding Key AD FS Concepts
Services (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 Join a Computer to a Domain

Directory domain.
Enroll a Secure Socket Layer (SSL) Enroll an SSL Certificate for AD FS

certificate for AD FS.
Install the AD FS role service. Install the AD FS Role Service
Configure a federation server. Configure a Federation Server
Optional step: Configure a federation Configure a federation server with Device

server with Device Registration Service Registration Service
(DRS).
Add a host (A) and alias (CNAME) Configure Corporate DNS for the Federation Service
resource record to corporate Domain and DRS
Name System (DNS) for the federation
service and DRS.
Verify that a federation server is Verify That a Federation Server Is Operational

operational.
See Also
AD FS Deployment
Windows Server 2012 R2 AD FS Deployment Guide

Join a Computer to a Domain
Article • 02/08/2023
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 Desktop, click the Start button, 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. Under 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 in the Computer Name/Domain Changes dialog box, and then restart the
computer.
To join a server to a domain

3. Under Related settings, click Rename this PC (advanced).
server to join, and then click OK.
server.
Additional references
Checklist: Setting Up a Federation Server
Checklist: Setting Up a Federation Server Proxy

Enroll an SSL Certificate for AD FS
Article • 08/15/2023
Active Directory Federation Services (AD FS) requires a certificate for Secure Socket

Layer (SSL) server authentication on each federation server in your federation server
farm. The same certificate can be used on each federation server in a farm. You must
have both the certificate and its private key available. For example, if you have the
certificate and its private key in a .pfx file, you can import the file directly into the Active
Directory Federation Services Configuration Wizard. This SSL certificate must contain the
following:
1. The subject name and subject alternative name must contain your federation
service name, such as fs.contoso.com.
2. The subject alternative name must contain the value enterpriseregistration that is
followed by the User Principal Name (UPN) suffix of your organization, for
example, enterpriseregistration.corp.contoso.com.
２ Warning
Specify the subject alternative name if you plan to enable the Device
Registration Service (DRS) for Workplace Join.
） Important
If your organization uses multiple UPN suffixes, and you plan to enable the DRS,
the SSL certificate must contain a subject alternative name entry for each suffix.
See Also
AD FS Deployment

Install the AD FS Role Service
Article • 08/15/2023
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.

requirement to complete this procedure. Review details about using the appropriate
To install the AD FS server role via the Add roles and

features wizard
1. Open Server Manager. To open Server Manager, click Server Manager on the Start
screen, or Server Manager in the taskbar on the desktop. In the Quick Start tab of
the Welcome tile on the Dashboard page, click Add roles and features.
Alternatively, you can click Add Roles and Features on the Manage menu.
3. On the Select installation type page, click Role-based or Feature-based

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.
then click Close.
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
Article • 08/15/2023
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
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 server in a federation
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,
4. On the Specify Service Properties 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 Import, and then browse to the file's location. Enter the
password for the .pfx file when you are prompted.
Provide a name for your federation service. For example, fs.contoso.com. This
name must match one of the subject or subject alternative names in the
certificate.
Provide a display name for your federation service. For example, Contoso
Corporation. Users see this name on the Active Directory Federation Services
(AD FS) sign-in page.
5. On the Specify Service Account page, specify a service account. You can either
create or use an existing group Managed Service Account (gMSA) or use an
existing domain user account. If you select the option to create a new gMSA
account, specify a name for the new account. If you select the option to use an
existing gMSA or domain account, click Select to select an account.
７ Note
The benefit of using a gMSA account is its auto-negotiated password update

feature.
２ Warning
If you want to use a gMSA account, you must have at least one domain
controller in your environment that is running the Windows Server 2012
operating system.
If the gMSA option is disabled, and you see an error message, such as Group
Managed Service Accounts are not available because the KDS Root Key has
not been set, you can enable gMSA in your domain by running the following
Windows PowerShell command on a domain controller, which runs Windows
Server 2012 or later, in your Active Directory domain: Add-KdsRootKey –
EffectiveTime (Get-Date).AddHours(-10) . Then return to the wizard, click
Previous, and then click Next to re-enter the Specify Service Account page.
The gMSA option should now be enabled. You can select it and enter a gMSA
account name that you want to use.
6. On the Specify Configuration Database page, specify an AD FS configuration

database, and then click Next. You can either create a database on this computer
by using Windows Internal Database (WID), or you can specify the location and the
instance name of Microsoft SQL Server.
For more information, see The Role of the AD FS Configuration Database.
） Important
If you want to create an AD FS farm and use SQL Server to store your
configuration data, you can use SQL Server 2008 and newer versions,
including SQL Server 2012 and SQL Server 2014.
Next.
8. On the Pre-requisite Checks page, verify that all prerequisite checks are
9. On the Results page, review the results and check whether the configuration is
federation service deployment. For more information, see Next steps for
completing your AD FS installation. Click Close to exit the wizard.
To configure the first federation server in a new

federation server farm via Windows PowerShell
You can create a new federation server farm by using either a new or existing gMSA
account or an existing domain user account.
If you want to create a new federation server by using a new gMSA account, do
the following:
） Important
You must have domain administrator permissions to create the first federation
server in a new federation server farm.
1. On the computer that you want to configure as a federation server, ensure

that the required SSL certificate has been imported into the Local
Computer\My Store directory. You can verify whether the SSL certificate has
been imported by running the following command in the Windows
PowerShell command window: dir Cert:\LocalMachine\My . The certificate is
listed by its thumbprint in the Local Computer\My Store directory.
2. On your domain controller, open the Windows PowerShell command window

and run the following command to verify whether the KDS Root Key has been
created in your domain: Get-KdsRootKey –EffectiveTime (Get-
Date).AddHours(-10) . If it has not been created so that the output displays no
information, run the following command to create the key: Add-KdsRootKey –

EffectiveTime (Get-Date).AddHours(-10) .
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: Install-AdfsFarm -
CertificateThumbprint <certificate_thumbprint> -
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
including SQL Server 2012.
If you want to create a new federation server by using an existing domain user
account, do the following:

Windows PowerShell 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:
Install-AdfsFarm -CertificateThumbprint <certificate_thumbprint> -

ServiceAccountCredential $fscred
To obtain the value for <certificate_thumbprint>, run dir
Cert:\LocalMachine\My , and then select the thumbprint of your SSL certificate.
The value of <federation_service_name> is the name of your federation

service, for example, fs.contoso.com.
７ Note
７ Note
The previous command creates a WID farm. If you want to create a SQL
Server farm, you must have the instance of SQL Server already installed
and operational.
You can use the following command to create the first federation server
in a new farm that uses an instance of SQL Server: Install-AdfsFarm -
CertificateThumbprint <certificate_thumbprint> -
ServiceAccountCredential $fscredential -SQLConnectionString "Data

Source=<SQL_Host_Name>\<SQL_instance_ name>;Integrated
Security=True" where SQL_Host_Name is the name of the server on
which SQL Server is running, and SQL_instance_name is the name of the

instance of SQL Server. If you use the default instance of SQL Server, use
a SQLConnectionString value of "Data Source=
<SQL_Host_Name>;Integrated Security=True".
） Important
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
2. On the Welcome page, select Add a federation server to a federation server

farm, and then click Next.
3. On the Connect to AD DS page, specify an account by using domain administrator

permissions for the AD domain to which this computer is joined, and then click
Next.
4. On the Specify Farm page, provide the name of the primary federation server in a
farm that uses WID or specify the database host name and the database instance
name of an existing federation server farm that uses SQL Server.
２ Warning
In Windows Server® 2012 R2, there is a workaround to specify the default

instance of SQL Server. The workaround is to not use the user interface.
Instead, use the steps in To configure the first federation server in a new
federation server farm via Windows PowerShell.
） Important
including SQL Server 2012.
5. On the Specify SSL Certificate page, import the .pfx file that contains the SSL
certificate and key that you have obtained previously. This certificate is the
required service authentication certificate. In Step 2: Enroll an SSL Certificate for AD
FS, you have obtained this certificate and copied it to the computer that you want
to configure as a federation server. To import the .pfx file via the wizard, click
Import and browse to the file's location. Enter the password for the .pfx file when
you are prompted.
6. On the Specify Service Account page, specify the same service account that you
configured when you created the first federation server in the farm. You can use an
existing group Managed Service Account or an existing domain user account.
） Important
The account that you specify must be the same account as the account that
was used on the primary federation server in this farm.
Next.
8. On the Pre-requisite Checks page, verify that all prerequisite checks are
9. On the Results page, review the results and check whether the configuration is
federation service deployment. For more information, see Next steps for
completing your AD FS installation. Click Close to exit the wizard.
To add a federation server to an existing federation

server farm via Windows PowerShell
You can add a federation server to an existing farm by using either an existing gMSA
account or an existing domain user account.
If you want to join a federation server to a farm by using an existing gMSA

Windows PowerShell command window, and run the following command.
Add-AdfsFarmNode -GroupServiceAccountIdentifier <domain>\

<GMSA_name>$ -PrimaryComputerName
<first_federation_server_hostname> -CertificateThumbprint
<certificate_thumbprint>
<domain>\<GMSA_name> is your AD domain and the name of your gMSA
account in that domain. <first_federation_server_hostname> is the host

name of the primary federation server in this existing farm.
You can obtain the value for <certificate_thumbprint> by running dir

Cert:\LocalMachine\My in the previous step.
７ Note
７ Note
The previous command creates a WID farm node. If you want to create a
server farm node of computers running SQL Server, you must have the
instance of SQL Server already installed and operational.
You can use the following command to add a federation server to an

existing farm that is using an instance of SQL Server: Add-AdfsFarmNode -
GroupServiceAccountIdentifier <domain>\<GMSA_name>$ -
SQLConnectionString "Data Source=<SQL_Host_Name>\<SQL_instance_
name>;Integrated Security=True" where SQL_Host_Name is the name of
the server on which SQL Server is running, and SQL_instance_name is

the name of the instance of SQL Server. If you use the default instance of
SQL Server, use a SQLConnectionString value of "Data Source=
） Important
If you want to join a federation server to a farm by using an existing domain user
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
3. In the same Windows PowerShell command window, run the following

command.
Add-AdfsFarmNode -ServiceAccountCredential $fscred -

PrimaryComputerName <first_federation_server_hostname> -
CertificateThumbprint <certificate_thumbprint>
７ Note
７ Note
The previous command creates a WID farm node. If you want to create a
server farm node of computers running SQL Server, you must have the
instance of SQL Server already installed and operational. You can use the
following command to add a federation server to an existing farm by
using an instance of SQL Server: Add-AdfsFarmNode -
ServiceAccountCredential $fscred -SQLConnectionString "Data Source=
<SQL_Host_Name>\<SQL_instance_ name>;Integrated Security=True" where
SQL_Host_Name is the name of the server on which the instance of SQL

Server is running, and SQL_instance_name is the name of the instance of
SQL Server. If you use the default instance of SQL Server, use a
SQLConnectionString value of "Data Source=
） Important
See Also
AD FS Deployment

Configure a federation server with
Device Registration Service
Article • 08/15/2023
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
Article • 08/15/2023
Step 6: Add a Host (A) and Alias (CNAME)

Resource Record to Corporate DNS for the
Federation Service and DRS
You must add the following resource records to corporate Domain Name System (DNS)
for your federation service and Device Registration Service that you configured in
previous steps.
Entry Type Address
federation_service_name Host (A) IP address of the AD FS server or the IP address of the

load balancer that is configured in front of your AD FS
server farm
enterpriseregistration Alias federation_server_name.contoso.com

(CNAME)
You can use the following procedure to add a host (A) and alias (CNAME) resource
records to corporate DNS for the federation server and the Device Registration Service.
Membership in Administrators, or equivalent, is the minimum requirement to complete

this procedure. Review details about using the appropriate accounts and group
memberships at Local and Domain Default Groups.
To add a host (A) and alias (CNAME) resource records to DNS for
your federation server
1. On you domain controller, in Server Manager, on the Tools menu, click DNS to
open the DNS snap-in.
2. In the console tree, expand the domain_controller_name node, expand Forward

Lookup Zones, right-click domain_name, and then click New Host (A or AAAA).
3. In the Name box, type the name to use for your AD FS farm.
4. In the IP address box, type the IP address of your federation server. Click Add
Host.
5. Right-click the domain_name node, and then click New Alias (CNAME).
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_service_farm_name.domain_name.com, and then click OK.
） Important
In a real world deployment, if your company has multiple User Principal Name
(UPN) suffixes, you must create multiple CNAME records for each of those
UPN suffixes in DNS.
See Also
AD FS Deployment

Verify your Windows Server 2012 R2
Federation Server is Operational
Article • 08/15/2023
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
2. Open a browser window, in the address bar type the federation server's DNS host
name, and then append /adfs/fs/federationserverservice.asmx to it for the new
federation server, for example:
https://fs1.fabrikam.com/adfs/fs/federationserverservice.asmx
3. Press ENTER, and then complete the next procedure on the federation server
computer. If you see the message There is a problem with this website's security
certificate, click Continue to this website.
The expected output is a display of XML with the service description document. If
this page appears, IIS on the federation server is operational and serving pages
successfully.


operational
1. Log on to the new federation server as an administrator.
2. On the Start screen, typeEvent Viewer, and then press ENTER.
3. In the details pane, double-click Applications and Services Logs, double-click AD

FS Eventing, and then click Admin.
4. In the Event ID column, look for event ID 100. If the federation server is configured
properly, you see a new event—in the Application log of Event Viewer—with the
event ID 100. This event verifies that the federation server was able to successfully
communicate with the Federation Service.
See Also
AD FS Deployment

Article • 08/15/2023
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

Windows Server 2012 AD FS
Deployment Guide
Article • 08/15/2023
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
Planning to Deploy AD FS
Implementing Your AD FS Design Plan
Checklist: Implementing a Web SSO Design
Checklist: Implementing a Federated Web SSO Design
Configuring Partner Organizations
Configuring Claim Rules
Deploying Federation Servers

Interoperating with AD FS 1.x

Planning to Deploy AD FS
Article • 08/15/2023
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
Planning Federation Server Proxy Placement
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.
Implementing Your AD FS Design Plan
Article • 08/15/2023
The following environmental conditions and requirements are important factors in the
implementation of your Active Directory Federation Services (AD FS) design plan:
Supported partners: You usually use AD FS to work with partner organizations. To
establish identity federation, determine the organizations with which you want to
form a partnership. After a baseline AD FS deployment is in place, operating with
partners involves adding partners, deleting partners, and updating partner
information. Changes to partnerships may occur for a variety of reasons. For
example, your AD FS deployment might require partnership updates if your
partner changes its business significantly, your organization becomes part of a
larger organization or a federation of organizations, or your organization is
acquired by a different company. In any scenario in which you federate identities
from multiple domains, you will need to know the domains (partners) that you are
currently supporting and all the additional domains that represent potential
partners.
Supported application and service types: Some applications and services require
access to operating system resources, while others are "claims aware." It is
important to understand the types of applications and services that AD FS
supports so that you can formulate administration requirements.
Logical and physical architectural diagrams or deployment topology: You will

need to know:
Whether federation servers will function in a set of farmed servers or on a single

server.
Where your network deploys firewalls and proxies.
The location of resources and whether users are accessing resources from within
your organization, outside the organization, or both.
How to implement your AD FS design using

this guide
The next step in implementing your design is to determine in what order each
deployment task must be performed. This guide uses checklists to help you walk
through the various server and application deployment tasks that are required to
implement your design plan. Parent and child checklists are used as necessary to
represent the order in which tasks for a specific AD FS design must be processed.
Use the following parent checklists in this section of the guide to become familiar with
the deployment tasks for implementing your organization's preferred AD FS design:

Checklist: Implementing a Web SSO
Design
Article • 08/15/2023
This parent checklist includes cross-reference links to important concepts about the
Web Single-Sign-On (SSO) design for Active Directory Federation Services (AD FS). It
also contains links to subordinate checklists that will help you complete the tasks that
are required to implement this design.
７ Note
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic or to a subordinate checklist, return to this topic after you review
the conceptual topic or complete the tasks in the subordinate checklist so that you
can proceed with the remaining tasks in this checklist.
Task Reference
Review important concepts about the Web SSO design and determine Web SSO Design
which AD FS deployment goals you can use to customize this design to
meet the needs of your organization. Note: Identifying Your AD
FS Deployment Goals
Review the hardware, software, certificate, Domain Name System (DNS), Appendix A:
attribute store, and client requirements for deploying AD FS in your Reviewing AD FS
organization. Requirements
According to your design plan, install one or more federation servers in Checklist: Setting
the corporate network or in the perimeter network. Note: The Web SSO Up a Federation
design requires only one federation server to function successfully. A Server
single federation server acts in both the claims provider role and the
relying party role.
(Optional) Determine whether or not your organization needs a Checklist: Setting

federation server proxy in the perimeter network. Up a Federation
Server Proxy
Depending on your Web SSO design plan and how you intend to use it, Checklist:
add the appropriate attribute store, relying party trusts, claims, and claim Configuring the
rules to the Federation Service. Account Partner
Organization
Task Reference
If you are an administrator in the resource partner organization, claims- Windows Identity
enable your Web browser application, Web service application, or Foundation
Microsoft® Office SharePoint® Server application using WIF and the WIF
SDK. Note: Windows Identity
Foundation SDK
Checklist: Implementing a Federated
Web SSO Design
Article • 08/15/2023
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
conceptual topic or to a subordinate checklist, return to this topic after you review
the conceptual topic or you complete the tasks in the subordinate checklist so that
you can proceed with the remaining tasks in this checklist.
Task Reference
Review important concepts about the Federated Web SSO design and Federated Web
determine which AD FS deployment goals you can use to customize this SSO Design
design to meet the needs of your organization.
Identifying Your AD
FS Deployment Goals
Planning Your
Deployment
Review the hardware, software, certificate, Domain Name System (DNS), Appendix A:
attribute store, and client requirements for deploying AD FS in your Reviewing AD FS
organization. Requirements
Review important concepts about claims, claim rules, attribute stores, and Understanding Key
the AD FS configuration database before deploying AD FS in both AD FS Concepts
partner organizations.
According to your design plan, install one or more federation servers in Checklist: Setting
each partner organization. Note: For the Federated Web SSO design, you Up a Federation
need at least one federation server in the account partner organization Server
and at least one federation server in the resource partner organization.
(Optional) Determine whether or not your organization needs a Checklist: Setting

federation server proxy. If your design plan calls for a proxy, you can Up a Federation
Server Proxy
install
Task one or more federation server proxies in each partner Reference
organization.
According to your design plan, share certificates, configure clients, and Checklist:
configure the trust relationships in both partner organizations so that Configuring the
they can communicate over a federation trust. Account Partner
Organization
Checklist:
Configuring the
Resource Partner
Organization
If you are an administrator in the resource partner organization, claims- Windows Identity
enable your Web browser application, Web service application, or Foundation
Microsoft® Office SharePoint® Server application using WIF and the WIF
SDK. Windows Identity
Foundation SDK
Configuring Partner Organizations
Article • 08/15/2023
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
Article • 08/15/2023
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
procedure, return to this topic after you complete the steps in that procedure so
that you can proceed with the remaining tasks in this checklist.
Checklist: Configuring the account partner organization
Task Reference
If you have an existing AD FS 1.0 or 1.1 deployment in your production Planning a

environment today, see the link to the right for information about how Migration to AD FS 2.0
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
Task Reference
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 the Provide Your Active
components that are required to provide users with access to the Directory Users Access
federated applications. 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
Determine which AD FS design this account partner organization will be Web SSO Design
associated with.
Federated Web SSO
Design
Before you begin deploying your AD FS servers, review the; 1.) Determine Your AD
advantages and disadvantages of choosing either Windows Internal FS Deployment
Database (WID) or SQL Server to store the AD FS configuration database Topology
2.) AD FS deployment topology types and their associated server
placement and network layout recommendations. AD FS Deployment
Topology
Considerations
Review AD FS capacity planning guidance to determine the proper Planning for AD FS

number of federation server and federation server proxy servers you Server Capacity
should use in your production environment.
To effectively plan and implement the physical topology for the account Checklist: Setting
partner deployment, determine whether your AD FS design requires one Up a Federation
or more federation servers or federation server proxies. Server
Checklist: Setting
Up a Federation
Server Proxy
Determine the type of attribute store that you want to add to AD FS. The Role of
Then, add the attribute store using the AD FS Management snap-in. Attribute Stores
Task Reference
Add an Attribute
Store
If you will need to send claims to or consume claims from a resource Planning for
partner who is using either an AD FS 1.0 or 1.1 Federation Service, see Interoperability with
the link to the right for information about how to configure AD FS to AD FS 1.x
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 partner Create a Relying
organization, create a relying party trust relationship using the AD FS Party Trust Manually
Management snap-in. You can create a relying party trust by entering
data about a resource partner manually or by using a federation Create a Relying
metadata URL that the administrator of the resource partner Party Trust Using
organization provides to you. You can use the federation metadata to Federation Metadata
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 more claim Checklist: Creating
rule sets for each relying party trust that is specified in the AD FS Claim Rules for a
Management snap-in so that claims will be issued appropriately. Relying Party Trust
A claim description must be created if one does not already exist that Add a Claim
will fulfill the needs of your organization. AD FS ships with a default set Description
of claim descriptions that are exposed in the AD FS Management snap-
in.
Determine whether your organization will need to use identity When to Use
delegation to authorize or constrain a specified account to "act as" or Identity Delegation
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

- Adding the URL for the account partner federation server to the Computers in the
trusted sites list for the client browser. Account Partner
- Using Group Policy to push the appropriate Secure Sockets Layer (SSL)
certificates to client computers. Configure Client
Computers to Trust
the Account
Federation Server
Distribute
Certificates to Client
Computers by Using
Group Policy
Checklist: Configuring the Resource
Article • 08/15/2023
The resource partner organization contains the Web servers hosting the Web-based
applications that will be accessed by users in the account partner. Administrators in this
organization must use the AD FS Management snap-in to create claims provider trusts
to represent their trust relationships with account partner organizations. In turn, the
account partner administrator must create relying party trusts for each account partner
organization that they want to trust.
This checklist includes the tasks that are necessary for deploying Active Directory
Federation Services (AD FS) in the resource partner organization. It also includes tasks
for configuring the components that are required to establish one-half of a federation
partnership.
If you are deploying a Web SSO Design, you do not have to follow this checklist.
However, you do have to complete the tasks in this checklist to successfully deploy a
Federated Web SSO Design.
） Important
Make sure that the administrator of the account partner organization follows the
guidance in Checklist: Configuring the Account Partner Organization to ensure
that all necessary deployment tasks will be completed to successfully create the
second half of the federation partnership
７ Note
Checklist: Configuring the resource partner organization
Task Reference
If you have an existing AD FS 1.0 or 1.1 deployment in your production Planning a

environment today, see the link to the right for information about how Migration to AD FS
to migrate settings from your current Federation Service to a new AD FS
Task Reference
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 the Provide Your Active
components that are required to provide users with access to the Directory Users Access
federated applications. 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
Determine which AD FS design this resource partner organization will be Web SSO Design
associated with.
Federated Web SSO
Design
Review the different application types, and decide which application to Determine Your
deploy. Federated Application
Strategy in the
Resource Partner
Before you begin deploying your AD FS servers, review the; 1.) Determine Your AD
advantages and disadvantages of choosing either Windows Internal FS Deployment
Database (WID) or SQL Server to store the AD FS configuration database Topology
2.) AD FS deployment topology types and their associated server
placement and network layout recommendations. AD FS Deployment
Topology
Considerations
Review AD FS capacity planning guidance to determine the proper Planning for AD FS

number of federation server and federation server proxy servers you Server Capacity
should use in your production environment.
To effectively plan and implement the physical topology for the account Checklist: Setting
partner deployment, determine whether your AD FS design requires one Up a Federation
or more federation servers or federation server proxies. Server
Task Reference
Checklist: Setting
Up a Federation
Server Proxy
Determine the type of attribute store that you want to add to AD FS. The Role of
Then, add the attribute store using the AD FS Management snap-in. Attribute Stores
Add an Attribute
Store
If you will need to send claims to or consume claims from an account Planning for
partner who is using either an AD FS 1.0 or 1.1 Federation Service, see Interoperability with
the link to the right for information about how to configure AD FS to AD FS 1.x
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 partner Create a Claims
organization, create a claims provider trust relationship by using the AD Provider Trust
FS Management snap-in. You can create a claims provider trust by Manually
entering data about an account partner manually or by using a
federation metadata URL that the administrator of the account partner Create a Claims
organization provides to you. You can use the federation metadata to Provider Trust Using
retrieve the data for the resource partner automatically. Note: If the Federation Metadata
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 more claim Checklist: Creating
rule sets for each claims provider trust that is specified in the AD FS Claim Rules for a
Management snap-in so that incoming claims will be passed through, Claims Provider Trust
transformed, or mapped appropriately to corresponding claims in the
resource partner.
(Optional) A claim description may have to be created if one does not Add a Claim
already exist that will fulfill the needs of your organization. AD FS Description
includes a default set of claim descriptions that are exposed in the AD FS
Management snap-in.
Add an Attribute Store
Article • 08/15/2023
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.

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
Directory, LDAP, or SQL.
In Connection string, if you have selected either a Lightweight Directory

Access Protocol (LDAP) store or a Structured Query Language (SQL) store,
enter the string that you used to establish a connection to the attribute store.
For Active Directory attribute stores, no connection string is necessary;
therefore, this field is disabled.
７ Note
AD FS automatically creates an Active Directory attribute store, by

default.
4. Click OK.
AD FS Operations
The Role of Attribute Stores

Create a Claims Provider Trust
Article • 08/15/2023
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 Start.
4. On the Select Data Source page, click Enter claims provider trust data manually,
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 Certificates 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 Import data about the claims provider
published online or on a local network. In Federation metadata address (host
name or URL), type the federation metadata URL or host name for the partner,
5. On the Specify Display Name page type a Display name, under Notes type a
information.
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
Checklist: Creating Claim Rules for a Claims Provider Trust
See Also
AD FS Operations
Create a Relying Party Trust
Article • 08/15/2023
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.

2. Under Actions, click Add Relying Party Trust.
3. On the Welcome page, choose Claims aware and click Start.

4. On the Select Data Source page, click Enter data about the relying party
manually, and then click Next.
5. On the Specify Display Name page, type a name in Display name, under Notes
type a description for this relying party trust, and then click Next.
6. On the Configure Certificate page, if you have an optional token encryption
certificate, click Browse to locate a certificate file, and then click Next.
7. On the Configure URL page, do one or both of the following, click Next, and then
go to step 8:
Select the Enable support for the WS-Federation Passive protocol check
box. Under Relying party WS-Federation Passive protocol URL, type the URL
for this relying party trust, and then click Next.
Select the Enable support for the SAML 2.0 WebSSO protocol check box.
Under Relying party SAML 2.0 SSO service URL, type the Security Assertion
Markup Language (SAML) service endpoint URL for this relying party trust,
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.
Rules dialog box.
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


4. On the Select Data Source page, click Import data about the relying party
name or URL), type the federation metadata URL or host name for the partner, and
then click Next.
5. On the Specify Display Name page type a name in Display name, under Notes
6. On the Choose Issuance Authorization Rules page, select either Permit all users to
access this relying party or Deny all users access to this relying party, and then
click Next.
rules for this relying party trust, see the Additional references.
See Also
AD FS Operations
Add a Claim Description
Article • 08/15/2023
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.

To add a claim description

2. Expand Service and on the right click Add Claim Description.
3. On the Add a Claim Description dialog box, in Display name, type a unique name
that identifies the group or role for this claim.
4. Add a Short Name.
5. In Claim identifier, type a URI that is associated with the group or role of the claim
that you will be using.
6. Under Description, type text that best describes the purpose of this claim.
7. Depending on the needs of your organization, select either of the following check
boxes, as appropriate, to publish this claim into federation metadata:
- To publish this claim to make partners aware that this server can accept
this claim, click **Publish this claim in federation metadata as a claim
type that this Federation Service can accept**.
- To publish this claim to make partners aware that this server can issue
this claim, click **Publish this claim in federation metadata as a claim
type that this Federation Service can send**.
8. Click OK.
See Also
AD FS Operations
Configure Client Computers to Trust the
Account Federation Server
Article • 08/15/2023
So that client computers can successfully access federated applications using

Active Directory Federation Services (AD FS), you must first configure the Internet
Explorer settings on each client computer so that the browser trusts the account
federation server. You can do this manually or through Group Policy, depending on your
administrative preference, by completing one of the following procedures.
Configuring Internet Explorer settings manually

You can use the following procedure to manually configure each user's Internet Explorer
settings to support federation through AD FS. If multiple users use a single computer,
complete this procedure multiple times—once for each user profile.
To perform this procedure, log on as the user who will be accessing federated
applications. This is a profile-specific setting. Therefore, it requires that you manually
add this setting for each profile that exists on a specific computer.
To manually configure client computers to trust the account

federation server
1. On the client computer, start Internet Explorer.
2. On the Tools menu, click Internet Options.
3. On the Security tab, click the Local intranet icon, and then click Sites.
4. Click Advanced, and in Add this Web site to the zone, type the full Domain Name
System (DNS) name of the account federation server (for example,
https://fs1.fabrikam.com), and then click Add.
5. Click OK three times.
Configuring Internet Explorer settings by using

Group Policy
For most deployments, we recommend that you use Group Policy to push the
appropriate Internet Explorer settings to each client computer.
Membership in Domain Admins or Enterprise Admins, or equivalent, in Active Directory

Domain Services (AD DS) is the minimum required to complete this procedure. Review
details about using the appropriate accounts and group memberships at Local and
Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To configure client computers to trust the account federation

server by using Group Policy
1. On a domain controller in the forest of the account partner organization, start the
Group Policy Management snap-in.
2. Find the appropriate Group Policy Object (GPO), right-click it, and then click Edit.
3. In the console tree, open User Configuration\Preferences\Windows

Settings\Internet Explorer Maintenance, and then click Security.
4. In the details pane, double-click Security Zones and Content Ratings.
5. Under Security Zones and Privacy, click Import the current security zones and
privacy settings, and then click Modify Settings.
6. Click Local intranet, and then click Sites.
7. In Add this Web site to the zone, type the full DNS name of the account
federation server (for example, https://fs1.fabrikam.com), click Add, and then click
Close.
8. Click OK two times to apply these changes to Group Policy.

Distribute Certificates to Client
Computers by Using Group Policy
Article • 08/15/2023
You can use the following procedure to push down the appropriate Secure Sockets
Layer (SSL) certificates (or equivalent certificates that chain to a trusted root) for account
federation servers, resource federation servers, and Web servers to each client computer
in the account partner forest by using Group Policy.
Membership in Domain Admins or Enterprise Admins, or equivalent, in Active Directory

Domain Services (AD DS) is the minimum required to complete this procedure. Review
details about using the appropriate accounts and group memberships at Local and
Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
To distribute certificates to client computers by using

Group Policy
1. On a domain controller in the forest of the account partner organization, start the
Group Policy Management snap-in.
2. Find an existing Group Policy Object (GPO) or create a new GPO to contain the
certificate settings. Ensure that the GPO is associated with the domain, site, or
organizational unit (OU) where the appropriate user and computer accounts
reside.
3. Right-click the GPO, and then click Edit.
4. In the console tree, open Computer Configuration\Policies\Windows

Settings\Security Settings\Public Key Policies, right-click Trusted Root
Certification Authorities, and then click Import.
5. On the Welcome to the Certificate Import Wizard page, click Next.
6. On the File to Import page, type the path to the appropriate certificate files (for
example, \\fs1\c$\fs1.cer), and then click Next.
7. On the Certificate Store page, click Place all certificates in the following store,
8. On the Completing the Certificate Import Wizard page, verify that the
information you provided is accurate, and then click Finish.
9. Repeat steps 2 through 6 to add additional certificates for each of the federation
Configuring Claim Rules
Article • 08/15/2023
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 Permit All Users
Create a Rule to Send an AD FS 1.x Compatible Claim
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
AD FS Operations
Checklist: Creating Claim Rules for a
Claims Provider Trust
Article • 08/15/2023
This checklist includes tasks for planning, designing, and deploying claim rules that are
associated with a claims provider trust in Active Directory Federation Services (AD FS).
７ Note
Checklist: Creating a claim rule set for a claims provider trust
Task Reference
Review concepts about claims, claim rules, claim rule sets, and claim The Role of Claims
rule templates and how they are associated with federated trusts.
The Role of Claim Rules
Review concepts about how a claim flows through all the stages in The Role of the Claims
the claims issuance pipeline and how rules are processed by the Pipeline
claims issuance engine.
The Role of the Claims
Engine
To effectively plan and implement the output claims that will be Determine the Type of
issued over this claims provider trust, determine whether one or Claim Rule Template to
more claim rules are needed and which claim rules you should use Use
with this claims provider trust.
Review concepts about when to create one claim rule over another When to Use a Pass
and how you can use the claim rule language to provide more Through or Filter Claim
complex logic than standard rules in order to provide a desired result Rule
in the ideal output claim set.
When to Use a
Transform Claim Rule
When to Use a Send

LDAP Attributes as Claims
Rule
When to Use a Send

Group Membership as a
Claim Rule
Task Reference
When to Use a Custom

Claim Rule
The Role of the Claim

Rule Language
A claim description must be created if one does not already exist Add a Claim
that will fulfill the needs of your organization. AD FS ships with a Description
default set of claim descriptions that are exposed in the AD FS
Management snap-in.
Depending on the needs of your organization, create one or more Create a Rule to Pass
claim rules for the acceptance transform rules set that is associated Through or Filter an
with this claims provider trust so that claims will be issued Incoming Claim
appropriately.
Create a Rule to Send

Claim
Create a Rule to
Transform an Incoming
Claim

an Authentication Method
Claim

an AD FS 1.x Compatible
Claim

Claims Using a Custom
Rule
Checklist: Creating Claim Rules for a
Relying Party Trust
Article • 08/15/2023
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
７ Note
Checklist: Creating a claim rule set for a relying party trust
Task Reference
Review concepts about claims, claim rules, claim rule sets, and claim The Role of Claims
rule templates and how they are associated with federated trusts.
Review concepts about how a claim flows through all the stages in The Role of the Claims
the claims issuance pipeline and how rules are processed by the Pipeline
claims issuance engine.
The Role of the Claims
Engine
To effectively plan and implement the output claims that will be Determine the Type of
issued over this relying party trust, determine whether one or more Claim Rule Template to
claim rules are needed and which claim rules you should use with Use
this relying party trust.
Review concepts about when to create one claim rule over another When to Use a Pass
and how you can use the claim rule language to provide more Through or Filter Claim
complex logic than standard rules in order to provide a desired Rule
result in the ideal output claim set.
When to Use a
Transform Claim Rule
When to Use a Send

Rule
When to Use a Send

Task Reference
Claim Rule
When to Use an
Authorization Claim Rule
When to Use a Custom

Claim Rule
The Role of the Claim

Rule Language
A claim description must be created if one does not already exist Add a Claim
that will fulfill the needs of your organization. AD FS ships with a Description
default set of claim descriptions that are exposed in the AD FS
Management snap-in.
Depending on the needs of your organization, create one or more Create a Rule to Pass
claim rules for the rule sets that are associated with this relying party Through or Filter an
trust so that claims will be issued appropriately. Incoming Claim


Claim
Create a Rule to
Transform an Incoming
Claim

an Authentication Method
Claim

an AD FS 1.x Compatible
Claim

Claims Using a Custom
Rule
Depending on the needs of your organization, create one or more Create a Rule to Permit
claim rules for either the issuance authorization rules set or the All Users
delegation authorization rules set that is associated with this relying
party trust so that users will be permitted access to the relying party. Create a Rule to Permit
or Deny Users Based on
an Incoming Claim
Create a Rule to Pass Through or Filter
an Incoming Claim
Article • 08/15/2023
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.

To create a rule to pass through or filter an

incoming claim on a Relying Party Trust in
Windows Server 2016
2. In the console tree, under AD FS, click Relying Party Trusts.

3. Right-click the selected trust, and then click Edit Claim Issuance Policy.
4. In the Edit Claim Issuance Policy dialog box, under Issuance Transform Rules click
Add Rule to start the rule wizard.
5. On the Select Rule Template page, under Claim rule template, select Pass
Through or Filter an Incoming Claim from the list, and then click Next.
6. On the Configure Rule page under Claim rule name type the display name for this
rule, in Incoming claim type select a claim type in the list, and then select one of
the following options, depending on the needs of your organization:
Pass through all claim values
Pass through only a specific claim value
Pass through only claim values that match a specific email suffix value
Pass through only claim values that start with a specific value
7. Click the Finish button.
8. In the Edit Claim Rules dialog box, click OK to save the rule.

incoming claim on a Claims Provider Trust in
Windows Server 2016
2. In the console tree, under AD FS, click Claims Provider Trusts.
3. Right-click the selected trust, and then click Edit Claim Rules.
4. In the Edit Claim Rules dialog box, under Acceptance Transform Rules click Add
Rule to start the rule wizard.

incoming claim in Windows Server 2012 R2
2. In the console tree, under AD FSAD FS\Trust Relationships, click either Claims
Provider Trusts or Relying Party Trusts, and then click a specific trust in the list
where you want to create this rule.
4. In the Edit Claim Rules dialog box, select one the following tabs, depending on the
trust you are editing and which rule set you want to create this rule in, and then
click Add Rule to start the rule wizard that is associated with that rule set:
Acceptance Transform Rules
Issuance Transform Rules
Issuance Authorization Rules

Delegation Authorization Rules
Configure Claim 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
Article • 08/15/2023
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.

Incoming Claim rule template on a Claims
Provider Trust in Windows Server 2016

UPN
E-Mail
Common Name
To create a rule to transform an incoming claim

on a Relying Party Trust in Windows Server
2016
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

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

on a Claims Provider Trust in Windows Server
2016

UPN
E-Mail
Common Name


Incoming Claim rule template on Windows
Server 2012 R2
1. In Server Manager, click Tools, and then click AD FS Management.
2. In the console tree, under AD FS\Trust Relationships, click either Claims Provider
Trusts or Relying Party Trusts, and then click a specific trust in the list where you
want to create this rule.


UPN
E-Mail
Common Name

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:


UPN
E-Mail
Common Name

Checklist: Creating Claim Rules for a Relying Party Trust
When to Use an Authorization Claim Rule
The Role of Claims

Article • 08/15/2023
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.

To create a rule to permit all users in Windows

Server 2016

3. Right-click the Relying Party Trust that you want to permit access to and select
Edit Access Control Policy.
4. On the Access control policy select Permit everyone and then click Apply and Ok.
To create a rule to permit all users in Windows
Server 2012 R2
2. In the console tree, under AD FS\Trust Relationships\Relying Party Trusts, click a

specific trust in the list where you want to create this rule.
4. In the Edit Claim Rules dialog box, click the Issuance Authorization Rules tab or
the Delegation Authorization Rules tab (based on the type of authorization rule
you require), and then click Add Rule to start the Add Authorization Claim Rule
Wizard.
5. On the Select Rule Template page, under Claim rule template, select Permit All
Users from the list, and then click Next.
6. On the Configure Rule page, click Finish.
The Role of Claims

Create a Rule to Permit or Deny Users
Based on an Incoming Claim
Article • 08/15/2023
In Windows Server 2016, you can use an Access Control Policy to create a rule that will
permit or deny users based on an incoming claim. In Windows Server 2012 R2, using the
Permit or Deny Users Based on an Incoming Claim rule template in Active Directory
Federation Services (AD FS), you can create an authorization rule that will grant or deny
user's access to the relying party based on the type and value of an incoming claim.
For example, you can use this to create a rule that will permit only users that have a
group claim with a value of Domain Admins to access the relying party. If you want to
permit all users to access the relying party, use the Permit Everyone Access Control
Policy or the Permit All Users rule template depending on your version of Windows
Server. Users who are permitted to access the relying party from the Federation Service
may still be denied service by the relying party.
snap-in.

To create a rule to permit users based on an

incoming claim on Windows Server 2016
2. In the console tree, under AD FS, click Access Control Policies.
3. Right-click and select Add Access Control Policy.

4. In the name box, enter a name for your policy, a description and click Add.
5. On the Rule Editor, under users, place a check in with specific claims in the
request and click the underlined specific at the bottom.
6. On the Select Claims screen, click the Claims radio button, select the Claim type,
the Operator, and the Claim Value then click Ok.
7. On the Rule Editor click Ok. On the Add Access Control Policy screen, click Ok.
8. In the AD FS Management console tree, under AD FS, click Relying Party Trusts.
10. On the Access control policy select your policy and then click Apply and Ok.
To create a rule to deny users based on an

incoming claim on Windows Server 2016
2. In the console tree, under AD FS, click Access Control Policies.
3. Right-click and select Add Access Control Policy.

4. In the name box, enter a name for your policy, a description and click Add.
5. On the Rule Editor, make sure everyone is selected and under Except place a
check in with specific claims in the request and click the underlined specific at the
bottom.
6. On the Select Claims screen, click the Claims radio button, select the Claim type,
the Operator, and the Claim Value then click Ok.
7. On the Rule Editor click Ok. On the Add Access Control Policy screen, click Ok.
8. In the AD FS Management console tree, under AD FS, click Relying Party Trusts.
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 Party Trusts, click a

specific trust in the list where you want to create this rule.
4. In the Edit Claim Rules dialog box, click the Issuance Authorization Rules tab or
the Delegation Authorization Rules tab (based on the type of authorization rule
you require), and then click Add Rule to start the Add Authorization Claim Rule
Wizard.
5. On the Select Rule Template page, under Claim rule template, select Permit or
Deny Users Based on an Incoming Claim from the list, and then click Next.
rule, in Incoming 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

Create a Rule to Send LDAP Attributes
as Claims
Article • 08/15/2023
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.

To create a rule to send LDAP attributes as

claims for a Relying Party Trust in Windows
Server 2016
5. On the Select Rule Template page, under Claim rule template, select Send LDAP
Attributes as Claims from the list, and then click Next.
rule, select the Attribute Store, and then select the LDAP attribute and map it to
the outgoing claim type.

claims for a Claims Provider Trust in Windows
Server 2016
rule, select the Attribute Store, and then select the LDAP attribute and map it to
the outgoing claim type.

claims for Windows Server 2012 R2
2. In the console tree, under AD FSAD FS\Trust Relationships, click either Claims
Provider Trusts or Relying Party Trusts, and then click a specific trust in the list
where you want to create this rule.
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:

rule, under Attribute store select Active Directory, and under Mapping of LDAP
attributes to outgoing claim types select the desired LDAP Attribute and
corresponding Outgoing Claim Type types from the drop-down lists.
You have to select a new LDAP attribute and outgoing claim type pair on a
different row for each Active Directory attribute that you want to issue a claim for
as part of this rule.
The Role of Claims

Create a Rule to Send Group
Membership as a Claim
Article • 08/15/2023
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.
snap-in.

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

claim on a Claims Provider Trust in Windows
Server 2016

claim in Windows Server 2012 R2

Membership as a Claim from the list, and then click Next.
7. Click Finish.
The Role of Claims

Create a Rule to Transform an Incoming
Claim
Article • 08/15/2023
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.
snap-in.


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

2016

７ Note

in Windows Server 2012 R2


７ Note
7. Click Finish.

The Role of Claims

Create a Rule to Send an Authentication
Method Claim
Article • 08/15/2023
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.
Actual Corresponding URI

Authentication
method
User name and https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password

password
authentication
Windows https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows
authentication
Transport Layer https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/tlsclient

Security (TLS)
Mutual
Authentication
method
authentication
that uses X.509
certificates
X.509-based https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/x509
authentication
that does not
use TLS
To create by using the Send Group Membership

as Claims rule template on a Claims Provider
Trust in Windows Server 2016

Authentication
method

password
authentication
authentication

Security (TLS)
Mutual
Authentication
method
authentication
that uses X.509
certificates
authentication
that does not
use TLS
To create this rule by using the transform an

incoming claim rule template on a Relying
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.

authentication
method

password
authentication
authentication
method
authentication
TLS mutual https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/tlsclient

authentication
that uses X.509
certificates
authentication
that does not
use TLS
７ 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

authentication
method

password
authentication
authentication
method
authentication

authentication
that uses X.509
certificates
authentication
that does not
use TLS
To create this rule by using the Send Group

Membership as Claims rule template in

Membership as a Claim from the list, and then click Next.

Authentication
Method

password
authentication
authentication

Security (TLS)
Mutual
Authentication
Method
authentication
that uses X.509
certificates
authentication
that does not
use TLS
７ Note
that are shown in the previous table reflect the URIs that the relying party accepts
by default.
To create this rule by using the Transform an
Incoming Claim rule template in Windows
Server 2012 R2


authentication
method

password
authentication
authentication
method
authentication

authentication
that uses X.509
certificates
authentication
that does not
use TLS
７ Note
that are shown ion the previous table reflect the URIs that the relying party accepts
by default.
The Role of Claims

Create a Rule to Send Claims Using a
Custom Rule
Article • 08/15/2023
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.


incoming claim on a 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.
this rule. Under Custom rule, type or paste the claim rule language syntax that you
want for this rule.
7. Click Finish.

incoming claim on a Claims Provider Trust in
Windows Server 2016
want for this rule.
7. Click Finish.
To create a rule to send claims by using a

custom claim in Windows Server 2012 R2

want for this rule.
7. Click Finish.
The Role of Claims

Deploying Federation Servers
Article • 08/15/2023
To deploy federation servers in Active Directory Federation Services (AD FS), complete

each of the tasks in Checklist: Setting Up a Federation Server.
７ Note
When you use this checklist, we recommend that you first read the references to
federation server planning in the AD FS Design Guide in Windows Server 2012
before you begin the procedures for configuring the servers. Following the
checklist in this way provides a better understanding of the design and deployment
process for federation servers.
About federation servers

Federation servers are computers running Windows Server 2008 with the AD FS software
installed that have been configured to act in the federation server role. Federation
servers authenticate or route requests from user accounts in other organizations and
from client computers that can be located anywhere on the Internet.
The act of installing the AD FS software on a computer and using the AD FS Federation
Server Configuration Wizard to configure it for the federation server role makes that
computer a federation server. It also makes the AD FS Management snap-in available on
that computer in the Start\Administrative Tools\ menu so that you can specify the
following:
The AD FS host name where partner organizations and applications will send token
requests and responses
The AD FS identifier that partner organizations and applications will use to identify
the unique name or location of your organization
The token-signing certificate that all federation servers in a server farm will use to
issue and sign tokens
The location of customized ASP.NET Web pages for client logon, logoff, and
account partner discovery that will enhance the client experience
７ Note
The majority of these core user interface (UI) settings are contained in the
web.config file on each federation server. The AD FS host name and AD FS
identifier values are not specified in the web.config file.
Federation servers host a claims issuance engine that issues tokens based on the
credentials (for example, user name and password) that are presented to it. A security
token is a cryptographically signed data unit that expresses one or more claims. A claim
is a statement that a server makes (for example, name, identity, key, group, privilege, or
capability) about a client. After the credentials are verified on the federation server
(through the user logon process), claims for the user are collected through examination
of the user attributes that are stored in the specified attribute store.
In Federated Web Single-Sign-On (SSO) designs (AD FS designs in which two or more
organizations are involved), claims can be modified by claim rules for a specific relying
party. The claims are built into a token that is sent to a federation server in the resource
partner organization. After a federation server in the resource partner receives the
claims as incoming claims, it executes the claims issuance engine to run a set of claim
rules to filter, pass through, or transform those claims. The claims are then built into a
new token that is sent to the Web server in the resource partner.
In the Web SSO design (an AD FS design in which only one organization is involved), a
single federation server can be used so that employees can log on once and still access
multiple applications.
Checklist: Setting Up a Federation
Server
Article • 08/15/2023
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
７ Note
Checklist: Setting up a federation server
Task Reference
Before you begin deploying your AD FS federation servers, review the; Determine Your AD FS
1.) advantages and disadvantages of choosing either Windows Deployment Topology
Internal Database (WID) or SQL Server to store the AD FS
configuration database 2.) AD FS deployment topology types and AD FS Deployment
their associated server placement and network layout Topology Considerations
recommendations.
Review AD FS capacity planning guidance to determine the proper Planning for

number of federation servers you should use in your production Federation Server
environment. Capacity
Review information in the AD FS Design Guide about where to place Planning Federation
federation servers in your organization Server Placement
Where to Place a
Federation Server
Determine whether a stand-alone federation server or a federation When to Create a

server farm is better for your deployment. Federation Server
When to Create a
Federation Server Farm
Determine whether this new federation server will be created in the Review the Role of the
account partner organization or in the resource partner organization. Federation Server in the
Account Partner
Task Reference
Review the Role of the

Federation Server in the
Resource Partner
Review information about how federation servers use service Certificate

communication certificates and token-signing certificates to securely Requirements for
authenticate client and federation server proxy requests. Caution: Federation Servers
Though it has long been common practice to use certificates with
unqualified host names such as https://myserver, these certificates
have no security value and can enable an attacker to impersonate the
AD FS Federation Service to enterprise clients. Therefore, it is
recommended that you use a fully qualified domain name (FQDN)
such as https://myserver.contoso.com and only use SSL certificates
issued to the FQDN of your Federation Service.
Review information about how to update the corporate network Name Resolution
Domain Name System (DNS) so that successful name resolution to Requirements for
federation servers can occur. Federation Servers
Join the computer that will become the federation server to a domain Join a Computer to a
in the account partner forest or resource partner forest where it will Domain
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 that Add a Host (A)
points the DNS host name of the federation server to the IP address Resource Record to
of the federation server. Corporate DNS for a
Federation Server
(Optional) If you will be adding a federation server to a federation Export the Private Key
server farm, you might have to first export the private key of the Portion of a Server
existing token-signing certificate (on the first federation server in the Authentication
farm) so that you have a file format of the certificate ready when other Certificate
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 private key) Import a Server
from a certification authority (CA), you must then import the Authentication
certificate file to the default Web site for each federation server. Note: Certificate to the Default
Web Site
Installing
Task this certificate on the default Web site is a requirement Reference
before you can use the AD FS Federation Server Configuration Wizard.
(Optional) As an alternative to obtaining a server authentication IIS: Create a Self-

certificate from a CA, you can use Internet Information Services (IIS) to Signed Server Certificate
create a sample certificate for your federation server. Caution: It is not and then complete the
a security best practice to deploy a federation server in a production procedure Import a
environment by using a self-signed server authentication certificate. Server Authentication
Certificate to the Default
Web Site
If you will be configuring a federation server farm environment in an Manually Configure a

account partner organization, you must create and configure a Service Account for a
dedicated service account in Active Directory Domain Services Federation Server Farm
(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.
Install the Federation Service role service on the computer that will Install the Federation
become the federation server. Service Role Service
Configure the AD FS software on the computer to act in the Create a Stand-Alone

federation server role by using the AD FS Federation Server Federation Server
Configuration Wizard.
Follow this procedure when you want to set up a stand-alone Create the First
federation server, create the first federation server in a new farm or Federation Server in a
join a computer to an existing federation server farm. Note: For the Federation Server Farm
Federated Web Single Sign-On (SSO) design, you must have at least
Add a Federation
one federation server in the account partner organization and at least
Server to a Federation
one federation server in the resource partner organization.
Server Farm
(Optional) Use the AD FS Management snap-in to add and configure Add a Token-Signing
the necessary AD FS certificates required to deploy your design. For Certificate
more information about when to add or change certificates using the
snap-in, see Certificate Requirements for Federation Servers. Add a Token-
Decrypting Certificate
Set a Service
Communications
Certificate
If this is the first federation server in your organization, configure the Checklist: Configuring
Federation Service so that it conforms to your AD FS design. the Account Partner
Organization
Checklist: Configuring
the Resource Partner
Organization
Task Reference
From a client computer, verify that the federation server is Verify That a
operational. Federation Server Is
Operational
Add a Host (A) Resource Record to
Corporate DNS for a Federation Server
Article • 08/15/2023
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
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
Article • 08/15/2023
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 Service Account wizard page on each federation server in the farm.
Create a dedicated service account
1. Create a dedicated user/service account in the Active Directory forest that is

located in the identity provider organization. This account is necessary for the
Kerberos authentication protocol to work in a farm scenario and to allow pass-
through authentication on each of the federation servers. Use this account only for
the purposes of the federation server farm.
2. Edit the user account properties, and select the Password never expires check box.
This action ensures that this service account's function is not interrupted as a result
of domain password change requirements.
７ Note
Using the Network Service account for this dedicated account will result in
random failures when access is attempted through Windows Integrated
Authentication, as a result of Kerberos tickets not validating from one server
to another.
To set the SPN of the service account

1. Because the application pool identity for the AD FS AppPool is running as a
domain user/service account, you must configure the Service Principal Name (SPN)
for that account in the domain with the Setspn.exe command-line tool. Setspn.exe
is installed by default on computers running Windows Server 2008 . Run the
following command on a computer that is joined to the same domain where the
user/service account resides:
setspn -a host/<server name> <service account>
For example, in a scenario in which all federation servers are clustered under the
Domain Name System (DNS) host name fs.fabrikam.com and the service account
name that is assigned to the AD FS AppPool is named adfs2farm, type the
command as follows, and then press ENTER:
setspn -a host/fs.fabrikam.com adfs2farm
It is necessary to complete this task only once for this account.
2. After the AD FS AppPool identity is changed to the service account, set the access
control lists (ACLs) on the SQL Server database to allow Read access to this new
account so that the AD FS AppPool can read the policy data.
Install the Federation Service Role
Service
Article • 08/15/2023
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.

To install the Federation Service role service
1. On the Start screen, typeServer Manager, and then press ENTER.

2. Click Manage, and then click Add Roles and Features to start the Add Roles and
Features Wizard.

installation, and click Next.
verify that the target computer is highlighted, and then click Next.
then click next.
７ Note
If you are prompted to install additional .NET Framework or Windows Process

Activation Service features, click Add Features to install them.
7. On the Select features page, verify that the features are set, and then click Next.
9. On the Select role services page, select the Federation Service check box, and
then click Next.
10. On the Web Server Role (IIS) page, click Next.
11. On the Select role services page, click Next.
click Install.
then click Close.
Create the First Federation Server in a
Federation Server Farm
Article • 08/15/2023
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.
Service and makes this computer the primary federation server. This means that this
computer will be configured with a read/write copy of the AD FS configuration
database. All other federation servers in this farm must replicate any changes that are
made on the primary federation server to their read-only copies of the AD FS
configuration database that they store locally. For more information about this
replication process, see The Role of the AD FS Configuration Database.
７ Note
Membership in Domain Admins, or a delegated domain account that has been granted
write access to the Program Data container in Active Directory, is the minimum required
to complete this procedure.
To create the first federation server in a federation server

farm
1. There are two ways to start the AD FS Federation Server Configuration Wizard. To
start the wizard, do one of the following:
After the Federation Service role service installation is complete, open the AD
FS Management snap-in and click the AD FS Federation Server
Configuration Wizard link on the Overview page or in the Actions pane.
Any time after the setup wizard is complete, open Windows Explorer,
navigate to the C:\Windows\ADFS folder, and then double-click
FsConfigWizard.exe.
2. On the Welcome page, verify that Create a new Federation Service is selected,
3. On the Select Stand-Alone or Farm Deployment page, click New federation

4. On the Specify the Federation Service Name page, verify that the SSL certificate
that is showing is correct. If this is not the correct certificate, select the appropriate
certificate from the SSL certificate list.
This certificate is generated from the Secure Sockets Layer (SSL) settings for the
Default Web Site. If the Default Web Site has only one SSL certificate configured,
that certificate is presented and automatically selected for use. If multiple SSL
certificates are configured for the Default Web Site, all those certificates are listed
here and you must select from among them. If there are no SSL settings
configured for the Default Web Site, the list is generated from the certificates that
are available in the personal certificates store on the local computer.
７ Note
The wizard will not allow you to override the certificate if an SSL certificate is
configured for IIS. This ensures that any intended prior IIS configuration for
SSL certificates is preserved. To work around this restriction, you can remove
the certificate or reconfigure it manually with the IIS Management Console.
5. If the AD FS database that you selected already exists, the Existing AD FS
Configuration Database Detected page appears. If that page appears, click Delete
database, and then click Next.
Ｕ Caution
Select this option only when you are sure that the data in this AD FS database
is not important or that it is not used in a production federation server farm.
6. On the Specify a Service Account page, click Browse. In the Browse dialog box,
locate the domain account that will be used as the service account in this new
federation server farm, and then click OK. Type the password for this account,
confirm it, and then click Next.
７ Note
See Manually Configure a Service Account for a Federation Server Farm for
more information about specifying a service account for a federation server
farm. Each federation server in the federation server farm must specify the
same service account for the farm to be operational. For example, if the
service account that was created was contoso\ADFS2SVC, each computer that
you configure for the federation server role and that will participate in the
same farm must specify contoso\ADFS2SVC at this step in the Federation
Server Configuration Wizard for the farm to be operational.
7. On the Ready to Apply Settings page, review the details. If the settings appear to
be correct, click Next to begin configuring AD FS with these settings.
8. On the Configuration Results page, review the results. When all the configuration
steps are finished, click Close to exit the wizard.
） Important
For secure deployment purposes, artifact resolution and reply detection are
disabled when you use the AD FS Federation Server Configuration Wizard to
configure a federation server farm. This wizard automatically configures the
Windows Internal Database for storing service configuration data. You might,
however, mistakenly undo this change by enabling the Artifact Resolution
endpoint using either the Endpoints node in the AD FS Management snap-in
or the Enable-ADFSEndpoint cmdlet in Windows PowerShell. Be careful to not
reconfigure the default setting so that this endpoint remains disabled when
you use a federation server farm and the Windows Internal Database
together.
Create a Stand-Alone Federation Server
Article • 08/15/2023
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

accounts and group memberships at Local and Domain 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 Service is selected,
3. On the Select Stand-Alone or Farm Deployment page, click Stand-alone

federation server, and then click Next.
） Important
When you select the Stand-alone federation server option in the AD FS

Federation Server Configuration Wizard, the service account associated with
this Federation Service will automatically be assigned to the NETWORK
SERVICE account. Using NETWORK SERVICE as the service account is only
recommended in situations where you are evaluating AD FS in a test lab
environment. If you intend to use the Stand-alone federation server option to
deploy a federation server in a production environment, it is important that
you change this service account to a more appropriate service account that
can be dedicated to serving requests for this new Federation Service.
Changing the service account to an account other than NETWORK SERVICE
will mitigate possible attack vectors that would otherwise make your
federation server vulnerable to malicious attacks.
4. On the Specify the Federation Service Name page, verify that the SSL certificate
that is showing is correct. If not, select the appropriate certificate from the SSL
certificate list.
This certificate is generated from the Secure Sockets Layer (SSL) settings for the
Default Web Site. If the Default Web Site has only one SSL certificate configured,
that certificate is presented and automatically selected for use. If multiple SSL
certificates are configured for the Default Web Site, all those certificates are listed
here and you must select from among them. If there are no SSL settings
configured for the Default Web Site, the list is generated from the certificates that
are available in the personal certificates store on the local computer.
７ Note
The wizard will not allow you to override the certificate if an SSL certificate is
configured for IIS. This ensures that any intended prior IIS configuration for
SSL certificates is preserved. To work around this restriction, you can remove
the certificate or reconfigure manually it with the IIS Management Console.
Configuration Database Detected page appears. If that occurs, click Delete
Ｕ Caution
Add a Federation Server to a Federation
Server Farm
Article • 08/15/2023
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

to the C:\Windows\ADFS folder, and double-click FsConfigWizard.exe.
2. On the Welcome page, verify that Add a federation server to an existing

Federation Service is selected, and then click Next.
Configuration Database Detected page appears. If that occurs, click Delete
Ｕ Caution
4. On the Specify the Primary Federation Server and Service Account page, under
Primary federation server name, type the computer name of the primary
federation server in the farm, and then click Browse. In the Browse dialog box,
locate the domain account that is used as the service account by all other
federation servers in the existing federation server farm, and then click OK. Type
the password and confirm it, and then click Next:
７ Note
For more information about specifying a service account for a federation

server farm, see Manually Configure a Service Account for a Federation
Server Farm. Each federation server in the federation server farm must specify
the same service account for the farm to be operational. For example, if the
service account that was created was contoso\ADFS2SVC, each computer you
configure for the federation server role and that will participate in the same
farm must specify contoso\ADFS2SVC at this step in the Federation Server
Configuration Wizard for the farm to be operational.
Add a Token-Signing Certificate
Article • 08/15/2023
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.
Ｕ Caution
Certificates used for token-signing are critical to the stability of the Federation
Service. Because loss or unplanned removal of any certificates configured for this
purpose can disrupt service, you should backup any certificates configured for this
purpose.
The token-signing certificate should chain to a trusted root in the Federation Service.
You can use the following procedure to add the token-signing certificate to the AD FS
Management snap-in from a file that you have exported.

To add a token-signing certificate

1. On the Start screen, typeAD FS Management, and then press ENTER.
2. In the console tree, double-click Service, and then click Certificates.
3. In the Actions pane, click the Add Token-Signing Certificate link.
4. In the Browse for Certificate file dialog box, navigate to the certificate file that you
want to add, select the certificate file, and then click Open.

Add a Token-Decrypting Certificate
Article • 08/15/2023
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.
Ｕ Caution
Certificates used for token-decrypting are critical to the stability of the Federation
Service. Because loss or unplanned removal of any certificates configured for this
purpose can disrupt service, you should backup any certificates configured for this
purpose.
You can use the following procedure to add the token-decrypting certificate to the AD
FS Management snap-in from a file that you have exported.

To add a token-decrypting certificate

3. In the Actions pane, click the Add Token-Decrypting Certificate link.
4. In the Browse for Certificate file dialog box, navigate to the certificate file that you
want to add, select the certificate file, and then click Open.

Set a Service Communications
Certificate
Article • 08/15/2023
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 communication certificates.

To set a service communications certificate

3. In the Actions pane, click the Set Service Communications Certificate link.
4. In the Select a service communications certificate dialog box, navigate to the

certificate file that you want to set as the service communications certificate, select
the certificate file, and then click Open.

Verify That a Federation Server Is
Operational
Article • 08/15/2023
You can use the following procedures to verify that a federation server is operational;
that is, that any client on the same network can reach a new federation server.

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

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
2. Open a browser window, in the address bar type the federation server's DNS host
name, and then append /adfs/fs/federationserverservice.asmx to it for the new
federation server, for example:
https://fs1.fabrikam.com/adfs/fs/federationserverservice.asmx
3. Press ENTER, and then complete the next procedure on the federation server
computer. If you see the message There is a problem with this website's security
certificate, click Continue to this website.
The expected output is a display of XML with the service description document. If
this page appears, IIS on the federation server is operational and serving pages
successfully.


operational
1. Log on to the new federation server as an administrator.
2. On the Start screen, type Event Viewer, and then press ENTER.

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
Article • 08/15/2023
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.
Checklist: Setting Up a Federation
Server Proxy
Article • 08/15/2023
This checklist includes the deployment tasks for preparing a server running Windows
Server® 2012 for the federation server proxy role in Active Directory Federation Services
(AD FS).
７ Note
Checklist: Setting Up a federation server proxy
Task Reference
Before you begin deploying your AD FS federation server proxies, Determine Your AD FS
review the AD FS deployment topology types and their Deployment Topology
associated server placement and network layout
recommendations. Planning Federation Server
Proxy Placement
Where to Place a
Federation Server Proxy
Review AD FS capacity planning guidance to determine the Planning for Federation

proper number of federation server proxies you should use in Server Proxy Capacity
your production environment.
Determine whether a single federation server proxy or a When to Create a

federation server proxy farm is better for your deployment. Note: Federation Server Proxy
Federation servers also perform federation server proxy
responsibilities. When to Create a
Federation Server Proxy Farm
Determine whether this new federation server proxy will be Review the Role of the
created in the perimeter network of the account partner Federation Server Proxy in
organization or the resource partner organization. the Account Partner
Review the Role of the

Federation Server Proxy in
the Resource Partner
Task Reference
Before you install AD FS on a computer that will become a Certificate Requirements

federation server proxy, read about the importance of obtaining for Federation Server Proxies
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

update Domain Name System (DNS) in the perimeter network so Requirements for Federation
that successful name resolution for federation servers and Server Proxies
federation server proxies can occur.
Determine whether the federation server proxy must be joined to Join a Computer to a
a domain. Although federation server proxies do not have to be Domain
joined to a domain, they are easier to manage with remote
administration and Group Policy features when they are joined to
a domain.
Depending on how the DNS infrastructure in your perimeter Configure Name

network is configured, complete one of the procedures in the Resolution for a Federation
topics on the right before you deploy a federation server proxy in Server Proxy in a DNS Zone
your organization. Note: Do not perform both procedures. Read That Serves Only the
Name Resolution Requirements for Federation Server Proxies to Perimeter Network
determine which procedure best suits the requirements of your
organization. Configure Name
Resolution for a Federation
Server Proxy in a DNS Zone
That Serves Both the
Perimeter Network and
Internet Clients
After you obtain a server authentication certificate, you must Import a Server
install it in Internet Information Services (IIS) on the default Web Authentication Certificate to
site of the federation server proxy. the Default Web Site
(Optional) As an alternative to obtaining a server authentication IIS: Create a Self-Signed

certificate from a certification authority (CA), you can use IIS to Server Certificate
acquire a sample certificate for your federation server proxy.
Because IIS generates a self-signed certificate that does not
originate from a trusted source, use it to create a self-signed
certificate only in the following scenarios:
- When you have to create a Secure Sockets Layer (SSL) channel

between your server and a limited, known group of users
- When you have to troubleshoot third-party certificate problems
Caution: It is not a security best practice to deploy a federation
server proxy in a production environment using a self-signed,
server authentication certificate.
Task Reference
Install the Federation Service Proxy role service on the computer Install the Federation
that will become the federation server proxy. Service Proxy Role Service
Configure the AD FS software on the computer to act in the Configure a Computer for
federation server proxy role by using the AD FS Federation Server the Federation Server Proxy
Proxy Configuration Wizard. Role
Using Event Viewer, verify that the federation server proxy service Verify That a Federation
has started. Server Proxy Is Operational
Article • 02/08/2023
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.

To join a computer to a domain

3. Under Computer name, domain, and workgroup settings, click Change settings.
computer to join, and then click OK.
computer.
To join a server to a domain

3. Under Related settings, click Rename this PC (advanced).
server to join, and then click OK.
server.

Configure Name Resolution for a
Federation Server Proxy in a DNS Zone
That Serves Only the Perimeter Network
Article • 08/15/2023
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 federation server proxy.
７ 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
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.

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

1. On a DNS server for the perimeter network, open the DNS snap-in. Click Start,
point to Administrative Tools, and then click DNS.
3. In Name, type only the computer name of the federation server. For example, for
the fully qualified domain name (FQDN) fs.fabrikam.com, type fs.
4. In IP address, type the IP address for the new federation server proxy, for example,
131.107.27.68.
5. Click Add Host.

Configure Name Resolution for a
Federation Server Proxy in a DNS Zone
That Serves Only the Perimeter Network
Article • 08/15/2023
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 federation server proxy.
７ 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
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.

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

1. On a DNS server for the perimeter network, open the DNS snap-in. Click Start,
point to Administrative Tools, and then click DNS.
3. In Name, type only the computer name of the federation server. For example, for
the fully qualified domain name (FQDN) fs.fabrikam.com, type fs.
4. In IP address, type the IP address for the new federation server proxy, for example,
131.107.27.68.
5. Click Add Host.

Export the Private Key Portion of a
Server Authentication Certificate
Article • 08/15/2023
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
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.

To export the private key portion of a server

authentication certificate
1. On the Start screen, typeInternet Information Services (IIS) Manager, and then
press ENTER.
2. In the console tree, click ComputerName.
3. In the center pane, double-click Server Certificates.

4. In the center pane, right-click the certificate that you want to export, and then click
Export.
5. In the Export Certificate dialog box, click the … button.
6. In File name, type C:\NameofCertificate, and then click Open.
7. Type a password for the certificate, confirm it, and then click OK.
8. Validate the success of your export by confirming that the file you specified is
created at the specified location.
） Important
So that this certificate can be imported to the local certificate store on the
new server, you must transfer the file to physical media and protect its
security during transport to the new server. It is extremely important to guard
the security of the private key. If this key is compromised, the security of your
entire AD FS deployment (including resources within your organization and in
resource partner organizations) is compromised.
9. Import the exported server authentication certificate into the certificate store on
the new server before you install the Federation Service. For information about
how to import the certificate, see Import a Server Certificate

Import a Server Authentication
Certificate to the Default Web Site
Article • 08/15/2023
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


To import a server authentication certificate to the

Default Web Site
1. On the Start screen, typeInternet Information Services (IIS) Manager, and then
press ENTER.
2. In the console tree, click ComputerName.
3. In the center pane, double-click Server Certificates.
4. In the Actions pane, click Import.
5. In the Import Certificate dialog box, click the … button.
6. Browse to the location of the pfx certificate file, highlight it, and then click Open.
7. Type a password for the certificate, and then click OK.


Install the Federation Service Proxy Role
Service
Article • 08/15/2023
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.

To install the Federation Service Proxy role service using

the Server Manager
1. On the Start screen, typeServer Manager, and then press ENTER.
2. Click Manage, and then click Add Roles and Features to start the Add Roles and
Features Wizard.

installation, and click Next.
verify that the target computer is highlighted, and then click Next.
6. On the Select server roles page, click Remote Access, and then click next.
７ Note
If you are prompted to install additional .NET Framework or Windows Process

Activation Service features, click Add Features to install them.
7. On the Select role services page, select the Federation Service Proxy check box,
click Install.
then click Close.
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
Article • 08/15/2023
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.

To configure a computer for the federation server proxy

role
On the Start screen, typeAD FS Federation Server Proxy Configuration

Wizard, and then press ENTER.
to the C:\Windows\ADFS folder, and then double-click FspConfigWizard.exe.
2. Using either method, start the wizard, and on the Welcome page, click Next.
3. On the Specify Federation Service Name page, under Federation Service name,
type the name that represents the Federation Service for which this computer will
act in the proxy role.
4. Based on your specific network requirements, determine whether you will need to
use an HTTP proxy server to forward requests to the Federation Service. If so,
select the Use an HTTP proxy server when sending requests to this Federation
Service check box, under HTTP proxy server address type the address of the proxy
server, click Test Connection to verify connectivity, and then click Next.
5. When you are prompted, specify the credentials that are necessary to establish a
trust between this federation server proxy and the Federation Service.
By default, only the service account used by the Federation Service or a member of
the local BUILTIN\Administrators group can authorize a federation server proxy.
be correct, click Next 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-ADFSProperties cmdlet. For example, to
configure these ports, use the following commands in the Windows PowerShell
session on the federation server computer:
Set-ADFSProperties -HttpsPort 444

Set-ADFSProperties -HttpPort 81
2. Configure the federation server proxy to use the nondefault port.
To do this, specify the nondefault port number by including it with the HttpsPort
and HttpPort options as part of the Set-ADFSProxyProperties cmdlet. For example,
to configure these ports, use the following commands in the Windows PowerShell
session on the federation server computer:
Set-ADFSProxyProperties -HttpsPort 444

Set-ADFSProxyProperties -HttpPort 81
７ Note
Endpoint URLs are not enabled by default for the federation server proxy
service. If you are configuring a new federation server installation, you must
enable federation server proxy service endpoints first. For example, it is
assumed that for all the endpoints that the example in this procedure refers to
you have enabled them for proxy by selecting them in the AD FS
Management snap-in and then selecting Enable on proxy.
3. Update the IIS installation at the federation server proxy so that Security Assertion
Markup Language (SAML) and WS-Trust endpoints are configured to reflect the
updated port number. To do this, you can use Notepad to modify the following in
the Web.config file, which is located at systemdrive%\inetpub\adfs\ls\ on the
federation server proxy computer. For example, assuming that you have a
federation server named sts1.contoso.com and the new port number is 444,
browse to and open the Web.config file in Notepad on the federation server proxy
computer, locate the following section, modify the port number as highlighted
below, and then save and exit Notepad.
<securityTokenService
samlProtocolEndpoint="https://sts1.contoso.com:444/adfs/services/trust/
samlprotocol/proxycertificatetransport"

wsTrustEndpoint="https://sts1.contoso.com:444/adfs/services/trust/proxy
certificatetransport" />
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
netsh http add urlacl http://+:81/adfs/services/ user="NT

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
Article • 08/15/2023
You can use the following procedure to verify that the federation server proxy can
communicate with the Federation Service in Active Directory Federation Services
(AD FS). You run this procedure after you run the AD FS Federation Server Proxy
Configuration Wizard to configure the computer to run in the federation server proxy
role. For more information about how to run this wizard, see Configure a Computer for
the Federation Server Proxy Role.
） Important
The result of this test is the successful generation of a specific event in Event Viewer
on the federation server proxy computer.

To verify that a federation server proxy is operational

1. Log on to the federation server proxy as an administrator.
2. On the Start screen, typeEvent Viewer, and then press ENTER.

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
Article • 08/15/2023
AD FS includes its own dedicated performance counters to help you monitor the
performance of both federation servers and federation server proxy computers. To use
Performance Monitor to monitor the performance of your AD FS servers, it's useful to
create a new data collector set and add the AD FS counters to that view. The following
procedure describes how to configure performance monitoring for AD FS.
To configure performance monitoring for AD FS using Performance

Monitor
1. On the Start screen, type Performance Monitor, and then press ENTER.
2. In the console tree, expand Data Collector Sets, right-click User Defined, point to
New, and then click Data Collector Set.
The Create New Data Collector Set Wizard appears.
3. In Create New Data Collector Set, for Name type a name for the new data
collector set (such as "AD FS performance"), click Create manually (Advanced), and
then click Next.
4. For the type of data to include, verify that Create data logs is selected, and then
click the check boxes for the following data types: Performance counter, Event
trace data, System configuration information.
5. For performance counters, expand AD FS in the Available counters list, and then
click Add.
The AD FS performance counters should appear in the Added counters list.
6. When you are prompted to add event trace providers, click Add, select AD FS
Eventing and AD FS Tracing from the list of providers.
7. When you are prompted to add registry keys to monitor, click Next.
8. When you are prompted to specify the location to save the performance data, you
can accept the default location (%systemdrive%\PerfLogs\Admin\
<data_collector_set>, and then click Next.
9. When you are prompted to create the data collector set, select Save and close,
and then click Finish.
The new data collector set appears in the console tree under the User Defined
node.
10. Use the following steps to work with the AD FS performance counters:
To begin performance monitoring using AD FS-related counters, right-click

the data collector set that you added (such as "AD FS performance"), and
then click Start.
To create a report to view the performance monitoring results, right-click the

data collector set that you added (such as "AD FS performance"), and then
click Latest Report.
To end a capture of performance data so that you can view the latest report,
right-click the data collector set that you added (such as "AD FS
performance"), and then click Stop.
The latest report is added and numbered automatically (starting at 000001) under
the Report\User Defined\<data_collector_set> node in the console tree.
AD FS performance counters
The following table lists the AD FS performance counters and describes how they are
useful for monitoring activity that relates to either a federation server or federation
server proxy.
Counter Description Can be used

on:
Token Requests Monitors the number of token requests sent to the Federation
federation server including SSOAuth token requests. Servers
Token Requests/sec Monitors the number of token requests sent to the Federation
federation server including SSOAuth token requests Servers
per second.
Federation Metadata Monitors the number of incoming federation Federation

Requests metadata requests sent to the federation server. Servers
Federation Metadata Monitors the number of incoming federation Federation

Requests/sec metadata requests per second that are sent to the Servers
federation server.
Artifact Resolution Monitors the number of incoming federation Federation

Requests metadata requests per second that are sent to the Servers
federation server.
Counter Description Can be used
on:
Artifact Resolution Monitors the number of requests to the artifact Federation

Requests/sec resolution endpoint per second that are sent to the Servers
federation server.
Proxy Requests Monitors the number of incoming requests sent to the Federation
federation server proxy. Server Proxies
Proxy Requests/sec Monitors the number of incoming requests per Federation

second that are sent to the federation server proxy. Server Proxies
Proxy MEX Requests Monitors the number of incoming WS-Metadata Federation

Exchange (MEX) requests that are sent to the Server Proxies
federation server proxy.
Proxy MEX Monitors the number of incoming MEX requests per Federation
Requests/sec second that are sent to the federation server proxy. Server Proxies
Article • 08/15/2023
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 .
AD FS 1.x Federation Service Equivalent AD FS Federation Service in Windows Server

setting 2012 setting
Account Partner Claims provider trust
Resource Partner Relying party trust
Application Relying party trust

AD FS 1.x Federation Service Equivalent AD FS Federation Service in Windows Server
setting 2012 setting
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
Article • 08/15/2023
Checklist: Configuring AD FS to consume

claims from AD FS 1.x
This checklist includes the tasks that are necessary for configuring your Active Directory
Federation Services (AD FS) Federation Service in Windows Server 2012 to consume
claims that are sent by an AD FS 1.x Federation Service.
７ Note
Checklist: Configuring AD FS to consume claims from AD FS 1.x
Task Reference
Plan for interoperability between AD FS in Windows Server 2012 and Planning for
previous versions of AD FS, and learn more about the Name ID claim type. Interoperability with
AD FS 1.x
Before you can interoperate with a previous version of AD FS, you must Create a Claims
first create a claims provider trust in the AD FS Federation Service. Note: Provider Trust
You cannot create a trust with an AD FS 1.x Federation Service by using Manually
federation metadata.
When you set up the trust using the procedure in the link to the right, you
must do the following in the Add Claims Provider Trust Wizard to set up
this trust to interoperate with an AD FS 1.x Federation Service:
1. On the Select Data Source page, select Enter data about the relying
party trust manually.
2. On the Choose Profile page, select AD FS 1.0 and 1.1 profile.
3. On the Configure URL page, under WS-Federation Passive URL, type
the Federation Service endpoint URL as defined in the AD FS 1.x
Federation Service of the partner.
4. On the Configure Identifiers page, under Claims provider trust
Task Reference
identifier, type the Federation Service URI as defined in the AD FS 1.x

Federation Service of the partner.
On the claims provider trust that you created earlier, you must create a Create a Rule to
claim rule that will take claims that are incoming from the AD FS 1.x Send an AD FS 1.x
Federation Service and pass through, filter, or transform them into a Compatible Claim
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
Contact the administrator of the AD FS 1.x Federation Service and have N/A
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
Article • 08/15/2023
Checklist: Configuring AD FS to send claims to

an AD FS 1.x Federation Service
Federation Services (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 Service
Task Reference
Plan for interoperability between AD FS in Windows Server 2012 and Planning for
previous versions of AD FS and learn more about the Name ID claim type. Interoperability
with AD FS 1.x
Before you can achieve interoperability with a previous version of AD FS, you Create a
must first create a relying party trust in the AD FS Federation Service to the Relying Party Trust
AD FS 1.x Federation Service. Note: You cannot create a trust with an Manually
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 Relying Party Trust Wizard to set up this
trust to interoperate with an AD FS 1.x Federation Service:
1. On the Select Data Source page, select Enter data about the relying party
trust manually.
3. On the Configure URL page, under WS-Federation Passive URL, type the
Federation Service endpoint URL as defined in the AD FS 1.x Federation
Service of the partner.
Task Reference
4. On the Configure Identifiers page, under Relying part trust identifier,

type the Federation Service URI as defined in the AD FS 1.x Federation
Service of the partner.
On the relying party trust that you created earlier, you must create claim Create a Rule to
rules that will take incoming claims that were extracted from an attribute Send an AD FS 1.x
store and pass through, filter, or transform them into a Name ID claim type Compatible Claim
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 Service and have the N/A
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
Article • 08/15/2023
Checklist: Configuring AD FS to send claims to

an AD FS 1.x claims-aware Web agent
Federation Services (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
Task Reference
Plan for interoperability between AD FS in Windows Server 2012 and previous Planning for
versions of AD FS and learn more about the Name ID claim type. Interoperability
with AD FS 1.x
If you have not already done so, use the link on the right to first create a relying party Checklist:
trust between the AD FS Federation Service in Windows Server 2012 and the Configuring
AD FS 1.x Federation Service. AD FS to Send
Claims to an
AD FS 1.x
Federation
Service
Before you can achieve interoperation with an application that is hosted by the Create a
AD FS 1.x claims-aware Web agent, you must first create a relying party trust in the Relying Party
AD FS Federation Service in Windows Server 2012 to the AD FS 1. x claims-aware Trust Manually
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
Task Reference
Service\Trust Policy\My Organization\Application). This relying party trust is

necessary because AD FS does not have an equivalent Application node in its own
snap-in. However, it still must have a secure channel to the application.
When you set up the trust using the procedure in the link to the right, you must do
the following in the Add Relying Party Trust Wizard to set up this trust to interoperate
with an AD FS 1.x claims-aware Web agent:
1. On the Select Data Source page, select Enter data about the relying party trust
manually.
3. On the Configure URL page, under WS-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 part trust identifier, type the
Application URL as defined in the AD FS 1.x claims-aware Web agent
Contact the administrator of the Web server running the AD FS 1.x claims-aware Web N/A
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
On the relying party trust that you created earlier, you have to create claim rules that Create a
will take incoming claims that were extracted from an attribute store and pass Rule to Send
through, filter, or transform them into a Name ID claim type that can be understood an AD FS 1.x
and consumed by the AD FS 1.x claims-aware Web agent. Note: Before you create Compatible
this rule, make sure that the claim rule set where you are creating this rule has a rule Claim
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.
Article • 08/15/2023

manually


go to step 8:
Rules dialog box.
７ Note


then click Next.
click Next.
See Also
AD FS Operations
Article • 08/15/2023



and click Next.
information.

federation metadata
７ Note

information.
See Also
AD FS Operations
Create a Rule to Send an AD FS 1.x
Compatible Claim
Article • 08/15/2023
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.
Incoming Claim rule template on a Relying

UPN
E-Mail
Common Name

Incoming Claim rule template on a Claims

UPN
E-Mail
Common Name

2016

UPN
E-Mail
Common Name


2016

UPN
E-Mail
Common Name


Incoming Claim rule template on Windows
Server 2012 R2


UPN
E-Mail
Common Name

claim using the Transform an Incoming Claim
rule template in Windows Server 2012 R2


UPN
E-Mail
Common Name

The Role of Claims

What is hybrid identity with Azure
Active Directory?
Article • 05/04/2023
Today, businesses, and corporations are becoming more and more a mixture of on-
premises and cloud applications. Users require access to those applications both on-
premises and in the cloud. Managing users both on-premises and in the cloud poses
challenging scenarios.
Microsoft’s identity solutions span on-premises and cloud-based capabilities. These

solutions create a common user identity for authentication and authorization to all
resources, regardless of location. We call this hybrid identity.

Hybrid identity is accomplished through provisioning and synchronization. Provisioning

is the process of creating an object based on certain conditions, keeping the object up
to date and deleting the object when conditions are no longer met. Synchronization is
responsible for making sure identity information for your on-premises users and groups
is matching the cloud.
For more information see What is provisioning? and What is inter-directory

provisioning?.
License requirements for using Azure AD

Connect
Using this feature is free and included in your Azure subscription.
Next Steps
What is Azure AD Connect and Connect Health?
What is password hash synchronization (PHS)?
What is pass-through authentication (PTA)?
What is federation?
What is single-sign on?
Migrate Active Directory Federation
Services Role Services to Windows
Server 2012 R2
Article • 08/15/2023
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
Recreating the original AD FS configuration and restoring the remaining AD FS

service settings on this server, which is now running the AD FS server role that is
installed with Windows Server 2012 R2.
This guide does not include instructions to migrate a server that is running
multiple roles. If your server is running multiple roles, we recommend that you
design a custom migration process specific to your server environment, based on
the information provided in other role migration guides. Migration guides for
additional roles are available on the Windows Server Migration Portal.
Supported operating systems

Destination server operating system:
Windows Server 2012 R2 (Server Core and full installation options)
Destination server processor:

x64-based
Source server processor Source server operating system
x86- or x64-based Windows Server 2008, both full and Server Core installation options
x64-based Windows Server 2008 R2
x64-based Server Core installation option of Windows Server 2008 R2
x64-based Server Core and full installation options of Windows Server 2012
７ Note
The versions of operating systems that are listed in the preceding table are
the oldest combinations of operating systems and service packs that are
supported.
The Foundation, Standard, Enterprise, and Datacenter editions of the
Windows Server operating system are supported as the source or the
destination server.
Migrations between physical operating systems and virtual operating
systems are supported.
Supported AD FS role services and features

The following table describes the migration scenarios of the AD FS role services and
their respective settings that are described in this guide.
From To AD FS installed with Windows Server

2012 R2
AD FS 2.0 federation server installed on Windows Migration on the same server is supported.
Server 2008 or Windows Server 2008 R2 For more information, see:
Preparing to Migrate the AD FS Federation
Server
Migrating the AD FS Federation Server
AD FS federation server installed on Windows Server Migration on the same server is supported.
2012 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
Prepare to Migrate the AD FS 2.0
Federation Server to AD FS on Windows
Server 2012 R2
Article • 08/15/2023
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 Windows Server 2012 R2.
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
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
Article • 08/15/2023
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:
PowerShell
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:
PowerShell
Get-ADFSProperties | Out-File “.\properties.txt”`.
The output file will contain the following important configuration values:
Federation Service Property name as reported Federation Service Property name in AD FS

by Get-ADFSProperties management console
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
Service in the Services console and manually record this value.
７ Note
For a stand-alone federation service, the built-in NETWORK SERVICE account is

used. In this case, you do not need to have a password.
5. Export the list of enabled AD FS endpoints to a file.
To do this, open Windows PowerShell and run the following command:
PowerShell
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:
PowerShell
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/server_support/adfs folder of the Windows Server 2012 R2 installation CD:
export-federationconfiguration.ps1 .
） Important
The export script takes the following parameters:
Export-FederationConfiguration.ps1 -Path <string> [-ComputerName

<string>] [-Credential <pscredential>] [-Force] [-CertificatePassword
<securestring>]
<securestring>] [-RelyingPartyTrustIdentifier <string[]>] [-
ClaimsProviderTrustIdentifier <string[]>]
<securestring>] [-RelyingPartyTrustName <string[]>] [-
ClaimsProviderTrustName <string[]>]
-RelyingPartyTrustIdentifier <string[]> - the cmdlet only exports relying

party trusts whose identifiers are specified in the string array. The default is to
export NONE of the relying party trusts. If none of RelyingPartyTrustIdentifier,
ClaimsProviderTrustIdentifier, RelyingPartyTrustName, and
ClaimsProviderTrustName is specified, the script will export all relying party
trusts and claims provider trusts.
-ClaimsProviderTrustIdentifier <string[]> - the cmdlet only exports claims
provider trusts whose identifiers are specified in the string array. The default is
to export NONE of the claims provider trusts.
-RelyingPartyTrustName <string[]> - the cmdlet only exports relying party

trusts whose names are specified in the string array. The default is to export
NONE of the relying party trusts.
-ClaimsProviderTrustName <string[]> - the cmdlet only exports claims

provider trusts whose names are specified in the string array. The default is to
export NONE of the claims provider trusts.
-Path <string> - the path to a folder that will contain the exported files.
-ComputerName <string> - specifies the STS server host name. The default is
the local computer. If you are migrating AD FS 2.0 or AD FS in Windows
Server 2012 to AD FS in Windows Server 2012 R2, this is the host name of the
legacy AD FS server.
-Credential <PSCredential> - specifies a user account that has permission to

perform this action. The default is the current user.
-Force – specifies to not prompt for user confirmation.
-CertificatePassword <SecureString> - specifies a password for exporting AD

FS certificates' private keys. If not specified, the script will prompt for a
password if an AD FS certificate with private key needs to be exported.
Inputs: None
Outputs: string - this cmdlet returns the export folder path. You can pipe the
returned object to Import-FederationConfiguration.
To back up custom attribute stores

1. You must manually export all custom attribute stores that you want to keep in your
new AD FS farm in Windows Server 2012 R2.
７ 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:
PowerShell
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 Certificates. Verify the service

communications, token-encryption/decryption, and token-signing certificates by
checking each against the values you exported into the certificates.txt file while
preparing for the migration.
To change the token-decrypting or token-signing certificates from the default self-

signed certificates to external certificates, you must first disable the automatic certificate
rollover feature that is enabled by default. To do this, you can use the following
Windows PowerShell command:
PowerShell
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:
PowerShell
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>]
CertificatePassword <securestring>] [-RelyingPartyTrustIdentifier <string[]>] [-
ClaimsProviderTrustIdentifier <string[]>
CertificatePassword <securestring>] [-RelyingPartyTrustName <string[]>] [-
ClaimsProviderTrustName <string[]>]
-RelyingPartyTrustIdentifier <string[]> - the cmdlet only imports relying party

trusts whose identifiers are specified in the string array. The default is to import
NONE of the relying party trusts. If none of RelyingPartyTrustIdentifier,
ClaimsProviderTrustIdentifier, RelyingPartyTrustName, and
ClaimsProviderTrustName is specified, the script will import all relying party trusts
and claims provider trusts.
-ClaimsProviderTrustIdentifier <string[]> - the cmdlet only imports claims

provider trusts whose identifiers are specified in the string array. The default is to
import NONE of the claims provider trusts.
-RelyingPartyTrustName <string[]> - the cmdlet only imports relying party trusts

whose names are specified in the string array. The default is to import NONE of the
relying party trusts.
-ClaimsProviderTrustName <string[]> - the cmdlet only imports claims provider

trusts whose names are specified in the string array. The default is to import NONE
of the claims provider trusts.
-Path <string> - the path to a folder that contains the configuration files to be
imported.
-LogPath <string> - the path to a folder that will contain the import log file. A log
file named “import.log” will be created in this folder.
-ComputerName <string> - specifies host name of the STS server. The default is
the local computer. If you are migrating AD FS 2.0 or AD FS in Windows Server
2012 to AD FS in Windows Server 2012 R2, this parameter should be set to the
hostname of the legacy AD FS server.
-Credential <PSCredential>- specifies a user account that has permission to

perform this action. The default is the current user.
-Force – specifies to not prompt for user confirmation.
-CertificatePassword <SecureString> - specifies a password for importing AD FS

certificates' private keys. If not specified, the script will prompt for a password if an
AD FS certificate with private key needs to be imported.
Inputs: string - this command takes the import folder path as input. You can pipe
Export-FederationConfiguration to this command.
Outputs: None.
Any trailing spaces in the WSFedEndpoint property of a relying party trust may cause
the import script to error. In this case, manually remove the spaces from the file prior to
import. For example, these entries cause errors:
<URI N="WSFedEndpoint">https://127.0.0.1:444 /</URI>
<URI N="WSFedEndpoint">https://myapp.cloudapp.net:83 /</URI>
They must be edited to:
<URI N="WSFedEndpoint">https://127.0.0.1:444/</URI>
<URI N="WSFedEndpoint">https://myapp.cloudapp.net:83/</URI>
） Important
If you have any custom claim rules (rules other than the AD FS default rules) on the
Active Directory claims provider trust in the source system, these will not be
migrated by the scripts. This is because Windows Server 2012 R2 has new defaults.
Any custom rules must be merged by adding them manually to the Active Directory
claims provider trust in the new Windows Server 2012 R2 farm.
1. Configure all custom AD FS endpoint settings. In the AD FS Management console,

select Endpoints. Check the enabled AD FS endpoints against the list of enabled
AD FS endpoints that you exported to a file while preparing for the AD FS
migration.
- And -
Configure any custom claim descriptions. In the AD FS Management console,

select Claim Descriptions. Check the list of AD FS claim descriptions against the list
of claim descriptions that you exported to a file while preparing for the AD FS
migration. Add any custom claim descriptions included in your file but not
included in the default list in AD FS. Note that Claim identifier in the management
console maps to the ClaimType in the file.
2. Install and configure all backed up custom attribute stores. As an administrator,

ensure any custom attribute store binaries are upgrade to .NET Framework 4.0 or
higher before updating the AD FS configuration to point to them.
3. Configure service properties that map to the legacy web.config file parameters.
If useRelayStateForIdpInitiatedSignOn was added to the web.config file in

your AD FS 2.0 or AD FS in Windows Server 2012 farm, then you must
configure the following service properties in your AD FS in Windows Server
2012 R2 farm:
AD FS in Windows Server 2012 R2 includes a
%systemroot%\ADFS\Microsoft.IdentityServer.Servicehost.exe.config
file. Create an element with the same syntax as the web.config file
element: <useRelayStateForIdpInitiatedSignOn enabled="true" /> . Include
this element as part of <microsoft.identityserver.web> section of the
Microsoft.IdentityServer.Servicehost.exe.config file.
If <persistIdentityProviderInformation enabled="true|false"
lifetimeInDays="90" enablewhrPersistence=”true|false” /> was added to
the web.config file in your AD FS 2.0 or AD FS in Windows Server 2012 farm,
then you must configure the following service properties in your AD FS in
Windows Server 2012 R2 farm:
a. In AD FS in Windows Server 2012 R2, run the following Windows
PowerShell command: Set-AdfsWebConfig –HRDCookieEnabled –
HRDCookieLifetime .
If <singleSignOn enabled="true|false" /> was added to the web.config file

in your AD FS 2.0 or AD FS in Windows Server 2012 farm, you do not need to
set any additional service properties in your AD FS in Windows Server 2012
R2 farm. Single sign-on is enabled by default in AD FS in Windows Server
2012 R2 farm.
If localAuthenticationTypes settings were added to the web.config file in your

AD FS 2.0 or AD FS in Windows Server 2012 farm, then you must configure
the following service properties in your AD FS in Windows Server 2012 R2
farm:
Integrated, Forms, TlsClient, Basic Transform list into equivalent AD FS in
Windows Server 2012 R2 has global authentication policy settings to
support both federation service and proxy authentication types. These
settings can be configured in the AD FS in Management snap-in under the
Authentication Policies.
After you import the original configuration data, you can customize the AD FS sign
in pages as needed. For more information, see Customizing the AD FS Sign-in
Pages.
Next Steps
Server Proxy Verifying the AD FS Migration to Windows Server 2012 R2
Migrate the Active Directory Federation
Services Proxy Server to Windows
Server 2012 R2
Article • 08/15/2023
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
） 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
Server Verifying the AD FS Migration to Windows Server 2012 R2
Verify the AD FS 2.0 migration to
Article • 08/15/2023
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.

the local 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
Server Migrating the AD FS Federation Server Proxy
Migrate Active Directory Federation
Services Role Services to Windows
Server 2012
Article • 08/15/2023
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

Supported migration scenarios

The migration instructions contains the following tasks:
Exporting the AD FS 2.0 configuration data from your server that is running
Performing an in-place upgrade of the operating system of this server from

Windows Server 2008 or Windows Server 2008 R2 to Windows Server 2012.
Recreating the original AD FS configuration and restoring the remaining AD FS

service settings on this server, which is now running the AD FS server role that is
installed with Windows Server 2012.
This guide does not include instructions to migrate a server that is running
multiple roles. If your server is running multiple roles, we recommend that you
design a custom migration process specific to your server environment, based on
the information provided in other role migration guides. Migration guides for
additional roles are available on the Windows Server Migration Portal.
Supported operating systems

Destination server operating system:
Windows Server 2012 or Windows Server 2008 R2 (Server Core and full installation
options)
Destination server processor:
x64-based
Source server processor Source server operating system
x86- or x64-based Windows Server 2003 with Service Pack 2
x86- or x64-based Windows Server 2003 R2
x86- or x64-based Windows Server 2008, both full and Server Core installation options
x64-based Windows Server 2008 R2
x64-based Server Core installation option of Windows Server 2008 R2
x64-based Server Core and full installation options of Windows Server 2012
７ Note
The versions of operating systems that are listed in the preceding table are
the oldest combinations of operating systems and service packs that are
supported.
The Foundation, Standard, Enterprise, and Datacenter editions of the
Windows Server operating system are supported as the source or the
destination server.
Migrations between physical operating systems and virtual operating
systems are supported.
Supported AD FS role services and features

The following table describes the migration scenarios of the AD FS role services and
their respective settings that are described in this guide.
From To AD FS installed with Windows Server 2012
AD FS 1.0 federation server Migration is not supported

installed with Windows Server
2003 R2

proxy installed with Windows
Server 2003 R2
AD FS 1.0 Windows token- Migration is not supported

based agent installed with
AD FS 1.0 claims-aware agent Migration is not supported

2003 R2)

2008 or Windows Server 2008
R2

proxy installed with Windows
Server 2008 or Windows
Server 2008 R2
AD FS 1.1 Windows token- Migration on the same server is supported, but the migrated AD
based agent installed with FS Windows token-based agent will function only with an AD FS
Windows Server 2008 or 1.1 federation service installed with Windows Server 2008 or
Windows Server 2008 R2 Windows Server 2008 R2. For more information, see:
Migrate the AD FS 1.1 Web Agents
AD FS 1.1 claims-aware agent Migration on the same server is supported. The migrated AD FS
installed with Windows Server 1.1 claims-aware web agent will function with the following:
2008 or Windows Server 2008 AD FS 1.1 federation service installed with Windows Server 2008
R2) or Windows Server 2008 R2
AD FS 2.0 federation service installed on Windows Server 2008

or Windows Server 2008 R2
AD FS federation service installed with Windows Server 2012
For more information, see:
AD FS 2.0 federation server Migration on the same server is supported. For more
installed on Windows Server information, see:
2008 or Windows Server 2008 Prepare to Migrate the AD FS 2.0 Federation Server
R2
Migrate the AD FS 2.0 Federation Server
AD FS 2.0 federation server Migration on the same server is supported. For more
proxy installed on Windows information see:
Server 2008 or Windows Prepare to Migrate the AD FS 2.0 Federation Server Proxy
Server 2008 R2
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
Federation Server
Article • 08/15/2023
This document is the starting point for preparing to migrate your AD FS 2.0 Federation
Server to Windows Server 2012. Choose the one that best fits your migration scenario:
Prepare to migrate a stand-alone AD FS federation server or a single-node AD FS

farm
Prepare to migrate a WID farm
Prepare to migrate a SQL Server farm
Next Steps
Prepare to migrate a stand-alone AD FS
federation server or a single-node AD
FS farm
Article • 08/15/2023
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:
by Get-ADFSProperties management console
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" .
5. Record the identity of the AD FS 2.0 federation service account and the password
of this account.
Service in the Services console and manually record this value.
７ Note
For a stand-alone federation service, the built-in NETWORK SERVICE account is

used. In this case, you do not need to have a password.
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
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
Prepare to migrate an AD FS 2.0 WID
farm
Article • 08/15/2023
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


Information Services (IIS) management console, select Default Web Site in the left
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
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.
of this account.
Service in the Services console and manually record the value.



Next Steps
Prepare to migrate a SQL Server farm
Article • 08/15/2023
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.


Information Services (IIS) management console, select Default Web Site in the left
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
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 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.
７ 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.
backup server.
７ Note
Record the SQL Server connection string after “policystore connectionstring=” in

the following file: %programfiles%\Active Directory Federation Services
2.0\Microsoft.IdentityServer.Servicehost.exe.config . You need this string when
you restore the original AD FS configuration on the federation server.
of this account.
Service in the Services console and manually record the value.


Next Steps
Federation Server Proxy
Article • 08/15/2023
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
Article • 08/15/2023
This document is the starting point for migrating your AD FS 2.0 Federation Server to
Windows Server 2012. Choose the one that best fits your migration scenario:
Migrate a stand-alone AD FS federation server or a single-node AD FS farm
Migrate a WID farm
Migrate a SQL Server farm
Next Steps
Migrate a stand-alone AD FS federation
server or a single-node AD FS farm
Article • 08/15/2023
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 Server Configuration Wizard to create a new federation

server. For more information, see Create the First Federation Server in a Federation
Server Farm.
As you go through the wizard, use the information you gathered while preparing to
migrate your AD FS federation server as follows:
Federation Server Use the following value
input option
SSL Certificate on the Select the SSL certificate whose subject name and thumbprint you
Specify the Federation recorded while preparing for the AD FS federation server migration.
Service Name page
Service account and Enter the service account information that you recorded while
Password on the Specify a preparing for the AD FS federation server migration. Note: If you
Service Account page 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
Data Source is the data source value in the policy store connection string value in the
following file: %programfiles%\Active Directory Federation Services

2.0\Microsoft.IdentityServer.Servicehost.exe.config .
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 Service and click Edit Federation
Service…. Verify the federation service settings by checking each of the values
against the values you exported into the properties.txt file while preparing for
the migration:

by Get-ADFSProperties Management console
In the AD FS management console, select Certificates. Verify the service

communications, token-decrypting, and token-signing certificates by checking
each against the values you exported into the certificates.txt file while preparing
for the migration.
To change the token-decrypting or token-signing certificates from the default self-

signed certificates to external certificates, you must first disable the automatic certificate
rollover feature that is enabled by default. To do this, you can use the following
Windows PowerShell command: PSH: Set-ADFSProperties –AutoCertificateRollover
$false .
In the AD FS Management console, select Endpoints. Check the enabled AD FS

endpoints against the list of enabled AD FS endpoints that you exported to a file
while preparing for the AD FS migration.
In the AD FS Management console, select Claim Descriptions. Check the list of AD

FS claim descriptions against the list of claim descriptions that you exported to a
file while preparing for the AD FS migration. Add any custom claim descriptions
included in your file but not included in the default list in AD FS. Note that Claim
identifier in the management console maps to the ClaimType in the file. For more
information on adding claim descriptions, see Add a Claim Description. For more
information, see the “Step 1 - Export Service Settings” section in Prepare to
Migrate the AD FS 2.0 Federation Server.
In the AD FS Management console, select Claims Provider Trusts. You must

recreate each Claims Provider trust manually using the Add Claims Provider Trust
Wizard. Use the list of claims provider trusts that you exported and recorded while
preparing for the AD FS migration. You can disregard the claims provider trust with
Identifier “AD AUTHORITY” in the file because this is the “Active Directory” claims
provider trust that is part of the default AD FS configuration. However, check for
any custom claim rules you may have added to the Active Directory trust prior to
the migration. For more information on creating claims provider trusts, see Create
a Claims Provider Trust Using Federation Metadata or Create a Claims Provider
Trust Manually.
In the AD FS Management console, select Relying Party Trusts. You must recreate
each Relying Party trust manually using the Add Relying Party Trust Wizard. Use
the list of relying party trusts that you exported and recorded while preparing for
the AD FS migration. For more information on creating relying party trusts, see
Create a Relying Party Trust Using Federation Metadata or Create a Relying Party
Trust Manually.
Next Steps
-
Migrate an AD FS 2.0 WID farm
Article • 08/15/2023
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

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 Server
Configuration Wizard to add a federation server to a WID farm. For more information,
see Add a Federation Server to a Federation Server Farm.
７ Note
When you reach the Specify the Primary Federation Server and a Service Account
page in the AD FS Federation Server Configuration Wizard, enter the name of the
primary federation server of the WID farm and be sure to enter the service account
information that you recorded while preparing for the AD FS migration. For more
information, see Prepare to Migrate the AD FS 2.0 Federation Server.
When you reach the Specify the Federation Service Name page, be sure to select
the same SSL certificate you recorded in the “Prepare to migrate a WID farm” in
Prepare to Migrate the AD FS 2.0 Federation Server.
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
） Important
As the result of upgrading the operating system, the AD FS configuration on this

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 Server
Configuration Wizard to add a federation server to a WID farm. For more information,
see Add a Federation Server to a Federation Server Farm.
７ Note
When you reach the Specify the Primary Federation server and a Service Account
page in the AD FS Federation Server Configuration Wizard, enter the service
account information that you recorded while preparing for the AD FS migration. For
more information, see Prepare to Migrate the AD FS 2.0 Federation Server.
When you reach the Specify the Federation Service Name page, be sure to select
the same SSL certificate you recorded in Prepare to Migrate the AD FS 2.0
Federation Server.
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
Migrate an AD FS 2.0 SQL farm
Article • 08/15/2023
This document provides detailed information on migrating an AD FS 2.0 SQL farm to

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
） Important

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 Source is the data source value in the policy store
connection string value in the following file: %programfiles%\Active Directory

Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config .
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
proxy
Article • 08/15/2023
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 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 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

Server Proxy Configuration Wizard. For more information, see Configure a
Computer for the Federation Server Proxy Role. As you execute the wizard, use the
information you gathered in Prepare to Migrate the AD FS 2.0 Federation Server
Proxy as follows:
Federation Server Proxy Wizard Use the following value

input option
Federation Service Name Enter the BaseHostName value from proxyproperties.txt file
Federation Server Proxy Wizard Use the following value
input option
Use an HTTP proxy server when Check this box if your proxyproperties.txt file contains a value
sending requests to this for the ForwardProxyUrl property
Federation Service check box
HTTP proxy server address Enter the ForwardProxyUrl value from proxyproperties.txt file
Credential prompt Enter the credentials of an account that is either an

administrator of the AD FS federation server or the service
account under which the AD FS federation service runs.
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
Migrate the AD FS web agent
Article • 08/15/2023
To migrate the AD FS 1.1 Windows token-based agent or the AD FS 1.1 claims-aware

agent that is installed with Windows Server 2008 R2 or Windows Server 2008 to
Windows Server 2012, perform an in-place upgrade of the operating system of the
computer that hosts either agent to Windows Server 2012. For more information, see
Installing Windows Server 2012. No further configuration is required.
） Important
The migrated AD FS 1.1 Windows token-based agent functions only with an AD FS

1.1 federation service that is installed with Windows Server 2008 R2 or Windows
Server 2008. For more information, see Interoperating with AD FS 1.x.
The migrated AD FS 1.1 claims-aware web agent functions with the following:
AD FS 1.1 federation service installed with Windows Server 2008 R2 or

Windows Server 2008
AD FS 2.0 federation service installed on Windows Server 2008 R2 or
Windows Server 2008
AD FS federation service installed with Windows Server 2012
For more information, see Interoperating with AD FS 1.x.
Next Steps
AD FS OpenID Connect/OAuth concepts
Article • 06/05/2023
Applies to Active Directory Federation Services (AD FS) 2016 and later
Modern authentication actors

Actor Description
End user The security principal (users, applications, services, and groups) who accesses
the resource.
Client Your web application, identified by its client ID. The client is usually the party
that the end user interacts with, and the client requests tokens from the
authorization server.
Authorization Your AD FS server. It's responsible for verifying the identity of security
server/Identity principals that exist in an organization's directory. It issues security tokens
provider (IdP) (bearer access token, ID token, and refresh token) upon successful
authentication of those security principals.
Resource Where the resource or data resides. It trusts the authorization server to
server/Resource securely authenticate and authorize the client and uses bearer access tokens to
provider/Relying ensure that access to a resource can be granted.
party
The following diagram provides the most basic relationship between the actors:
Application types
Application Description Role
Type
Native Sometimes called a public client. It's Requests tokens from the
application intended to be a client app that runs on a authorization server (AD FS) for user
pc or device and with which the user access to resources. Sends HTTP
interacts. requests to protected resources, by
using the tokens as HTTP headers.
Server A web application that runs on a server Requests tokens from the
application and is accessible to users via a browser. authorization server (AD FS) for user
(web app) Because it's capable of maintaining its own access to resources. Before it
client secret or credential, it's sometimes requests a token, client (web app)
called a confidential client. needs to authenticate by using its
secret.
web API The end resource that the user accesses. Consumes bearer access tokens
Think of it as the new representation of obtained by the clients.
relying parties.
Application group
You must associate an application group with every native or web app OAuth client or
web API resource that's configured with AD FS. Configure the clients in an application
group to access the resources in the same group. An application group can have
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 contain information about the user so that client can
use it.
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: Issued by AD FS for the client to use when it needs to refresh the
id_token and access_token. The token is opaque to the client and only consumed
by AD FS.
Refresh token lifetimes

Simple logon, no KMSI, device not registered: AD FS applies SsoLifetime and
DeviceUsageWindowInDays . The first refresh token has
lifetime=DeviceUsageWindowInDays or SsoLifetime , based on which field is lower
but no further refresh tokens are issued.

KMSI logon, EnableKmsi=true in AD FS conf and kmsi=true passed as parameter:
AD FS applies KmsiLifetimeMins with DeviceUsageWindowInDays . The first refresh
token has lifetime=DeviceUsageWindowInDays and each subsequent
grant_type=refresh_token request gets a new refresh token. This process happens
only with native clients or confidential client plus device authentication.

Registered devices, device auth: AD FS uses PersistentSsoLifetimeMins and
DeviceUsageWindowInDays similar to KMSI. Both native and confidential clients
should get new refresh tokens, based on device authentication.
To learn more, see AD FS single sign-on documentation.
Scopes
When you register a resource in AD FS, you can configure scopes to let AD FS perform
specific actions. Along with configuring the scope, you must send the scope value in the
request for AD FS to perform the action. For example, an administrator configures the
scope as openid during resource registration and the application (client) must send the
scope = openid in the authentication request for AD FS to issue the ID Token. The
following are details on the available scopes in AD FS:
aza - If you use OAuth 2.0 protocol extensions for broker clients and if the scope
parameter contains the scope aza , the server issues a new primary refresh token. It
sets the token in the refresh_token field of the response and sets the
refresh_token_expires_in field to the lifetime of the new primary refresh token if
one is enforced.
openid - Lets the application request use of the openid connect authentication
protocol.
logon_cert - Lets an application request sign-in certificates that you can use to
interactively log on 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. For more information, see MS-OAPX:
OAuth 2.0 protocol extensions.
user_impersonation - Requests an on-behalf-of access token from AD FS. For
details on how to use this scope, see Build a multi-tiered application using On-
Behalf-Of (OBO) using OAuth with AD FS 2016.
allatclaims – Lets the application request the claims in the access token to be
added to the ID token as well.

vpn_cert - Lets an application request VPN certificates, which establish VPN
connections by using EAP-TLS authentication. This feature isn't supported

anymore.
email - Lets the application request an email claim for the signed-in user.
profile - Lets the application request profile-related claims for the signed-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

A diagram of the high-level flow follows.

1. AD FS receives authentication request from the client.
2. AD FS validates the client ID in the authentication 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 authentication
request. AD FS also validates the redirect URI of the Client.
3. AD FS identifies the resource that the client wants to access through the resource
parameter that's passed in the authentication request. If you use the MSAL client
library, the resource parameter isn't sent. Instead, the resource URL is sent as a part
of the scope parameter: scope = [resource url]/[scope values, for example, openid].
If the resource isn't passed using the resource or scope parameters, AD FS uses a
default resource urn:microsoft:userinfo whose policies, such as, MFA, issuance, or
authorization policy, can't be configured.
4. Next AD FS validates whether the client has permissions to access the resource. AD
FS also validates whether the scopes passed in the authentication request match
the scopes configured while registering the resource. If the client doesn't have the
permissions, or the right scopes aren't sent in the authentication request, the
authentication flow terminates.
5. Once permissions and scopes validate, AD FS authenticates the user by using the
configured authentication method.
6. If another authentication method is required as per the resource policy or the
global authentication policy, AD FS triggers the extra authentication.
7. AD FS uses Azure AD Multi-Factor Authentication or third-party Multi-Factor

Authentication to do the authentication.
8. Once the user is authenticated, AD FS applies the claim rules. Claim rules
determine the claims sent to the resource as a part of the security tokens. AD FS
also applies the access control polices that confirm the user meets the required
conditions to access the resource.
9. Next, AD FS generates the access and refreshes the tokens. AD FS also generates
the ID token.
10. AD FS receives the authentication request.
11. If you include the scope = allatclaims in the authentication request, it customizes
the ID token 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 and includes the tokens. The ID token response is only included in the
response if the authentication request includes scope = openid . The client can
always get the ID token after authentication by using the token endpoint.
Types of libraries
Use two types of libraries with AD FS:
Client libraries: Native clients and server apps use client libraries to get access
tokens for calling a resource such as a web API. Microsoft Authentication Library
(MSAL) is the latest and recommended client library when you use AD FS 2019.
Server middleware libraries: Web apps use server middleware libraries for user
sign-in. Web APIs use server middleware libraries to validate tokens sent by native
clients or by other servers. Open Web Interface for .NET (OWIN) is the
recommended middleware library.
Customize ID token (extra claims in ID token)

In certain scenarios, it's possible that the web app client needs extra claims in an ID
token to help in the functionality. Set up extra claims in an ID token by using one of the
following options:
Option 1: Use this option when you have a public client and the web app doesn't have a
resource that it's trying to access. This option requires:
response_mode is set as form_post
Relying party identifier (web API identifier) is the same as the client identifier
Option 2: Use this option when the web app has a resource that it's trying to access and
needs to pass extra claims through the ID token. You can use both public and
confidential clients. This option requires:
response_mode is set as form_post
KB4019472 is installed on your AD FS servers
Scope allatclaims is assigned to the client – RP pair. You can assign the scope by
using the Grant-ADFSApplicationPermission . Use Set-AdfsApplicationPermission if
it's already been granted once. The PowerShell cmdlet is indicated in the following
example:
PowerShell
Grant-AdfsApplicationPermission -ClientRoleIdentifier
"https://my/privateclient" -ServerRoleIdentifier
"https://rp/fedpassive" -ScopeNames "allatclaims","openid"
To better understand how to configure a web app in AD FS to get a customized ID

token, see Custom ID tokens in AD FS 2016 or later.
Single log-out
Single log-out ends all client sessions that use the session ID. AD FS 2016 and later
supports single log-out for OpenID Connect/OAuth. For more information, see Single
log-out for OpenID Connect with AD FS.
AD FS endpoints
AD FS Endpoint Description
/authorize AD FS returns an authorization code that you can use to get the
access token.
/token AD FS returns an access token that you can use to access the
resource, as in, the web API.
/userinfo AD FS returns the subject claim.
/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- AD FS returns OAuth/OpenID Connect metadata.

configuration
AD FS OpenID Connect/OAuth flows
and Application Scenarios
Article • 08/15/2023
Applies to AD FS 2019 and later
Scenario Scenario OAuth 2.0 Client Type

walkthrough using Flow/Grant
samples
Single-page app Sample using MSAL 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
Web App calls Web API Sample using MSAL Authorization Code Confidential
Web API calls another web Sample using MSAL On-behalf-of Web app acts as
API on behalf of (OBO) the Confidential
user
Daemon App calls Web API Client credentials Confidential
Web App calls Web API Resource owner Public,

using user credentials password credentials Confidential
Browserless App calls Web Device code Public,

API Confidential
Implicit grant flow
７ Note
Microsoft highly recommends migrating to Azure AD instead of upgrading to a

newer AD FS version. For more information on implicit grant flow in Azure AD, see
Implicit grant flow in Microsoft identity platform.
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 the OAuth 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 flow allows the app to
sign in the user, maintain session, and get tokens to other web APIs within the client
JavaScript code. There are a few important security considerations to take into account
when using the implicit flow specifically around client .
If you want to use the implicit flow and AD FS to add authentication to your JavaScript
app, follow the general steps in the following section.
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 an OpenID Connect authentication
request and get id_token and 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
Parameter Required/Optional Description
client_id required The Application (client) ID that the AD 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 .
Using token here allows 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 is to 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 of scopes. 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 isn't sent. Instead the resource url is sent as a
part of the scope parameter: scope = [resource
url]//[scope values e.g., openid]
If resource isn't passed here or in scope, AD FS uses a
default resource urn:microsoft:userinfo. userinfo resource
policies 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 is also to 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 for preventing 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 are sign-in, and none.
-  prompt=login  forces the user to enter their credentials
on that request, negating single-sign on.
-  prompt=none  is the opposite - it ensures 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 returns an interaction_required error.
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 use this parameter
during reauthentication, having already extracted the
username from a previous sign-in using the  upn  claim
from id_token .
domain_hint optional If included, it skips 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 is asked to enter their credentials and complete the
authentication. Once the user authenticates, the AD FS authorization endpoint returns a
response to your app at the indicated redirect_uri, using the method specified in
the response_mode parameter.
Successful response
A successful response
using  response_mode=fragment and response_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 if response_type includes  token .
token_type Included if response_type includes  token . is always "Bearer".
expires_in Included if response_type includes  token . Indicates the number of seconds the

token is valid, for caching purposes.
scope Indicates the scope(s) for which the access_token is valid.
id_token Included if response_type includes  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 doesn't 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 in the previous section using the  prompt=none  parameter to control the
identity platform's behavior. If you want to receive a new id_token , be sure to
use  response_type=id_token .
Authorization code grant flow
７ Note

newer AD FS version. For more information on authorization code grant flow in
Azure AD, see Authorization code grant flow in Microsoft identity platform.
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 in section 4.1 of the OAuth 2.0 specification . It's used to perform
authentication and authorization in most app types, including web apps and natively
installed apps. The flow enables apps to securely acquire access_tokens that can be used
to access resources that 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 /authorize endpoint. 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
client_id required The Application (client) ID that the AD FS

assigned to your app.
response_type required Must include code for 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.

parameter isn't sent. Instead the resource url is
sent as a part of the scope parameter: scope =
[resource url]//[scope values e.g., openid]
If resource isn't passed here or in scope, AD FS
uses a default resource urn:microsoft:userinfo.
userinfo resource policies such as MFA, Issuance
or authorization policy, can't be 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 methods:
- 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
use query, fragment,
or form_post.  form_post  executes a POST
containing the code to your redirect URI.
state optional A value included in the request that is also to 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
for preventing 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
are sign-in, and none.
-  prompt=login  forces the user to enter their
credentials on that request, negating single-sign

on.
-  prompt=none  is the opposite - it ensures 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
returns an interaction_required error.
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 use this parameter during reauthentication,
having already extracted the username from a
previous sign-in using the  upn claim from
id_token .
domain_hint optional If included, it skips 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 the code_verifier for

the code_challenge parameter. Can be one of the
following values:
- plain
- S256
If excluded, code_challenge is assumed to be
plaintext if  code_challenge  is included. AD FS
supports both plain and S256. For more
information, see the PKCE 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 the PKCE RFC
At this point, the user is asked to enter their credentials and complete the
authentication. Once the user authenticates, the AD FS returns a response to your app at
the indicated  redirect_uri , using the method specified in the  response_mode  parameter.
Successful response
A successful response using response_mode=query looks 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 the code for an  access_token  to the desired resource. Redeem
the code by sending a POST request to the /token endpoint:
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)
Parameter Required/optional Description
client_id required The Application (client) ID that the AD FS assigned to your

app.
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.
Parameter Required/optional Description
redirect_uri required The same redirect_uri value that was used to acquire the
authorization_code .
client_secret required for web The application secret that you created during app
apps 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
the PKCE RFC . This option applies to AD FS 2019 and later
Successful response
A successful token response looks 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 to acquire
more 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 shouldn't rely on them
for any authorization or security boundaries.
Use the access token

HTTP
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 another POST request to
the  /token  endpoint, this time providing the refresh_token instead of the code. Refresh
tokens are valid for all permissions that your client has already received access token for.
Refresh tokens don't 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
handle errors returned by the token issuance endpoint correctly.
Although refresh tokens aren't revoked when used to acquire new access tokens, you're
expected to discard the old refresh token. As per the OAuth 2.0 spec says: "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.
HTTP

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

app.
grant_type required Must be  refresh_token  for this leg of the authorization
code flow.

parameter isn't sent. Instead the resource url is sent as a
part of the scope parameter: scope = [resource
url]//[scope values e.g., openid]
If resource isn't passed here or in scope, AD FS uses a
default resource urn:microsoft:userinfo. userinfo resource
policies such as MFA, Issuance or authorization policy, can't
be 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 The application secret that you created in the app
apps registration portal for your app. It shouldn't 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.
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).
scope The scopes that the access_token is valid for.
refresh_token An OAuth 2.0 refresh token. The app can use this token to acquire
more 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
７ Note

newer AD FS version. For more information on On-Behalf-Of flow in Azure AD, see
On-Behalf-Of flow in Microsoft identity platform.
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 the OAuth 2.0
authorization code grant flow described in the previous section. At this point, the
application has an access token for 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

For 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).
It should be the same as the resource ID used in the
first leg that is, url of the first Web API.
client_secret required The application secret that you created during

server 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 calls 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:
Parameter required/Optional Description
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).
It should be the same as the resource ID used in the
first leg that is, url of the first Web API.
client_assertion_type required The value must be urn: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 calls 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. This example is similar to the request
by shared secret except that the client_secret parameter is replaced by two parameters:
client_assertion_type and client_assertion.
Example
The following HTTP POST requests an access token for the Web API with a certificate.
HTTP
// 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.
token_type Indicates the token type value. The only type that AD FS supports
is Bearer.
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 in the previous response example to make authenticated
requests to the downstream web API, by setting the token in the Authorization header.
Example
HTTP
GET /v1.0/me HTTP/1.1

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

newer AD FS version. For more information on client credentials grant flow in Azure
AD, see Client credentials grant flow in Microsoft identity platform.
You can use the OAuth 2.0 client credentials grant specified 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 as daemons or service 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

HTTP

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

app.
scope optional A space-separated list of scopes that 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

HTTP
// 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=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRn
d2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials
client_assertion_type required The value must be set

to urn: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 the AD FS assigned

to your app. It's part of client_assertion, so it isn't
required to be passed in here.
scope optional A space-separated list of scopes that 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.
HTTP
GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
Resource owner password credentials grant

flow (Not recommended)
７ Note

newer AD FS version. For more information on resource owner password
credentials grant flow in Azure AD, see Resource owner password credentials
grant flow in Microsoft identity platform.
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.
https
// 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 to password.
username required The user's email address.
password required The user's password.
scope optional A space-separated list of scopes.
Successful authentication response

The following example shows a successful token response:
HTTP
{
"scope": "openid",
"expires_in": 3599,
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIn...",
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDR..."
}
token_type Always set to Bearer.
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 the scopes that were requested.
refresh_token_expires_in Number of seconds that the included refresh token is valid for.
refresh_token Issued if the original scope parameter included offline_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 of this article.
Device code flow
７ Note

newer AD FS version. For more information on device code flow in Azure AD, see
Device code flow in Microsoft identity platform.
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 /devicecode endpoint. 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 for expires_in), so only make this request
when the user has indicated they're ready to sign in.
HTTP
// Line breaks are for legibility only.
POST https://adfs.contoso.com/adfs/oauth2/devicecode
scope=openid
Parameter Condition Description
client_id required The Application (client) ID that the AD FS assigned to your app.
Parameter
scope Condition
optional Description
A space-separated list of scopes.
Device authorization response

A successful response is 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 the user_code in order to sign in.
verification_uri_complete The URI the user should go to with the user_code in order to sign in.
It's prefilled with user_code so that user doesn't need to enter
user_code
expires_in The number of seconds before the device_code and user_code expire.
interval The number of seconds the client should wait between polling
requests.
message A human-readable string with instructions for the user. It can be

localized by including a query parameter in the request of the form ?
mkt=xx-XX, filling in the appropriate language culture code.
Authenticating the user

After the client receives the user_code and verification_uri, it displays these details 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
the verfication_uri_complete, which takes the step of entering the user_code for the user.
While the user is authenticating at the verification_uri, the client should be polling
the /token endpoint for the requested token using the device_code.
HTTP
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
Parameter required Description
grant_type required Must be urn:ietf:params:oauth:grant-type:device_code
client_id required Must match the client_id used in the initial request.
code required The device_code returned in the device authorization request.
Successful authentication response

token_type Always "Bearer".
scope If an access token was returned, it 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 the scopes that were requested.
id_token Issued if the original scope parameter included the openid scope.
refresh_token Issued if the original scope parameter included offline_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
Article • 08/15/2023
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 TryEndAuthentication methods
use the type System.Security.Claims.Claim, part of .NET Framework version 4.5. There is
one reference required for the project:
Reference dll Where to find it Required for
Microsoft.IdentityServer.Web.dll The dll is located in Interface types including

%windir%\ADFS on a Windows IAuthenticationContext,
Server 2012 R2 server on which IProofData
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.IdentityServer.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.IdentityServer.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:
C#
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)
{
class
}
public IAdapterPresentation
TryEndAuthentication(IAuthenticationContext authContext, IProofData
proofData, HttpListenerRequest request, out Claim[] outgoingClaims)
{
class
}
}
}
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.
C#
class MyMetadata : IAuthenticationAdapterMetadata

{
class MyPresentationForm : IAdapterPresentationForm

{
10. Next, you can add the required members for each.First, the metadata (with helpful
inline comments)
C#
class MyMetadata : IAuthenticationAdapterMetadata

{
//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/windowsaccount
name"
/// "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 perform an implementation of these.
11. Replace the entire contents of your class with the following:
C#
namespace MFAadapter
{
{
{
//get { return new <instance of
IAuthenticationAdapterMetadata derived class>; }
}

authContext)
{
class
}

{
}
public void
configData)
{
//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)
{
class
}
{
class
}
}
}
Next, the presentation form:
C#
class MyPresentationForm : IAdapterPresentationForm

{
/// 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";
}
}
12. 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:
C#

{
{
//get { return new <instance of IAuthenticationAdapterMetadata
derived class>; }
get { return new MyMetadata(); }
}

authContext)
{
//return new instance of IAdapterPresentationForm derived class
return new MyPresentationForm();
}

{
}
public void
configData)
{
//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)
{
}
{
outgoingClaims = new Claim[0];
}
13. Now for the resource file containing the html fragment. Create a new text file in
your project folder with the following contents:
HTML
<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>
14. Then, select Project->Add Component... Resources file and name the file
Resources, and click Add:
15. 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:
C#
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 Properties.
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 that 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 set up 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 and 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):
1. Register-AdfsAuthenticationProvider –TypeName YourTypeName –Name

“AnyNameYouWish” [–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:
PowerShell
$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:
PowerShell
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.
PowerShell
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:
PowerShell
Set-AdfsAdditionalAuthenticationRule –AdditionalAuthenticationRules 'c:
[type ==
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authentication
method", value = "http://schemas.microsoft.com/claims/multipleauthn"
);'
Example 2: to create MFA rules to require MFA for external requests to a specific
relying party. (Note: Individual providers cannot be connected to individual relying
parties in AD FS in Windows Server 2012 R2).
PowerShell
$rp = Get-AdfsRelyingPartyTrust –Name <Relying Party Name>

Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –
AdditionalAuthenticationRules 'c:[type ==
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authentication
method", value = "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 Primary

Authentication area, click Edit next to Global Settings.
i. Or just click the Primary 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 and 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:
C#
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:
C#
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:

C#
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(
d", "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 unregister 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
reconfigure 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”
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.
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.)
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

1. PS C:>$typeName = "MFAadapter.MyAdapter, MFAadapter, Version=1.0.0.1,
Culture=neutral, PublicKeyToken=e675eb33c62805a0, processorArchitecture=MSIL”
2. PS C:>Register-AdfsAuthenticationProvider -TypeName $typeName -Name

“MyMFAAdapter1”
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

Primary Authentication area, click Edit next to Global Settings.
i. Or just click the Primary 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

Build Plug-ins with AD FS 2019 Risk
Assessment Model
Article • 08/15/2023
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:
Bash
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 Properties.
b. From the Properties 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:
PowerShell
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:
PowerShell
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:
PowerShell
UnRegister-AdfsThreatDetectionModule -Name "<name used while

registering the dll in 5. above>"
PowerShell
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:
PowerShell
Import-AdfsThreatDetectionModuleConfiguration -name "<name given while

registering the dll>" -ConfigurationFilePath "<path of the .csv file>"
PowerShell
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.
C#
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:
Method Type Definition
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

Method Type Definition
Property 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.
C#
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.
C#
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<Claim> 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.
C#
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<Claim> 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 Description
Risky User Sample plug-in that blocks authentication or enforces MFA based on user risk
Plug-in level determined by Azure AD Identity Protection.
Single log-out for OpenID Connect with
AD FS
Article • 08/15/2023
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_clien
t_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","vp
n_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:
PowerShell
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
PowerShell
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
Scenario: Native App calling Web API
Article • 08/15/2023
Applies to: Windows Server 2022, Windows Server 2019, 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
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 AD FS 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
Visual Studio 2013 or later
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-Server 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 everyone 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.
8. On the Complete screen, click Close.
9. In AD FS Management, click on Application Groups and select

NativeAppToWebApi application group. Right-click and select Properties.
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

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 StartUp Projects…
3. On the Properties pages make sure Action is set to Start 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 Service (Web API) and add the
item in the cache.
Next Steps
Scenario: Web API calling Web API (On
Behalf Of Scenario)
Article • 08/15/2023
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
MSAL AcquireTokenOnBehalfOf method 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
call AcquireTokenSilentlater to request tokens for other downstream APIs (but still
on behalf of the same user). AcquireTokenSilent refreshes the token when needed.
To better understand how to configure on behalf of auth scenario in AD FS, 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

Application Group.
2. On the Application Group Wizard, for the Name enter WebApiToWebApi and
under Client-Server applications select the Native application accessing a Web
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 Properties.
10. On WebApiToWebApi properties screen, click Add application….

11. Under Standalone applications, select Server 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 Properties.
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

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: ClientSecret - enter the shared secret copied from #13 in App
ida:RedirectUri - enter the RedirectUri value from #12 in App Registration in


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: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 StartUp Projects…
2. On the Properties pages make sure Action is set to Start 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
Article • 08/15/2023
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
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 AD FS 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.

Application Group.
2. On the Application Group Wizard, for the Name enter WebAppToWebApi and
under Client-Server applications select the Server application accessing a Web
3. Copy the Client Identifier value. It will be used later as the value for ida:ClientId in
the applications 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.
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: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
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
Article • 08/15/2023
） Important

AD FS
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
AD FS Rapid Restore Tool
Configure alternate hostname binding for certificate authentication in AD FS
Customize HTTP security response headers with AD FS 2019
Delegate AD FS Powershell Commandlet Access to Non-Admin Users
Fine tune SQL and address latency
What is KDFv2?
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 Authentication Policies
Configuring Alternate Login ID
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 AD FS to Send Password Expiry Claims
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
Set up an AD FS lab environment
Walkthrough Guide: Manage Risk with Conditional Access Control
Walkthrough: Workplace Join with a Windows Device
Walkthrough: Workplace Join with an iOS Device
Controlling Access to Organizational
Data with Active Directory Federation
Services
Article • 08/15/2023
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
Article • 08/15/2023
Access Control Policy Templates in AD FS

Active Directory Federation Services now supports the use of access control policy
templates. By using access control policy templates, an administrator can enforce policy
settings by assigning the policy template to a group of relying parties (RPs).
Administrator can also make updates to the policy template and the changes will be
applied to the relying parties automatically if there is no user interaction needed.
What are Access Control Policy Templates?

The AD FS core pipeline for policy processing has three phases: authentication,
authorization and claim issuance. Currently, AD FS administrators have to configure a
policy for each of these phases separately. This also involves understanding the
implications of these policies and if these policies have inter-dependency. Also,
administrators have to understand the claim rule language and author custom rules to
enable some simple/common policy (ex. block external access).
What access control policy templates do is replace this old model where administrators
have to configure Issuance Authorization Rules using claims language. The old
PowerShell cmdlets of issuance authorization rules still apply but it is mutually exclusive
of the new model. Administrators can choose either to use the new model or the old
model. The new model allows administrators to control when to grant access, including
enforcing multi-factor authentication.
Access control policy templates use a permit model. This means by default, no one has
access and that access must be explicitly granted. However, this is not just an all or
nothing permit. Administrators can add exceptions to the permit rule. For example, an
administrator may wish to grant access based on a specific network by selecting this
option and specifying the IP address range. But the administrator may add and
exception, for instance, the administrator may add an exception from a specific network
and specify that IP address range.
Built-in access control policy templates vs
custom access control policy templates
AD FS includes several built-in access control policy templates. These target some
common scenarios which have the same set of policy requirements, for example client
access policy for Office 365. These templates cannot be modified.
To provide increased flexibility to address your business needs, administrators can create
their own access policy templates. These can be modified after creation and changes to
custom policy template will apply to all the RPs which are controlled by those policy
templates. To add a custom policy template simply click Add Access Control Policy from
within AD FS management.
To create a policy template, an administrator needs to first specify under which

conditions a request will be authorized for token issuance and/or delegation. Condition
and action options are shown in the table below. Conditions in bold can be further
configured by the administrator with different or new values. Admin can also specify
exceptions if there is any. When a condition is met, a permit action will not be triggered
if there is an exception specified and the incoming request matches the condition
specified in the exception.
Permit Users Except
From specific network From specific network

Permit Users Except
From specific groups
From devices with specific trust levels
With specific claims in the request
From specific groups From specific network
From devices with specific trust levels From specific network
With specific claims in the request From specific network
And require multi-factor authentication From specific network
If an administrator selects multiple conditions, they are of AND relationship. Actions are
mutually exclusive and for one policy rule you can only choose one action. If admin
selects multiple exceptions, they are of an OR relationship. A couple of policy rule
examples are shown below:
Policy Policy rules
Extranet access requires MFA Rule #1

All users are permitted
from extranet
and with MFA

Policy Policy rules
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
permitted From extranet
and from non-FTE group
Permit
Rule #2
from intranet
and from workplace joined device
and from FTE group
Permit
Extranet access requires MFA except "service admin" Rule #1

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

requires MFA
Permit AD fabric for intranet and extranet access from intranet
And from AD Fabric group
Permit
Rule #2
from extranet
Policy Policy rules
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
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
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
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

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
Article • 08/15/2023
The policies described in this article make use of two kinds of claims
1. Claims AD FS creates based on information the AD FS and Web Application proxy

can inspect and verify, such as the IP address of the client connecting directly to
AD FS or the WAP.
2. Claims AD FS creates based on information forwarded to AD FS by the client as

HTTP headers
Important: The policies as documented below will block Windows 10 domain join
and sign on scenarios that require access to the following additional endpoints
AD FS endpoints required for Windows 10 Domain Join and sign on
[federation service name]/adfs/services/trust/2005/windowstransport

[federation service name]/adfs/services/trust/13/windowstransport
[federation service name]/adfs/services/trust/2005/usernamemixed
[federation service name]/adfs/services/trust/13/usernamemixed
[federation service name]/adfs/services/trust/2005/certificatemixed
[federation service name]/adfs/services/trust/13/certificatemixed
Important: /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 =

７ Note
Claims from this category should only be used to implement business policies and
not as security policies to protect access to your network. It is possible for
unauthorized clients to send headers with false information as a way to gain access.
The policies described in this article should always be used with another authentication
method, such as username and password or multi factor authentication.
Client Access Policies Scenarios

Scenario Description
Scenario 1: Block all external Office 365 access is allowed from all clients on the internal
access to Office 365 corporate network, but requests from external clients are denied
based on the IP address of the external client.
Scenario 2: Block all external Office 365 access is allowed from all clients on the internal
access to Office 365 except corporate network, as well as from any external client devices,
Exchange ActiveSync 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 Blocks external access to Office 365, except for passive (browser-
access to Office 365 except based) applications such as Outlook Web Access or SharePoint
browser-based applications Online.
Scenario Description
Scenario 4: Block all external This scenario is used for testing and validating client access
access to Office 365 except policy deployment. It blocks external access to Office 365 only
for designated Active for members of one or more Active Directory group. It can also
Directory groups 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 create rules to block all external access to Office 365
1. From Server Manager, click Tools, then click AD FS Management.
2. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts,
right-click the Microsoft Office 365 Identity Platform trust, and then click Edit
Claim Rules.
3. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab,
and then click Add Rule to start the Claim Rule Wizard.
Using a Custom Rule, and then click Next.
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 =
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:
"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 create rules to block all external access to Office 365 except

Exchange ActiveSync
Claim Rules.
this rule, for example “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 ==

"http://custom/ipoutsiderange", Value = "true");
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.
this rule, for example “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:
c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:

[Type ==
"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");
list.
this rule, for example “check if application claim exists”. Under Custom rule, type
or paste the following claim rule language syntax:
NOT EXISTS([Type ==
client-application"]) => add(Type = "http://custom/xmsapplication",
Value = "fail");
list.
this rule, for example “deny users with ipoutsiderange true and application fail”.
Under Custom rule, type or paste the following claim rule language syntax:

[Type == "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:

"https://schemas.microsoft.com/authorization/claims/permit", Value =
"true");
19. To save the new rules, in the Edit Claim Rules dialog box, click OK. The resulting list
should look like the following.

browser-based applications
To create rules to block all external access to Office 365 except

Claim Rules.
ipoutsiderange claim”. Under Custom rule, type or paste the following claim rule
language syntax(replace the value above for “x-ms-forwarded-client-ip” with a
c1:[Type ==
"false"] && c2:[Type ==
"http://custom/ipoutsiderange", Value = "true");
list.
this rule, for example “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:

[Type ==
endpoint-absolute-path", Value != "/adfs/ls/"] => issue(Type =
DenyUsersWithClaim");`
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).
c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit",
Value = "true");
11. To save the new rules, in the Edit Claim Rules dialog box, click OK. The resulting
list should look like the following.
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 create rules to block all external access to Office 365, except

for designated Active Directory groups
Claim Rules.
ipoutsiderange claim.” Under Custom rule, type or paste the following claim rule
language syntax(replace the value above for “x-ms-forwarded-client-ip” with a
`c1:[Type ==
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");`
list.
this rule, for example “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");
list.
this rule, for example “deny users with ipoutsiderange true and groupsid fail”.
Under Custom rule, type or paste the following claim rule language syntax:

"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).

"true");
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
Article • 08/15/2023
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'll 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 ==
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.0 Management.
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.
rule. Under Custom rule, type or paste the following claim rule language syntax:
exists([Type ==
"https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) &&
NOT exists([Type ==
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.

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
2.0 Management.
Rules.
exists([Type ==
NOT 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 ==

７ 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.
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 isn't 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

2.0 Management.
Rules.
exists([Type ==
NOT exists([Type ==
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
2.0 Management.
Rules.
exists([Type ==
exists([Type ==
"https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~
"Group SID value of allowed AD group"]) && NOT exists([Type ==

Descriptions of the claim rule language syntax used in the

above scenarios
Description Claim Rule language syntax
Default AD FS rule to Permit => issue(Type = "

Access to All Users. This rule <https://schemas.microsoft.com/authorization/claims/permit>", Value =
should already exist in the "true") ;
Microsoft Office 365 Identity
Platform relying party trust
list.
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's recommended that all exists([Type == "

rules include this. <https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-
proxy>"] )
Used to establish that the NOT exists([Type == "

request is from a client with <https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-
an IP in the defined forwarded-client-ip>", Value=~"customer-provided public ip address
acceptable range. regex"])
This clause is used to specify NOT exists([Type == "

that if the application being <https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-
accessed isn't client-application>", Value=="Microsoft.Exchange.ActiveSync"])
Microsoft.Exchange.ActiveSync
the request should be denied.
This rule allows you to NOT exists([Type == "

determine whether the call <https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-
was through a Web browser, endpoint-absolute-path>", Value == "/adfs/ls/"])
and won't be denied.
This rule states that the only exists([Type == "

users in a particular Active <https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid>",
Directory group (based on SID Value =~ "{Group SID value of allowed AD group}"])
value) should be denied.
Adding NOT to this statement
means a group of users will be
allowed, regardless of
location.
This is a required clause to => issue(Type = "

issue a deny when all <https://schemas.microsoft.com/authorization/claims/deny>", Value =
preceding conditions are met. "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 can't 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 won't 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'll provide
examples for how to construct such an expression to match the following address ranges
(note that you'll 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'll
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 third party authentication
providers as primary authentication in
AD FS 2019
Article • 08/15/2023
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 other factors prior to
collecting the password.
For example, AD FS 2016 introduced Azure AD Multi-Factor Authentication as primary

authentication so that OTP codes from the Authenticator App could be used as the first
factor. Beginning 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 sign in from brute-force attacks and lockouts by prompting for
an additional, external factor first. A password prompt is only seen when the external
authentication is successfully completed. This eliminates a convenient way attackers
have been trying to compromise or disable accounts.
This scenario consists of two components:
Prompting for Azure AD Multi-Factor Authentication (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 AD Multi-Factor Authentication with Authenticator app

Windows 10 Hello for Business
Certificate authentication
External authentication providers
Concepts
What primary authentication really means is that it's 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 AD Multi-Factor Authentication,
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 and
“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 see a choice page and be
able to choose a primary method, just as they do for additional authentication.
Prerequisites
Before configuring external authentication providers as primary, ensure you have the
following prerequisites 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 information 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 in the
next section of this article.
Enable external authentication methods as

primary
After you have verified the prerequisites, there are two ways to configure AD FS
additional authentication providers as primary: PowerShell, or the AD FS Management
console.
Using PowerShell
PowerShell
PS C:\> Set-AdfsGlobalAuthenticationPolicy -
AllowAdditionalAuthenticationAsPrimary $true
The AD FS service must be restarted after enabling or disabling additional

authentication as primary.
Using the AD FS Management console

In the AD FS Management console, under Service -> Authentication Methods, under
Primary Authentication Methods, select Edit
Select the checkbox for Allow additional authentication providers as primary.
The AD FS service must be restarted after enabling or disabling additional

authentication as primary.
Enable username and password as additional

authentication
To complete the “protect the password” scenario, enable username and password as
additional authentication using either PowerShell or the AD FS Management console.
Examples are provided for both methods.

authentication using PowerShell
PowerShell
PS C:\> $providers = (Get-

AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider
PS C:\>$providers = $providers + "FormsAuthentication"
PS C:\>Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider
$providers

authentication using AD FS Management console
In the AD FS Management console, under Service -> Authentication Methods, under
Additional Authentication Methods, select Edit
Select the checkbox for Forms Authentication to enable username and password as
additional authentication.
Setting up an AD FS Deployment with
Article • 08/15/2023
A highly available geo-distributed topology provides:
Elimination of a single point of failure: With failover capabilities, you can achieve a
highly available AD FS 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 AD FS 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 On Availability Group (AG) is a one or more user databases that fail over
together. An availability group consists of a primary availability replica and 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.
An availability group listener on 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.
Category Feature Supported Supported

by WID by SQL
AD FS Federation server farm deployment Yes Yes

Features
AD FS SAML artifact resolution. Note: This is not common No Yes

Features for SAML applications
AD FS SAML/WS-Federation token replay detection. Note: No Yes

Features 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 Basic database redundancy using pull replication, No No

Features where one or more servers hosting a read-only
copy of the database request changes that are
made on a source server host a read/write copy of
the database
Database Database redundancy using high Availability No Yes

Features solutions, such as clustering or mirroring (at the
database layer)
Additional OAuth Authcode Scenario Yes Yes

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

Enroll an SSL Certificate for AD FS
Install the AD FS Role Service
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 ( <instance name> ), where <instance name> 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 AD FS 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.
Tab Brief Description
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 Use this tab to specify your backup preference for the availability group as a
Preferences 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 AD FS service on all the AD
FS 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”
prompt=login parameter support
Article • 08/15/2023
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/passwo
rd 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/p
assword : 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 or later
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*”. This
is a per domain setting. If you have multiple domains federated with one single
federation, it is required to apply the changes for each of the domains desired.
1. First obtain the current values of PreferredAuthenticationProtocol , SupportsMfa ,

and PromptLoginBehavior for the federated domain by running the following
PowerShell command:
PowerShell
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:
PowerShell
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 prompt=login to
wauth=https://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/p
assword and wfresh=0 .
NativeSupport: 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
Article • 08/15/2023
Applies to: Windows Server 2019
The user interface for sign-in is updated in Windows Server 2019 to feature a look and
feel identical to Azure Active Directory. This update provides users with a more
consistent sign-in experience that incorporates a centered and paginated user flow.
What's new
In AD FS in Windows Server 2012 R2 and 2016, your sign-in screen looked something
like this:
Instead of displaying a single form located on the right side of the screen, Windows
Server 2019 sign-in features several design updates, including:
Centered UI. In earlier versions, the sign-in UI displays on the right side of the
screen, as shown in the previous screenshot. The UI is now positioned front and
center to modernize the experience.
Pagination. Instead of a long form to fill out, a new flow takes you through the
sign-in experience step-by-step. Our research shows that with this approach, our
customers have more successful sign-ins. It also enables more flexibility for
incorporating various authentication methods, such us phone factor
authentication.
On the first page, you're asked to enter your username. You can 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're presented with authentication options, configured by your
administrator. If allowing external authentication as primary is enabled, that is also
included.
On the third page, you're asked to enter your password (assuming you selected
“Password” as your authentication option).
Upgrading to paginated sign-in

New installations of AD FS receive the new sign-in UI by default.
If you're an existing customer using AD FS 2012 R2 or 2016, there are two ways to
receive the new UI 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 are enabled when this
feature is enabled.
If you're a new customer to AD FS, you receive the new design by default. However, if
you're using AD FS 2012 R2 or 2016, there are several steps you need to take to receive
the new design:
Set-AdfsGlobalAuthenticationPolicy -AllowAdditionalAuthenticationAsPrimary $true

Customization
Options for customization still work in AD FS 2019.
Related links
If you don't plan to upgrade your servers to AD FS 2019, but still want to enjoy the
new sign-in design: Using an Azure AD UX Web Theme in Active Directory
Federation Services
Customization guidance: AD FS user sign-in customization
AD FS single sign-on settings
Article • 08/15/2023
Applies to: Windows Server (All supported versions)
Single sign-on (SSO) allows users to authenticate once and access multiple resources
without being prompted for more credentials. This article describes the default AD FS
behavior for SSO and the configuration settings that let you customize this behavior.
Supported types of single sign-on

AD FS supports several types of single sign-on experiences:
Session SSO
Session SSO eliminates extra prompts when the user switches applications during a
particular session. If a particular session ends, the user will be prompted for their
credentials again. Session SSO cookies are written for the authenticated user.
AD FS will set session SSO cookies by default if users' devices aren't registered. If
the browser session has ended and is restarted, this session cookie is deleted and
isn't valid anymore.
Persistent SSO
Persistent SSO eliminates extra prompts when the user switches applications for as
long as the persistent SSO cookie is valid. Persistent SSO cookies are written for
the authenticated user. 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 no longer valid, it's 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.
AD FS will set the expiration time of a refresh token based on the persistent SSO
cookie's lifetime for a registered device. By default, the cookie lifetime is seven
days for AD FS on Windows Server 2012 R2. The default cookie lifetime for AD FS
on Windows Server 2016 is up to a maximum of 90 days if the device is used to
access AD FS resources within a 14-day window.
If the device isn't registered but a user selects the “Keep me signed in” option, the
expiration time of the refresh token will equal the persistent SSO cookie's lifetime for
"Keep me signed in". The persistent SSO cookie lifetime is one day by default with
maximum of seven days. Otherwise, refresh token lifetime equals session SSO cookie
lifetime (8 hours by default).
Users on registered devices will always get a persistent SSO unless the persistent SSO is
disabled. For unregistered 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 August 2014 update rollup for
Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 .
Task PowerShell Description
Enable/disable Set-AdfsProperties – Persistent SSO is enabled by default. If it's

persistent SSO EnablePersistentSso disabled, no PSSO cookie is created.
<Boolean>
"Enable/disable Set-AdfsProperties – "Keep me signed in" feature is disabled by

“keep me signed in" EnableKmsi <Boolean> default. If it's enabled, the 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.
After 15 days, users will be prompted for credentials again.
Persistent SSO is enabled by default. If it's disabled, no PSSO cookie is created.|
PowerShell
Set-AdfsProperties –EnablePersistentSso <Boolean\>

The device usage window (14 days by default) is governed by the AD FS property
DeviceUsageWindowInDays.
PowerShell
Set-AdfsProperties -DeviceUsageWindowInDays
The maximum single sign-on period (90 days by default) is governed by the AD FS
property PersistentSsoLifetimeMins.
PowerShell
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.
PowerShell
Set-AdfsProperties -EnableKmsi $true
With KMSI disabled, the default single sign-on period is 8 hours. The single sign-on
period can be configured using the property SsoLifetime. The property is measured in
minutes, so its default value is 480.
PowerShell
Set-AdfsProperties –SsoLifetime <Int32\>
With KMSI enabled, the default single sign-on period is 24 hours. The single sign-on
period with KMSI enabled can be configured using the property KmsiLifetimeMins. The
property is measured in minutes, so its default value is 1440.
PowerShell
Set-AdfsProperties –KmsiLifetimeMins <Int32\>
Multi-factor authentication (MFA) behavior

AD FS provides relatively long periods of single sign-on. It's important to note AD FS will
prompt for more authentication (multi factor authentication) when a previous sign-on is
based on primary credentials (not MFA) but the current sign-on requires MFA. This
behavior is regardless of SSO configuration. When AD FS receives an authentication
request, it first determines whether or not there's an SSO context (such as a cookie), and
then whether MFA is required. For example, MFA is required when the authentication
request is from outside. In such a case, AD FS assesses whether or not the SSO context
contains MFA. If not, MFA is prompted.
PSSO revocation
To protect security, AD FS rejects any persistent SSO cookie previously issued when the
following conditions are met:
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 isn't 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. With a cutoff time
configured, AD FS will reject any persistent SSO cookie issued before this time
Rejection of a persistent SSO cookie requires the user to provide their credentials in
order to authenticate with AD FS again.
To set the cutoff time, run the following PowerShell cmdlet:
PowerShell
Set-AdfsProperties -PersistentSsoCutoffTime <DateTime>

Enable PSSO for Office 365 users to access
SharePoint Online
After PSSO is enabled and configured, AD FS creates a persistent cookie immediately
after user authentication. PSSO avoids the need to reauthenticate in subsequent
sessions, as long as the cookie is still valid.
Users can also avoid extra authentication prompts for Office 365 and SharePoint Online.
Configure 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, install this hotfix . It's part of the 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:
Single sign-on experience ADFS 2012 R2 ADFS 2016

Is device Is device registered?
registered?
No No but KMSI Yes No No but KMSI Yes
SSO=>set Refresh Token=> 8 hrs n/a n/a 8 hrs n/a n/a
PSSO=>set Refresh n/a 24 hrs 7 days n/a 24 hrs Max 90 days with 14-days
Token=> window
Token lifetime 1 hr 1 hr 1 hr 1 hr 1 hr 1 hr
Registered Device? You get PSSO / Persistent SSO.
Not Registered Device? You get SSO.

Not Registered Device but KMSI? You get PSSO/ Persistent SSO.
IF:
[x] Admin has enabled the KMSI feature [AND]

[x] User selects the KMSI check box on the forms sign in page
AD FS 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 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 isn't issued.
Good to Know:
Federated users who don't have the LastPasswordChangeTimestamp attribute synced

are issued session cookies and refresh tokens that have a Max Age value of 12 hours.
Max Age value session cookies and refresh tokens are issued because Azure AD can't
determine when to revoke tokens that are related to an old credential. This behavior
could be caused by a password that has been changed, for example. Azure AD must
check more frequently to make sure that user and associated tokens are still valid.
Rapid Restore tool
Article • 08/15/2023
Active Directory Federation Services (AD FS) is made highly available by setting up an
AD FS farm. Some organizations prefer a single server AD FS deployment to eliminate
the need for multiple AD FS servers and network load-balancing infrastructure. This
approach helps to ensure quick restoration of service after resolving potential issues.
The 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. Use the tool to export
an AD FS configuration to Azure or to an on-premises location. You can apply the
exported data to a fresh AD FS installation and recreate or duplicate the AD FS
environment.
Use case scenarios

You can use the AD FS Rapid Restore tool in various scenarios:
Quickly restore AD FS functionality after issues. Use the Rapid Restore tool to
create a cold standby installation of AD FS that can be quickly deployed in place of
the online AD FS server.
Deploy identical test and production environments. Quickly create an accurate

copy of the production AD FS in a test environment. You can also use the Rapid
Restore tool to quickly deploy a validated test configuration to production.
Migrate SQL and Windows Integrated Database (WID) configurations. Migrate

your data with the Rapid Restore tool and move from a SQL-based farm
configuration to WID or vice versa.
７ Note
If you use SQL Merge Replication or Always on Availability Groups, the Rapid
Restore tool isn't supported. We recommend SQL-based backups and a backup of
the SSL certificate.
Backup contents
The Rapid Restore tool backs up the following AD FS configuration:
AD FS configuration database (SQL or WID)

Configuration file (located in the AD FS folder)
List of installed custom authentication providers, attribute stores, and local claims
provider trusts
Automatically generated token signing and decrypting certificates and private keys
from the Active Directory Distributed Key Manager (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. The user running the script must have permission
to access the keys.
Backup encryption
All backup data is encrypted before it's pushed to the cloud or stored in the file system.
Each document that's created as part of the backup is encrypted by using AES-256. The
password provided to the Rapid Restore tool is used as a pass phrase to generate a new
password via the Rfc2898DeriveBytes Class.
The RngCryptoServiceProvider Class generates the salt (binary blob) used by AES and
the Rfc2898DeriveBytes Class.
Get started
To get started with the AD FS Rapid Restore tool, first review the following system and
tool requirements.
The tool works for AD FS in Windows Server 2016 and later.

The tool requires .NET framework 4.0 or later.
If you use a WID, the tool must run on the primary AD FS server. Use the Get-
AdfsSyncProperties cmdlet to check if your server is the primary server.
A restore must run on an AD FS server of the same version as the backup server,
and use the same Active Directory account as the AD FS service account.
Follow these steps to set up the tool:

1. Download and install the MSI to your AD FS server.
2. After you install the tool, run the following command from a PowerShell prompt:
PowerShell
Import-Module 'C:\Program Files (x86)\ADFS Rapid Recreation

Tool\ADFSRapidRecreationTool.dll'
Create backups: Backup-ADFS

To create a backup, use the Backup-ADFS PowerShell cmdlet. The backup cmdlet backs
up the AD FS configuration, database, SSL certificates, and so on.
Before you use the backup cmdlet, review the following access and permissions
requirements.
Run as local admin. To run the backup cmdlet, the user must be at least a local
admin.
Back up as domain admin. To back up the Active Directory DKM container (which
is required in the default AD FS configuration), the user privileges must satisfy one
or more of the following criteria:
The user must be a domain admin.
The user must pass in the AD FS service account credentials.
The user must have access to the DKM container.
Use gMSA account as domain admin. For a Group Managed Service Account
(gMSA), the user must be a domain admin or have permissions to the container.
The user can't provide the gMSA credentials.
Backup-ADFS cmdlet parameters

Each backup is named according to the pattern adfsBackup_ID_Date-Time . The name
contains the version number, date, and time of the backup.
The following are the parameters for the Backup-ADFS cmdlet:
PowerShell
Backup-ADFS
-StorageType {FileSystem | Azure}
-EncryptionPassword <string>
-AzureConnectionCredentials <pscredential>
-AzureStorageContainer <string>
[-BackupComment <string>]
[-ServiceAccountCredential <pscredential>]
[-BackupDKM]
Backup-ADFS -StorageType {FileSystem | Azure}

-EncryptionPassword <string>
-StoragePath <string>
[-BackupComment <string>]
[-BackupDKM]
The following list describes the parameter details for the Backup-ADFS cmdlet.
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 approach uses the Azure AD ldifde tool to export the
Azure AD container and all its subtrees.
StorageType <string> : When the user performs the backup, they select the backup
location:
FileSystem indicates the user wants to store the backup in a local folder or in
the network. To store the backup in the file system, the user must satisfy the
following requirements:
A storage path must be specified.
In the path directory, a new directory is created for each backup. Each directory
created contains the backed-up files.
Azure indicates the user wants to store the backup in the Azure Storage
Container. To store the backup in the cloud, the user must satisfy the following
requirements:
Azure Storage credentials should be passed to the cmdlet. The storage
credentials contain the account name and key.
A container name must also be passed in. If the container doesn't exist, it's
created during the backup.
EncryptionPassword <string> : The password to use to encrypt all the backed-up
files before they're stored.
AzureConnectionCredentials <pscredential> : The account name and key for the

Azure storage account.
AzureStorageContainer <string> : The storage container for the backup in Azure.
StoragePath <string> : The storage location for the backups.
ServiceAccountCredential <pscredential> : The service account used for the
current running AD FS Service. This parameter is needed only when the user wants
to back up the DKM and they aren't a domain admin or can't access the container
contents.
BackupComment <string[]> : An informational string about the backup to display
during the restore. This string is similar to the concept of Hyper-V checkpoint
naming. The default is an empty string.
Backup examples
The following PowerShell examples demonstrate backup options for an AD FS
configuration with the AD FS Rapid Restore tool and the Backup-ADFS cmdlet.
Back up to file system with DKM as domain admin

The following cmdlet backs up the AD FS configuration to the file system with the DKM
by using the -BackupDKM parameter. This approach provides access to the DKM
container contents as the domain admin or a user with delegated permissions.
PowerShell
Backup-ADFS -StorageType "FileSystem" -StoragePath

"C:\Users\administrator\testExport\" -EncryptionPassword "password" -
BackupComment "Clean Install of AD FS (FS)" -BackupDKM
Back up to file system with DKM as local admin

The following cmdlet also backs up the AD FS configuration to the file system with the
DKM, but uses a slightly different approach. In this option, you specify the service
account credential by using the -ServiceAccountCredential $cred parameter, and run
the operation as a local admin.
PowerShell

BackupComment "Clean Install of AD FS (FS)" -BackupDKM -
ServiceAccountCredential $cred
Back up to Azure Storage container without DKM

The following cmdlet backs up the AD FS configuration to the Azure Storage container
without using the DKM. Use the -AzureStorageContainer "adfsbackups" parameter to
specify the container.
PowerShell
Backup-ADFS -StorageType "Azure" -AzureConnectionCredentials $cred -

AzureStorageContainer "adfsbackups" -EncryptionPassword "password" -
BackupComment "Clean Install of AD FS"
Back up to file system without DKM

The following cmdlet backs up the AD FS configuration to the file system without using
the DKM. Notice the -BackupDKM parameter isn't specified.
PowerShell

BackupComment "Clean Install of AD FS (FS)"
Restore backups: Restore-ADFS

To apply a configuration created by using the Backup-ADFS cmdlet to a new AD FS
installation, use the Restore-ADFS cmdlet. The restore cmdlet creates a new AD FS farm
by using the Install-AdfsFarm cmdlet and restores the AD FS configuration, database,
certificates, and so on.
The restore cmdlet checks the restore location for existing backups. The cmdlet prompts
the user to choose an appropriate backup based on the date and 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, the user is first
prompted to choose the appropriate AD FS configuration.
Before you use the restore cmdlet, review the following requirements.
If the AD FS role isn't installed on the server, the cmdlet installs the role.
The user has to be both a local and domain admin to run this cmdlet.
） Important
Before you use the AD FS Rapid Restore tool to restore a backup, make sure the
server is joined to the domain.
Restore-ADFS cmdlet parameters

The following are the parameters for the Restore-ADFS cmdlet:
PowerShell
Restore-ADFS
-DecryptionPassword <string>
-AzureConnectionCredentials <pscredential>
-AzureStorageContainer <string>
[-ADFSName <string>]
[-GroupServiceAccountIdentifier <string>]
[-DBConnectionString <string>]
[-Force]
[-RestoreDKM]
Restore-ADFS
-DecryptionPassword <string>
-StoragePath <string>
[-ADFSName <string>]
[-GroupServiceAccountIdentifier <string>]
[-DBConnectionString <string>]
[-Force]
[-RestoreDKM]
The following list describes the parameter details for the Restore-ADFS cmdlet.
StorageType <string> : The type of storage to use:
FileSystem stores the backup in a local folder or in the network.

Azure stores the backup in the Azure Storage Container.
DecryptionPassword <string> : The password 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 to store the backup in
Azure.
StoragePath <string> : The storage location for the backup.
ADFSName <string> : The name of the federation that was backed up and to now
restore.
When a name isn't specified and only one federation service name exists, then
that federation service name is used.
If more than one federation service is backed up to the location, the user is
prompted to choose a backed-up federation service.
ServiceAccountCredential <pscredential> : Specifies the service account to use for
the new AD FS Service that's being restored.
GroupServiceAccountIdentifier <string> : The gMSA that the user wants to use for
the new AD FS Service that's being restored.

By default, if a value isn't provided, the backed-up account name is used, if the
account is gMSA.
If a value isn't provided, and the account isn't gMSA, the user is prompted to
specify a service account.
DBConnectionString <string> : To use a different database for the restore, specify
the SQL Connection String or enter "WID."
Force <bool> : Skip any prompts from the tool after you select the backup process.
RestoreDKM <bool> : Restore the DKM Container to the Active Directory. Set this
option when restoring to a new Active Directory and the DKM was backed up
initially.
Restore examples
The following PowerShell examples demonstrate restore options for an AD FS
configuration with the AD FS Rapid Restore tool and the Restore-ADFS cmdlet.
Restore to file system with DKM as domain admin

The following cmdlet restores the AD FS configuration to the file system with the DKM
by using the -RestoreDKM parameter.
PowerShell
Restore-ADFS -StorageType "FileSystem" -StoragePath

"C:\Users\administrator\testExport\" -DecryptionPassword "password" -
RestoreDKM
Restore to file system without DKM

The following cmdlet restores the AD FS configuration to the file system without using
the DKM. Notice the -RestoreDKM parameter isn't specified.
PowerShell

"C:\Users\administrator\testExport\" -DecryptionPassword "password"
Restore to Azure Storage container without DKM

The following cmdlet restores the AD FS configuration to the Azure Storage container
without using the DKM. Use the -AzureStorageContainer "adfsbackups" parameter to
specify the container.
PowerShell
Restore-ADFS -StorageType "Azure" -AzureConnectionCredential $cred -

DecryptionPassword "password" -AzureStorageContainer "adfsbackups"
Restore to WID
The following cmdlet restores the AD FS configuration to WID. Notice the WID value
passed to the -DBConnectionString parameter.
PowerShell

DBConnectionString "WID"
Restore to SQL
The following cmdlet restores the AD FS configuration to SQL. Notice the Data Source
and Integrated Security values passed to the -DBConnectionString parameter.
PowerShell

DBConnectionString "Data Source=TESTMACHINE\SQLEXPRESS; Integrated
Security=True"
Restores with specified gMSA account

The following cmdlet restores the AD FS configuration and uses a specified gMSA
account. Notice the use of the -GroupServiceAccountIdentifier parameter.
PowerShell

GroupServiceAccountIdentifier "mangupd1\adfsgmsa$"
Restore with specified service account credentials

The following cmdlet restores the AD FS configuration and uses the specified service
account credentials. Notice the use of the -ServiceAccountCredential parameter.
PowerShell

ServiceAccountCredential $cred
Log files
A log file is created for every backup and restore operation. The log files can be found at
%LOCALAPPDATA%\ADFSRapidRecreationTool.
７ Note
When you do a restore, a PostRestore_Instructions file might be created. This file
contains an overview of the additional data or services that must be installed
manually before you start the AD FS service. The file specifies authentication
providers, attribute stores, and local claims provider trusts.
Version release history

The following sections identify version details for the AD FS Rapid Restore tool.
Version 1.0.82.3
Release: April 2020
Fixed issues:
Add 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

Add more trace information to the log file
Version 1.0.75.0
Release: August 2018
Fixed issues:
Update the Backup-ADFS cmdlet for the -BackupDKM switch. The tool determines
if the current context has access to the DKM container. When access is available,
the tool doesn't require Domain Admin privileges or service account credentials.
This update enables automated backups that don't the user to explicitly provide
credentials or run the operation as a Domain Administrator account.
Version 1.0.73.0
Release: August 2018
Fixed issues:
Update the encryption algorithms to ensure application is FIPS compliant
） Important
Previous backups won't work with the latest version of the tool, due to
changes in encryption algorithms for FIPS compliance.
Add support for SQL clusters that use merge replication
Version 1.0.72.0
Release: July 2018
Fixed issues:
Bug fix: Fix .MSI installer to support in-place upgrades
Version 1.0.18.0
Release: July 2018
Fixed issues:
Bug fix: Handle service account passwords with special characters (that is, '&')
Bug fix: Resolve issues relation to restoration failure because
Microsoft.IdentityServer.Servicehost.exe.config is in use by another process
Version 1.0.0.0
Release: October 2016
Initial release of AD FS Rapid Restore Tool

AD FS support for alternate hostname
binding for certificate authentication
Article • 08/15/2023
Applies to: Windows Server 2016 and later
On many networks, the local firewall policies may not allow traffic through nonstandard
ports like 49443. Nonstandard ports created issue when trying to accomplish certificate
authentication with AD FS prior to Windows Server 2016 because different bindings for
device authentication and user certificate authentication on the same host isn't possible.
Prior to Windows Server 2016, default port 443 is bound to receive device certificates
and can't be altered to support multiple binding in the same channel. Smart card
authentication doesn't work and there's no notification to users explaining the cause.
AD FS in Windows Server supports alternate

host name binding
AD FS in Windows Server provides support for alternate host name binding. Two modes
are supported. The first mode uses the same host (that is, adfs.contoso.com) with
different ports (443, 49443). The second mode uses different hosts (adfs.contoso.com
and certauth.adfs.contoso.com) with the same port (443). The second mode requires an
TLS/SSL certificate to support "certauth.<adfs-service-name>" as an alternate subject
name. Alternate host name binding can be configured 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 you can add the alternate host name binding for certificate
authentication.
When setting up a new AD FS farm with AD FS for Windows Server 2016, if the
certificate contains a subject alternative name (SAN), it's automatically set up to
use the second mode mentioned in the preceding section. Meaning it
automatically sets up two different hosts (sts.contoso.com and
certauth.sts.contoso.com) with the same port.
If the certificate doesn't contain a SAN, you see a warning telling you that certificate
subject alternative names doesn't support certauth.*. See the following screenshots. The
first screenshot shows an installation where the certificate contains a SAN. The second
screenshot shows a certificate that didn't contain a SAN.
After AD FS in Windows Server has been deployed, you can use the PowerShell
cmdlet Set-AdfsAlternateTlsClientBinding to add the alternate host name
binding for certificate authentication. For more information, see Set-
AdfsAlternateTlsClientBinding.
PowerShell
Set-AdfsAlternateTlsClientBinding -Member ADFS1.contoso.com -Thumbprint

'<thumbprint of cert>'
When prompted, select Yes to confirm.

Related links
Managing SSL Certificates in AD FS and WAP in Windows Server 2016
AD FS user sign-in customization
Article • 08/15/2023
AD FS provides a number of options for administrators to customize and tailor the end-
user experience to meet their corporate needs. The following page will serve as a central
location for customization. You can use the table below to quickly find your
customization option.
Topic Description
AD FS Customization in Windows Server 2016 New customization options available for AD FS

in Windows Server 2016
Change the company name Steps for displaying your companies name on
the sign-in page
Change the company logo Steps for changing the logo that appears on the
sign-in-page
Change the illustration Steps for changing the illustration that appears
on the sign-in page
Add sign-in description Steps for adding a description to the sign-in

page
Add help desk link Steps for adding a help desk link
Topic Description
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 Information on using MFA and external auth
providers customization providers
Customization for Localization Information on localization considerations
Removing the Microsoft copyright Steps on removing the Microsoft copyright
Customizing the display names and Steps on customizing display names and
descriptions for authentication methods descriptions for authentication methods
Advanced Customization Advanced customization options using the

onload.js file.
Article • 08/15/2023
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.

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
Directory, LDAP, or SQL.
In Connection string, if you have selected either a Lightweight Directory

Access Protocol (LDAP) store or a Structured Query Language (SQL) store,
enter the string that you used to establish a connection to the attribute store.
For Active Directory attribute stores, no connection string is necessary;
therefore, this field is disabled.
７ Note
AD FS automatically creates an Active Directory attribute store, by

default.
4. Click OK.
AD FS Operations
The Role of Attribute Stores

Compound authentication and AD DS
claims in AD FS
Article • 08/15/2023
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
Requirements
1. The Computers accessing federated applications, must Authenticate to AD FS
using Windows Integrated Authentication.
Windows Integrated Authentication is only available when connecting to the

Backend AD FS Servers.
Computers must be able to reach the Backend AD FS Servers for Federation
Service Name
AD FS Servers must offer Windows Integrated Authentication as a Primary
Authentication method in its Intranet settings.
2. The policy Kerberos client support for claims compound authentication and
Kerberos armoring must be applied to all Computers accessing federated
applications that are protected by Compound Authentication. This is applicable in
case of single forest or cross forest scenarios.
3. The Domain housing the AD FS Servers must have the KDC support for claims
compound authentication and Kerberos armoring policy setting applied to the
Domain Controllers.
Steps for configuring AD FS in Windows Server

2012 R2
Use the following steps for configuring compound authentication and claims
Step 1: Enable KDC support for claims, compound

authentication, and Kerberos armoring on the Default
Domain Controller Policy
1. In Server Manager, select Tools, Group Policy Management.
2. Navigate down to the Default Domain Controller Policy, right-click and select edit.
3. On the Group Policy Management Editor, under Computer Configuration, expand

Policies, expand Administrative Templates, expand System, and select KDC.
4. In the right pane, double-click KDC support for claims, compound authentication,
and Kerberos armoring.
5. In the new dialog window, set KDC support for claims to Enabled.
6. Under Options, select Supported from the drop-down menu and then click Apply
and OK.
Step 2: Enable Kerberos client support for claims,
compound authentication, and Kerberos armoring on
computers accessing federated applications
1. On a Group Policy applied to the computers accessing federated applications, in
the Group Policy Management Editor, under Computer Configuration, expand
Policies, expand Administrative Templates, expand System, and select Kerberos.
2. In the right pane of the Group Policy Management Editor window, double-click
Kerberos client support for claims, compound authentication, and Kerberos
armoring.
3. In the new dialog window, set Kerberos client support to Enabled and click Apply
and OK.
4. Close the Group Policy Management Editor.
Step 3: Ensure the AD FS servers have been updated.

You need to ensure that the following updates are installed on your AD FS servers.
Update Description
KB2919355 Cumulative security update(includes

KB2919355,KB2932046,KB2934018,KB2937592,KB2938439)
KB2959977 Update for Server 2012 R2
Hotfix 3052122 This update adds support for compound ID claims in Active Directory
Federation Services.
Step 4: Configure the Primary Authentication Provider

1. Set the Primary Authentication Provider to Windows Authentication for AD FS
Intranet settings.
2. In AD FS Management, under Authentication Policies, select Primary

Authentication and under Global Settings click edit.
3. On Edit Global Authentication Policy under Intranet select Windows

Authentication.
4. Click Apply and Ok.

5. Using PowerShell you can use the Set-AdfsGlobalAuthenticationPolicy cmdlet.
PowerShell
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 AD FS 2012 R2 and needs to be manually added.
2. In AD FS Management, under Service, right-click Claim description and select Add

claim description
3. Enter the following information in the claim description
Display Name: 'Windows device group'

Claim Description:
'<https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdevice
group>' `
4. Place a check in both boxes.
5. Click OK.
6. Using PowerShell you can use the Add-AdfsClaimDescription cmdlet.
PowerShell
Add-AdfsClaimDescription -Name 'Windows device group' -ClaimType

'https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdevice
group' `
-ShortName 'windowsdevicegroup' -IsAccepted $true -IsOffered $true -
IsRequired $false -Notes 'The windows group SID of the device'
７ Note
Step 6: Enable the compound authentication bit on the

msDS-SupportedEncryptionTypes attribute
1. Enable compound authentication bit on the msDS-SupportedEncryptionTypes
attribute on the account you designated to run the AD FS service using the Set-
ADServiceAccount PowerShell cmdlet.
７ Note
If you change the service account, then you must manually enable compound
authentication by running the Set-ADUser -compoundIdentitySupported:$true
Windows PowerShell cmdlets.
PowerShell
Set-ADServiceAccount -Identity “ADFS Service Account” -

CompoundIdentitySupported:$true
2. Restart the AD FS Service.
７ Note
Once ‘CompoundIdentitySupported' is set to true, installation of the same gMSA

on new Servers (2012R2/2016) fails with the following error – Install-
ADServiceAccount : Cannot install service account. Error Message: 'The provided
context did not match the target.'.
Solution: Temporarily set CompoundIdentitySupported to $false. This step causes

AD FS 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 AD FS
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 Directory and select Edit Claim Rules.
3. On the Edit Claim Rules for Active Director click Add Rule.
4. On the Add Transform Claim Rule Wizard select Pass Through or Filter an
Incoming Claim and click Next.
5. Add a display name and select Windows device group from the Incoming claim
type drop-down.
6. Click Finish. Click Apply and Ok.
Step 8: On the Relying Party where the

‘WindowsDeviceGroup' claims are expected, add a similar
‘Pass-through' Or ‘Transform' claim rule.
2. In AD FS Management, click Relying Party Trusts and in the right pane, right-click
your RP and select Edit Claim Rules.
3. On the Issuance Transform Rules click Add Rule.
type drop-down.
Steps for configuring AD FS in Windows Server

2016
The following will detail the steps for configuring compound authentication on AD FS
for Windows Server 2016.
Step 1: Enable KDC support for claims, compound

authentication, and Kerberos armoring on the Default
Domain Controller Policy
1. In Server Manager, select Tools, Group Policy Management.
2. Navigate down to the Default Domain Controller Policy, right-click and select edit.
3. On the Group Policy Management Editor, under Computer Configuration, expand
Policies, expand Administrative Templates, expand System, and select KDC.
4. In the right pane, double-click KDC support for claims, compound authentication,
and Kerberos armoring.
5. In the new dialog window, set KDC support for claims to Enabled.
6. Under Options, select Supported from the drop-down menu and then click Apply
and OK.
Step 2: Enable Kerberos client support for claims,

compound authentication, and Kerberos armoring on
computers accessing federated applications
1. On a Group Policy applied to the computers accessing federated applications, in
the Group Policy Management Editor, under Computer Configuration, expand
Policies, expand Administrative Templates, expand System, and select Kerberos.
2. In the right pane of the Group Policy Management Editor window, double-click
Kerberos client support for claims, compound authentication, and Kerberos
armoring.
3. In the new dialog window, set Kerberos client support to Enabled and click Apply
and OK.
4. Close the Group Policy Management Editor.
Step 3: Configure the Primary Authentication Provider

1. Set the Primary Authentication Provider to Windows Authentication for AD FS
Intranet settings.
2. In AD FS Management, under Authentication Policies, select Primary
Authentication and under Global Settings click edit.
3. On Edit Global Authentication Policy under Intranet select Windows
Authentication.
4. Click Apply and Ok.
5. Using PowerShell you can use the Set-AdfsGlobalAuthenticationPolicy cmdlet.
PowerShell
Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider
'WindowsAuthentication'
７ Note
Step 4: Enable the compound authentication bit on the

msDS-SupportedEncryptionTypes attribute
1. Enable compound authentication bit on the msDS-SupportedEncryptionTypes
attribute on the account you designated to run the AD FS service using the Set-
ADServiceAccount PowerShell cmdlet.
７ Note
If you change the service account, then you must manually enable compound
authentication by running the Set-ADUser -compoundIdentitySupported:$true
Windows PowerShell cmdlets.
PowerShell
Set-ADServiceAccount -Identity “ADFS Service Account” -

CompoundIdentitySupported:$true
2. Restart the AD FS Service.
７ Note
Once ‘CompoundIdentitySupported' is set to true, installation of the same gMSA

on new Servers (2012R2/2016) fails with the following error – Install-
ADServiceAccount : Cannot install service account. Error Message: 'The provided
context did not match the target.'.
Solution: Temporarily set CompoundIdentitySupported to $false. This step causes

AD FS 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 AD FS
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 Directory and select Edit Claim Rules.
3. On the Edit Claim Rules for Active Director click Add Rule.
type drop-down.
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 Party Trusts and in the right pane, right-click
your RP and select Edit Claim Rules.
3. On the Issuance Transform Rules click Add Rule.
type drop-down.
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 AD FS and update it with Claim Rule as specified in steps above. When
authenticating to the Application using Windows Integrated Authentication provider of
AD FS, 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 =
od", Value = "https://schemas.microsoft.com/claims/multipleauthn");'
Configure AD FS support for user certificate
authentication
Article • 08/15/2023
This article describes how to enable user certificate authentication in Active Directory Federation Services (AD FS). It
also provides troubleshooting information for common problems with this type of authentication.
There are two main use cases for user certificate authentication:
Users are using smart cards to sign in against their AD FS system.

Users are using certificates provisioned to mobile devices.
Prerequisites
Determine the mode of AD FS user certificate authentication that you want to enable by using one of the modes
described in AD FS support for alternate hostname binding for certificate authentication.
Ensure that your user certificate trust chain is installed and trusted by all AD FS and Web Application Proxy (WAP)
servers, including any intermediate certificate authorities. You usually do this via Group Policy Object (GPO) on AD
FS and WAP servers.
Ensure that the root certificate of the chain of trust for your user certificates is in the NTAuth store in Active
Directory.
If you're using AD FS in alternate certificate authentication mode, ensure that your AD FS and WAP servers have
Secure Sockets Layer (SSL) certificates that contain the AD FS hostname prefixed with "certauth." An example is
certauth.fs.contoso.com . Also ensure that traffic to this hostname is allowed through the firewall.
If you're using certificate authentication from the extranet, ensure that at least one Authority Information Access
(AIA) and at least one CRL distribution point (CDP) or Online Certificate Status Protocol (OCSP) location from the
list specified in your certificates are accessible from the internet.
If you're configuring AD FS for Azure Active Directory (Azure AD) certificate authentication, ensure that you've
configured the Azure AD settings and the AD FS claim rules required for certificate issuer and serial number.
If you're using Azure AD certificate authentication for Exchange ActiveSync clients, the client certificate must have
the user's routable email address in Exchange Online in either the Principal Name value 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.
７ Note
AD FS doesn't support username hints with smart card or certificate-based authentication.
Enable user certificate authentication

Enable user certificate authentication as an intranet or extranet authentication method in AD FS, by using either the AD
FS Management console or the PowerShell cmdlet Set-AdfsGlobalAuthenticationPolicy .
Optional considerations include:
If you want to use claims based on certificate fields and extensions in addition to the EKU claim type,
https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku , configure more claim passthrough
rules on the Active Directory claims provider trust. See the complete list of available certificate claims later in this
article.
If you need to restrict access based on the type of certificate, you can use the additional properties on the
certificate in AD FS issuance authorization rules for the application. Common scenarios are to allow only
certificates provisioned by a mobile device management (MDM) provider or to allow only smart card certificates.
） Important
Customers who use device code flow for authentication and perform device authentication by using an
identity provider other than Azure AD (for example, AD FS) can't enforce device-based access for Azure AD
resources. For example, they can't allow only managed devices by using a third-party MDM service.
To help protect access to corporate resources in Azure AD and prevent any data leakage, configure Azure AD
device-based Conditional Access. For example, use Require device to be marked complaint to grant control
in Azure AD Conditional Access.
Configure allowed issuing certificate authorities for client certificates by using the guidance under "Management
of trusted issuers for client authentication" in the Schannel SSP technical overview.
Consider modifying sign-in pages to suit the needs of your users when they're doing certificate authentication. A
common case is to change Sign in with your X509 certificate to something more user friendly.
Configure seamless certificate authentication for the Chrome

browser on Windows desktops
When a machine has multiple user certificates (such as Wi-Fi certificates) that satisfy the purposes of client
authentication, the Chrome browser on Windows desktops will prompt users to select the right certificate. This prompt
might be confusing to users. To optimize this experience, you can set a policy for Chrome to automatically select the
right certificate.
You can set this policy manually by making a registry change, or you can configure it 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 certificate authentication for Chrome, see Chrome Enterprise policy list .
Troubleshoot certificate authentication

Use the following information to troubleshoot common problems when you've configured AD FS for certificate
authentication for users.
Check if certificate trusted issuers are configured properly in all AD FS and

WAP servers
If certificate trusted issuers aren't configured properly, a common symptom is an HTTP 204 error: "No content from
https://certauth.adfs.contoso.com."
AD FS uses the underlying Windows operating system to prove possession of the user certificate and ensure that it
matches a trusted issuer by validating the certificate trust chain. To match the trusted issuer, you need to ensure that
all root and intermediate authorities are configured as trusted issuers in the local store for computer certificate
authorities.
To validate this automatically, use the AD FS Diagnostics Analyzer tool . The tool queries all the servers and ensures
that the right certificates are provisioned correctly.
1. Download and run the tool.

2. Upload the results and review for any failures.
Check if certificate authentication is enabled in the AD FS authentication

policy
AD FS performs user certificate authentication by default on port 49443 with the same hostname as AD FS (example:
adfs.contoso.com ). You can also configure AD FS to use port 443 (the default HTTPS port) by using the alternate SSL
binding. However, the URL used in this configuration is certauth.<adfs-farm-name> (example: certauth.contoso.com ).
For more information, see AD FS support for alternate hostname binding for certificate authentication.
７ Note
In AD FS on Windows Server 2016, two modes are now supported. The first mode uses the host adfs.contoso.com
with ports 443 and 49443. The second mode uses hosts adfs.contoso.com and certauth.adfs.contoso.com with
port 443. You need an SSL certificate to support certauth.\<adfs-service-name> as an alternate subject name. You
can do this at the time of farm creation or later via PowerShell.
The most common case of network connectivity problems is that a firewall has been incorrectly configured and blocks
traffic for user certificate authentication. Usually, you see a blank screen or a 500 server error when this problem
occurs. To fix it:
1. Note the hostname and port that you configured in AD FS.

2. Ensure that any firewall in front of AD FS or WAP is configured to allow the hostname:port combination for your
AD FS farm. Your network engineer must perform this step.
Check CRL connectivity

Certificate revocation lists (CRLs) are endpoints that are encoded into the user certificate to perform runtime
revocation checks. For example, if a device that contains a certificate is stolen, an administrator can add the certificate
to the list of revoked certificates. Any endpoint that accepted this certificate earlier will now fail the authentication.
Every AD FS and WAP server needs to reach the CRL endpoint to validate if the certificate that was presented to it is
still valid and hasn't been revoked. CRL validation can occur over HTTPS, HTTP, LDAP, or OCSP. If AD FS and WAP
servers can't reach the endpoint, the authentication will fail. Use the following steps to troubleshoot it:
1. Consult with your public key infrastructure (PKI) engineer to determine which CRL endpoints are used to revoke
user certificates from your PKI system.
2. On each AD FS and WAP server, ensure that the CRL endpoints are reachable via the protocol that's used
(typically HTTPS or HTTP).
3. For advanced validation, enable CAPI2 event logging on each AD FS and 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 technique allows you to enable tracing by targeting a server.
Check for SNI problems

AD FS requires client devices (or browsers) and the load balancers to support Server Name Indication (SNI). Some
client devices (for example, older versions of Android) might not support SNI. Additionally, load balancers might not
support SNI or might not be configured for SNI. In these instances, you're likely to get user certification failures.
To fix this problem, work with your network engineer to ensure that the load balancer for AD FS and WAP supports SNI.
If SNI can't be supported, use the following workaround in AD FS:
1. Open an elevated Command Prompt window on the primary AD FS server.

2. Enter Netsh http show sslcert .
3. Copy the application GUID and certificate hash of the federation service.
4. Enter 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 might notice that some devices are working correctly but other devices are not. In most cases, it means that the
user certificate wasn't provisioned correctly on some client devices. Follow these steps:
1. If the problem is specific to an Android device, the most common cause is that the certificate chain is not fully
trusted on the 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.
If the issue is specific to a Windows device, check if the certificate is provisioned correctly by checking the
Windows certificate store for the logged-in user (not system or computer).
2. Export the client user certificate to a .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 is updated to support only a higher version of TLS (for example, 1.3). Or you might have
the reverse problem, where AD FS and WAP servers were updated to use only a higher TLS version that the client
device doesn't support.
You can use online SSL tools to check your AD FS and WAP servers and see if they're compatible with the device. For
more information on how to control the TLS versions, see Managing SSL/TLS protocols and cipher suites for AD FS.
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 configured certificate authentication in AD FS, your users see only a password
login. To fix this problem:
1. Get the federated domain settings by using the Get-MsolDomainFederationSettings cmdlet.

2. Ensure that the PromptLoginBehavior parameter is set to either Disabled or NativeSupport .
For more information, see AD FS prompt=login parameter support.
Additional troubleshooting
In a rare occurrence, if your CRL lists are very long, they might hit a time-out when attempting to download. In this
case, you need to update MaxFieldLength and MaxRequestByte as described in Http.sys registry settings for Windows .
Reference: Complete list of user certificate claim types and
example values
Claim type Example value
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:1 8
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users,

DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users,

DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate

data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd
36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal

Name=user@contoso.com, RFC822
Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4
Related links
Configure alternate hostname binding for AD FS certificate authentication
Configure certificate authorities in Azure AD
Configure Azure AD Multi-Factor
Authentication as authentication
provider using AD FS
Article • 06/30/2023
The information in this article applies to Windows 2016 and later.
If your organization is federated with Azure AD, you can use Azure AD Multi-Factor
Authentication to secure Active Directory Federation Services (AD FS) resources, both on-
premises and in the cloud. Azure AD Multi-Factor Authentication enables you to eliminate
passwords and provide a more secure way to authenticate. With AD FS, you can configure
Azure AD Multi-Factor Authentication for primary authentication or use it as an extra
authentication provider.
Unlike with AD FS in Windows Server 2012 R2, the AD FS 2016 Azure AD Multi-Factor
Authentication adapter integrates directly with Azure AD and doesn't require an on
premises Azure AD Multi-Factor Authentication server. The Azure AD Multi-Factor
Authentication adapter is built into Windows Server 2016. No other installation is
required.
Register users for Azure AD Multi-Factor

Authentication by using AD FS
AD FS doesn't support inline "proofup" registration of Azure AD Multi-Factor
Authentication security verification information, such as on a phone number or mobile
app. Without support for inline proof, users must get proofed up by visiting
https://account.activedirectory.windowsazure.com/Proofup.aspx before they use Azure
AD Multi-Factor Authentication to authenticate to AD FS applications.
When a user that
hasn't yet proofed up in Azure AD tries to authenticate with Azure AD Multi-Factor
Authentication at AD FS, they 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
create this message by using onload.js customization to detect the error message string
within the AD FS page. Then you can show a new message to direct the user to
https://aka.ms/mfasetup so that they can reattempt authentication. For more
information, see Customize the AD FS web page to guide users to register MFA
verification methods.
７ Note
Prior to this update, users had to authenticate by using Azure AD Multi-Factor
Authentication for registration by visiting
https://account.activedirectory.windowsazure.com/Proofup.aspx . With this
update, an AD FS user who hasn't yet registered Azure AD Multi-Factor
Authentication verification information can access the Azure proofup page by using
the shortcut https://aka.ms/mfasetup with only primary authentication, such as
Windows Integrated Authentication or username and password at the AD FS web
pages. If the user has no verification methods configured, Azure AD performs inline
registration. The user sees the message, "Your admin has required that you set up
this account for additional security verification." Then the user selects Set it up now.
Users who already have at least one verification method configured will still be
prompted to provide multi-factor authentication (MFA) when visiting the proofup
page.
Recommended deployment topologies

This section covers using Azure AD Multi-Factor Authentication as the primary
authentication method with AD FS and Azure AD Multi-Factor Authentication for Office
365.
Azure AD Multi-Factor Authentication as primary

authentication
There are a couple of great reasons to use Azure AD Multi-Factor Authentication as
Primary Authentication with AD FS:
It avoids passwords for sign-in to Azure AD, Office 365, and other AD FS apps.
It protects password based sign-in by requiring another factor, such as verification
code prior to the password.
You also might want to use Azure AD Multi-Factor Authentication as the primary
authentication method and Azure AD conditional access, including true MFA by
prompting for extra factors. To use Azure AD MFA on premises, you can configure the
Azure AD domain setting by setting SupportsMfa to $true . In this configuration, Azure
AD can prompt AD FS to perform extra authentication or "true MFA" for conditional
access scenarios that require it.
Any AD FS user who isn't registered (hasn't yet configured MFA verification information),
should be prompted to configure verification information. To prompt unregistered users,
you can use a customized AD FS error page to direct users to https://aka.ms/mfasetup
and configure verification information. After configuration, the user can reattempt their
AD FS sign-in.
Azure AD Multi-Factor Authentication as primary authentication is considered a single

factor. After initial configuration users need to provide another factor to manage or
update their verification information in Azure AD, or to access other resources that
require MFA.
７ Note
With AD FS 2019, you're required to make a modification to the anchor claim type
for the Active Directory Claims Provider trust and modify this from the
windowsaccountname to User Principal Name (UPN). Run the following PowerShell
cmdlet. This has no effect on the internal functioning of the AD FS farm. It's possible
a few users might be re-prompted for credentials after this change is made. After
logging in again, end users will see no difference.
PowerShell
Set-AdfsClaimsProviderTrust -AnchorClaimType
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -TargetName
"Active Directory"
Azure AD Multi-Factor Authentication as extra

authentication to Office 365
Azure AD Multi-Factor Authentication adapter for AD FS enables your users to do MFA on
AD FS. To secure your Azure AD resource, you should require MFA through a Conditional
Access policy. You must also set the domain setting SupportsMfa to $true and emit the
multipleauthn claim when a user performs two-step verification successfully.
As described previously, any AD FS user who isn't registered (hasn't yet configured MFA
verification information) should be prompted to configure verification information. To
prompt unregistered users, you can use a customized AD FS error page to direct users to
https://aka.ms/mfasetup and configure verification information. After configuration, the
user can reattempt their AD FS sign-in.
Prerequisites
The following prerequisites are required when you use Azure AD Multi-Factor
Authentication for authentication with AD FS:
An Azure subscription with Azure Active Directory .
Azure AD Multi-Factor Authentication.
７ Note
Azure AD and Azure AD Multi-Factor Authentication are included in Azure AD

Premium and the Enterprise Mobility Suite (EMS). You don't need individual
subscriptions if you have either of these applications installed.
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 must be federated with Azure AD.

Microsoft Azure Active Directory Module for Windows PowerShell.
Global administrator permissions on your instance of Azure AD to configure it by
using Azure AD PowerShell.
Enterprise administrator credentials to configure the AD FS farm for Azure AD Multi-
Factor Authentication.
Configure the AD FS Servers

In order to complete configuration for Azure AD Multi-Factor Authentication for AD FS,
you need to configure each AD FS server by using the steps described here.
７ Note
Ensure that these steps are performed on all AD FS servers in your farm. If you've
multiple AD FS servers in your farm, you can perform the necessary configuration
remotely by using Azure AD PowerShell.
Step 1: Generate a certificate for Azure AD Multi-Factor

Authentication on each AD FS server
The first thing you need to do is to use the New-AdfsAzureMfaTenantCertificate
PowerShell command to generate a certificate for Azure AD Multi-Factor Authentication
to use. After you generate the certificate, find it in the local machines certificate store. The
certificate is marked with a subject name containing the TenantID for your Azure AD
directory.
The TenantID is the name of your directory in Azure AD. Use the following PowerShell
cmdlet to generate the new certificate:
PowerShell
$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 by using the New-AdfsAzureMFaTenantCertificate
cmdlet serve as these credentials. Open PowerShell, and perform the following steps 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 by using Connect-MsolService . These steps assume you've already
connected via PowerShell. For information, see Connect-MsolService.
Step 3: Set the certificate as the new credential against the

Azure Multi-Factor Auth Client
PowerShell
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 haven't had 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

After you've completed the steps in the previous section for each AD FS server, set the
Azure tenant information by using the Set-AdfsAzureMfaTenant cmdlet. This cmdlet
needs to be executed only once for an AD FS farm.
Open PowerShell, 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 your farm before these
changes take effect. For minimal impact, take each AD FS server out of the NLB
rotation one at a time and wait for all connections to drain.
PowerShell
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 if you aren't in the Azure Government cloud:
1. Open Registry Editor on the AD FS server.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS. Create the

following registry key values:
Registry Value
key
SasUrl https://adnotifications.windowsazure.us/StrongAuthenticationService.svc/Connector
StsUrl https://login.microsoftonline.us
ResourceUri https://adnotifications.windowsazure.us/StrongAuthenticationService.svc/Connector
3. Restart the AD FS service on each server in the farm before these changes take
effect. To reduce the effect on your systems, take each AD FS server out of the NLB
rotation one at a time and wait for all connections to drain.
After this step, you'll see that Azure AD Multi-Factor Authentication is available as a
primary authentication method for intranet and extranet use.
If you want to use Azure AD Multi-Factor Authentication as a secondary authentication
method, on the Edit Authentication Methods box, select the Multi-factor tab (the
Additional tab in AD FS 2019) and ensure that it's enabled. Otherwise you might receive
error messages, such as, "No valid strong authentication method found. Contact your
administrator to configure and enable an appropriate strong authentication provider."
Renew and Manage AD FS Azure AD Multi-

Factor Authentication Certificates
The following guidance is designed to help you manage the Azure AD Multi-Factor
Authentication certificates on your AD FS servers.
By default, when you configure AD FS with Azure AD Multi-Factor Authentication, the

certificates generated via the New-AdfsAzureMfaTenantCertificate PowerShell cmdlet are
valid for two years. To determine how close to expiration your certificates are, and to
renew and install new certificates, use the following procedure.
1. Assess AD FS Azure AD Multi-Factor Authentication certificate expiration date.

On each AD FS server, in the local computer My store, there's a self signed
certificate with "Microsoft AD FS Azure AD Multi-Factor Authentication" in the Issuer
and Subject area. This certificate is the Azure AD Multi-Factor Authentication
certificate. Check the validity period of this certificate on each AD FS server to
determine the expiration date.
2. Create a new AD FS Azure AD Multi-Factor Authentication 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 AD Multi-Factor Authentication certificate on each AD FS
server. In PowerShell generate a new certificate on each AD FS server by using the
following cmdlet:
Ｕ Caution
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.
PowerShell
$newcert = New-AdfsAzureMfaTenantCertificate -TenantId <tenant id such

as contoso.onmicrosoft.com> -Renew $true
If the certificate hasn't already expired, the command generates a new certificate
that is valid from two days after the current day to two years plus two days in the
future. AD FS and Azure AD Multi-Factor Authentication operations aren't affected
when running the cmdlet or renewing the certificate. The two-day delay is
intentional and provides time to follow the next steps to configure the new
certificate in the tenant before AD FS starts by using it for Azure AD Multi-Factor
Authentication.
3. Configure each new AD FS Azure AD Multi-Factor Authentication certificate in the

Azure AD tenant.
With the Azure AD PowerShell module, for each new certificate (on each AD FS
server), update your Azure AD tenant settings as follows. You must first connect to
the tenant by using Connect-MsolService to run the following commands.
PowerShell
New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-
a875-f8b09b8cd720 -Type Asymmetric -Usage Verify -Value $newcert
If your previous certificate is 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.
4. Verify that the new certificate(s) is used for Azure AD Multi-Factor Authentication.
After the new certificate(s) become valid, AD FS will pick them up and use each respective
certificate for Azure AD Multi-Factor Authentication within a few hours to one day. After
AD FS uses the new certificates, on each server you'll see an event logged in the AD FS
Admin event log with the following information:
Output
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 haven't yet
proofed up (configured MFA verification information).
Find the error

First, AD FS returns a couple of different error messages when the user lacks verification
information.
If you're using Azure AD Multi-Factor Authentication as primary
authentication, the unproofed user sees an AD FS error page containing the following
messages:
HTML
<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 extra authentication is being attempted, the unproofed user sees an
AD FS error page containing the following messages:
HTML
<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, append the JavaScript to the end
of the onload.js file that's part of the AD FS web theme. Doing so allows you to:
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 Advanced
Customization of AD FS Sign-in Pages.
The following steps show a simple example:
1. Open Windows PowerShell on your primary AD FS server, and create a new AD FS

Web Theme by running the following command.
PowerShell
New-AdfsWebTheme –Name ProofUp –SourceName default
2. Create the folder, and export the default AD FS Web Theme.
PowerShell
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:
JavaScript
//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.
After you've 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 entering the following Windows
PowerShell command:
PowerShell
Set-AdfsWebTheme -TargetName ProofUp -AdditionalFileResource

@{Uri='/adfs/portal/script/onload.js';path="c:\theme\script\onload.js"}
7. Apply the custom AD FS Web Theme by entering the following Windows PowerShell
command:
PowerShell
Set-AdfsWebConfig -ActiveThemeName "ProofUp"
Related links
Manage SSL/TLS protocols and cipher suites for AD FS
Configure AD FS Extranet Lockout
Protection
Article • 08/15/2023
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 isn't 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 three 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 won't increase while the account is soft-locked out.
ExtranetObservationWindow <TimeSpan> this determines for how long the user
account will be soft-locked out. AD FS will start to perform username and
password authentication again when the window is passed. AD FS uses the AD
attribute badPasswordTime as the reference for determining whether the extranet
observation window has passed or not. The window has passed if current time >
badPasswordTime + ExtranetObservationWindow.
７ Note
AD FS extranet lockout functions independently from the AD lockout policies.

However, we strongly recommend that you set the ExtranetLockoutThreshold
parameter value to a value that's 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:
PowerShell

-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'll 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 doesn't send the credentials to AD. AD
FS doesn't 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:
PowerShell

-ExtranetObservationWindow (new-timespan -Minutes 30) -
ExtranetLockoutRequirePDC $false
Working with the Active Directory lockout

policy
The Extranet Lockout feature in AD FS works independently from the AD lockout policy.
However, you do need to make sure the settings for the Extranet Lockout is properly
configured so that it can serve its security purpose with the AD lockout policy.
Let's take a look at AD lockout policy first. There are three settings regarding lockout
policy in AD:
Account Lockout Threshold: this setting is similar to the ExtranetLockoutThreshold

setting in AD FS. It determines the number of failed logon attempts that will cause
a user account to be locked out. In order to protect your user accounts from a
malicious account lockout attack, you want to set the value of
ExtranetLockoutThreshold in AD FS < the Account Lockout Threshold value in AD
Account Lockout Duration: this setting determines for how long a user account is
locked out. This setting doesn't matter much in this conversation as Extranet
Lockout should always happen before AD lockout happens if configured properly
Reset Account Lockout Counter After: this setting determines how much time
must elapse from user's last logon failure before badPwdCount is reset to 0. In
order for Extranet Lockout feature in AD FS to work well with AD lockout policy,
you want to make sure the value of ExtranetObservationWindow in AD FS > the
Reset Account Lockout Counter After value in AD. The examples below will explain
why.
Let's take a look at two examples and see how badPwdCount changes over time based
on different settings and states. Let's assume in both examples Account Lockout
Threshold = 4 and ExtranetLockoutThreshold = 2. The red arrow represents bad
password attempt, the green arrow represents a good password attempt. In example #1,
ExtranetObservationWindow > Reset Account Lockout Counter After. In example #2,
ExtranetObservationWindow < Reset Account Lockout Counter After.
Example 1
Example 2
As you can see from the above, there are two conditions when badPwdCount will be
reset to 0. One is when there's a successful logon. The other is when it's time to reset
this counter as defined in Reset Account Lockout Counter After setting. When Reset
Account Lockout Counter After < ExtranetObservationWindow, an account doesn't
have any risk of being locked out by AD. However, if Reset Account Lockout Counter
After > ExtranetObservationWindow, there's 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's a known issue where the AD user account can't authenticate with AD FS because
the badPwdCount attribute isn't 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 doesn't 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 can't 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 isn't available.
AD FS will allow authentication requests from extranet if badPwdCount <
ExtranetLockoutThreshold
If badPwdCount >= ExtranetLockoutThreshold AND badPasswordTime +
ExtranetObservationWindow < Current time, AD FS will reject authentication
requests from extranet
To avoid malicious account lockout, you should make sure
ExtranetLockoutThreshold < Account Lockout Threshold AND
ExtranetObservationWindow > Reset Account Lockout Counter
Related links
Best practices for securing Active Directory Federation Services
Delegate AD FS Powershell Commandlet Access to Non-Admin Users
Set-AdfsProperties
AD FS Operations
AD FS Extranet Lockout and Extranet
Smart Lockout Overview
Article • 06/19/2023
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 might be an attacker. AD FS can lock out
attackers while letting valid users continue to use their accounts. This distinction
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 username and password authentication requests that come
through the extranet with the Web Application Proxy or a third party proxy. Any third
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 third party
proxy documentation to determine if the proxy supports the MS-ADFSPIP protocol.
Features in AD FS 2019
Extranet Smart Lockout in AD FS 2019 adds the following advantages compared to AD
FS 2016:
Independent lockout thresholds for familiar and unfamiliar locations. Users in

known good locations can have more room for error than requests from suspicious
locations.
Audit mode for smart lockout while continuing to enforce previous soft lockout
behavior. This distinction lets you learn about user-familiar locations and still be
protected by the extranet lockout feature that's available from AD FS 2012 R2.
Configuration information
When ESL is enabled, a new table in the Artifact database,
AdfsArtifactStore.AccountActivity , is created. A node is also selected in the AD FS
farm as the “User Activity” primary node. In a Windows Internal Database (WID)
configuration, this node is always the primary node. In a SQL configuration, one node is
selected to be the User Activity primary node.
To view the node selected as the "User Activity" primary node, use (Get-
AdfsFarmInformation).FarmRoles .
All secondary nodes contact the primary node on each fresh sign-in through Port 80 to
learn the latest value of the bad password counts and new familiar location values.
Secondary nodes also update the primary node after the sign-in is processed.
If the secondary node can't contact the primary node, the secondary node writes error
events into the AD FS admin log. Authentications continue to be processed, but AD FS
only writes the updated state locally. AD FS retries contacting the primary node every 10
minutes. AD FS switches back to the primary node once the primary node is available.
Terminology
FamiliarLocation: During an authentication request, ESL checks all presented
Internet Protocols (IPs). These IPs are a combination of network IP, forwarded IP,
and the optional x-forwarded-for IP. If the request is successful, all 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 is 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 is treated as an “Unknown” location.
This action handles 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, AD FS rejects requests from
the extranet until the observation window has passed.
ExtranetObservationWindow: This value determines the duration that username
and password requests from unknown locations are locked out. When the window
has passed, AD FS starts 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 falls back to another
domain controller in case the PDC is unavailable.
ExtranetLockoutMode: Controls Log-Only vs Enforced mode of ESL.
ADFSSmartLockoutLogOnly: ESL is enabled. AD FS writes admin and audit
events but doesn't reject authentication requests. This mode is intended to be
enabled for FamiliarLocation to be populated before
ADFSSmartLockoutEnforce is enabled.
ADFSSmartLockoutEnforce: 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 are a combination of network IP, forwarded IP, and the optional x-
forwarded-for IP. In the audit logs, these IPs are listed in the <IpAddress> field in
the order of x-ms-forwarded-client-ip, x-forwarded-for, x-ms-proxy-client-ip.
Based on these IPs, AD FS determines if the request is from a familiar location and
then checks if the respective badPwdCount is less than the set threshold limit or if
the last failed attempt happened longer than the observation window time frame.
If one of these conditions is true, AD FS 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. In
Windows Server 2019, AD FS checks against the appropriate threshold limit based
on if the IP address matches a familiar location.
Successful Login: If the login succeeds, then the IPs from the request are added to
the user's familiar location IP list.
Failed Login: If the login fails, the badPwdCount is increased. The user goes into a
lockout state if the attacker sends more bad passwords to the system than the
threshold allows. (badPwdCount > ExtranetLockoutThreshold)
The UnknownLockout value equals True when the account is locked out. This lockout
means that the user's badPwdCount is over the threshold. For example, someone
attempted more passwords than the system allows. In this state, there are two ways that
a valid user can sign in:
Wait for the ObservationWindow time to elapse.

In order to reset the Lockout state, reset the badPwdCount back to zero with
Reset-ADFSAccountLockout.
If no resets occur, the account is allowed a single password attempt against AD for each
observation window. After that attempt, the account returns to the locked-out state, and
the observation window restarts. The badPwdCount value only resets automatically after
a successful password sign-in.
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 aren't known to AD FS. ESL
then behaves 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 where UnknownLockout equals True
and attempts to sign in with a good password from an IP that isn't in the “familiar” IP
list, then they aren't 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

The following sections describe the prerequisites and configurations for enabling ESL for
AD FS 2016.
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 runs at the 2016 farm
behavior level.
2. Verify Permissions.
ESL requires that Windows Remote management is enabled on every AD FS server.
3. Update artifact database permissions.
ESL requires the AD FS service account to have permissions to create a new table in
the AD FS artifact database. Sign in to any AD FS server as an AD FS admin. Then
grant this permission in a PowerShell Command Prompt window by running the
following commands:
PowerShell
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 previous commands might fail due to lack of sufficient permission because
your AD FS farm uses SQL Server, and the credential provided previously doesn't
have admin permission on your SQL server. In this case, you can configure
database permissions manually in SQL Server Database when you're connected to
the AdfsArtifactStore database by running the following command:
# 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 AD FS configuration file."
return
$doc = new-object Xml
$doc.Load($fileLocation)
$connString =
$doc.configuration.'microsoft.identityServer.service'.policystore.conne
ctionString
$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 and
the local policy on all AD FS servers.
Configuration Instructions
ESL uses the AD FS property ExtranetLockoutEnabled. This property was previously
used to control Extranet Soft Lockout in Server 2012 R2. If ESL is enabled, and you want
to view the current property configuration, run Get-AdfsProperties .
Configuration Recommendations
When configuring ESL, 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 ESL. However, if Active Directory
lockout is enabled, select ExtranetLockoutThreshold in AD FS and 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 falls back to another domain
controller in case the PDC is unavailable.
To set this property run:
PowerShell

-ExtranetObservationWindow (New-TimeSpan -Minutes 30) -
ExtranetLockoutRequirePDC $false
Enable Log-Only Mode

In Log-Only mode, AD FS populates a user's familiar location information and writes
security audit events but doesn't 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 sign-in activity per user
(whether in Log-Only mode or Enforce mode).
Set the lockout behavior to Log-Only by
running the following cmdlet:
Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly
Log-Only mode is intended to be a temporary state so that the system can learn sign-in
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 run for a minimum of 24 hours.
On AD FS 2016, if 2012 R2 Extranet Soft Lockout behavior is enabled prior to enabling

Extranet Smart Lockout, Log-Only mode disables the Extranet Soft Lockout behavior. AD
FS Smart Lockout doesn't lock out users in Log-Only mode. However, on-premises AD
might lock out the user based on the AD configuration. Review AD Lockout policies to
learn how on-premises AD can lock out users.
On AD FS 2019, another advantage is to be able to enable Log-Only mode for smart

lockout while continuing to enforce the previous soft lockout behavior by 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 by
using:
Restart-service adfssrv
Once the mode is configured, you can enable smart lockout by 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 primary role.
７ Note
You can use Just Enough Administration (JEA) to delegate AD FS commandlets to

reset account lockouts. For example, you can delegate permissions to Help Desk
personnel to use ESL commandlets. For more information, see Delegate AD FS
Powershell commandlet access to nonadmin Users.
You can override this behavior by passing the -Server parameter.
Get-ADFSAccountActivity -UserPrincipalName
The cmdlet automatically connects to the farm primary node by using the Account
Activity REST endpoint. Therefore, all data should always be consistent. Read the current
account activity for a user account by using:
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 that is True if the BadPwdCountFamiliar >
ExtranetLockoutThreshold.
UnknownLockout: Boolean value that is True if the BadPwdCountUnknown >
ExtranetLockoutThreshold.
FamiliarIPs: maximum of 20 IPs that are familiar to the user. When 20 IPs is
exceeded, the oldest IP in the list is removed.
Set-ADFSAccountActivity
Set-ADFSAccountActivity adds new familiar locations. The familiar IP list has a
maximum of 20 entries. If 20 entries are exceeded, the oldest IP in the list is 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 counter (badPwdCountUnfamiliar).
When you reset a counter, the FamiliarLockout or UnfamiliarLockout value updates, as
the reset counter is 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
The following sections describe how to monitor event logging, user account activity, and
lockouts.
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 that exceed designated threshold. Email notifications can be set
to alert administrators with customizable email settings when failed AD FS sign-in
activities occur. For more information and setup instructions, see Monitor AD FS using
Azure AD Connect Health.
AD FS Extranet Smart Lockout events
７ Note
To troubleshoot ESL, see Mitigating password spray attacks and account

lockouts .
For Extranet Smart Lockout events to be written, ESL must be enabled in Log-Only or
Enforce mode, and AD FS security auditing must be enabled.
AD FS writes extranet
lockout events to the security audit log when:
A user is locked out, meaning that user reaches the lockout threshold for
unsuccessful sign-in attempts.
AD FS receives a sign-in attempt for a user who is already in a 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 by using the Get-ADFSAccountActivity
cmdlet to determine if the lockout occurred from familiar or unfamiliar IP addresses. You
can also use the Get-ADFSAccountActivity cmdlet to double check the list of familiar IP
addresses for that user.
Event Description
ID
1203 This event is written for each bad password attempt. As soon as the badPwdCount
reaches the value specified in ExtranetLockoutThreshold, the account is locked out on
AD FS for the duration specified in ExtranetObservationWindow.
Activity ID: %1
XML: %2
1210 This event is written each time a user is locked out.
Activity ID: %1
XML: %2
Event Description
ID
557 An error occurred while trying to communicate with the account store rest service on
(AD node %1. If you use a WID farm, the primary node might be offline. If you use a SQL farm,
FS AD FS automatically selects a new node to host the user store primary role.
2019)
562 An error occurred when communicating with the account store endpoint on server %1.
(AD Exception Message: %2

FS
2019)
563 An error occurred while calculating extranet lockout status. Due to the value of the %1,
(AD setting authentication is allowed for this user, and token issuance continues. If you use a
FS WID farm, the primary node might be offline. If you use a SQL farm, AD FS automatically
2019) selects a new node to host the user store primary role.
Account store server name: %2
User ID: %3
Exception Message: %4
512 The account for the following user is locked out. A sign-in 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
provided. This account might be compromised.
More Data
Activity ID: %1
User: %2
Client IP: %3
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 AD FS farm that uses Extranet Smart Lockout in Enforce mode ever see
malicious user lockouts?
If AD FS Smart Lockout is set to Enforce mode, then you 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 if ESL is enabled and the bad actor has a user's password?
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
doesn't block the access since the sign-in meets successful criteria of a 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 AD FS and to require multi factor
authentication for the users. You should install Azure AD Password Protection to ensure
guessable passwords don't get into the system.
If my user has never signed in successfully from an IP and then tries with a wrong
password a few times, will they be able to sign in once they finally type their
password correctly?
If a user submits multiple bad passwords (for example, by mistyping) and on the
following attempt gets the password correct, then the user immediately signs in
successfully. This successful sign-in clears the bad password count and adds that IP to
the FamiliarIPs list. However, if they go above the threshold of failed sign-ins from the
unknown location, they enter into lockout state. They must then wait past the
observation window and sign in with a valid password. They might require admin
intervention to reset their account.
Does ESL work on intranet too?
If the clients connect directly to the AD FS servers and not via Web Application Proxy
servers, then the ESL behavior doesn't apply.
I'm seeing Microsoft IP addresses in the Client IP field. Does ESL block EXO proxied
brute force attacks?  
ESL works 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 is in the x-ms-forwarded-client-ip, and the Microsoft
Exchange Online server IP is 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 aren't in the familiar list, then the request is marked as
unfamiliar. The familiar user is able to sign in successfully while requests from the
unfamiliar locations are blocked.
Can I estimate the size of the ADFSArtifactStore before enabling ESL?
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 1 GB per 100,000 users. If
the AD FS farm uses 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 5 GB of free storage before enabling ESL. In addition to disk storage, plan
for total process memory to grow after enabling ESL by up to 1 GB of RAM for a user
population of 500,000 or less.
See also
Set-AdfsProperties
AD FS Operations
AD FS and banned IP addresses
Article • 08/15/2023
AD FS on Windows Server 2016 introduced Banned IPs as part of 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 are blocked. Requests that have IP
addresses in the x-forwarded-for or x-ms-forwarded-client-ip headers are also blocked
by AD FS.
Adding banned IPs

To add banned IPs to the global list, use the below PowerShell cmdlet:
PowerShell
PS C:\ >Set-AdfsProperties -AddBannedIps "1.2.3.4", "::3", "1.2.3.4/16"
Allowed formats are as follows:
IPv4
IPv6
CIDR format with IPv4 or v6
There's 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 following PowerShell cmdlet:
PowerShell
PS C:\ >Set-AdfsProperties -RemoveBannedIps "1.2.3.4"
Reading banned IPs

To read the current set of banned IP addresses, use the following PowerShell cmdlet:
PowerShell
PS C:\ >Get-AdfsProperties
Example output:
BannedIpList : {1.2.3.4, ::3,1.2.3.4/16}
Related links
Set-AdfsProperties
AD FS Operations
Configure AD FS to authenticate users
stored in LDAP directories in Windows
Server 2016 or later
Article • 08/15/2023
The following topic describes the configuration required to enable your AD FS

infrastructure to authenticate users whose identities are stored in Lightweight Directory
Access Protocol (LDAP) v3-compliant directories.
In many organizations, identity management solutions consist of a combination of

Active Directory, AD LDS, or third-party LDAP directories. With the addition of AD FS
support for authenticating users stored in LDAP v3-compliant directories, you can
benefit from the entire enterprise-grade AD FS feature set regardless of where your user
identities are stored. AD FS supports any LDAP v3-compliant directory.
７ Note
Some of the AD FS features include single sign-on (SSO), device authentication,

flexible conditional access policies, support for work-from-anywhere through the
integration with the Web Application Proxy, and seamless federation with Azure AD
which in turn enables you and your users to utilize the cloud, including Office 365
and other SaaS applications. For more information, see Active Directory Federation
Services Overview.
In order for AD FS to authenticate users from an LDAP directory, you must connect this
LDAP directory to your AD FS farm by creating a local claims provider trust. A local
claims provider trust is a trust object that represents an LDAP directory in your AD FS
farm. A local claims provider trust object consists of a variety of identifiers, names, and
rules that identify this LDAP directory to the local federation service.
You can support multiple LDAP directories, each with its own configuration, within the
same AD FS farm by adding multiple local claims provider trusts. In addition, AD DS
forests that are not trusted by the forest that AD FS lives in can also be modeled as local
claims provider trusts. You can create local claims provider trusts by using Windows
PowerShell.
LDAP directories (local claims provider trusts) can co-exist with AD directories (claims
provider trusts) on the same AD FS server, within the same AD FS farm, therefore, a
single instance of AD FS is capable of authenticating and authorizing access for users
that are stored in both AD and non-AD directories.
Only forms-based authentication is supported for authenticating users from LDAP

directories. Certificate-based and Integrated Windows authentication are not supported
for authenticating users in LDAP directories.
All passive authorization protocols that are supported by AD FS, including SAML, WS-
Federation, and OAuth are also supported for identities that are stored in LDAP
directories.
The WS-Trust active authorization protocol is also supported for identities that are
stored in LDAP directories.
Configure AD FS to authenticate users stored in

an LDAP directory
To configure your AD FS farm to authenticate users from an LDAP directory, you can
complete the following steps:
1. First, configure a connection to your LDAP directory using the New-

AdfsLdapServerConnection cmdlet:
$DirectoryCred = Get-Credential
$vendorDirectory = New-AdfsLdapServerConnection -HostName dirserver -
Port 50000 -SslMode None -AuthenticationMethod Basic -Credential
$DirectoryCred
７ Note
It is recommended that you create a new connection object for each LDAP
server you want to connect to. AD FS can connect to multiple replica LDAP
servers and automatically fail over in case a specific LDAP server is down. For
such a case, you can create one AdfsLdapServerConnection for each of these
replica LDAP servers and then add the array of connection objects using the -
LdapServerConnection parameter of the Add-AdfsLocalClaimsProviderTrust
cmdlet.
NOTE: Your attempt to use Get-Credential and type in a DN and password to be

used to bind to an LDAP instance might result in a failure because 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
Configure AD FS to Send Password
Expiry Claims
Article • 08/15/2023
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.
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 Windows
Hello for Business 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
Article • 08/15/2023
In order to enable multi-factor authentication (MFA), you must select at least one extra
authentication method. By default, in Active Directory Federation Services (AD FS) in
Windows Server, you can select Certificate Authentication (in other words, smart card-
based authentication) as an extra 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 Active Directory 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 authentication

methods
You can also configure and enable Microsoft and third-party authentication methods in
AD FS in Windows Server. 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.
Provider Offering Link to learn more
Akamai Akamai MFA Integrating Akamai MFA with Microsoft

Technologies AD FS
aPersona aPersona Adaptive Multi-Factor aPersona ASM AD FS Adapter

Authentication for Microsoft AD FS
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 Futurae Strong Authentication

FS
Green Rocket GreenRADIUS MFA Adapter for AD GreenRADIUS MFA for AD FS

Security FS
inWebo inWebo Enterprise Authentication inWebo Enterprise Authentication

Technologies service
Microsoft Corp. Microsoft Azure MFA Configure Azure MFA as authentication

provider with AD FS
Mideye Mideye Authentication Provider for Mideye two-factor authentication with

AD FS Microsoft Active Directory Federation
Service
Okta Okta MFA for Active Directory Okta MFA for Active Directory
Federation Services Federation Services (AD FS)
One Identity Defender AD FS Defender AD FS Adapter
Ping Identity PingID MFA Adapter for AD FS PingID MFA Adapter for AD FS
RSA RSA SecurID Authentication Agent RSA SecurID Authentication Agent for
for Microsoft Active Directory Microsoft Active Directory Federation
Federation Services Services
SecureMFA SecureMFA OTP Provider AD FS Multi Factor Authentication

Providers
Swisscom Mobile ID Authentication Service and Mobile ID Authentication Service

Signature Services
Symantec Symantec Validation and ID Symantec Validation and ID Protection

Protection Service (VIP) Service (VIP)
Thales SafeNet Trusted Access (STA) Authentication with AD Federation

Services
Trusona Essential (passwordless MFA) and Trusona Multi-factor Authentication

Executive (Essential + Identity
Proofing)
Custom Authentication Method for AD FS in

Windows Server
We now provide instructions for building your own custom authentication method for
AD FS in Windows Server. For more information, see Build a Custom Authentication
Method for AD FS in Windows Server 2012 R2.
See Also
Manage Risk with Additional multi-factor authentication for Sensitive Applications
Configure Authentication Policies
Article • 08/15/2023
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
requirement to complete these procedures. Review details about using the appropriate
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
2. In AD FS snap-in, click Authentication Policies.
3. In the Primary Authentication section, click Edit next to Global Settings. You can
also right-click Authentication Policies, and select Edit Global Primary
Authentication, or, under the Actions pane, select Edit Global Primary
Authentication.
4. In the Edit Global Authentication Policy window, on the Primary tab, you can
configure the following settings as part of the global authentication policy:
Authentication methods to be used for primary authentication. You can select

available authentication methods under the Extranet and Intranet.
Device authentication via the Enable device authentication check box. For
more information, see Join to Workplace from Any Device for SSO and
Seamless Second Factor Authentication Across Company Applications.
To configure primary authentication per relying

party trust
2. In AD FS snap-in, click Authentication Policies\Per Relying Party Trust, and then

click the relying party trust for which you want to configure authentication policies.
3. Either right-click the relying party trust for which you want to configure
authentication policies, and then select Edit Custom Primary Authentication, or,
under the Actions pane, select Edit Custom Primary Authentication.
4. In the Edit Authentication Policy for <relying_party_trust_name> window, under

the Primary tab, you can configure the following setting as part of the Per Relying
Party Trust authentication policy:
Whether users are required to provide their credentials each time at sign-in
via the Users are required to provide their credentials each time at sign-in
check box.
To configure multi-factor authentication

globally
2. In AD FS snap-in, click Authentication Policies.
3. In the Multi-factor Authentication section, click Edit next to Global Settings. You
can also right-click Authentication Policies, and select Edit Global Multi-factor
Authentication, or, under the Actions pane, select Edit Global Multi-factor
Authentication.
4. In the Edit Global Authentication Policy window, under the Multi-factor tab, you
can configure the following settings as part of the global multi-factor
authentication policy:
Settings or conditions for MFA via available options under the Users/Groups,
Devices, and Locations sections.
To enable MFA for any of these settings, you must select at least one
additional authentication method. Certificate Authentication is the default
available option. You can also configure other custom additional
authentication methods, for example, Windows Azure Active Authentication.
For more information, see Walkthrough Guide: Manage Risk with Additional
Multi-Factor Authentication for Sensitive Applications.
２ Warning
You can only configure additional authentication methods globally.
To configure multi-factor authentication per

relying party trust
2. In AD FS snap-in, click Authentication Policies\Per Relying Party Trust, and then

click the relying party trust for which you want to configure MFA.
3. Either right-click the relying party trust for which you want to configure MFA, and
then select Edit Custom Multi-factor Authentication, or, under the Actions pane,
select Edit Custom Multi-factor Authentication.
4. In the Edit Authentication Policy for <relying_party_trust_name> window, under
the Multi-factor tab, you can configure the following settings as part of the per-
relying party trust authentication policy:
Settings or conditions for MFA via available options under the Users/Groups,
Devices, and Locations sections.
Configure authentication policies via Windows

PowerShell
Windows PowerShell enables greater flexibility in using various factors of access control
and the authentication mechanism that are available in AD FS in Windows Server 2012
R2 to configure authentication policies and authorization rules that are necessary to
implement true conditional access for your AD FS -secured resources.

requirement to complete these procedures. Review details about using the appropriate
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
run the following command:
`$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust`
２ Warning
Ensure to replace <relying_party_trust> with the name of your relying party trust.
2. In the same Windows PowerShell command window, run the following command.
$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/authenticationmet
hod'", Value '"https://schemas.microsoft.com/claims/multipleauthn'");"

AdditionalAuthenticationRules $MfaClaimRule
７ Note
Ensure to replace <group_SID> with the value of the security identifier (SID) of your
Active Directory (AD) group.
To configure MFA globally based on users' group

membership data
$MfaClaimRule = "c:[Type == '"

https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid'", Value
== '"group_SID'"]
=> issue(Type =
hod'", Value = '"https://schemas.microsoft.com/claims/multipleauthn'");"
Set-AdfsAdditionalAuthenticationRule $MfaClaimRule
７ Note
Ensure to replace <group_SID> with the value of the SID of your AD group.
To configure MFA globally based on user's location


https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork'", Value ==
'"true_or_false'"]
=> issue(Type =
７ 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


https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser'
", Value == '"true_or_false"']
=> issue(Type =
７ Note
Ensure to replace <true_or_false> with either true or false . The value depends on
your specific rule condition that is based on whether the device is workplace-joined
or not.
To configure MFA globally if the access request comes

from the extranet and from a non-workplace-joined
device
`Set-AdfsAdditionalAuthenticationRule "c:[Type ==
'"https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduse
r'", Value == '"true_or_false'"] && c2:[Type ==
'"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork'", Value
== '" true_or_false '"] => issue(Type =
hod'", Value ='"https://schemas.microsoft.com/claims/multipleauthn'");" `
７ Note
Ensure to replace both instances of <true_or_false> with either true or false ,

which depends on your specific rule conditions. The rule conditions are based on
whether the device is workplace-joined or not and whether the access request
comes from the extranet or intranet.
To configure MFA globally if access comes from an

extranet user that belongs to a certain group
Set-AdfsAdditionalAuthenticationRule "c:[Type ==
`"https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid`", Value
== `"group_SID`"] && c2:[Type ==
`"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork`", Value==
`"true_or_false`"] => issue(Type =
`"https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmet
hod`", 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
$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`");"
IssuanceAuthorizationRules $GroupAuthzRule
７ Note
Ensure to replace <group_SID> with the value of the SID of your AD group.
To grant access to an application that is secured by AD FS

only if this user's identity was validated with MFA
`$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust `
７ Note
$GroupAuthzRule = "@RuleTemplate = `"Authorization`"

@RuleName = `"PermitAccessWithMFA`"
c:[Type ==
`"https://schemas.microsoft.com/claims/authnmethodsreferences`", Value
=~ `"^(?i)https://schemas\.microsoft\.com/claims/multipleauthn$`"] =>
issue(Type =
`"https://schemas.microsoft.com/authorization/claims/permit`", Value =
'"PermitUsersWithClaim'");"

only if the access request comes from a workplace-joined
device that is registered to the user
$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust
７ Note

@RuleName = `"PermitAccessFromRegisteredWorkplaceJoinedDevice`"
c:[Type ==
`"https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduse
r`", Value =~ `"^(?i)true$`"] => issue(Type =
`"PermitUsersWithClaim`");

only if the access request comes from a workplace-joined
device that is registered to a user whose identity has
been validated with MFA
`$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust `
７ Note
$GroupAuthzRule = '@RuleTemplate = "Authorization"

@RuleName = "RequireMFAOnRegisteredWorkplaceJoinedDevice"
c1:[Type ==
`"https://schemas.microsoft.com/claims/authnmethodsreferences`", Value
=~ `"^(?i)http://schemas\.microsoft\.com/claims/multipleauthn$`"] &&
c2:[Type ==
`"https://schemas.microsoft.com/2012/01/devicecontext/claims/isregister
eduser`", Value =~ `"^(?i)true$"] => issue(Type =
"https://schemas.microsoft.com/authorization/claims/permit`", Value =
`"PermitUsersWithClaim`");"
To grant extranet access to an application secured by AD

FS only if the access request comes from a user whose
identity has been validated with MFA
`$rp = Get-AdfsRelyingPartyTrust –Name relying_party_trust`
７ Note

@RuleName = `"RequireMFAForExtranetAccess`"
c1:[Type == `"https://schemas.microsoft.com/claims/authnmethodsreferences`",
Value =~ `"^(?i)http://schemas\.microsoft\.com/claims/multipleauthn$`"] &&
c2:[Type ==
`"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork`", Value
=~ `"^(?i)false$`"] => issue(Type =
`"PermitUsersWithClaim`");"
AD FS Operations
Configure Claim Rules in AD FS for
Windows Server
Article • 08/15/2023
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
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 an AD FS 1.x Compatible Claim
Create a Rule to Send Claims Using a Custom Rule
See Also
AD FS Operations
Configure On-Premises Conditional
Access using registered devices
Article • 08/15/2023
The following document will guide you through installing and configuring on-premises
conditional access with registered devices.
Infrastructure pre-requisites
The following per-requisites are required before you can begin with on-premises
conditional access.
Requirement Description
An Azure AD subscription with To enable device write-back for on premises conditional

Azure AD Premium 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 Schema level 85 or higher is required.

Directory schema
Windows Server 2016 domain This is only required for Hello For Business key-trust
controller deployments. Additional information can be found at here.
Requirement Description
Windows 10 client Build 10586 or newer, joined to the above domain is required
for Windows 10 Domain Join and Windows Hello for Business
scenarios only
Azure AD user account with For registering the device

Azure AD Premium license
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=<domain>,DC=
<com> 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):
PowerShell
Get-ADObject "cn=schema,cn=configuration,dc=domain,dc=local" -Property

objectVersion
For more 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 a new AD FS 2016 farm.
2. Or migrate a farm to AD FS 2016 from AD FS 2012 R2
3. Deploy Azure AD Connect using the Custom path to connect AD FS to Azure AD.
Configure Device Write Back and Device

Authentication
７ Note
If you ran Azure AD Connect using Express Settings, the correct AD objects have
been created for you. However, in most AD FS scenarios, Azure AD Connect was
run with Custom Settings to configure AD FS, so the below steps are necessary.
Create AD objects for AD FS Device Authentication

If your AD FS farm is not already configured for Device Authentication (you can see this
in the AD FS Management console under Service -> Device Registration), use the
following steps to create the correct AD DS objects and configuration.
Note: The below commands require Active Directory administration tools, so if your
federation server is not also a domain controller, first install the tools using step 1
below. Otherwise you can skip step 1.
1. Run the Add Roles & Features wizard and select feature Remote Server
Administration Tools -> Role Administration Tools -> AD DS and AD LDS Tools -
> Choose both the Active Directory module for Windows PowerShell and the AD
DS Tools.
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 Windows Hello for Business, 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
Windows Hello for Business

For information on enabling Windows 10 with Windows Hello for Business, see Enable
Windows Hello for Business in your organization.
Automatic MDM enrollment

To enable automatic MDM enrollment of registered devices so that you can use the
isCompliant claim in your access control policy, follow the steps here.
Troubleshooting
1. If you get an error on Initialize-ADDeviceRegistration that complains about an
object already existing in the wrong state, such as "The DRS service object has
been found without all the required attributes", you may have executed Azure AD
Connect PowerShell commands previously and have a partial configuration in AD
DS. Try deleting manually the objects under CN=Device Registration
Configuration,CN=Services,CN=Configuration,DC=<domain> and trying again.
2. For Windows 10 domain joined clients
a. To verify that device authentication is working, sign on to the domain joined
client as a test user account. To trigger provisioning quickly, lock and unlock the
desktop at least one time.
b. Instructions to check for STK key credential link on AD DS object (does sync still
have to run twice?)
3. If you get an error upon trying to register a Windows computer that the device
was already enrolled, but you are unable or have already unenrolled the device,
you may have a fragment of device enrollment configuration in the registry. To
investigate and remove this, use the following steps:
a. On the Windows computer, open Regedit and navigate to
HKLM\Software\Microsoft\Enrollments
b. Under this key, there will be many subkeys in the GUID form. Navigate to the
subkey that 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 Windows Integrated
Authentication (WIA)
Article • 08/15/2023
By default, Windows Integrated Authentication (WIA) is enabled in Active Directory

Federation Services (AD FS) in Windows Server for authentication requests that occur
within the organization's internal network (intranet) for any application that uses a
browser for its authentication. For example, applications can be browser-based 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 fall back to forms-based authentication for such
devices and browsers.
AD FS in Windows Server 2016 and Windows Server 2012 R2 provides the

administrators with the ability to configure the list of user agents that support the
fallback to forms-based authentication. The fallback is made possible by two
configurations:
The WIASupportedUserAgentStrings property of the Set-ADFSProperties

commandlet
The WindowsIntegratedFallbackEnabled property of the Set-
AdfsGlobalAuthenticationPolicy commandlet
The WIASupportedUserAgentStrings defines the user agents that support WIA. AD FS

analyzes the user agent string when performing logins in a browser or browser control.
If the component of the user agent string does not match any of the components of the
user agent strings that are configured in WIASupportedUserAgentStrings property, AD
FS will fall back to providing forms-based authentication, provided that the
WindowsIntegratedFallbackEnabled flag is set to True.
By default, a new AD FS installation has a set of user agent string matches created.
However, these may be out of date based on changes to browsers and devices.
Particularly, Windows devices have similar user agent strings with minor variations in the
tokens. The following Windows PowerShell example provides the best guidance for the
current set of devices that are on the market today that support seamless WIA:
PowerShell
Set-AdfsProperties -WIASupportedUserAgents @("MSIE 6.0", "MSIE 7.0; Windows

NT", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0; Windows NT 6", "Windows NT 6.3;
Trident/7.0", "Windows NT 6.3; Win64; x64; Trident/7.0", "Windows NT 6.3;
WOW64; Trident/7.0", "Windows NT 6.2; Trident/7.0", "Windows NT 6.2; Win64;
x64; Trident/7.0", "Windows NT 6.2; WOW64; Trident/7.0", "Windows NT 6.1;
Trident/7.0", "Windows NT 6.1; Win64; x64; Trident/7.0", "Windows NT 6.1;
WOW64; Trident/7.0", "MSIPC", "Windows Rights Management Client")
The command above will ensure that AD FS only covers the following use cases for WIA:
User Agents Use cases
MSIE 6.0 IE 6.0
MSIE 7.0; Windows NT IE 7, IE in intranet zone. The "Windows NT" fragment is sent by
desktop operation system.
MSIE 8.0 IE 8.0 (no devices send this, so need to make more specific)
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; Windows 8.1 desktop operating system, different platforms

Trident/7.0
Windows NT 6.3; Win64;

x64; Trident/7.0
Windows NT 6.3; WOW64;

Trident/7.0
Windows NT 6.2; Windows 8 desktop operating system, different platforms

Trident/7.0

x64; Trident/7.0
User Agents Use cases

Trident/7.0
Windows NT 6.1; Windows 7 desktop operating system, different platforms

Trident/7.0

x64; Trident/7.0

Trident/7.0
MSIPC Microsoft Information Protection and Control Client
Windows Rights Windows Rights Management Client

Management Client
In order to enable fall back to form based authentication for user agents other than
those mentioned in the WIASupportedUserAgents string, set the
WindowsIntegratedFallbackEnabled flag to true
PowerShell
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:
PowerShell
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:
PowerShell
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:
PowerShell
Get-AdfsProperties | Select -ExpandProperty WIASupportedUserAgents
７ Note
As new browsers and devices are released, it is recommended that you reconcile
the capabilities of those user agents and update the AD FS configuration
accordingly to optimize the user's authentication experience when using said
browser and devices. More specifically, it is recommended that you re-evaluate the
WIASupportedUserAgents setting in AD FS when adding a new device or browser
type to your support matrix for WIA.
Configuring Alternate Login ID
Article • 08/15/2023
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 use their email ID for sign-in and it can be different from their UPN. This is particularly common 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, such as email ID. Using the alternate ID enables you to adopt SaaS providers like 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, such as 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 Windows Server 2012 R2, 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):
PowerShell
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.
PowerShell
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.
PowerShell
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 third-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.
Step 1. Update to required Office version
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.
Step 2. Update to required Windows version
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.
Step 3. Configure registry for impacted users using group policy
The office applications rely on information pushed by the directory administrator to identify the Alternate ID environment. The
following registry keys need to be configured to help office applications authenticate the user with Alternate ID without showing any
extra prompts.
Regkey to add Regkey data name, Windows Windows Description

type, and value 7/8 10
HKEY_CURRENT_USER\Software\Microsoft\AuthN DomainHint Required Required The value of this regkey is

REG_SZ a verified custom domain
contoso.com 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_USER\Software\Microsoft\Office\16.0\Common\Identity EnableAlternateIdSupport Required Required The value of this regkey

REG_DWORD for for can be 1 / 0 to indicate to
1 Outlook Outlook Outlook application
2016 2016 whether it should engage
ProPlus ProPlus the improved Alternate ID
authentication logic.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet * Required Required This regkey can be used

Settings\ZoneMap\Domains\contoso.com\sts REG_DWORD to set the STS as a trusted
1 Zone in the internet
settings. Standard AD FS
deployment recommends
adding the AD FS
namespace to the Local
Regkey to add Regkey data name, Windows Windows Description
type, and value 7/8 10
Intranet Zone for Internet

Explorer.
New authentication flow after additional configuration
1. a: User is provisioned in Azure AD using Alternate ID

b: Directory administrator pushes required regkey settings to impacted client machines
2. User authenticates on the local machine and opens an office application
3. Office application takes the local session credentials
4. Office application authenticates to Azure AD using domain hint pushed by administrator and local credentials
5. Azure AD successfully authenticates the user by directing to correct federation realm and issue a token
Applications and user experience after the additional configuration
Non-Exchange and Skype for Business Clients
Client Support statement Remarks
Microsoft Teams Supported Microsoft Teams supports AD FS (SAML-P, WS-Fed, WS-Trust, and OAuth) and Modern
Authentication.
Core Microsoft Teams such as Channels, chats and files functionalities does work with Alternate Login
ID.
1st and 3rd party apps must be separately investigated by the customer. This is because each
application has their own supportability authentication protocols.
OneDrive for Supported - client-side With Alternate ID configured you see the on-premises UPN is pre-populated In the verification field. This
Business registry key needs to be changed to the alternate identity that is being used. We recommend using the client side
recommended registry key noted in this article: Office 2013 and Lync 2013 periodically prompt for credentials to
SharePoint Online, OneDrive, and Lync Online.
OneDrive for Supported

Business Mobile
Client
Office 365 Pro Supported - client-side With Alternate ID configured you see the on-premises UPN is pre-populated in the verification field. This
Plus activation registry key needs to be changed to the alternate identity that is being used. We recommend using the client-side
page recommended registry key noted in this article: Office 2013 and Lync 2013 periodically prompt for credentials to
SharePoint Online, OneDrive, and Lync Online.
Exchange and Skype for Business Clients

Client Support Statement Support Statement - without HMA
- with HMA
Outlook Supported, no extra Supported

prompts
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 Supported, no extra With Modern Authentication for Exchange Online: Supported
Folders prompts.
With regular authentication for Exchange Online: Not Supported
Hybrid Public Folders are not able to expand if Alternate IDs are used and therefore should not be used
today with regular authentication methods.
Cross premises See Configure See Configure Exchange to support delegated mailbox permissions in a hybrid deployment
Delegation Exchange to support
delegated mailbox
permissions in a
hybrid deployment
Archive mailbox Supported, no extra Supported - Users get an extra prompt for credentials when accessing the archive, they have to provide
access (Mailbox prompts their alternate ID when prompted.
on-premises -
archive in the
cloud)
Outlook Web Supported Supported

Access
Outlook Mobile Supported Supported

Apps for
Android, IOS,
and Windows
Phone
Skype for Supported, with no Supported (except as noted) but there is a potential for user confusion.
Business/ Lync extra prompts
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 and Considerations

Azure AD offers different features related to 'Alternate login ID'
The AD FS Alternate Login ID configuration feature for Federated1 identity infrastructure environments described in this article.
The Azure AD Connect Sync configuration that defines which on-premises attribute is used as Azure AD username
(userPrincipalName) for Federated1 OR Managed2 identity infrastructure environments, which is partially covered in this article.
The Sign-in to Azure AD with email as an alternate login ID feature for Managed2 identity infrastructure environments.
The Alternate login ID feature described in this article is available for Federated1 identity infrastructure environments. It is not
supported in the following scenarios:
An AlternateLoginID attribute with non-routable domains (e.g. Contoso.local) that cannot be verified by Azure AD.
Managed environments that do not have AD FS deployed. Please either refer to the Azure AD Connect Sync documentation or
to the Sign-in to Azure AD with email as an alternate login ID documentation. If you decide to adjust the Azure AD Connect
Sync configuration in a Managed2 identity infrastructure environment, the Applications and user experience after the
additional configuration section of this article may still be applicable while the specific AD FS configuration is no longer
applicable since no AD FS is deployed in a Managed2 identity infrastructure environment.
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
1
A Federated identity infrastructure environment represents an environment with an identity provider such as AD FS or other third-
party IDP.
2 A Managed identity infrastructure environment represents an environment with Azure AD as the identity provider deployed with
either password hash sync (PHS) or pass-through authentication (PTA).
Events and Performance Counters

The following performance counters have been added to measure the performance of AD FS servers when alternate login ID is
enabled:
Alternate Login ID Authentications: number of authentications performed by using alternate login ID
Alternate Login ID Authentications/Sec: number of authentications performed by using alternate login ID per second
Average Search Latency for Alternate Login ID: average search latency across the forests that an administrator has configured for
alternate login ID
The following are various error cases and corresponding impact on a user's sign-in experience with events logged by AD FS:
Error Cases Impact on Sign-in Event

Experience
Unable to get a value for Login failure Event ID 364 with exception message MSIS8012: Unable to find
SAMAccountName for the user object samAccountName for the user: '{0}'.
The CanonicalName attribute is not Login failure Event ID 364 with exception message MSIS8013: CanonicalName: '{0}' of the
accessible user:'{1}' is in bad format.
Error Cases Impact on Sign-in Event
Experience
Multiple user objects are found in one Login failure Event ID 364 with exception message MSIS8015: Found multiple user accounts
forests with identity '{0}' in forest '{1}' with identities: {2}
Multiple user objects are found across Login failure Event ID 364 with exception message MSIS8014: Found multiple user accounts
multiple forests with identity '{0}' in forests: {1}
See Also
AD FS Operations
Article • 08/15/2023



and click Next.
information.

federation metadata
７ Note

information.
See Also
AD FS Operations
Create a Non-Claims-Aware Relying
Party Trust
Article • 08/15/2023
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.

To create a non-claims aware Relying Party

Trust manually
3. On the Welcome page, choose Non claims aware and click Start.
Rules dialog box.
See Also
AD FS Operations
Article • 08/15/2023

manually


go to step 8:
Rules dialog box.
７ Note


then click Next.
click Next.
See Also
AD FS Operations
Customize HTTP security response
headers with AD FS 2019
Article • 06/30/2023
Active Directory Federation Services (AD FS) 2019 adds the functionality to customize
the HTTP security response headers sent by AD FS. These tools help administrators
protect against common security vulnerabilities and allow them to take advantage of
the latest advancements in browser-based protection mechanisms. This feature comes
from the introduction of two new cmdlets: Get-AdfsResponseHeaders and Set-
AdfsResponseHeaders .
７ Note
The functionality to customize the HTTP security response headers (except CORS
Headers) by using cmdlets: Get-AdfsResponseHeaders and Set-AdfsResponseHeaders
was backported to AD FS 2016. You can add the functionality to your AD FS 2016
by installing KB4493473 and KB4507459 .
This article discusses commonly used security response headers to demonstrate how to
customize headers sent by AD FS 2019.
７ Note
The article assumes that you installed AD FS 2019.
Scenarios
The following scenarios demonstrate the need admins might have to customize security
headers.
An administrator enabled HTTP Strict-Transport-Security (HSTS) to protect the

users who might access the web app by using HTTP from a public wifi access point
that might be hacked. HSTS forces all connections over HTTPS encryption. They
would like to further strengthen security by enabling HSTS for subdomains.
An administrator configured the X-Frame-Options response header to protect the
web pages from being clickjacked. X-Frame-Options prevents rendering any web
page in an iFrame. However, they need to customize the header value due to a
new business requirement to display data (in iFrame) from an application with a
different origin (domain).
An administrator enabled X-XSS-Protection to sanitize and block the page if
browser detects cross scripting attacks. X-XSS-Protection prevents cross scripting
attacks. However, they need to customize header to allow the page to load after
it's sanitized.
An administrator needs to enable Cross Origin Resource Sharing (CORS), and they
need to set the origin (domain) on AD FS to allow a single page application to
access a web API with another domain.
An Administrator enabled the Content Security Policy (CSP) header to prevent
cross site scripting and data injection attacks by disallowing any cross-domain
requests. However, due to a new business requirement they need to customize the
header to allow web page to load images from any origin and restrict media to
trusted providers.
HTTP security response headers

AD FS includes the response headers in the outgoing HTTP response sent a web
browser. You can list the headers by using the Get-AdfsResponseHeaders cmdlet as
shown in the following screenshot.
The ResponseHeaders attribute in the screenshot identifies the security headers

included by AD FS in every HTTP response. AD FS sends the response headers only if
ResponseHeadersEnabled is set to True (default value). The value can be set to False
to prevent AD FS including any of the security headers in the HTTP response. However,
this setting isn't recommended. You can set ResponseHeaders to False with the
following command:
PowerShell
Set-AdfsResponseHeaders -EnableResponseHeaders $false
HTTP Strict-Transport-Security (HSTS)

HTTP Strict-Transport-Security (HSTS) is a web security policy mechanism, which helps
mitigate protocol downgrade attacks and cookie hijacking for services that have both
HTTP and HTTPS endpoints. It allows web servers to declare that web browsers, or other
complying user agents, should only interact with it by using HTTPS and never via the
HTTP protocol.
All AD FS endpoints for web authentication traffic are opened exclusively over HTTPS. As
a result, AD FS effectively mitigates the threats that HTTP Strict Transport Security policy
mechanism provides. By default, there's no downgrade to HTTP since there are no
listeners in HTTP. The header can be customized by setting the following parameters:
max-age=<expire-time>. The expiry time (in seconds) specifies how long the site
should only be accessed using HTTPS. The default and recommended value is
31536000 seconds (one year).
includeSubDomains. This parameter is optional. If specified, the HSTS rule applies
to all subdomains as well.
HSTS customization
By default, the header is enabled and max-age is set to one year; however,
administrators can modify the max-age (lowering max-age value isn't recommended) or
enable HSTS for subdomains through the Set-AdfsResponseHeaders cmdlet.
PowerShell
Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -

SetHeaderValue "max-age=<seconds>; includeSubDomains"
Example:
PowerShell
Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -

SetHeaderValue "max-age=31536000; includeSubDomains"
By default, the header is included in the ResponseHeaders attribute; however,

administrators can remove the header through the Set-AdfsResponseHeaders cmdlet.
PowerShell
Set-AdfsResponseHeaders -RemoveHeaders "Strict-Transport-Security"
X-Frame-Options
AD FS by default doesn't allow external applications to use iFrames when performing
interactive sign in. This configuration prevents certain style of phishing attacks. Non-
interactive sign-in can be performed via iFrame due to prior session level security that
has been established.
However, in certain rare cases you might trust a specific application that requires an
iFrame capable interactive AD FS sign-in page. The X-Frame-Options header is used for
this purpose.
This HTTP security response header is used to communicate to the browser whether it
can render a page in a <frame>/<iframe>. The header can be set to one of the
following values:
deny. The page in a frame isn't displayed. This configuration is the default and
recommended setting.
sameorigin. The page is only displayed in the frame if the origin is the same as the
origin of the web page. The option isn't useful unless all ancestors are also in the
same origin.
allow-from <specified origin>. The page is only displayed in the frame if the
origin (for example, https://www.".com ) matches the specific origin in the header.
Some browsers might not support this option.
X-Frame-Options customization
By default, the header is set to deny; however, admins can modify the value through the
Set-AdfsResponseHeaders cmdlet.
PowerShell
Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "

<deny/sameorigin/allow-from<specified origin>>"
Example:
PowerShell
Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue

"allow-from https://www.example.com"
By default, the header is included in the ResponseHeaders attribute; however,

administrators can remove the header through the Set-AdfsResponseHeaders cmdlet.
PowerShell
Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"
X-XSS-Protection
This HTTP security response header is used to stop web pages from loading when
browsers detect cross-site scripting (XSS) attacks. This approach is referred to as XSS
filtering. The header can be set to one of the following values:
0 disables XSS filtering. Not recommended.

1 enables XSS filtering. If an XSS attack is detected, the browser sanitizes the page.
1; mode=block enables XSS filtering. If an XSS attack is detected, the browser
prevents rendering of the page. This setting is the default and recommended
setting.
X-XSS-Protection customization
By default, the header is set to 1; mode=block;. However, administrators can modify the
value through the Set-AdfsResponseHeaders cmdlet.
PowerShell
Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "

<0/1/1; mode=block/1; report=<reporting-uri>>"
Example:
PowerShell
Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue

"1"
By default, the header is included in the ResponseHeaders attribute; however, admins

can remove the header through the Set-AdfsResponseHeaders cmdlet.
PowerShell
Set-AdfsResponseHeaders -RemoveHeaders "X-XSS-Protection"
Cross Origin Resource Sharing (CORS) headers

Web browser security prevents a web page from making cross-origin requests initiated
from within scripts. However, you might want to access resources in other origins
(domains). Cross Origin Resource Sharing (CORS) is a W3C standard that allows a server
to relax the same-origin policy. By using CORS, a server can explicitly allow some cross-
origin requests while rejecting others.
To better understand a CORS request, the following scenario walks through an instance
where a single page application (SPA) needs to call a web API with a different domain.
Further, consider that both SPA and API are configured on AD FS 2019 and AD FS has
CORS enabled. AD FS can identify CORS headers in the HTTP request, validate header
values, and include appropriate CORS headers in the response. For details on how to
enable and configure CORS on AD FS 2019, see CORS Customization section. The
following sample flow walks you through the scenario:
1. A user accesses SPA through the client browser and is redirected to AD FS auth
endpoint for authentication. Since SPA is configured for implicit grant flow, the
request returns an Access + ID token to the browser after successful
authentication.
2. After user authentication, the front-end JavaScript included in SPA makes a request
to access the web API. The request is redirected to AD FS with following headers:
Options - describes the communication options for the target resource.

Origin - includes the origin of the web API.
Access-Control-Request-Method - identifies the HTTP method (for example,
DELETE) to be used when an actual request is made.
Access-Control-Request-Headers - identifies the HTTP headers to be used
when an actual request is made.
７ Note
A CORS request resembles a standard HTTP request. However, the presence

of an origin header signals the incoming request is CORS related.
3. AD FS verifies that the web API origin included in the header is listed in the trusted
origins configured in AD FS. For more information on how to modify trusted
origins, see CORS Customization. AD FS then responds with the following headers:
Access-Control-Allow-Origin - value same as in the Origin header.

Access-Control-Allow-Method - value same as in the Access-Control-
Request-Method header.
Access-Control-Allow-Headers - value same as in the Access-Control-
Request-Headers header.
4. The browser sends the actual request including the following headers:
HTTP method (for example, DELETE).

Origin – includes the origin of the web API.
All headers included in the Access-Control-Allow-Headers response header.
5. After it's verified, AD FS approves the request by including the web API domain
(origin) in the Access-Control-Allow-Origin response header.
6. The inclusion of the Access-Control-Allow-Origin header allows the browser to call

the requested API.
CORS customization
By default, CORS functionality isn't enabled; however, admins can enable the
functionality through the Set-AdfsResponseHeaders cmdlet.
PowerShell
Set-AdfsResponseHeaders -EnableCORS $true
After it's enabled, admins can enumerate a list of trusted origins by using the same
cmdlet. For instance, the following command would allow CORS requests from the
origins https://example1.com and https://example1.com .
PowerShell
Set-AdfsResponseHeaders -CORSTrustedOrigins
https://example1.com,https://example2.com
７ Note
Admins can allow CORS requests from any origin by including "*" in the list of
trusted origins, although this approach isn't recommended due to security
vulnerabilities and a warning message is provided if they choose to.
Content Security Policy (CSP)

This HTTP security response header is used to prevent cross-site scripting, clickjacking,
and other data injection attacks by preventing browsers from inadvertently executing
malicious content. Browsers that don't support Content Security Policy (CSP) ignore the
CSP response headers.
CSP customization
Customization of the CSP header involves modifying the security policy that defines the
resources that the browser is allowed to load for the web page. The default security
policy is:
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src

'self' data:;
The default-src directive is used to modify -src directives without listing each directive
explicitly. For instance, in the following example, the policy 1 is same as policy 2.
Policy 1
PowerShell
Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -

SetHeaderValue "default-src 'self'"
Policy 2
PowerShell

SetHeaderValue "script-src 'self'; img-src 'self'; font-src 'self';
frame-src 'self'; manifest-src 'self'; media-src 'self';"
If a directive is explicitly listed, the specified value overrides the value given for default-
src. In the following example, the img-src takes the value as '*' (allowing images to be
loaded from any origin) while other -src directives take the value as 'self' (restricting to
same origin as the web page).
PowerShell

SetHeaderValue "default-src 'self'; img-src *"
The following sources can be defined for the default-src policy:

'self' - specifying this source restricts the origin of the content to load to the origin
of the web page.
'unsafe-inline' - specifying this source in the policy allows the use of inline
JavaScript and CSS.
'unsafe-eval' - specifying this source in the policy allows the use of text to
JavaScript mechanisms like eval.
'none' - specifying this source restricts the content from any origin to load.
data: - specifying data: URIs allow content creators to embed small files inline in
documents. Usage not recommended.
７ Note
AD FS uses JavaScript in the authentication process and therefore enables

JavaScript by including 'unsafe-inline' and 'unsafe-eval' sources in default policy.
Custom headers
In addition to the previously listed security response headers (HSTS, CSP, X-Frame-
Options, X-XSS-Protection and CORS), AD FS 2019 enables you to set new headers.
As an example, you could set a new header "TestHeader" and "TestHeaderValue" as the
value.
PowerShell
Set-AdfsResponseHeaders -SetHeaderName "TestHeader" -SetHeaderValue

"TestHeaderValue"
After it's set, the new header is sent in the AD FS response, as shown in the following
Fiddler snippet:
Web browser compatibility
Use the following table and links to determine which web browsers are compatible with
each of the security response headers.
HTTP Security Response Headers Browser Compatibility
HTTP Strict-Transport-Security (HSTS) HSTS browser compatibility
X-Frame-Options X-Frame-Options browser compatibility
X-XSS-Protection X-XSS-Protection browser compatibility
Cross Origin Resource Sharing (CORS) CORS browser compatibility
Content Security Policy (CSP) CSP browser compatibility
Next
Use AD FS Help troubleshooting guides
AD FS Troubleshooting
Delegate AD FS PowerShell commandlet
access to nonadmin users
Article • 08/15/2023
By default, only AD FS administrators can perform AD FS administration via PowerShell.

For many large organizations, this may not be a viable operational model when dealing
with other personas such as a help desk personnel.
With Just Enough Administration (JEA), customers now can delegate permissions for
specific commandlets to different personnel groups.
A good example of this use case is allowing help desk personnel to query AD FS account
lockout status and reset account lockout state in AD FS after a user has been vetted. In
this case, the commandlets that would need to be delegated are:
Get-ADFSAccountActivity
Set-ADFSAccountActivity
Reset-ADFSAccountLockout
We use this example in the rest of this document. However, you can customize this to
also allow delegation to set properties of relying parties and hand this off to application
owners within the organization.
Create the required groups necessary to grant

users permissions
1. Create a Group Managed Service Account. The gMSA account is used to allow the
JEA user to access network resources as other machines or web services. It
provides a domain identity that can be used to authenticate against resources on
any machine within the domain. The gMSA account is granted the necessary
administrative rights later in the setup. For this example, we call the account
gMSAContoso.
2. Create an Active Directory group can be populated with users that need to be
granted the rights to the delegated commands. In this example, help desk
personnel are granted permissions to read, update, and reset the AD FS lockout
state. We refer to this group throughout the example as JEAContoso.
Install the gMSA account on the AD FS server

Create a service account that has administrative rights to the AD FS servers. This can be
performed on the domain controller or remotely as long as the AD RSAT package is
installed. The service account must be created in the same forest as the AD FS server.
Modify the example values to the configuration of your farm.
PowerShell
# This command should only be run if this is the first time gMSA accounts
are enabled in the forest
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) 
# Run this on every node that you want to have JEA configured on
$adfsServer = Get-ADComputer server01.contoso.com
# Run targeted at domain controller

$serviceaccount = New-ADServiceAccount gMSAcontoso -DNSHostName <FQDN of the
domain containing the KDS key> -PrincipalsAllowedToRetrieveManagedPassword
$adfsServer –passthru
# Run this on every node

Add-ADComputerServiceAccount -Identity server01.contoso.com -ServiceAccount
$ServiceAccount
Install the gMSA account on the AD FS server. This needs to be run on every AD FS node
in the farm.
PowerShell
Install-ADServiceAccount gMSAcontoso
Grant the gMSA Account admin rights

If the farm is using delegated administration, grant the gMSA Account admin rights by
adding it to the existing group, which has delegated admin access.
If the farm isn't using delegated administration, grant the gMSA account admin rights
by making it the local administration group on all of the AD FS servers.
Create the JEA role file

On the AD FS server, create the JEA role in a notepad file. Instructions to create the role
are provided on JEA role capabilities.
The commandlets delegated in this example are Reset-AdfsAccountLockout, Get-
ADFSAccountActivity, and Set-ADFSAccountActivity .
Sample JEA role delegating access of ‘Reset-ADFSAccountLockout', ‘Get-

ADFSAccountActivity', and ‘Set-ADFSAccountActivity' commandlets:
PowerShell
@{
GUID = 'b35d3985-9063-4de5-81f8-241be1f56b52'
ModulesToImport = 'adfs'
VisibleCmdlets = 'Reset-AdfsAccountLockout', 'Get-ADFSAccountActivity',
'Set-ADFSAccountActivity'
}
Create the JEA session configuration file

Follow the instructions to create the JEA session configuration file. The configuration file
determines who can use the JEA endpoint and what capabilities they can access.
Role capabilities are referenced by the flat name (filename without the extension) of the
role capability file. If multiple role capabilities are available on the system with the same
flat name, PowerShell uses its implicit search order to select the effective role capability
file. It doesn't give access to all role capability files with the same name.
To specify a Role Capability File with a path, use the RoleCapabilityFiles argument. For
a subfolder, JEA looks for valid PowerShell modules that contain a RoleCapabilities
subfolder, where the RoleCapabilityFiles argument should be modified to be
RoleCapabilities .
Sample session configuration file:
PowerShell
@{
SchemaVersion = '2.0.0.0'
GUID = '54c8d41b-6425-46ac-a2eb-8c0184d9c6e6'
SessionType = 'RestrictedRemoteServer'
GroupManagedServiceAccount = 'CONTOSO\gMSAcontoso'
RoleDefinitions = @{ JEAcontoso = @{ RoleCapabilityFiles = 'C:\Program
Files\WindowsPowershell\Modules\AccountActivityJEA\RoleCapabilities\JEAAccou
ntActivityResetRole.psrc' } }
}
Save the session configuration file.

It's recommended to test your session configuration file if you have edited the pssc file
manually using a text editor to ensure the syntax is correct. If a session configuration file
doesn't pass this test, it isn't successfully registered on the system.
Install the JEA session configuration on the AD FS server

Install the JEA session configuration on the AD FS server
PowerShell
Register-PSSessionConfiguration -Path .\JEASessionConfig.pssc -name

"AccountActivityAdministration" -force
Operational instructions
After it's set up, JEA logging and auditing can be used to determine if the correct users
have access to the JEA endpoint.
To use the delegated commands:
PowerShell
Enter-pssession -ComputerName server01.contoso.com -ConfigurationName

"AccountActivityAdministration" -Credential <User Using JEA>
Get-AdfsAccountActivity <User>
Device authentication controls in AD FS
Article • 08/15/2023
The following document shows how to enable device authentication controls in

Windows Server 2016 and 2012 R2.
Device Authentication controls in AD FS 2012

R2
Originally in AD FS 2012 R2 there was one global authentication property called
DeviceAuthenticationEnabled that controlled device authentication.
To configure the setting, the Set-AdfsGlobalAuthenticationPolicy cmdlet was used as

shown below:
PowerShell
PS:\>Set-AdfsGlobalAuthenticationPolicy –DeviceAuthenticationEnabled $true
To disable device authentication, the same cmdlet was used to set the value to $false.
Device Authentication controls in AD FS 2016

The only type of device authentication supported in 2012 R2 was clientTLS. In AD FS
2016, in addition to clientTLS there are two new types of device authentication for
modern devices authentication. These are:
PKeyAuth
PRT
To control the new behavior, the DeviceAuthenticationEnabled property is used in

combination with a new property called DeviceAuthenticationMethod .
The device authentication method determines the type of device authentication that will
be done: PRT, PKeyAuth, clientTLS, or some combination. It has the following values:
SignedToken: PRT only

PKeyAuth: PRT + PKeyAuth
ClientTLS: PRT + clientTLS
All: All of the above
As you can see, PRT is part of all device authentication methods, making it in effect the
default method that is always enabled when DeviceAuthenticationEnabled is set to
$true .
Example: To configure the method(s), use the DeviceAuthenticationEnabled cmdlet as

above, along with new property:
PowerShell
PS:\>Set-AdfsGlobalAuthenticationPolicy –DeviceAuthenticationEnabled $true
７ Note
In AD FS 2019, DeviceAuthenticationMethod can be used with the Set-

AdfsRelyingPartyTrust command.
PowerShell
PS:\>Set-AdfsRelyingPartyTrust -DeviceAuthenticationMethod ClientTLS
７ Note
Enabling device authentication (setting DeviceAuthenticationEnabled to $true )

means the DeviceAuthenticationMethod is implicitly set to SignedToken , which
equates to PRT.
PowerShell
PS:\>Set-AdfsGlobalAuthenticationPolicy –DeviceAuthenticationMethod All
７ Note
The default device authentication method is SignedToken . Other values are

PKeyAuth,ClientTLS, and All.
The meanings of the DeviceAuthenticationMethod values have changed slightly since AD

FS 2016 was released. See the table below for the meaning of each value, depending on
the update level:
AD FS version DeviceAuthenticationMethod Means
value
2016 RTM SignedToken PRT + PkeyAuth
clientTLS clientTLS
All PRT + PkeyAuth +

clientTLS
2016 RTM + up to date with SignedToken (changed meaning) PRT (only)

Windows Update
PkeyAuth (new) PRT + PkeyAuth
clientTLS PRT + clientTLS
All PRT + PkeyAuth +

clientTLS
See Also
AD FS Operations
What is KDFv2 for AD FS?
Article • 08/15/2023
On July 13, 2021, updates were released for AD FS to address token replay attacks, as
described in CVE-2021-33779 . These updates introduce new settings to enable and
control a new, Key Derivation Function (KDF) called "KDFv2". This new version of KDF is
more secure than the previous version. This document describes new settings enabled
by the security fix for CVE-2021-33779 , and how to enable these settings in different
deployment scenarios. For product-specific KB numbers and related downloads, please
refer to links provided in the CVE article.
KDFv2 Settings:
KDFv2 may be configured by an Administrator on an AD FS server to run in one of
several modes, which are as follows:
None - (Default value) This is used to track if the KDFv2 setting value was ever
changed. This value may not be set by an Administrator.
Disabled - This value may be set in order to revert the Key Derivation Function to
its original behavior, in case there are any issues encountered when enabling
KDFv2.
Enabled - Enable KDFv2 support. The ADFS server will advertise that it supports
the new capabilities. If an initial Primary Refresh Token (PRT) request is sent from a
client using the original KDF version, ADFS will accept the request and use the
original KDF. This allows for support of unpatched clients.
Enforced - Enable KDFv2 support and disallow (reject) initial PRT requests using
the original KDF. Once an Administrator is comfortable that all clients have been
patched, they may switch to enforced mode.
KDFv2 modes may be changed by an Administrator on an AD FS server via the following

PowerShell commands:
Enable KDFv2:
PowerShell
Set-AdfsProperties -KdfV2Support enable
Disable KDFv2:
PowerShell
Set-AdfsProperties -KdfV2Support disable
Enforce KDFv2:
PowerShell
Set-AdfsProperties -KdfV2Support enforce
An Administrator may run Get-AdfsProperties to check the current KDFv2 setting. The
KdfV2Support value returned will match the configured mode.
Deployment Scenarios
Depending on the OS version that AD FS servers are running when patched to support
KDFv2, KDFv2 may be enabled automatically. Also, the OS-version-dependent events
may be logged to indicate the state of KDFv2 in the farm. The following are possible
deployment scenarios and expected behaviors.
Scenario 1: Windows Server 2019 or above is installed on

all AD FS servers in a farm. One or more farm nodes are
unpatched.
Expected behavior: If all nodes in farm are not patched then the below error event will
be logged indicating recommended remediation actions. This event will be logged every
24 hours until all nodes in the farm are patched. Once all nodes are patched, KDFv2 will
be enabled automatically for all systems in the farm via the "Enable" mode.
Source: AD FS
Level: Error
ID: 181
Message: AD FS could not enable the new KDFv2 feature automatically because
of missing Windows Updates on one or more nodes of the farm. Please make
sure that all the farm nodes are patched with the latest Windows Updates. AD
FS checks regularly for the required updates to enable the new KDFv2
feature. An event 182 will be logged when a check is successful. For more
information on this, please see https://go.microsoft.com/fwlink/?
linkid=2153807.
Scenario 2: Windows Server 2016 is installed on one or
more servers in a farm. All servers are running Windows
2016 or greater. One or more farm nodes are unpatched.
Expected behavior: If all nodes in farm are not patched then the below error event will
be logged indicating recommended remediation actions. This event will be logged every
24 hours until all nodes in the farm are patched. Once all nodes are patched, KDFv2
must be manually enabled on all servers in the farm.
Source: AD FS
Level: Error
ID: 185
Message: KDFv2 feature is not enabled on AD FS farm. Please make sure that
all the farm nodes are patched with latest Windows Updates and the KDFv2
feature is enabled to enhance the security of the farm. For more information
on this, please see https://go.microsoft.com/fwlink/?linkid=2153807.
Scenario 3: Windows Server 2019 or above is installed on

all ADFS servers in a farm. All servers in the farm have
been patched.
Expected behavior: Once KDFv2 has been enabled automatically on the farm as
described in Scenario 1 above, then the below event will be logged.
Source: AD FS
Level: Information
ID: 182
Message: AD FS enabled the new KDFv2 feature successfully. For more
information on this, please see https://go.microsoft.com/fwlink/?
linkid=2153807.
７ Note
Event 182 will not be logged if any servers in a farm are running Windows Server
2016.
Scenario 4: Administrator has disabled KDFv2 on one or
more servers in their environment.
Expected behavior: The below log message will be logged on each system in the farm
where KDFv2 has been disabled, on ADFS service start.
Source: AD FS
Level: Warning
ID: 183
Message: KDFv2 feature is disabled on AD FS farm. Please make sure that all
the farm nodes are patched with latest Windows Updates and the KDFv2 feature
is enabled to enhance the security of the farm. For more information on
this, please see https://go.microsoft.com/fwlink/?linkid=2153807.
Next
Use AD FS Help troubleshooting guides
AD FS Troubleshooting
Improved interoperability with SAML 2.0
Article • 08/15/2023
AD FS in Windows Server 2016 contains additional SAML protocol support, including

support for importing trusts based on metadata that contains multiple entities. This
enables you to configure AD FS to participate in confederations such as InCommon
Federation and other implementations conforming to the eGov 2.0 standard.
The new capability is based on groups of relying party or claims provider trusts. Each
group is an EntitiesDescriptor (<md:EntitiesDescriptor>) element as specified in the
eGov 2.0 profile, containing one or many EntityDescriptor elements. The groups have
common authorization rules, and all other properties can be modified like individual
trust objects.
Once the trust groups are imported into AD FS, AD FS automatically updates the trusts
as a group based on the metadata document.
Enabling these scenarios is as simple as using the new PowerShell commandlets that
Add and Remove AdfsClaimsProviderTrustsGroup and AdfsRelyingPartyTrustsGroup
objects. This can be done using a metadata URL or a file, as shown in the examples
below.
Additionally, AD FS 2016 has support for the scoping parameter as described in the
SAML Core specification, section 3.4.1.2. This element allows relying parties to specify
one or more identity providers for an authentication request.
Examples
Add-AdfsClaimsProviderTrustsGroup -MetadataUrl
"https://www.contosoconsortium.com/metadata/metadata.xml"
Add-AdfsClaimsProviderTrustsGroup -MetadataFile "C:\metadata.xml"
References
The eGov 2.0 profile can be found here.
The SAML Core specification can be found here.
Join to Workplace from Any Device for
SSO and Seamless Second Factor
Authentication Across Company
Applications
Article • 08/15/2023
The rapid increase in the number of consumer devices and ubiquitous information
access is changing the way that people perceive their technology. The constant use of
information technology throughout the day, along with easy access of information, is
blurring traditional boundaries between work and home life. These shifting boundaries
are accompanied by a belief that personal technology-selected and customized to fit
users' personalities, activities, and schedules-should extend into the workplace. To
accommodate the growing requirement of personal consumer devices to be connected
to enterprise networks, we are introducing the following value propositions:
Administrators can control who has access to company resources that are based
on application, user, device, and location.
Employees can access applications and data everywhere, on any device. Employees
can use Single Sign-On in browser applications or enterprise applications.
Key concepts introduced in the solution
Workplace Join
By using Workplace Join, information workers can join their personal devices with their
company's workplace computers to access company resources and services. When you
join your personal device to your workplace, it becomes a known device and provides
seamless second factor authentication and Single Sign-On to workplace resources and
applications. When a device is joined by Workplace Join, attributes of the device can be
retrieved from the directory to drive conditional access for the purpose of authorizing
issuance of security tokens for applications. Windows 8.1 and iOS 6.0+, and Android
4.0+ devices can be joined by using Workplace Join.
Azure Active Directory Device Registration service

Workplace Join is made possible by the Azure Active Directory Device Registration
service. When a device is joined by Workplace Join, the service provisions a device
object in Azure Active Directory and then sets a key on the local device that is used to
represent the device identity. This device identity can then be used with access control
rules for applications that are hosted in the cloud and on-premises.
For more details, see Introduction to device management in Azure Active Directory.
Workplace Join as a seamless second factor

authentication
Companies can manage the risk that is related to information access and drive
governance and compliance while granting consumer devices access to corporate
resources. Workplace Join on devices provides the following capabilities to
administrators:
Identifies known devices with device authentication. Administrators can use this
information to drive conditional access and control access to resources.
Provides a more seamless sign-in experience for users to access company

resources from trusted devices.
Single Sign-On
Single Sign-On (SSO) in the context of this scenario is the functionality that reduces the
number of password prompts that the end user has to enter to access company
resources from known devices. This functionality implies that users are prompted only
one time during the lifetime of SSO to access company applications and resource from
this device. If a device uses Workplace Join, the user who is registered to use this device
gets persistent SSO, by default for seven days. This user has a seamless sign-in
experience in the same session or in new sessions.
Solution Overview
As part of this solution, you learn how to use Workplace Join on a supported device and
experience Single Sign-On to a company resource.
７ Note
To support Windows 8.1, iOS 6.0+, and Android 4.0+ devices, you MUST configure
Azure Active Directory Device Registration along with device object write-back, see
Step-by-Step Guide for On-premises Conditional Access using Azure Active
Directory Device Registration Service
This solution guides takes you through the following walkthrough steps:
1. Walkthrough: Workplace Join with a Windows Device
2. Walkthrough: Workplace Join with an iOS Device
3. Walkthrough: Workplace Join with an Android Device
See Also
Configure a federation server with Device Registration Service
Manage Risk with Additional Multi-
Factor Authentication for Sensitive
Applications
Article • 08/15/2023
Set up the lab environment for AD FS in Windows Server 2012 R2

Configure Additional Authentication Methods for AD FS
In this guide
This guide provides the following information:
Authentication mechanisms in AD FS - description of the authentication

mechanisms available in Active Directory Federation Services (AD FS) in Windows
Server 2012 R2
Scenario Overview - a description of a scenario where you use Active Directory

Federation Services (AD FS) to enable multifactor authentication (MFA) based on
user's group membership.
７ Note
In AD FS in Windows Server 2012 R2 you can enable MFA based on the

network location, device identity, and user identity or group membership.
For detailed step-by-step walkthrough instructions for configuring and verifying

this scenario, see Walkthrough Guide: Manage Risk with Additional Multi-Factor
Authentication for Sensitive Applications.
Key Concepts - Authentication mechanisms in

AD FS
Benefits of authentication mechanisms in AD FS

Active Directory Federation Services (AD FS) in Windows Server 2012 R2 provides IT
administrators with a richer, more flexible set of tools for authenticating users who want
to access corporate resources. It empowers administrators with flexible control over the
primary and the additional authentication methods, provides a rich management
experience for configuring authentication polices (both through the user interface and
Windows PowerShell), and enhances the experience for the end users that access
applications and services that are secured by AD FS. The following are some of the
benefits of securing your application and services with AD FS in Windows Server 2012
R2:
Global authentication policy - a central management capability, from which an IT

administrator can choose what authentication methods are used to authenticate
users based on the network location from which they access protected resources.
This enables administrators to do the following:
Mandate the use of more secure authentication methods for access requests
from the extranet.
Enable device authentication for seamless second-factor authentication. This

ties the user's identity to the registered device that is used to access the
resource, thus offering more secure compound identity verification before
protected resources are accessed.
７ Note
For more information about device object, Device Registration Service,

Workplace Join, and the device as seamless second-factor authentication
and SSO, see Join to Workplace from Any Device for SSO and Seamless
Second Factor Authentication Across Company Applications.
Set MFA requirement for all extranet access or conditionally based on the user's
identity, network location or a device that is used to access protected resources.
Greater flexibility in configuring authentication policies: you can configure custom

authentication policies for AD FS-secured resources with varying business values.
For example, you can require MFA for application with high business impact.
Ease of use: simple and intuitive management tools such as the GUI-based AD FS
Management MMC snap-in and the Windows PowerShell cmdlets enable IT
administrators to configure authentication policies with relative ease. With
Windows PowerShell, you can script your solutions for use at scale and to
automate mundane administrative tasks.
Greater control over corporate assets: since as an administrator you can use AD FS
to configure an authentication policy that applies to a specific resource, you have
greater control over how corporate resources are secured. Applications cannot
override the authentication policies specified by IT administrators. For sensitive
applications and services, you can enable MFA requirement, device authentication,
and optionally fresh authentication every time the resource is accessed.
Support for custom MFA providers: for organizations that leverage third-party MFA
methods, AD FS offers the ability to incorporate and use these authentication
methods seamlessly.
Authentication scope
In AD FS in Windows Server 2012 R2 you can specify an authentication policy at a global
scope that is applicable to all applications and services that are secured by AD FS. You
can also set authentication policies for specific applications and services (relying party
trusts) that are secured by AD FS. Specifying an authentication policy for a particular
application (per relying party trust) does not override the global authentication policy. If
either global or per relying party trust authentication policy requires MFA, MFA will be
triggered when the user tries to authenticate to this relying party trust. The global
authentication policy is a fallback for relying party trusts (applications and services) that
do not have a specific authentication policy configured.
A global authentication policy applies to all relying parties that are secured by AD FS.
You can configure the following settings as part of the global authentication policy:
Authentication methods to be used for primary authentication
Settings and methods for MFA
Whether device authentication is enabled. For more information, see Join to

Workplace from Any Device for SSO and Seamless Second Factor Authentication
Across Company Applications.
Per-relying party trust authentication policies apply specifically to attempts to access

that relying party trust (application or service). You can configure the following settings
as part of the per-relying party trust authentication policy:
Whether users are required to provide their credentials each time at sign-in
MFA settings based on the user/group, device registration, and access request
location data
Primary and additional authentication methods
With AD FS in Windows Server 2012 R2, in addition to the primary authentication
mechanism, administrators can configure additional authentication methods. Primary
authentication methods are built-in and are intended to validate users' identities. You
can configure additional authentication factors to request that more information about
the user's identity is provided and consequently ensure stronger authentication.
With primary authentication in AD FS in Windows Server 2012 R2, you have the
following options:
For resources published to be accessed from outside the corporate network, Forms
Authentication is selected by default. In addition, you can also enable Certificate
Authentication (in other words, smart card-based authentication or user client
certificate authentication that works with AD DS).
For intranet resources, Windows Authentication is selected by default. In addition

you can also enable Forms and/or Certificate Authentication.
By selecting more than one authentication method, you enable your users to have a
choice of what method to authenticate with at the sign-in page for your application or
service.
You can also enable device authentication for seamless second-factor authentication.
This ties the user's identity to the registered device that is used to access the resource,
thus offering more secure compound identity verification before protected resources
are accessed.
７ Note
For more information about device object, Device Registration Service, Workplace
Join, and the device as seamless second-factor authentication and SSO, see Join to
Workplace from Any Device for SSO and Seamless Second Factor Authentication
Across Company Applications.
If you specify Windows Authentication method (default option) for your intranet
resources, authentication requests undergo this method seamlessly on browsers that
support Windows authentication.
７ Note
Windows authentication is not supported on all browsers. The authentication
mechanism in AD FS in Windows Server 2012 R2 detects the user's browser user
agent and uses a configurable setting to determine whether that user agent
supports Windows Authentication. Administrators can add to this list of user agents
(via the Windows PowerShell Set-AdfsProperties -WIASupportedUserAgents
command, in order to specify alternate user agent strings for browsers that support
Windows Authentication. If the client's user agent does not support Windows
Authentication, the default fallback method is Forms Authentication.
Configuring MFA
There are two parts to configure MFA in AD FS in Windows Server 2012 R2: specifying
the conditions under which MFA is required, and selecting an additional authentication
method. For more information about additional authentication methods, see Configure
Additional Authentication Methods for AD FS.
MFA settings
The following options are available for MFA settings (conditions under which to require
MFA):
You can require MFA for specific users and groups in the AD domain that your
federation server is joined to.
You can require MFA for either registered (workplace joined) or unregistered (not
workplace joined) devices.
Windows Server 2012 R2 takes a user-centric approach to modern devices where

device objects represent a relationship between user@device and a company.
Device objects are a new class in AD in Windows Server 2012 R2 that can be used
to offer compound-identity when providing access to applications and services. A
new component of AD FS - the device registration service (DRS) - provisions a
device identity in Active Directory and sets a certificate on the consumer device
that will be used to represent the device identity. You can then use this device
identity to workplace join your device, in other words, to connect your personal
device to the Active Directory of your workplace. When you join your personal
device to your workplace, it becomes a known device and will provide seamless
second-factor authentication to protected resources and applications. In other
words, after a device is workplace joined, the user's identity is tied to this device
and can be used for a seamless compound identity verification before a protected
resource is accessed.
For more information on workplace join and leave, see Join to Workplace from Any
Device for SSO and Seamless Second Factor Authentication Across Company
Applications.
You can require MFA when the access request for the protected resources comes
from either the extranet or the intranet.
Scenario Overview
In this scenario, you enable MFA based on the user's group membership data for a
specific application. In other words, you will set up an authentication policy on your
federation server to require MFA when users that belong to a certain group request
access to a specific application that is hosted on a web server.
More specifically, in this scenario, you enable an authentication policy for a claims-based
test application called claimapp, whereby an AD user Robert Hatley will be required to
undergo MFA since he belongs to an AD group Finance.
The step-by step instructions to set up and verify this scenario are provided in
Sensitive Applications. In order to complete the steps in this walkthrough, you must set
up a lab environment and follow the steps in Set up the lab environment for AD FS in
Other scenarios of enabling MFA in AD FS include the following:
Enable MFA, if the access request comes from the extranet. You can modify the
code presented in the "Set up MFA Policy" section of Walkthrough Guide: Manage
Risk with Additional Multi-Factor Authentication for Sensitive Applications with the
following:
'c:[type ==
value == "false"] =>
issue(type="https://schemas.microsoft.com/ws/2008/06/identity/claims/au
thenticationmethod", value =
"https://schemas.microsoft.com/claims/multipleauthn" );'
Enable MFA, if the access request comes from a non-workplace joined device. You
can modify the code presented in the "Set up MFA Policy" section of Walkthrough
Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive
Applications with the following:
'NOT
EXISTS([type=="https://schemas.microsoft.com/2012/01/devicecontext/clai
ms/registrationid"]) => issue
(type="https://schemas.microsoft.com/ws/2008/06/identity/claims/authent
icationmethod", value =
"https://schemas.microsoft.com/claims/multipleauthn");'
Enable MFA, if the access is coming from a user with a device that is workplace
joined but not registered to this user. You can modify the code presented in the
"Set up MFA Policy" section of Walkthrough Guide: Manage Risk with Additional
Multi-Factor Authentication for Sensitive Applications with the following:
'c:
[type=="https://schemas.microsoft.com/2012/01/devicecontext/claims/isre
gistereduser", value == "false"] => issue
(type="https://schemas.microsoft.com/ws/2008/06/identity/claims/authent
icationmethod", value =
"https://schemas.microsoft.com/claims/multipleauthn");'
See Also
Sensitive Applications Set up the lab environment for AD FS in Windows Server 2012 R2
Manage Risk with Conditional Access
Control
Article • 08/15/2023
Key concepts-conditional access control in AD FS
Managing Risk with Conditional Access Control
Key concepts - conditional access control in AD

FS
The overall function of AD FS is to issue an access token that contains a set of claims.
The decision regarding what claims AD FS accepts and then issues is governed by claim
rules.
Access control in AD FS is implemented with issuance authorization claim rules that are
used to issue a permit or deny claims that will determine whether a user or a group of
users will be allowed to access AD FS-secured resources or not. Authorization rules can
only be set on relying party trusts.
Rule option Rule logic
Permit all users If incoming claim type equals any claim type and value equals any
value, then issue claim with value equals Permit
Permit access to users with If incoming claim type equals specified claim type and value equals
this incoming claim specified claim value, then issue claim with value equals Permit
Deny access to users with If incoming claim type equals specified claim type and value equals
this incoming claim specified claim value, then issue claim with value equals Deny
For more information about these rule options and logic, see When to Use an
Authorization Claim Rule.
In AD FS in Windows Server 2012 R2, access control is enhanced with multiple factors,
including user, device, location, and authentication data. This is made possible by a
greater variety of claim types available for the authorization claim rules. In other words,
in AD FS in Windows Server 2012 R2, you can enforce conditional access control based
on user identity or group membership, network location, device (whether it is workplace
joined, for more information, see Join to Workplace from Any Device for SSO and
Seamless Second Factor Authentication Across Company Applications), and the
authentication state (whether multifactor authentication (MFA) was performed ).
Conditional access control in AD FS in Windows Server 2012 R2, offers the following
benefits:
Flexible and expressive per-application authorization policies, whereby you can

permit or deny access based on user, device, network location, and authentication
state
Creating issuance authorization rules for relying party applications
Rich UI experience for the common conditional access control scenarios
Rich claims language & Windows PowerShell support for advanced conditional
access control scenarios
Custom (per relying party application) 'Access Denied' messages. For more
information, see Customizing the AD FS Sign-in Pages. By being able to customize
these messages, you can explain why a user is being denied access and also
facilitate self-service remediation where it is possible, for example, prompt users to
workplace join their devices. For more information, see Join to Workplace from Any
Device for SSO and Seamless Second Factor Authentication Across Company
Applications.
The following table includes all the claim types available in AD FS in Windows Server
2012 R2 to be used for implementing conditional access control.
Claim type Description
Email Address The email address of the user.
Given Name The given name of the user.
Name The unique name of the user,
UPN The user principal name (UPN) of the user.
Common Name The common name of the user.
AD FS 1 x E-mail Address The email address of the user when interoperating with AD FS 1.1 or
AD FS 1.0.
Group A group that the user is a member of.
AD FS 1 x UPN The UPN of the user when interoperating with AD FS 1.1 or AD FS 1.0.
Role A role that the user has.

Surname The surname of the user.
PPID The private identifier of the user.
Name ID The SAML name identifier of the user.
Authentication time Used to display the time and date that the user was authenticated.
stamp
Authentication method The method used to authenticate the user.
Deny only group SID The deny-only group SID of the user.
Deny only primary SID The deny-only primary SID of the user.
Deny only primary group The deny-only primary group SID of the user.
SID
Group SID The group SID of the user.
Primary group SID The primary group SID of the user.
Primary SID The primary SID of the user.
Windows account name The domain account name of the user in the form of domain\user.
Is Registered User User is registered to use this device.
Device Identifier Identifier of the device.
Device Registration Identifier for Device Registration.

Identifier
Device Registration Display name of Device Registration.

Display Name
Device OS Type Operating system type of the device.
Device OS Version Operating system version of the device.
Is Managed Device Device is managed by a management service.
Forwarded Client IP IP address of the user.
Client Application Type of the client application.
Client User Agent Device type the client is using to access the application.
Client IP IP address of the client.
Endpoint Path Absolute Endpoint path which can be used to determine active versus
passive clients.
Proxy DNS name of the federation server proxy that passed the request.
Application Identifier Identifier for the relying party.
Application policies Application policies of the certificate.
Authority Key Identifier The authority key identifier extension of the certificate that signed an
issued certificate.
Basic Constraint One of the basic constraints of the certificate.
Enhanced Key Usage Describes one of the enhanced key usages of the certificate.
Issuer The name of the certification authority that issued the X.509
certificate.
Issuer Name The distinguished name of the certificate issuer.
Key Usage One of the key usages of the certificate.
Not After Date in local time after which a certificate is no longer valid.
Not Before The date in local time on which a certificate becomes valid.
Certificate Policies The policies under which the certificate has been issued.
Public Key Public key of the certificate.
Certificate Raw Data The raw data of the certificate.
Subject Alternative Name One of the alternative names of the certificate.
Serial Number The serial number of the certificate.
Signature Algorithm The algorithm used to create the signature of a certificate.
Subject The subject from the certificate.
Subject Key Identifier The subject key identifier of the certificate.
Subject Name The subject distinguished name from a certificate.
V2 Template Name The name of the version 2 certificate template used wen issuing or
renewing a certificate. This is a Microsoft-specific value.
V1 Template Name The name of the version 1 certificate template used when issuing or
renewing a certificate. This is a Microsoft-specific value.
Thumbprint Thumbprint of the certificate.

X 509 Version The X.509 format version of the certificate.
Inside Corporate Used to indicate if a request originated from inside the corporate
Network network.
Password Expiration Time Used to display the time when the password expires.
Password Expiration Days Used to display the number of days to password expiry.
Update Password URL Used to display the web address of update password service.
Authentication Methods Used to indicate al authentication methods used to authenticate the

References user.
Managing Risk with Conditional Access Control

Using the available settings, there are many ways in which you can manage risk by
implementing conditional access control.
Common Scenarios
For example, imagine a simple scenario of implementing conditional access control
based on the user's group membership data for a particular application (relying party
trust). In other words, you can set up an issuance authorization rule on your federation
server to permit users that belong to a certain group in your AD domain access to a
particular application that is secured by AD FS. The detailed step by step instructions
(using the UI and Windows PowerShell) for implementing this scenario are covered in
Walkthrough Guide: Manage Risk with Conditional Access Control. In order to complete
the steps in this walkthrough, you must set up a lab environment and follow the steps in
Set up the lab environment for AD FS in Windows Server 2012 R2.
Advanced Scenarios
Other examples of implementing conditional access control in AD FS in Windows Server
2012 R2 include the following:
Permit access to an application secured by AD FS only if this user's identity was

validated with MFA
You can use the following code:

@RuleTemplate = "Authorization"
@RuleName = "PermitAccessWithMFA"
c:[Type ==
"https://schemas.microsoft.com/claims/authnmethodsreferences", Value =~
"^(?i)https://schemas\.microsoft\.com/claims/multipleauthn$"] =>
issue(Type =
"PermitUsersWithClaim");
Permit access to an application secured by AD FS only if the access request is

coming from a workplace joined device that is registered to the user
@RuleName = "PermitAccessFromRegisteredWorkplaceJoinedDevice"
c:[Type ==
"https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistere
duser", Value =~ "^(?i)true$"] => issue(Type =
Permit access to an application secured by AD FS only if the access request is

coming from a workplace joined device that is registered to a user whose identity
has been validated with MFA
You can use the following code
@RuleName = "RequireMFAOnRegisteredWorkplaceJoinedDevice"
c1:[Type ==
"^(?i)http://schemas\.microsoft\.com/claims/multipleauthn$"] &&
c2:[Type ==
"https://schemas.microsoft.com/2012/01/devicecontext/claims/isregistere
duser", Value =~ "^(?i)true$"] => issue(Type =
Permit extranet access to an application secured by AD FS only if the access

request is coming from a user whose identity has been validated with MFA.
@RuleName = "RequireMFAForExtranetAccess"
c1:[Type ==
"^(?i)http://schemas\.microsoft\.com/claims/multipleauthn$"] &&
c2:[Type ==
Value =~ "^(?i)false$"] => issue(Type =
See Also
Walkthrough Guide: Manage Risk with Conditional Access Control Set up the lab
environment for AD FS in Windows Server 2012 R2
Manage TLS/SSL certificates in AD FS
and WAP in Windows Server 2016
Article • 08/15/2023
This article describes how to deploy a new TLS/SSL certificate to your Active Directory
Federation Services (AD FS) and Web Application Proxy (WAP) servers.
７ Note
The recommended way to replace the TLS/SSL certificate going forward for an AD
FS farm is to use Azure AD Connect. For more information, see Update the TLS/SSL
certificate for an Active Directory Federation Services (AD FS) farm.
Obtain your TLS/SSL certificates

For production AD FS farms, a publicly trusted TLS/SSL certificate is recommended. AD
FS obtains this certificate by submitting a certificate signing request (CSR) to a third
party, public certificate provider. There are various ways to generate the CSR, including
from a Windows 7 or higher PC. Your vendor should have documentation for this
process.
Make sure the certificate meets the AD FS and Web Application Proxy TLS/SSL
certificate requirements.
Certificates needed
You should use a common TLS/SSL certificate across all AD FS and WAP servers. For
detailed requirements, see AD FS and Web Application Proxy TLS/SSL certificate
requirements.
TLS/SSL certificate requirements

For requirements, including naming root of trust and extensions, see AD FS and Web
Application Proxy TLS/SSL certificate requirements.
Replace the TLS/SSL certificate for AD FS

７ Note
The AD FS TLS/SSL certificate isn't the same as the AD FS Service communications

certificate found in the AD FS Management snap-in. To change the AD FS TLS/SSL
certificate, you need to use PowerShell.
First, determine whether your AD FS servers run default certificate authentication

binding mode or alternate client TLS binding mode.
Replace the TLS/SSL certificate for AD FS running in

default certificate authentication binding mode
AD FS by default performs device certificate authentication on port 443 and user
certificate authentication on port 49443 (or a configurable port that isn't 443). In this
mode, use the PowerShell cmdlet Set-AdfsSslCertificate to manage the TLS/SSL
certificate as shown in the following steps:
1. First, you need to obtain the new certificate. You can get it by submitting a
certificate signing request (CSR) to a third party, public certificate provider. There
are various ways to generate the CSR, including from a Windows 7 or hi

Windows Server Identity

Uploaded by

Document Information

Original Title

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

Windows Server Identity

Uploaded by

Copyright:

Available Formats

Tell us about your PDF experience.

Identity and Access documentation

About Identity and Access technologies

Privileged Access Management for Active Directory Domain Services & AD DS

Windows 10 for the enterprise: Ways to use devices for work

Active Directory Domain Services

Active Directory Federation Services

Windows Local Administrator Password Solution (LAPS)

Solutions and Scenario Guides

Secure access to company resources from any location on any device

Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications

Manage Risk with Conditional Access Control

Older versions of Windows Server

Windows previous versions documentation

Access and Information Protection

Guide How can this guide help you

Manage Risk with Access control in AD FS is implemented with issuance authorization

Configuring Certificate This article provides step-by-step instructions to implement the

Apply Rights Management Services (RMS) protection by using automatic RMS

Kerberos authentication support for user claims and device claims.

Improvements to the File Classification Infrastructure (FCI).

Dynamic Access Control Content Roadmap

Scenario: Central Access Policy Dynamic Plan: A Central Deploy a - Modeling

Active Directory, therefore - Exception

describes how a claim traverses - Operations to

regulatory compliance. For - Monitor

establish the presence or - Monitor

and mitigate gaps in security - Monitor

of user activity that can be - Monitor

Scenario: Access-Denied Scenario: Plan for Deploy Access-

administrators that need to - Determine

appropriate context from users - Customize

information worker and - Plan for

deal with the access denied - Determine

Scenario: Classification-Based Scenario: Plan to deploy Deploy

To support this scenario,

Scenario: Implement Scenario: Plan for Deploy

File Classification Infrastructure

Dynamic Access Control is not supported on ReFS (Resilient File System).

Product evaluation - Dynamic Access Control Reviewers Guide

- Dynamic Access Control Developer Guidance

Planning - Planning a Central Access Policy Deployment

Deployment - Active Directory Deployment

- File and Storage Services Deployment

Operations Dynamic Access Control PowerShell Reference

|Community resources|Directory Services Forum|

Organizational access policies are driven by compliance and business regulatory

Identify and mark the files that contain PII.

Organization-wide authorization policy. Most commonly initiated from the

Departmental authorization policy. Each department in an organization has some

Need-to-know policy. This authorization policy type is typically used in

A central access policy rule has the following logical parts:

Figure 2 Central access policy workflow

The central authorization policy combines the following components:

A centrally defined policy that contains a list of rules.

Plan a Central Access Policy deployment

Deploy a Central Access Policy (Demonstration Steps)

Dynamic Access Control: Scenario Overview

Roles and features included in this scenario

Role/feature How it supports this scenario

Active AD DS in Windows Server 2012 introduces a claims-based authorization platform

Deploying a central access policy includes the following phases:

Deploy the central access policy Deploy the policy.