Active Directory Domain

Services
Overview of AD DS
AD DS is composed of both logical and physical components

Logical components Physical components

• Partitions • Domain controllers
• Schema • Data stores
• Domains • Global catalog
• Domain trees servers
• Forests • RODCs
• Sites
• OUs
• Containers
What Are OUs?

• Containers that can be used to

group objects within a domain
• Create OUs to:
• Configure objects by assigning
GPOs
• Delegate administrative
permissions

OUs are represented by a

folder with a book on it
Containers are represented
by a blank folder
Active Directory
Structure and Storage
Architecture
• Active Directory domains and forests. Forests,
domains, and organizational units (OUs) make up
the core elements of the Active Directory logical
structure. A forest defines a single directory and
represents a security boundary. Forests contain
domains.
• Domain Name System (DNS) support for
Active Directory. DNS provides a name resolution
service for domain controller location and a
hierarchical design that Active Directory can use to
provide a naming convention that can reflect
organizational structure.
• Schema. The schema provides object definitions
that are used to create the objects that are stored in
the directory.
• Data store. The data store is the portion of the
directory that manages the storage and retrieval of
data on each domain controller
Understanding the AD DS Database

Domain Domain Partition

Controller

Configuration
Partition

Schema Partition
AD DS
Database

Application
Partitions (optional)
Data Store Components

Component Description
Interfaces (LDAP, REPL, MAPI, The data store interfaces provide a way for directory
SAM) clients and other directory servers to communicate
with the data store.
DSA (Ntdsa.dll) The DSA (which runs as Ntdsa.dll on each domain
controller) provides the interfaces through which
directory clients and other directory servers gain
access to the directory database. In addition, the
DSA enforces directory semantics, maintains the
schema, guarantees object identity, and enforces
data types on attributes.
Database layer The database layer is an application programming
interface (API) that resides in Ntdsa.dll and provides
an interface between applications and the directory
database to protect the database from direct
interaction with applications. Calls from applications
are never made directly to the database; they go
through the database layer. In addition, because the
directory database is flat — with no hierarchical
namespace — the database layer provides the
database with an abstraction of an object hierarchy.
ESE (Esent.dll) The ESE (which runs as Esent.dll) communicates
directly with individual records in the directory
database on the basis of an object’s relative
distinguished name attribute.
Database files The data store stores directory information in a
single database file. In addition, the data store also
uses log files, to which it temporarily writes
uncommitted transactions.
Data Store
Physical
Structure
Operations Master

Five operations master roles manage single-master operations in AD DS.

Two operations master roles exist in each forest:

•The schema master, which governs all changes to the schema.

•The domain naming master, which adds and removes domains to and from the forest.

In addition to the two forestwide operations master roles, three operations master roles exist in each
domain:

•The primary domain controller (PDC) emulator. The PDC emulator receives preferential
replication of password changes that are performed by other domain controllers in the
domain, and it is the source for the latest password information whenever a logon
attempt fails as a result of a bad password. It is a preferred point of administration for
services (examples are Group Policy and Distributed File System, DFS

•The relative identifier (RID) master. The RID master allocates RIDs to all domain controllers to ensure
that all security principals have a unique identifier.
•The infrastructure master. The infrastructure master for a given domain maintains a list of the security
principals from other domains that are members of groups within its domain.
fsmoRoleOwner attribute
Schema master
LDAP://CN=Schema,CN=Configuration,DC=Contoso,DC=Com

Domain naming master

LDAP://CN=Partitions,CN=Configuration,DC=Contoso,DC=Com

RID master
LDAP://CN=Rid Manager$,CN=System,DC=Contoso,DC=Com

PDC emulator
LDAP://DC=Contoso,DC=Com

Infrastructure master
LDAP://CN=Infrastructure,DC=Contoso,DC=Com
 Global Catalog
• Forest-wide searches.
• Universal group membership
enumeration from a global catalogue
server

• Resolve user principal name (UPN)

• Universal Group Membership Caching
Exchange Address Book lookups
 What Is the AD DS Schema?

The schema defines the objects that can be stored in AD DS

How DNS Integrates with Active Directory
•Standard zone storage, using a text-based file.

Zones stored this way are located in .dns files that are stored in the systemroot\System32\Dns folder on each
computer operating a DNS server. Zone file names correspond to the name you choose for the zone when
creating it, such as “example.microsoft.com.dns” if the zone name was “example.microsoft.com.”

•Directory-integrated zone storage, using the Active Directory database.

Zones stored this way are located in the Active Directory tree under the domain or application directory
partition. Each directory-integrated zone is stored in a dnsZone container object identified by the name you
choose for the zone when creating it.
DNS-AD Integrated
Benefits of Integrating DNS with Active Directory
Using Active Directory as the data storage and replication engine provides the following
benefits:
•DNS replication is performed by Active Directory, so there is no need to support a separate
replication topology for DNS servers.
•Active Directory service replication provides per-property replication.
•Active Directory service replication is secure.
•A primary DNS server is eliminated as a single point of failure. Original DNS replication is
single-master and relies on a primary DNS server to update all the secondary servers. Unlike
original DNS replication, Active Directory service replication is multimaster; an update can be
made to any domain controller in it, and the change will be propagated to other domain
controllers. In this way if DNS is integrated into Active Directory service the replication engine
will always synchronize the DNS zone information.
DNS Application Directory Partitions
Forest-wide DNS application directory
partition
Domain-wide DNS application
directory partition
DNS application directory partition for the entire forest. DNS zones
stored in this application directory partition are replicated to all DNS
servers running on domain controllers in the forest.
This DNS application directory partition is created when you install the
DNS Server service on the first Windows Server 2003
domain controller in the forest.
DNS application directory partition for each domain in the forest. DNS
zones stored in this application directory partition are replicated to all
DNS servers running on domain controllers in the domain. For the
forest root domain, this DNS application directory partition is created
when you first install the DNS Server service on a Windows Server
2003 domain controller in the forest.
For each new domain in the forest (child domain), this DNS
application directory partition is created when you first install the DNS
Server service on a Windows Server 2003 domain controller for the
new domain.
DC Locator process
DC Locator process

•The Windows computer and the selected Domain Controller belong to the same Active Directory site: In this situation, the following will happen:
•The selected Domain Controller provides the client computer with the site name
DC Locator Process
•The Windows computer sends a DNS query to ask for DNS resolution of
•ldap._tcp.Computer_Site_Name._sites.dc._msdcs.domain.com
•(Example: _ldap._tcp.denver._sites.dc._msdcs.contoso.com) SRV records
DC Locator
Replication Model Components

Component Description Advantage

Multimaster replication
Every domain controller can receive
originating updates to data for which it
is authoritative, rather than having a
single domain controller that receives
all original updates
Provides fault tolerance, eliminating
the dependency on a single domain
controller to maintain directory
operations.

Pull replication Domain controllers request (pull) Reduces unnecessary network traffic.
changes rather than send (push)
changes that might not be needed.

Store-and-forward replication
Each domain controller communicates Balances the replication load among
with a subset of domain controllers to many domain controllers.
transfer replication changes, rather
than one domain controller being
responsible for communicating with
every other domain controller that
requires the change.

State-based replication Each domain controller tracks the state Conflicts and unnecessary replication
of replication updates. are reduced.
Active Directory Replication Dependencies

Active Directory replication has the following

dependencies:
•DNS. The Domain Name System (DNS) that resolves DNS
names to IP addresses. Active Directory requires that DNS
is properly designed and deployed so that domain
controllers can correctly resolve DNS names of replication
partners.
•Remote procedure call (RPC). Active Directory
replication requires IP connectivity and the Remote
Procedure Call (RPC) to transfer updates between
replication partners.
•Kerberos v5 authentication. The authentication protocol
for both authentication and encryption that is required for
all Active Directory RPC replication.
•LDAP protocol. The primary access protocol for Active
Directory. Replication of an entire replica of an Active
Directory domain, as occurs when Active Directory is
installed on an additional domain controller in an existing
domain, uses LDAP communication rather than RPC.
Active Directory Replication

Active Directory supports the following four types of

update requests:

•Add an object to the directory.

•Modify (add, delete, or replace) attribute values of an
object in the directory.
•Move an object by changing the name or parent of the
object.
•Delete an object from the directory.

****

•Replication uses Kerberos v 5 authentication protocol for security, which does require that the
time services on domain controllers are synchronized.

Active Directory replication does not primarily depend on time to determine

what changes need to be propagated. Instead it uses update sequence
numbers (USNs) that are assigned by a counter that is local to each domain
controller
Active Directory Replication

The DSA GUID is the GUID of the NTDS Settings object (class nTDSDSA), which is a child object of the
server object. Its value is stored in the objectGUIDattribute of the NTDS Settings object.

The Active Directory database has its own GUID, which the DSA uses to identify the database
instance (version of the database). The database GUID is stored in the invocationIdattribute
on the NTDS Settings object.

The current USN is a 64-bit counter that is maintained by each Active Directory domain
controller as the highestCommittedUsnattribute on the rootDSE object.
 Tracking Object Creation, Replication, and Change
1. Replication-related Data on DC1 When a User Object is Created

2. Replication-related Data on DC2 When a New User Object is Replicated From DC1
 Tracking Object Creation, Replication, and Change

3. Replication-related Data on DC2 After the User Password Value Has Been Changed on DC2

4. Replication-related Data on DC1 After the Password Change Has Replicated to DC1
 Replication Request Filtering

Two values are used by source and destination domain controllers to filter updates when the
destination requests changes from the source replication partner:

•Up-to-dateness vector. The current status of the latest originating updates to occur on all domain controllers
that store a replica of a specific directory partition.
•High-watermark (direct up-to-dateness vector). The latest update (originating or replicated) to a specific
directory partition that has been received by a destination from a specific source replication partner during the
current replication cycle.

Both of these values specify the invocation ID of the source domain controller.
Multiple Paths Without Redundant Replication

1.DC A updates a password attribute. In this example, the originating USN of the
attribute is set to 3.
2.Destination DC B requests changes from source DC A and sends its high-watermark
and up-to-dateness vector to DC A.
3.According to the high-watermark that was passed by DC B, source DC A examines
one or more objects, one of which contains the changed password. When DC A
encounters the changed password attribute, it proceeds as follows:
1. First, DC A finds that the originating directory system agent (DSA) of the
password attribute is DC A.
2. Therefore, DC A reads the up-to-dateness vector supplied by DC B and finds
that DC B is guaranteed to be up-to-date with updates that originated at DC
A and that have an originating USN of less than or equal to 2.
3. DC A then finds that the originating USN of the password attribute is 3.
4. Because 3 is greater than 2, DC A sends the changed password attribute to DC
B.
 KCC Architecture and Process Components

Component Description

Knowledge Consistency The application running on

Checker (KCC) each domain controller that
communicates directly with
the Ntdsa.dll to read and write
replication objects.

Directory System Agent (DSA) The directory service

component that runs as
Ntdsa.dll on each domain
controller, providing the
interfaces through which
services and processes such
as the KCC gain access to the
directory database.

Extensible Storage Engine The directory service

(ESE) component that runs as
Esent.dll. ESE manages the
tables of records, each with
one or more columns. The
tables of records comprise the
directory database.

Remote procedure call (RPC) The Directory Replication

Service (Drsuapi) RPC
protocol, used to
communicate replication
status and topology to a
domain controller. The KCC
also uses this protocol to
communicate with other KCCs
to request error information
when building the replication
topology.

Intersite Topology Generator The single KCC in a site that

(ISTG) manages intersite connection
objects for the site.
 AD Replication

The following rules apply to the replication transports:

•Replication within a site always uses RPC over IP.
•Replication between sites can use either RPC over IP or SMTP over IP.
•Replication between sites over SMTP is supported for only domain controllers of different domains. Domain
controllers of the same domain must replicate by using the RPC over IP transport. Therefore, replication between
sites over SMTP is supported for only schema, configuration, and global catalog replication, which means that
domains can span sites only when point-to-point, synchronous RPC is available between sites.

When domain controllers for the same domain are located in different sites, at least one bridgehead server per
directory partition and per transport (IP or SMTP) replicates changes from one site to a bridgehead server in
another site

By default, site links are transitive, or “bridged.” If site A has a common site link with site B, site B also has a
common site link with Site C, and the two site links are bridged, domain controllers in site A can replicate
directly with domain controllers in site C under certain conditions, even though there is no site link between
site A and site C. In other words, the effect of bridged site links is that replication between sites in the bridge is
transitive.
 AD Replication

The KCC performs two major functions:

•Configures appropriate replication connections (connection objects) on the basis of the existing cross-reference,
server, NTDS settings, site, site link, and site link bridge objects and the current status of replication.
•Converts the connection objects that represent inbound replication to the local domain controller into the
replication agreements that are actually used by the replication engine. These agreements, called replica links,
accommodate replication of a single directory partition from the source to the destination domain controller.

By default, the KCC runs its first replication topology check five minutes after the domain controller starts. The
domain controller then attempts initial replication with its intrasite replication partners

The KCC on a destination domain controller evaluates the topology by reading the existing
connection objects. For each connection object, the KCC reads attribute values of the NTDS
Settings object (class nTDSDSA) of the source domain controller (indicated by
the fromServer value on the connection object) to determine what directory partitions its
destination domain controller has in common with the source domain controller.
 AD Replication
The KCC automatically rebuilds the replication topology when it recognizes that a domain controller has failed or is
unresponsive.

The requesting domain controller must have made n attempts to replicate from the target domain
controller.

A certain amount of time must have passed since the last successful replication attempt.

Bridgehead servers can be selected in the following ways:

•Automatically by the ISTG from all domain controllers in the site.
•Automatically by the ISTG from all domain controllers that are identified as preferred bridgehead servers, if any
preferred bridgehead servers are assigned. Preferred bridgehead servers must be assigned manually.
•Manually by creating a connection object on a domain controller in one site from a domain controller in a
different site.

Restricting the directory service to using a fixed port requires editing the TCP/IP Port registry
entry (REG_DWORD), located in:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
 Replication Metadata
the data which captures all the change log of an object since its creation until deletion. In fact, we will be able to see
an object’s metadata even after deletion, as long as the object is tombstoned in Active Directory (AD).

Repadmin /showobjmeta : We can run this command from any Domain Controller, or where AD
Module is installed.
Get-ADReplicationAttributeMetadata: This is the PowerShell command which is available
Windows Server 2012 onward.

Replication Metadata provides us below information about an object:

When the object was created, and in which Domain Controller.
Which attribute has been modified at what time, and from which Domain Controller.
All the corresponding USN Numbers.

Replication
Replication Metadata is the factor that governs AD Replication. During an AD replication, Domain
Controllers compare the USN number with its direct connection partners and replicate all metadata
changes which happened since last replication.
 Replication Metadata
Forward links
Only forward links attributes are replicated, not backward links. For example, for a user object, the “Member Of”
attribute values are not replicated. All group’s “Members” attributes are replicated, and from there the “Members”
tab of linked objects are automatically updated. That means backward links are updated automatically on every
Domain Controllers, by calculating the corresponding forward links which have been replicated.
Active Directory Trusts

 Trusts provide a mechanism for users to gain secure access to resources in another domain
 Trusts can be created between domains and Active Directory forests
 All trusts between domains in an AD forest are transitive and two-way. When a new child domain is
created, a two-way, transitive trust is automatically created between the new child domain and the parent
domain.
 Admin would need to create a trust between domains of different Active Directory forests if you need to
allow users from one domain to access resources in another domain in a different Active Directory forest.
 Trusted domain: The domain where the user account requesting access is located
 Trusting: The domain that contains a shared resource that a user account is trying to access

Access

TRUST

Trust Relation -
Simple

Corp.tailspin.com Corp.wingting.com Corp.tailspin.com Corp.wingting.com

Direction of Trust

One-Way  A one-way trust is a unidirectional authentication path created between two.

 In a one-way trust between a trusted domain and a trusting domain, users or computers
in the trusted domain can access resources in the trusting domain. However, users in the
trusting domain cannot access resources in the trusted domain.
 Some one-way trusts can be either nontransitive or transitive, depending on the type of
trust being created.
Two-Way  Trusting and trusted domains both trust each other (trust and access flow in both
directions)
 Authentication requests can be passed between the two domains in both directions
 Some two-way relationships can be either nontransitive or transitive depending on the
type of trust being created
 When a new child domain is created, a two-way, transitive trust is automatically created
between the new child domain and the parent domain.
Transitivity  Transitivity determines whether a trust can be extended beyond the two domains
between which it was formed
 A transitive trust extends trust relationships to other domains & nontransitive trust does
not extend trust relationships to other domains.

Trust & Access

Trust Types

Type Description
Intra-Forest Intra-forest trusts are transitive trusts that can be used only within a single forest, and include tree-root,
parent-child, and shortcut trusts
Tree-Root By default, two-way, transitive trusts are automatically created when a new domain is added to a domain
tree or forest root domain by using the Active Directory Installation Wizard. When a new domain tree is
created in an existing forest, a new tree-root trust is established.
Parent-Child When a new child domain is added to an existing domain tree, a new parent and child trust is
established. Authentication requests made from subordinate domains flow upward through their parent
to the trusting domain.
ShortCut A transitive trust between domains in the same domain tree or forest that is used to shorten
the trust path in a large and complex domain tree or forest.
Realm A transitive trust between an Active Directory domain and a Kerberos V5 realm. Realm trusts
can be manually switched back and forth between nontransitive and transitive by using the
Netdom.exe tool. Realm trusts can be either one-way or two-way
External External trusts are nontransitive and can be created between Active Directory domains in
different forests or between an Active Directory domain and a Windows NT 4.0 domain
Forest A transitive trust between one forest root domain and another forest root domain
Illustration – Types of Trusts
Figure 2

Figure 1

Figure 3
Create Trust

• Use the AD Domains and Trusts snap-in or Netdom command

 Netdom Trust <TrustingDomain> /D:<TrustedDomain> /Add

 Netdom Trust <TrustingDomain> /D:<TrustedDomain> /Verify

 Windows Time Service

 Windows Time Services - Maintains date and time synchronization on all clients and servers in the network. If this
service is stopped, date and time synchronization will be unavailable. If this service is disabled, any services that
explicitly depend on it will fail to start.

 Path to exe: C:\WINDOWS\system32\svchost.exe -k LocalService [dynamic link library: W32Time.dll]

 Registry key: HKLM\System\CurrentControlSet\Services\W32Time

 W32Time service is essential to the successful operation of Kerberos V5 authentication and, therefore, to AD DS-
based authentication.

 Kerberos-aware applications, 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.

 In Active Directory, the PDC Emulator should get the time from an external time source and then all member
computers of this domain will get the correct time. Set the PDC emulator to synchronize with a valid Network Time
Protocol (NTP) source. If you have not configured a source, the Windows Time service logs a message to the event log, and then
uses the local clock when it provides time to clients
 Windows Time Service – Time Protocol

 Time Protocol- It communicates between two computers to exchange time information and uses 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.
 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)
 pool.ntp.org is a round-robin of random selected NTP servers http://support.ntp.org/bin/view/Servers/NTPPoolServers
 Example: w32tm /config /manualpeerlist:”0.pool.ntp.org 1.pool.ntp.org” /syncfromflags:MANUAL
Service name UDP TCP
NTP 123 N/A
SNTP 123 N/A

 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

 W2k16 uses improved algorithms to use correct time and condition the local clock to sync with UTC.
Illustration
Commonly used switches of w32tm

Command Description

w32tm /query /status Displays the current status

w32tm /query /source Displays the currently used time source. After a restart of the service, it
might show Local CMOS Clock until everything has refreshed properly
w32tm /query /peers Displays all configured peers you have configured

w32tm.exe /resync /rediscover /nowait
w32tm /query /configuration
w32tm /config /manualpeerlist:<peers>
/syncfromflags:manual /reliable:yes /update
Resynchronize the clock as soon as possible, disregarding all accumulated
error statistics. It will not wait for resynchronization and will force
redetection of sources
Displays the configuration
To configure the PDC emulator

Tip: To clear the configuration, start from scratch and configure NTP using w32tm.exe:

 Stop-Service w32time
 w32tm /unregister
 w32tm /register
 Start-Service w32time
Clippings

Tip: If the machine is a VM inside Hyper-V, you have to disable time sync. Open VM settings -> Management -> Integration Services
and uncheck Time Synchronization
RODC

 Represents the fundamental change in how we typically use or place Domain Controllers [DC]

 Represents DCs that host complete, read-only copies of Active Directory database partitions, a read-
only copy of SYSVOL, and a Filtered Attribute Set (FAS) that restricts the inbound replication of
certain application data from writable DCs
 Default RODC FAS contains:
ms-PKI-DPAPIMasterKeys
ms-PKI-AccountCredentials
ms-PKI-RoamingTimeStamp
ms-FVE-KeyPackage
ms-FVE-RecoveryPassword
ms-TPM-OwnerInformation

 Credentials, except for the RODC's own computer account credentials and a special krbtgt account
for the RODC are not replicated to this role

 This feature is meant for environments that require local authentication and authorization, but lack
the physical security to safely use writable DCs – mainly Remote Branch Offices, typical end points in
a hub-and-spoke network topology

 Installation: Server Manager, Roles to add with RODC are GC and DNS
Screen shots

$domain = 'AD'
$domainName = 'ad.wingping.com'
$NTDSpath = 'C:\Windows\NTDS'
$SYSVOLpath = 'C:\Windows\SYSVOL'

• Install-WindowsFeature –Name AD-Domain-Services -includemanagementtools

• Install-ADDSDomainController -Credential (Get-Credential) -CriticalReplicationOnly:$false -DomainName $domainName
-InstallDNS:$true -LogPath $NTDSpath -DatabasePath $NTDSpath -ReadOnlyReplica:$true -SiteName "Default-First-
Site-Name" -SYSVOLPath $SYSVOLpath -Force:$true
Differences with Other DC Roles

Features DC [Writable] RODC

AD database Read and Write operations possible • Database Read-only; Appls can only read only from the directory
• RODCs automatically forward certain write operations to writable
domain controllers, and they can send referrals to writable domain
controllers when necessary

Data Replication Replication bidirectional • Replicates data from a writable domain controller, and it never
replicates data to another domain controller in the domain. This is
true for both the Active Directory data and the SYSVOL data.

Data Stored in the DB Contain complete copy of the
directory database
Administration Managed by Domain admins
• Contains complete copy of the database with the exception of
credentials and attributes that are part of FAS; However, you
admin can select which credentials can be cached on the RODC to
provide better authentication performance for users who are
located in a site that an RODC services
• By delegated users that do not have any domain privileges beyond
standard domain users.
RODC Caching

 To enable RODCs to authenticate users and computer accounts, configure the Password Replication
Policy (PRP) to ensure that it replicates and caches the credentials on the RODC for subsequent
authentications
 With RODC install, there are 4 new attributes and two built-in-groups created to support PRP: the
Allowed RODC PRP [This group is added to the msDS-Reveal-OnDemandGroup]and the Denied RODC PRP [This group is added
to the msDS-NeverRevealGroup]

 msDS-Reveal-OnDemandGroup
 msDS-NeverRevealGroup
 msDS-RevealedList
 msDS-AuthenticatedToAccountList

 The RODC caches account credentials for members of the Allowed Password Replication Group but not
those of the Denied Password Replication Group. By default, accounts from privileged groups such as
Enterprise, Schema, and Domain Admins are members of the Denied RODC Password Replication Group
Get-ADGroupMember -Identity "Denied RODC Password Replication Group" | ft DistinguishedName, Name,
ObjectClass
 Once an RODC caches passwords, there is no way to delete them on it directly. However, resetting the
passwords on a writeable DC also removes them from the password cache on the RODC
List of accounts with cached passwords in RODC: Get-ADDomainControllerPasswordReplicationPolicyUsage
• Configure PRP by:
Open Active Directory Users and
Computers snap-in and select the
RODC in the Domain Controllers
organizational unit.

• Another feature: Prepopulate the

password cache for an RODC
Authentication

 When a user account is not cached, the RODC forwards the authentication to a writable Domain
Controller which does the authentication.
 If the Users password is allowed to be cached, then the RODC will pull that through a replication
request
 Once the user has been authenticated, and their password has been cached, any subsequent login
can then be handled by the RODC alone
 There might be increase in WAN traffic with introduction of RODC, but after caching user passwords
there should be a significant reduction in traffic and a more secure environment.
New in ADDS in 2k16

 Privileged Access Management

 Extending cloud capabilities to W10 devices through AAD Join

 Connecting domain-joined devices to Azure AD for Windows 10 experiences

 Enable Microsoft Passport for Work in your organization

 Deprecation of File Replication Service (FRS) and Windows Server 2003 functional levels
 DFSN
DFS clients
DFS clients are the computers used to access namespaces. DFS clients are typically end-user computers; computers
running Windows-based server operating systems can also access namespaces

Root servers
Root servers (also called root targets) are the servers on which administrators create stand-alone and
domain-based namespaces. A root server can be a member server or a domain controller

For stand-alone namespaces, the DFS metadata is stored in the registry of the root server. For
domain-based namespaces, DFS metadata is stored in Active Directory. Root servers also keep the
DFS metadata for each namespace in a memory cache.

Root servers host shared folders that act as the root (known as the root folder) and subfolders (under
the root folders) that correspond to every link (known as link folders) in those namespaces.

When a client attempts to access a root or link in a stand-alone namespace, or a link in a domain-
based namespace, the root server provides a referral to the client.

Link targets
Link targets are typically shared folders or folders within shared folders. Link targets can be served
by any network file system that is accessible by a UNC path, such as Server Message Block (SMB),
NetWare Core Protocol (NCP) for NetWare, or Network File System (NFS) for UNIX.
DFSN
 DFS Client Components

Component Description
Domain cache Contains the domain name referrals and domain controller referrals that
are stored in memory on each client computer. The domain cache stores
NetBIOS and DNS domain names for the local domain, all trusted
domains in the forest, domains in trusted forests, and the mappings of
the domain names to the domain controllers. The domain cache (also
called SPC cache) is maintained in Mup.sys.

I/O Manager Plays a role in handling the file I/O in redirecting the UNC paths to
Mup.sys. I/O Manager is part of the core kernel (Ntoskrnl.exe) of the
operating system.
Mrxsmb.sys Handles communications to the root servers, domain controllers, and
Windows-based file servers that use the CIFS protocol.
Mup.sys Implements DFS client support and redirector selection. "Mup" stands for
“multiple UNC provider.”
Mup.sys is a networking component that handles input/output (I/O)
requests for a file or device that has a UNC name (that is, a name that
begins with \\). If the UNC name is a DFS path, Mup.sys resolves it to
the physical UNC path. After the path is resolved, or if the path was not a
DFS path, Mup.sys determines the local redirector that handles the UNC
path.
Ntlanman.dll Handles the establishment of drive letter and unnamed connections for
DFS and SMB paths.
Nwrdr.sys and Mrxdav.sys The redirectors for Netware and Web Distributed Authoring and
Versioning (WebDAV), respectively.
Referral cache Stores the root referrals and link referrals received by the client when it
accesses a namespace. The referral cache (also known as the PKT cache)
is maintained in Mup.sys.
Workstation service (Wkssvc.dll) Sends domain controller information and domain names to Mup.sys.
Mup.sys uses this information to generate the referrals in the client’s
domain cache. This service is also a component of the Server Message
Block (SMB) client. Also manages the loading and unloading of the
Mrxsmb.sys.
DFS Root Components

Component Description
Dfs.sys The DFS driver. Dfs.sys runs only on Windows-based server
operating systems and reflects referral requests from DFS
clients to the DFS service running in user mode. Dfs.sys also
handles the processing of links when they are encountered
during file system access.

DFS metadata cache The in-memory copy of DFS metadata maintained in Dfssvc.exe
on root servers. DFS metadata consists of information about
entire namespace, including the root, root targets, links, link
targets, and settings.
Dfssvc.exe The DFS service. Provides server-side support for
NetDFSxxx APIs that configures and maintains DFS
namespaces. The DFS service is also responsible for
maintaining an up-to-date version of the DFS metadata and for
giving referrals to clients who attempt to access the
namespace.
Domain-based root referral cache and site caches The in-memory copies of domain-based root referrals and site
information that enable Dfssvc.exe to perform fast lookups.
These caches are described in the next section.
Registry Where the DFS metadata is stored for stand-alone DFS
namespaces.
Srv.sys The SMB Service server driver. Plays a role in DFS by passing
on referral requests from DFS clients to Dfs.sys.

Active Directory Where the DFS object is stored. The DFS object stores the DFS
metadata for a domain-based namespace
Referral Process for Domain-based Namespaces
 DFSN

Dfsutil.exe command-line tool with the /spcinfo

[*][dc-01.contoso.com]
[*][CONTOSO] MUP Cache
[*][contoso.com] The multiple UNC provider (MUP) cache stores information about
[+][contoso.com] which redirector, such as DFS, SMB, or WebDAV, is required for each
[-dc-02.contoso.com] UNC path that a client computer attempts to access. Entries in the
[+dc-01.contoso.com] MUP cache are held for 15 minutes. You can use
[-dc-04.contoso.com] Dfsutil.exe’s /PurgeMupCache parameter to clear the MUP cache
[-dc-03.contoso.com]
[-][AFRICA]
[-][EUROPE]
[+][CONTOSO]
[-DC-02] [+DC-01] [-
DC-03] [-DC-04] [-
][europe.contoso.com]
[-
][africa.contoso.com]
Referral Cache on Clients
How Changes Are Discovered in Domain-based Namespaces

the DFS metadata is stored in the DFS object in Active Directory on each domain controller and is stored in a
memory cache on multiple root servers. To ensure that all root servers discover changes to the namespace,
DFS uses two methods of keeping root servers up to date:
•Root server notification

•Periodic polling of the PDC emulator master

DFS Protocols
DFS uses the Common Internet File System (CIFS) for communication between DFS clients,
root servers, and domain controllers. CIFS is an extension of the Server Message Block (SMB)
file sharing protocol.
 Distributed File System Replication

The Distributed File System Replication (DFSR) service is a state-based, multimaster replication engine that supports
replication scheduling and bandwidth throttling

uses a compression algorithm known as remote differential compression (RDC).

DFS Replication is a multimaster replication engine. Any change that occurs on one member is
replicated to all other members of the replication group.

DFS Replication detects changes on the volume by monitoring the update sequence number (USN)
journal, and DFS Replication replicates changes only after the file is closed.

DFS Replication uses a staging folder to stage a file before sending or receiving it

When a file is changed, only the changed blocks are replicated, not the entire file

DFS Replication uses a conflict resolution heuristic of last writer wins for files that are in conflict
 DFSR
DFS Replication is self-healing and can automatically recover from USN journal wraps, USN journal loss, or loss of
the DFS Replication database.

DFS Replication uses a Windows Management Instrumentation (WMI) provider that provides
interfaces to obtain configuration and monitoring information from the DFS Replication service.

DFSR Replicated Folders

The state of a replicated folder can be one of the following: uninitialized, initialized, initial sync,
auto recovery, normal, or in error

DFSR uses fence values to ensure that the correct version of a resource (file or folder) is replicated
where there is a conflict

Replication flow for a replicated folder begins at the designated primary member, flows to its
downstream partners, then to their downstream partners, and so on.
DFSR

Fence Values
The fence values for resources are used to guarantee predictable outcomes from conflict resolution.
•A version of a resource with a normal fence value takes precedence over versions with initial-primary and
initial-sync fence values.
•A version of a resource with an initial-primary fence value takes precedence over versions with an initial-
sync fence value.
•If two versions have the same fence value, the conflict is resolved using first create time, then last
modified time.
•A newly created file has a default fence value.
•A file can also be unfenced, which guarantees that it will lose on conflict.
•Time stamps can also be used as fence values; in this case, the version with the highest time stamp takes
precedence over other time stamps or fence values.
 Group Policy

Group Policy Objects are actually

composed of two parts

1) the Group Policy Container

(GPC) which exists in Active
Directory
2) Group Policy Template (GPT)
where the actual content of your
GPOs resides.

A third component, known as Client-

Side Extensions (CSEs) can be found
on client devices and are necessary
for them to properly process the
Group Policies assigned to them.
Using LDP (GPC)
 GPT (Group Policy Container)

The Group Policy Template is where the meat of the GPO resides
it resides in a share known as SYSVOL.
is replicated to every DC in the domain •%windir%
• sysvol
• sysvol (shared as \\servername\sysvol)
• <domain name>
• Policies
• scripts
Within the policies folder, you'll find the various GPOs and
their configured settings. Again, the following folders/files
are guaranteed to be present for every GPO in your
domain:
•Policies
• <GPO GUID>
• Machine (folder containing the computer-side
settings of the GPO)
• User (folder containing the user-side settings of
the GPO)
• GPT.INI (file containing the GPO's configuration
settings)
Group Policy
Group Policy
Group Policy
Group Policy
•Scripts folder - This folder can contain information on which scripts to run, or may include the scripts
themselves. The possible types of scripts include:
• Startup/Shutdown: applies to Computers
• Logon/Logoff: applies to Users

Documents and Settings folder - this folder contains any Folder Redirectoin settings
configured by the GPO.

IEAK folder - this user-side folder contains settings related to Internet Explorer Maintenance.

Registry.pol - this file contains the registry settings the GPO has been configured to
apply. This file also contains any Software Restriction Policy settings that have been
configured.

Registry-based policy settings (located under the Administrative Templates category in the
Group Policy Object Editor) are defined using a standards-based, XML file format, known as
ADMX files
How Does a Client Know Which GPOs to Apply?

Within the directory, GPOs can be linked to the following levels:

•Site
•Domain
•Organizational Unit
Depending on where the client object is located determines which GPOs it applies

Order of events when starting up and logging on

1) Network starts. Remote procedure Call System Service (RPCSS) and Multiple
Universal Naming Convention provider (MUP) start.
2) An ordered list of Group Policy objects is obtained for the computer. The list might
depend on these factors:
Whether the computer is part of a domain and therefore subject to Group Policy
through Active Directory.
The location of the computer in Active Directory.
Whether the list of Group Policy objects has changed. If the list of Group Policy objects
has not changed, no processing is done. You can use a policy setting to change this
behavior.
 Group Policy

3) Computer policy is applied. These are the settings under Computer Configuration from the gathered list.
4) Startup scripts run. This is hidden and synchronous by default;
5) An ordered list of Group Policy objects is obtained for the user. The list might depend on
these factors:
Whether the user is part of a domain and therefore subject to Group Policy through Active
Directory.
Whether loopback is enabled, and the state (Merge or Replace) of the loopback policy
setting.
The location of the user in Active Directory.
Whether the list of Group Policy objects has changed. If the list of Group Policy objects has not
changed, no processing is done. You can use a policy setting to change this behavior.

6) User policy is applied. These are the settings under User Configuration from the gathered
list.

7) Logon scripts run

 Order of processing settings

Group Policy settings are processed in the following order:

1.Local Group Policy object--Each computer has exactly one Group Policy object that is stored locally.
2.Site--Any Group Policy objects that have been linked to the site are processed next. Processing is synchronous
and in an order that is specified by the administrator.
3.Domain--Processing of multiple domain-linked Group Policy objects is synchronous and in an order specified by
the administrator.
4.Organizational units--Group Policy objects that are linked to the organizational unit that is highest in the Active
Directory hierarchy are processed first, then Group Policy objects that are linked to its child organizational unit, and
so on. Finally, the Group Policy objects that are linked to the organizational unit that contains the user or computer
are processed.

Exceptions to the default order

No Override
Block Policy inheritance
A computer that is a member of a workgroup processes only the local Group Policy object.
Loopback Policy
 Filtering a GPO

control the GPO by assigning

permissions for who can
process your GPO. This is
known as filtering.
When you filter a GPO,
you specifically designate
which users, group and
computers are allowed to
apply a GPO

In order for a GPO to

apply to an object, that
object must have two
rights over that
GPO. These are:
Read
Apply Group Policy
 How Clients Process GPOs

GPO Versions

Every change
that is put into a
GPO causes its
version number
to increase
 Group Policy
the AD portion (the GPC) of the GPO is showing one version number and the portion of the GPO in SYSVOL (the GPT)
is showing another, this means the GPO is not fully synchronized
 CSE

HKEY_LOCAL_MACHINE\SOFT
WARE\Microsoft\Windows\Cur
rentVersion\Group
Policy\State
Within this registry key, you'll
see two nodes. These are:

Machine - this key contains

the GPOs that apply machine-
side settings to your client
User SID - this key is the
user's security identifier and
contains the GPOs that apply
user-side settings to your
client
 Client-Side Extensions (CSEs)

A Client-Side Extension is
nothing more than a file
that has been installed on
the client machine which
has the ability to interpret
and process certain of the
settings in a GPO.
What is the difference between GP policy settings and
preferences
GP policy settings will:
1.not tattoo. In other words, when a Group Policy object (GPO) goes out of scope, the policy setting is
removed allowing the original configuration value to be used.
2.supersede an application's configuration setting. In other words, when a GP policy is configured to
a value, the application is aware of that value and always uses it over the configurable value.
3.be recognized by an application. In other words, the display of the configuration item under control
of a GP policy setting will be unavailable through the user interface. This is where graying out a
configuration item on a menu, not displaying a dialog box, or providing a pop-up message explaining
the current feature is under administrator control is used to inform the user they can't configure an
option.

GP preference settings will:

1) tattoo, by default.
2) overwrite an application's configuration setting
3) not be recognized by an application.
Identity federation

 Identity federation is a process that enables distributed identification, authentication and authorization
across organizational and platform boundaries

 Federation requires trust relationship between two orgs or entities

 Allows orgs to retain control of:
 Resource Access
 Their own user and group accounts

Federation for B2B Federation for B2C or

B2E in a web SSO
scenario
 Identity Federation

 Federation Trust
ADFS farm – 5  Authentication Protocol
Account fed server  Sign-In Protocol
 Token Type
Web Application 4 Web server
 Account federation org
DC – identity
1 2  Resource Federation org
store
 ADFS Proxy
3
External user  ADFS Farm
ADFS farm- resource
 Identity Store
ADFS proxy - LB federation server  Web server

Account partner
Federation Trust
Resource partner
org/Claims Provider org/relying party

To implement federation:
 Create a trust policy for both the resource and account partners
 Create org claims
 Create account store
 Create and configure apps
A. DatumAccount
Microsoft
Partner E-CompanyPartner
Trey Research
Resource Store
Account Forest(Users) Resource Forest
(Resource)
(Resource)
(Users)

Federation Trust
Active Directory

Federation Server Federation Server

Internal Client Web Server

What is ADFS
 ADFS is federated identity management solution – Microsoft’s identity access solution/STS provider
 Optional component in Windows 2003 R2, is now a role from Windows 2008 onwards
 ADFS helps to establish trust relationship and reduce the need for provisioning and managing user
accounts
 Provides browser based clients (internal and external to network) with seamless Single Sign on [SSO]
access to one or more protected Internet apps like O365
ADFS Concepts
Terms
Federation Server
Claims
Account partner organization
Resource partner org
Configuration database
Federation metadata
Description
A Windows Server that has been configured using the AD FS Federation Server Configuration Wizard to act in the
federation server role. A federation server issues tokens and serves as part of a Federation Service.
claims are statements made about users, that are used primarily for authorizing access to claims-based
applications located anywhere on the Internet. Each statement corresponds to a value that is stored in the claim
Claims can include values such as an e-mail address, User Principal Name (UPN), group membership, and other
account attributes: Identity, Group and Custom
A federation partner organization that is represented by a claims provider trust in the Federation Service. The
account partner organization contains the users that will access Web-based applications in the resource partner
A federation partner that is represented by a relying party trust in the Federation Service. The resource partner
issues claims-based security tokens that contains published Web-based applications that users in the account
partner can access
Stores all the configuration data that represents a single instance of ADFS. It defines the set of parameters that a
Federation Service requires to identify partners, certificates, attribute stores, claims, and various data about these
associated entities. The entire contents can be stored either in SQL or WID, not both.
WID uses a relational data store and does not have its own management user interface (UI). Use fsconfig.exe or
Powershell
The data format for communicating configuration information between a claims provider and a relying party to
facilitate proper configuration of claims provider trusts and relying party trusts. The data format is defined in
Security Assertion Markup Language (SAML) 2.0, and it is extended in WS-Federation.
Claims Pipeline

Account Partner
A. Datum Resource Partner
Trey Research
Account Forest (Users) Resource Forest
(Resource)

Accept Incoming Accept Incoming

Claims Claims

Authorize the Authorize the

Requestor Requestor

Issue Outgoing Claims Issue Outgoing Claims

How ADFS works

Claims based authentication Model to

maintain application security and
implement federated identity

Claims Based Auth: process of

authenticating an user based on a set of
claims about its identity contained in a
trusted token

AD: identity store for ADFS. ADFS hosts

the security token service that issues
tokens for claims based on the
credential verification
Installation
Installation
 Configuration

 ADFS will need third party certificate which should be present in the cert store before you start the
configuration – to encrypt and decrypt the traffic
 Provide the service account name to configure the federation farm. The severs should be able to
communicate with each other in the farm.
Configuration