Week 10 – Manage Multiple Domains and Forest
• Configure Domain and Forest Functional Levels
• Manage Multiple Domains and Trust Relationships
• Active Directory Certificate Services
1
Understand Functional Levels
• Domain functional levels
• Forest functional levels
• New functionality requires that domain controllers (DCs)
are running a particular version of Windows®

Windows 2000

Windows Server® 2003

Windows Server 2008
• Active Directory Domains and Trusts
• Cannot raise functional level
while DCs are running previous
versions of Windows
• Cannot add DCs running
previous versions of Windows
after raising functional level
2
Domain Functional Levels
• Windows 2000 Native
• Windows Server 2003

Domain controller rename

Default user and computer container redirection

lastLogonTimestamp attribute

Selective authentication on external trust relationships
• Windows Server 2008

Distributed File System Replication (DFS-R) of SYSVOL

Fine-grained password policy

Advanced Encryption Services (AES 128 and AES 256) for Kerberos
3
Forest Functional Levels
• Windows 2000
• Windows Server 2003
 Forest trusts
 Domain rename
 Linked-value replication
 Support for Read-Only domain controllers (RODCs)
• Requires adprep /rodcprep and one writeable Windows Server
2008 DC
 Improved Knowledge Consistency Checker (KCC) algorithms and
scalability
 Conversion of inetOrgPerson objects to user objects
 Support for dynamicObject auxilliary class
 Support for application basic groups and Lightweight Directory
Access Protocol (LDAP) query groups
 Deactivation and redefinition of attributes and object classes
• Windows Server 2008
 No new features; sets minimum level for all new domains
4
Define Your Forest and Domain Structure
• Dedicated forest root domain
• Single-domain forest

Single domain partition, replicated to all DCs

Single Kerberos policy

Single Domain Name System (DNS) namespace
• Multiple-domain forest

Increased hardware and administrative cost

Increased security risk
• Multiple trees
• Multiple forests
5
Move Objects Between Domains and Forests
• Inter-forest migration: Copy objects
• Intra-forest migration: Move objects
• Active Directory Migration Tool (ADMT)

Console, command line, scriptable APIs

“Simulation” mode: Test the migration settings and migrate later
• Security identifiers, security descriptors, and migration

sIDHistory

Security Translation: NTFS, printers, SMB shares, registry, rights,
profiles, group memberships
• Group membership
6
Understand Trust Relationships
• Extends concept of trusted identity store to another domain
• Trusting domain (with the resource) trusts the identity store
and authentication services of the trusted domain.
• A trusted user can authenticate to, and be given access to
resources in, the trusting domain
• Within a forest, each domain trusts all other domains
• Trust relationships can be established with external domains
B
A
Trusting Domain Trusted Domain
7
Characteristics of Trust Relationships
• Direction
• Transitivity
• Automatic or Manual
Trusting domain
C
Trusted domain
A
B
Trusted domain
Trusting domain
8
How Trusts Work Within a Forest
Forest Root
Domain
Tree Root
Domain
tailspintoys.com
wingtiptoys.com
europe.tailspintoys.com
usa.wingtiptoys.com
asia.wingtiptoys.com
9
Shortcut Trusts
tailspintoys.com
wingtiptoys.com
europe.tailspintoys.com
usa.wingtiptoys.com
asia.wingtiptoys.com
10
External Trusts and Realm Trusts
tailspintoys.com
worldwideimporters.com
asia.tailspintoys.com
europe.tailspintoys.com
sales.worldwideimporters.com
11
Forest Trusts
tailspintoys.com
worldwideimporters.com
asia.tailspintoys.com
europe.tailspintoys.com
sales.worldwideimporters.com
12
Administer Trust Relationships
• Validate a trust relationship

Active Directory Domains and Trusts

netdom trust TrustingDomainName
/domain:TrustedDomainName /verify
• Remove a manually created trust relationship

Active Directory Domains and Trusts

netdom trust TrustingDomainName
/domain:TrustedDomainName
/remove [/force] /UserD:User /PasswordD:*
•
UserD is a user in the Enterprise Admins or Domain Admins
group of the trusted domain
13
Domain Quarantine
• Filters out trusted user SIDs that come from a domain other
than the trusted domain
• If a user was migrated into the trusted domain

User account may have SIDs from user’s previous domain in the
sIDHistory attribute

Those SIDs are included in the user’s privilege attribute certificate
(PAC) that is part of the Kerberos ticket the user presents to the
trusted domain

These SIDs are discarded
• Enabled by default on all new outgoing trusts to external
domains/forests
• Disable if necessary
netdom trust TrustingDomainName /domain:TrustedDomainName
/quarantine:[Yes|No]
14
Resource Access for Users from Trusted Domains
• Giving trusted users access to resources

Authenticated Users

Add trusted identities to trusting domain’s domain local groups

Add trusted identities to ACLs
• Selective authentication

Reduces the risk of exposure--for
example, to Authenticated Users

You specify which trusted users are
allowed to authenticate
on a server-by-server (computer-bycomputer) basis

Enable selective authentication in the
properties of the trust

Give users Allowed To Authenticate
permission on the computer object in
Active Directory
15
Components of a PKI Solution
PKI Provides: Confidentiality, Integrity, Authenticity, and Non-repudiation
Is a standards approach to security-based tools, technologies , processes, and
services used to enhance the security of communications, applications and
business transactions
Relies on the exchange of digital certificates between authenticated users and
trusted resources
CA
Digital Certificates
Public Key–Enabled
Applications and
Services
Certificate Templates
Certificates and CA
Management Tools
CRLs and Online
Responders
AIA and CDPs
Validating Certificates by Using PKI Solutions
PKI-enabled applications use CryptoAPI to validate certificates.
Certificate Discovery
Path Validation
Revocation Checking
How AD CS Supports PKI
AD CS
CA
CA Web Enrollment
Online Responder
NDES
Overview of CA
CA
Issues a Certificate
for Itself
Verifies the Identity of
the Certificate Requestor
Issues Certificates to Users,
Computers, and Services
Manages Certificate
Revocation
Types of CAs
Root CA
• Is the most trusted type of CA in a PKI
• Is a self-signed certificate
• Issues certificates to other subordinate CAs
• Certificate issuance policy is typically more rigorous
than subordinate CAs
• Requires physical security policy
Subordinate CA
• Is issued by another CA
• Addresses specific usage policies,
organizational or geographical boundaries,
load balancing, and fault tolerance
• Issues certificates to other CAs to form a
hierarchical PKI
Stand-Alone Versus Enterprise CAs
Stand-Alone CAs
Enterprise CAs
Requires the use of AD DS
Stand-alone CA must be used if
any CA (root or intermediate /
policy) is offline, because a
stand-alone CA is not joined to
an AD DS domain
Users provide identifying
information and specify type of
certificate
Does not require certificate
templates
All certificate requests are kept
pending until administrator
approval
Can use Group Policy to
propagate certificate to
trusted root CA certificate
store
Publishes user certificates and
CRLs to AD DS
Issues certificates based upon
a certificate template
Supports autoenrollment for
issuing certificates
Usage Scenarios in a CA Hierarchy
Root
Root
Subordinate
Subordinate
S/MIME
EFS
RAS
India
Canada
Location
Certificate Use
Root
Root
Subordinate
Subordinate
Manufacturing
Engineering
Departments
USA
Accounting
Employee
Contractor
Partner
Organizational Unit
What Is a Cross-Certification Hierarchy?
Cross-Certification at the Root CA
Level
Root CA
Subordinate
CA
Organization 1
Root CA
Subordinate
CA
Organization 2
Cross-Certification Subordinate CA to Root
CA
Root CA
Subordinate
CA
Organization 1
Root CA
Subordinate
CA
Organization 2
Considerations for Installing a Root CA
Computer Name and
Domain Membership
Name and
Configuration
Certificate Database
and Log Location
Validity Period
Planning a Root CA
#
CSP
Default: 2048
Key Character Length
Certificate
Hash Algorithm
Private Key Configuration
Considerations for Installing a Subordinate CA
Computer Name and
Domain Membership
Name and
Configuration
Certificate Database
and Log Location
Validity Period
Planning a Root CA
#
CSP
Default: 2048
Certificate
Hash Algorithm
Key Character Length
Private Key Configuration
Request Certificate for Subordinate CA
How the CAPolicy.inf File Is Used for Installation
The CAPolicy.inf file is stored in the %Windir% folder of the root or
subordinate CA. This file defines the following:

Certification Practice Statement (CPS)

Object Identifier (OID)

CRL Publication Intervals

CA Renewal Settings

Key Size

Certificate Validity Period

CDP and AIA Paths
What Are CRLs?
Base CRLs
+
All Revoked
Certificates
Lesser Publication Interval
Large Size
Client Computer Using
Any Version of Windows
Delta CRLs
-
Last Base CRL
Certificate
Greater Publication Interval
Small Size
Client Computer Using
Windows® XP or
Windows Server® 2003
How CRLs Are Published
Delta CRL#3
Delta CRL#2
Cert5
Cert7
Cert5
Revoke
Cert5
Revoke
Cert7
Time
Cert3
Cert3
Cert5
Cert7
Base CRL#1
Base CRL#2
Where to Publish AIAs and CDPs
Publish the root certificate CA and URL to:
• Active Directory
• Web servers
• FTP servers
Offline
Root CA
• File servers
External Web Server
FTP Server
Active Directory
Internet
Firewall
Firewall
Internal Web Server
File Server