+ All Categories
Home > Documents > Active Directory 101 Manage and Maintain Active Directory ... · Active Directory Domains vs....

Active Directory 101 Manage and Maintain Active Directory ... · Active Directory Domains vs....

Date post: 12-May-2020
Category:
Upload: others
View: 83 times
Download: 6 times
Share this document with a friend
30
Sander Berkouwer CTO at SCCT 10-fold Microsoft MVP Active Directory aficionado Mason Takacs Solutions Engineer Netwrix Manage and Maintain Active Directory Domain Services Active Directory 101
Transcript

Sander BerkouwerCTO at SCCT10-fold Microsoft MVPActive Directory aficionado

Mason Takacs

Solutions EngineerNetwrix

Manage and Maintain Active Directory Domain Services

Active Directory 101

Agenda

• Active Directory Domains and Trusts

• Active Directory Sites and Replication

• Securing Active Directory

• How to determine which changes in your environment merit inspection with Netwrix

Auditor

AD Domains and Trusts

Active Directory Domains vs. Forests

• Active Directory Domains

– Administrative boundary

– Group Policy boundary*

– Passwords and Account policies

– Domain DNS Zone replication

• Create multiple Domains to:

– Satisfy replication and DNS requirements

– Allow for resource domains

• Active Directory Forests

– Security boundary

– Schema and Configuration partitions boundary

– Global Catalog replication

– Forest DNS Zone replication

• Create multiple Forests to:

– Satisfy security, schema and perimeter network

requirements

– Allow for mergers, acquisitions, etc.

Trusts

• Trusts allow for inter-domain and inter-forest authentication and authorization

– 5 Types: Parent-Child, Tree Root, External, Shortcut and Forest trusts

– 2 relationships: One-way and Two-way trusts (basically 2 one-way trusts…)

– 2 scopes: Transitive and non-transitive trusts

• Security considerations

– SID Filtering prevents privilege escalation, based on sIDHistory

– Selective authentication limits authentication to specified resources only

• A resource domain/forest trusts the account domain/forest

Domain and Forest Functional Levels

• New functionality might require an Active Directory functional level

– The Domain Functional Level (DFL) ensures all Domain Controllers run the version indicated by the DFL

and thus support the functionality

– The Forest Functional Level (FFL) ensures all Domains in the forest run the DFL indicated by the FFL and

thus support the functionality

• Typical functionality that required raising the DFL/FFL

– Read-only Domain Controllers require the Windows Server 2003 FFL

– The Active Directory Recycle Bin requires the Windows Server 2008 R2 FFL

Best Practices for Multi-Domain environments

• Take care of DNS

– Optimize DNS resolution using Conditional Forwarders or Stub zones

– Deploy a GlobalNames DNS zone to get rid of WINS dependencies

• Think about the userPrincipalNames

– userPrincipalNames change and might lead to loss of (access to) data in environments with AD FS and cloud

– Align userPrincipalNames with email addresses

Coming from a previous version of Active Directory

1. In-place upgrading Domain Controllers

2. Transitioning Domain Controllers

– Add new Windows Server 2016-based Domain Controllers

– Remove previously available Domain Controllers

3. Migrating Active Directory

– Use the Active Directory Migration Tool (ADMT) or 3rd party tooling

Migrate user objects, groups, computer objects and (g)MSAs

sIDHistory may be used to keep authorizations alive

– Migrate all objects and leave the old environment completely

AD Sites and Replication

Active Directory Partitions

1. Configuration

Contains the forest-wide information on the AD DS structure

2. Schema

Contains the forest-wide information on object classes and rules for creating and manipulating objects and attributes

3. Domain

Contains the object within the Active Directory domain

4. Application

The Directory Service Agent GUID1

The InvocationID2Update Sequence Number (USN),aka “Logical Clock”3

Components of Active Directory object replication

• Unique to a Domain Controller

• Persistent over the life of a Domain Controller

• Used in USNs to track Domain Controller’s originating updates

• Used by DSA to identify a Domain Controller’s instance of the AD database

• Can change over time (e.g. during a DC restore operation)

• Used by Domain Controllers to track updates sent and received

• Increases per write transaction, independently on each Domain Controllers

4 What about Timestamps?• Conflict Resolution: Check the Stamps, last write wins

• Stamp = Version + Originating Time + Originating DSA

How Active Directory intra-site replication works

Active Directory Site

DC1 DC2

Unique Serial Number

400Unique Serial Number

270

High Watermark Tabel

<InvocationID of DC2>

270

High Watermark Tabel

<InvocationID of DC1>

400

System Volume (SYSVOL) Replication

• The System Volume share

– contains logon scripts, Group Policy templates, and GPOs

• Two replication mechanisms for SYSVOL currently in the wild:

– File Replication Service (FRS)

Has been around since Windows NT 4

Primarily used in Windows Server 2003 and older domain structures

– Distributed File System Replication (DFS-R)

Used in Windows Server 2008 and newer domains

• Migrate SYSVOL replication from FRS to DFS Replication

– Raise the domain functional level to Windows Server 2008, and up

• Use dfsrmig.exe to perform the migration

Active Directory Sites

• Active Directory Sites identify network locations with fast, reliable network connections

– Sites are associated with subnet objects

• Sites are used to manage:

– Replication, when Domain Controllers are separated by slow links

– Service localization:

Domain controller authentication, based on SRV records

Site-aware services and applications

Like Distributed File System (DFS) and DNS A/AAA records

• Implement additional Active Directory Sites to:

– Overcome a slow or non-existing link in the network

– Provide reliable authentication to users by a Domain Controller in a branch office

– Control replication between Domain Controllers using sitelinks and sitelink costs

– Control Active Directory service localization through DNS SRV records

Components of inter-site replication

• Replication schedules and other options are available

– Only replicate during specific time frames

– Compress replication traffic

– Use SMTP instead of IP

• Change notifications

• PDC Chaining for password change integrity

• Inter-site Topology Generator (ISTG)

– Process, activated on one Domain Controller per site

Creates a view of the replication topology

Automatically manages site links

Automatically assigns a bridgehead server per site

– Leverages the intra-site Knowledge Consistency Checker (KCC)

Active Directory Site BActive Directory Site A

Active Directory Sitelink

Replication Schedule

How Active Directory inter-site replication works

DC1 DC2

Unique Serial Number

400Unique Serial Number

270

High Watermark Tabel

<InvocationID of DC2>

270

High Watermark Tabel

<InvocationID of DC1>

400DC3

High Watermark Tabel

<InvocationID of DC3>

100

Unique Serial Number

100

High Watermark Tabel

<InvocationID of DC2>

270

Bridgehead Server Bridgehead Server

Active Directory Sitelinks and Universal Group membership Caching

• Site links connect Active Directory sites in scope

– Best Practice: Let the ISTG manage the site links

– Going manually?

Only include two sites per site link

Do not disable site link bridging

• Universal Group membership Caching

– When no Global Catalog is available in a Site, the sitelink needs to be traversed to gain Universal group memberships

– Universal Group Membership Caching solves this authentication delay

May be enabled manually, per Site

Cached indefinitely, updated every 8 hours (by default)

May result in security concerns

Monitoring and managing replication

• Use repadmin.exe

• Use the Active Directory Replication Status Tool

• Use System Center Operations Manager (SCOM)

• Use Windows PowerShell

Securing Active Directory

Best Practices for Security with Active Directory

Secure Active Directory Domain Controllers

Disable legacy protocols like LM, NTLM and SMB1

Deploy strong authentication

Use (group) Managed Service Accounts

Deploy the Local Administrator Password Solution (LAPS)

Establish the right provisioning and deprovisioning processes

Audit critical object changes

Domain Controllers are prime targets for attacks

• Secure Domain Controllers physically

– For kitchen cupboards and storage room scenarios, use RODCs

• Deploy BitLocker Drive Encryption and/or Shielded VMs

• Treat Domain Controller backups as Domain Controllers

• Run the Security Configuration Wizard (SCW)

– Disable unnecessary services

– Block unwanted traffic

– Deploy to all Domain Controllers, based on the configuration of one

The skinny on Read-only Domain Controllers

• Requirements:

– One Domain Controller running Windows Server 2008, or up

– Windows Server 2003 Forest Functional Level

• Scoping:

– Password Replication Policies allows for control of password caching on the Read-only Domain Controller, can be configured domain-wide, or RODC-specific

– Filtered Attribute Set can be used to scope attributes

• Implement:

– Run adprep.exe /rodcprep

– Install using

Optionally: Add-ADDSReadOnlyDomainControllerAccount

Install-ADDSDomainController –ReadOnlyReplica

Deploying Domain Controllers in Azure IaaS

• Scenarios in which you might deploy AD DS on an Azure IaaS-based virtual machine:

– Disaster recovery

– Geo-distribution of Domain Controllers

– Isolate applications and services

• Considerations during deployment include:

– Allow for multiple networking paths to Azure (VPNs, ExpressRoute, etc.)

– Create separate Active Directory Sites

– Do not provide fixed IP addresses to Domain Controllers in Azure IaaS

– Apply proper DNS

Best Practices for Strong Authentication

Privileged accounts

– Implement smart cards or multi-factor authentication

– Place them in the Protected Users group

Prevents locally cached credentials, requires Kerberos, limits TGT

– Use Authentication Policies and Authentication Policy silos

Scope admin accounts to admin workstations and servers only

Use claims for rich authorization scenarios

Implement fine-grained password and account lockout policies

Implement Single Sign-on

Deploy Windows Hello for Business

Best Practices for Service Accounts

Organizations misuse domain-based user objects to run services

– Of course, they don’t change the passwords, “would break everything”

– No overview of where the user objects are used

– Usually no scoping

Use (group) Managed Service Accounts to run services, instead

– Automatic password management and SPN management

– Automatically scoped

– gMSAs require Windows Server 2012 Domain Controllers

Netwrix Auditorfor AD

Demonstration

Netwrix Auditor

Questions?

www. .com

Thank You!

Sander Berkouwer

10-time Microsoft MVPActive Directory aficionado

Mason Takacs

Solutions EngineerNetwrix


Recommended