1 Week 10 – Manage Multiple Domains and Forest Configure Domain and Forest Functional Levels Manage Multiple Domains and Trust Relationships Active Directory Certificate Services

2 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

3 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

4 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

5 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

6 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

7 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 Trusted Domain Trusting Domain AB

8 Characteristics of Trust Relationships Direction Transitivity Automatic or Manual Trusted domainTrusting domain Trusted domain Trusting domain AB C

9 How Trusts Work Within a Forest tailspintoys.com Tree Root Domain Forest Root Domain europe.tailspintoys.com asia.wingtiptoys.com wingtiptoys.com usa.wingtiptoys.com

10 Shortcut Trusts tailspintoys.com europe.tailspintoys.com asia.wingtiptoys.com wingtiptoys.com usa.wingtiptoys.com

11 External Trusts and Realm Trusts worldwideimporters.com sales.worldwideimporters.comeurope.tailspintoys.com tailspintoys.com asia.tailspintoys.com

12 Forest Trusts worldwideimporters.com sales.worldwideimporters.comeurope.tailspintoys.com tailspintoys.com asia.tailspintoys.com

13 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

14 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]

15 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-by- computer) basis  Enable selective authentication in the properties of the trust  Give users Allowed To Authenticate permission on the computer object in Active Directory

Components of a PKI Solution CA Digital Certificates CRLs and Online Responders Certificate Templates Public Key–Enabled Applications and Services Certificates and CA Management Tools AIA and CDPs 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 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

Validating Certificates by Using PKI Solutions PKI-enabled applications use CryptoAPI to validate certificates. Certificate Discovery Path ValidationRevocation Checking

How AD CS Supports PKI CA AD CS CA Web Enrollment Online Responder NDES

Overview of CA CA Issues a Certificate for Itself Verifies the Identity of the Certificate Requestor Manages Certificate Revocation Issues Certificates to Users, Computers, and Services

Types of CAs 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 Root 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 Subordinate CA

Stand-Alone Versus Enterprise CAs Stand-Alone CAsEnterprise CAs 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 Requires the use of AD DS Can use Group Policy to propagate certificate to trusted root CA certificate store Users provide identifying information and specify type of certificate Publishes user certificates and CRLs to AD DS Does not require certificate templates Issues certificates based upon a certificate template All certificate requests are kept pending until administrator approval Supports autoenrollment for issuing certificates

Usage Scenarios in a CA Hierarchy Root Subordinate RASEFSS/MIME IndiaCanadaUSA Root Subordinate Root Subordinate Root Subordinate ManufacturingEngineering Accounting Employee Contractor Partner Certificate Use Location Departments Organizational Unit

What Is a Cross-Certification Hierarchy? Root CA Organization 1 Organization 2 Subordinate CA Root CA Organization 1 Organization 2 Subordinate CA Cross-Certification at the Root CA Level Cross-Certification Subordinate CA to Root CA

Considerations for Installing a Root CA Computer Name and Domain Membership Name and Configuration Private Key Configuration Validity Period Certificate Database and Log Location CSP Default: 2048 Key Character Length Hash Algorithm Certificate # Planning a Root CA

Considerations for Installing a Subordinate CA Computer Name and Domain Membership Name and Configuration Private Key Configuration Validity Period Certificate Database and Log Location Request Certificate for Subordinate CA CSP Default: 2048 Key Character Length Hash Algorithm Certificate # Planning a Root 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? Delta CRLs Client Computer Using Windows ® XP or Windows Server ® 2003 Base CRLs All Revoked Certificates Greater Publication Interval Last Base CRL Certificate Lesser Publication Interval + - Large Size Small Size Client Computer Using Any Version of Windows

How CRLs Are Published Cert3 Base CRL#1 Revoke Cert5 Delta CRL#2 Cert5 Revoke Cert7 Cert5 Cert7 Delta CRL#3 Cert3 Cert5 Cert7 Time Base CRL#2

Where to Publish AIAs and CDPs Offline Root CA Publish the root certificate CA and URL to: Active Directory Web servers FTP servers File servers Internet Firewall External Web Server Active Directory FTP Server Internal Web Server File Server