Active Directory For Beginners

0.1 What is Active Directory?

🔍 Definition

Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. It stores information about objects on the network — such as users, groups, computers, printers, and applications — and makes this information easy for administrators and users to find and use.

AD authenticates and authorizes all users and computers in a Windows domain, enforcing security policies and allowing centralized management of resources. It is built on standard protocols including LDAP (Lightweight Directory Access Protocol), Kerberos for authentication, and DNS (Domain Name System) for service location.

🧠 Core Concepts

• Directory Service: A hierarchical database that stores objects and their attributes. Objects can be users (with fields like name, password, phone), computers, groups, or even policies.
• Authentication: Verifying the identity of a user or computer. AD primarily uses Kerberos (default) and can fall back to NTLM.
• Authorization: Determining what an authenticated user is allowed to do, based on group memberships and permissions.
• Policy Enforcement: Group Policy Objects (GPOs) allow administrators to define security settings, software installation, scripts, and desktop configurations across the domain.
• Centralized Management: Administrators can manage all objects from a single console (Active Directory Users and Computers) or via PowerShell.

📦 AD as a Database

The AD database is stored in a file called NTDS.DIT (NT Directory Services Directory Information Tree) on each domain controller. It uses the Extensible Storage Engine (ESE) (also known as Jet Blue) to provide high-performance, transactional data storage. The database is divided into partitions (also called naming contexts):

• Domain partition: Contains objects specific to a domain (users, groups, computers). Replicated to all DCs in that domain.
• Configuration partition: Stores forest-wide configuration information (site topology, service definitions). Replicated to all DCs in the forest.
• Schema partition: Defines all object classes and attributes that can be created in the forest. Replicated to all DCs.
• Application partitions: Optional partitions for application-specific data (e.g., DNS zones).

🌐 AD and DNS

Active Directory is tightly integrated with DNS. Domain controllers register SRV records in DNS so that clients can locate them. Without DNS, clients cannot find the domain, and many AD functions break.

0.2 Why Active Directory Exists

📉 The Pre-AD Era: Workgroups and NT Domains

Before Active Directory, small networks often used workgroups, where each computer maintained its own local user database. For larger environments, Microsoft introduced Windows NT domains (NT 3.1/3.5/4.0). In an NT domain, there was a single Primary Domain Controller (PDC) that held the master copy of the domain database, and one or more Backup Domain Controllers (BDCs) that held read-only copies. This model had several limitations:

• Single point of failure: If the PDC went down, changes could not be made (though authentication could still happen via BDCs).
• Flat structure: Domains could not be organized hierarchically; all users and computers were in one flat list.
• Replication was one-way: BDCs pulled changes from the PDC; there was no multi-master replication.
• Limited scalability: The domain database had a maximum size (around 40 MB) and number of objects (about 40,000).
• No delegation: Administrative permissions were all-or-nothing within a domain.

🚀 The Birth of Active Directory

Active Directory was introduced with Windows 2000 Server to overcome these limitations. It was designed from the ground up to be:

• Hierarchical and extensible: Domains can be organized in trees, and forests can contain multiple trees.
• Scalable: Supports millions of objects per domain and hundreds of domains per forest.
• Multi-master replication: Any domain controller can accept changes, which then replicate to others.
• Standards-based: Uses LDAP for directory access, Kerberos for authentication, and DNS for naming and location.
• Granular delegation: Administrators can delegate control over specific OUs or tasks.
• Integrated with Group Policy: Centralized configuration management.

🎯 Business Drivers

• Operational efficiency: IT staff can manage identities and policies from a central location, reducing manual work and errors.
• Security and compliance: Enforce strong authentication, password policies, and auditing across the organization.
• User experience: Single sign-on (SSO) means users log in once to access all permitted resources (file servers, printers, intranet, etc.).
• Cost reduction: Automating user provisioning and deprovisioning lowers administrative overhead and improves security (no orphaned accounts).

0.3 Evolution from Windows NT to AD DS

📜 Detailed Version History

🔧 Important Protocol Changes

• Kerberos adoption: Replaced NTLM as the default authentication protocol, providing mutual authentication and reduced risk of pass-the-hash attacks.
• DNS integration: AD requires DNS for domain controller location; dynamic DNS updates allow DCs to register SRV records automatically.
• LDAP over SSL (LDAPS): Introduced to encrypt directory queries, later replaced by LDAP over TLS (StartTLS).

0.4 AD Components Overview

Active Directory consists of both logical and physical components that work together to provide directory services.

🧩 Logical Components (The Design)

• Forest – The outermost container. A forest is a collection of one or more domains that share a common schema, configuration, and global catalog. Domains in a forest are linked by transitive trusts. The first domain created in a forest is called the forest root domain.
• Domain – A logical grouping of objects (users, groups, computers) that share a common directory database and security policies. Domains are identified by DNS names (e.g., corp.example.com). Each domain has its own security boundaries; administrators of one domain do not automatically have rights in another domain unless trusts exist.
• Organizational Unit (OU) – Containers used to organize objects within a domain. OUs can be nested to reflect business structure (e.g., by department, location, or function). They are used to:
  • Delegate administrative authority (e.g., helpdesk can reset passwords for the Sales OU).
  • Apply Group Policies (GPOs) to a subset of users or computers.
  • Hide objects from users (through security filtering).
• Objects – The actual entities stored in AD. Common object classes include:
  • User – represents a person or service account; attributes include logon name, password, phone, etc.
  • Group – a collection of users, computers, or other groups used for assigning permissions.
  • Computer – represents a workstation or server joined to the domain.
  • Printer – represents a shared printer in the directory.
  • Contact – an object with no security principal, used for email addresses.
  • Shared Folder – points to a network share.
• Schema – Defines all object classes and attributes that can exist in the forest. The schema is extensible; applications can add their own classes and attributes (e.g., Exchange Server extends the schema to add mailbox attributes). Schema updates are forest-wide and should be performed carefully.

🖥️ Physical Components (The Infrastructure)

• Domain Controller (DC) – A server that hosts a writable copy of the AD database for its domain. It authenticates users, processes LDAP queries, and replicates changes to other DCs. Each DC also holds a copy of the schema and configuration partitions for the forest.
• Global Catalog Server (GC) – A DC that additionally holds a partial read-only copy of all objects in the forest (only some attributes, like name and location). GCs enable forest-wide searches and are essential for logon in a multi-domain environment (they provide universal group membership information).
• Read-Only Domain Controller (RODC) – A DC that holds a read-only copy of the AD database. Introduced in Windows Server 2008, RODCs are intended for branch offices with lower physical security. They cache user credentials only on demand and can be managed by delegated non-administrative users.
• Sites & Subnets – Sites represent physical locations with good network connectivity (LAN speed). Subnets are IP ranges assigned to sites. AD uses site information to:
  • Direct clients to the nearest domain controller.
  • Optimize replication traffic between DCs (intra-site replication is frequent and uncompressed; inter-site replication can be scheduled and compressed).

0.5 AD Logical vs Physical Structure

Active Directory separates the logical representation of the organization from the physical network infrastructure. This separation allows administrators to design a directory that reflects business needs independently of network topology.

🧭 Logical Structure (Business View)

• Based on business hierarchy, geography, or administrative requirements.
• Examples: a company may have a single domain with OUs for each department (HR, Finance, IT) or separate domains for subsidiaries.
• Logical structure is defined by:
  • Forests and domains – security boundaries.
  • OUs – delegation and GPO boundaries.
  • Groups – access control.
• Changes to logical structure (creating a new OU, moving users) do not directly impact network traffic.

🌍 Physical Structure (Network View)

• Based on actual network links, locations, and connectivity speed.
• Defined by sites (collections of well-connected subnets) and site links (connections between sites).
• Physical structure influences:
  • Authentication: Clients find a DC in their own site first.
  • Replication: DCs within a site replicate frequently (pull model); between sites, replication can be scheduled and compressed to save bandwidth.

📊 Comparison Table

🔄 Interaction Between Logical and Physical

When a user logs on, their computer is in a specific subnet, which is associated with an AD site. The logon request goes to a DC in that site (or a nearby site). The DC authenticates the user using the domain database (logical). Group Policies linked to the user's OU (logical) are applied, and the computer may receive policy settings. Meanwhile, DCs in different sites replicate changes according to the site link schedule (physical).

0.6 Real-World Enterprise Use Cases

Active Directory is used in organizations of all sizes. Here are typical enterprise scenarios with expanded details:

🏢 Case Study 1: Centralized User Authentication

Scenario: A multinational corporation with 50,000 employees uses AD to manage identities. Employees log into their Windows workstations using their domain credentials. They access file servers, internal websites, and email (Exchange) with the same password. When an employee leaves, IT disables the account once, and access to all resources is immediately revoked.

Technical details: AD stores user objects with attributes like sAMAccountName, userPrincipalName, displayName, and hashed credentials. Authentication is handled via Kerberos: the client obtains a Ticket Granting Ticket (TGT) from the DC and then uses it to request service tickets for resources.

⚙️ Case Study 2: Group Policy Management

Scenario: A financial services firm needs to enforce strict security settings on all company workstations. They create a GPO linked to the domain that enforces password complexity (minimum length 12, complexity required), locks workstations after 15 minutes of inactivity, and disables USB storage devices. For IT staff, they create a separate GPO applied to the IT OU that allows PowerShell execution and local admin rights.

Technical details: GPOs are stored in two parts: Group Policy Template (GPT) in SYSVOL (scripts, policies) and Group Policy Container (GPC) in AD (version, path). When a computer starts, it downloads and applies GPOs in order: Local, Site, Domain, OU (with inheritance and blocking).

🔐 Case Study 3: Delegated Administration

Scenario: A university's IT department has a central team that manages the domain, but each faculty (e.g., Engineering, Arts) has its own support staff. The central team creates OUs for each faculty and delegates control: faculty support staff can reset passwords and manage group memberships only within their own OU. This prevents them from affecting other faculties or domain-wide settings.

Technical details: Delegation is achieved by modifying ACLs on OUs. The Delegation of Control Wizard assigns permissions like "Reset user passwords" or "Manage group membership" to specific security groups.

🌐 Case Study 4: Multi-Site Deployment

Scenario: A global retailer has headquarters in Chicago, distribution centers in Europe and Asia, and retail stores worldwide. They deploy domain controllers at each major site. They configure AD sites for each region (North America, Europe, Asia) with subnets assigned. Site links are created with appropriate costs (e.g., Chicago–Europe cost 100, Europe–Asia cost 200). Replication between sites is scheduled to occur during off-peak hours to conserve WAN bandwidth.

Technical details: The Knowledge Consistency Checker (KCC) automatically generates replication topology. Inter-site replication uses the Intersite Messaging Protocol (ISM) and can be compressed. Clients in a store in Paris are in the Europe site and authenticate to a local DC, not to Chicago.

☁️ Case Study 5: Hybrid Identity with Azure AD

Scenario: A medium-sized company uses Office 365 and wants users to have the same password for on-premises and cloud. They deploy Azure AD Connect to synchronize on-premises AD with Azure AD. Password hash synchronization (or pass-through authentication) allows users to sign into Office 365 with their corporate credentials. They also enable seamless SSO so that domain-joined computers automatically sign into Azure AD without prompting.

Technical details: Azure AD Connect uses the DirSync engine to replicate changes. It can also write back attributes (e.g., groups) from Azure AD to on-premises. Hybrid identity requires Azure AD Premium licenses for features like password writeback and device writeback.

📁 Case Study 6: Resource Access Control

Scenario: A law firm uses AD to control access to sensitive legal documents. They create security groups: "Legal_Attorneys", "Legal_Paralegals", "Finance_Team". NTFS permissions on shared folders are set to allow read/write only to the appropriate groups. When a new attorney joins, HR creates the user account in AD and adds it to the "Legal_Attorneys" group. The attorney immediately gains access to all resources.

Technical details: When a user accesses a file share, the server checks the user's access token (which includes group SIDs) against the ACL. Changes to group membership take effect after the user logs off and on again (or after Kerberos ticket renewal).

0.7 Active Directory Setup from Scratch (Windows Server)

Before performing Active Directory attacks or applying hardening techniques, it is essential to understand how an AD environment is built. This section provides a step-by-step guide to setting up Active Directory Domain Services (AD DS) using Windows Server.

This lab-based setup mirrors real enterprise environments and forms the foundation for learning AD misconfigurations, attacks, and defenses.

1.1 What is a Domain Controller (DC)?

🔍 Definition

A Domain Controller (DC) is a server that runs Active Directory Domain Services (AD DS). It stores a writable copy of the Active Directory database (NTDS.DIT) for its domain, authenticates users and computers, enforces security policies, and replicates directory changes with other DCs in the domain and forest.

🧠 Core Functions of a Domain Controller

• Authentication: Verifies user and computer logon credentials using Kerberos (default) or NTLM.
• Authorization: Provides access tokens that determine what resources a user can access.
• Directory storage: Hosts the AD database, which contains all objects (users, groups, computers) and their attributes.
• Replication: Synchronizes changes with other DCs to ensure consistency across the domain/forest.
• Group Policy processing: Stores and replicates Group Policy Objects (GPOs) and provides them to clients.
• DNS services: Often runs DNS to support AD location (SRV records) and name resolution.

🏛️ Domain Controller Architecture

A DC runs the following key components:

• NTDS.DIT: The database file storing directory data. It is divided into partitions (domain, configuration, schema).
• EDB.Log files: Transaction logs that ensure database integrity; changes are written first to logs, then to the database.
• SYSVOL: A shared folder that contains Group Policy templates and logon scripts, replicated among DCs (using FRS or DFS-R).
• LSASS (Local Security Authority Subsystem Service): Handles authentication and security policies.
• KDC (Key Distribution Center): Implements the Kerberos protocol, issuing tickets.

📊 Domain Controller Placement Considerations

In an enterprise, DCs should be placed strategically:

• At least two DCs per domain: Provides redundancy and fault tolerance.
• At each major site: Users authenticate locally to avoid WAN latency.
• Global Catalog servers: At least one per site for multi-domain forests.
• Secure physical location: DCs hold the keys to the kingdom; physical security is paramount.

1.2 Installing AD DS Role

📦 Prerequisites

Before installing AD DS, ensure the following:

• Windows Server edition: Standard, Datacenter, or Essentials (not Core? Core can be used, but GUI is optional).
• Static IP address: DCs must have a static IP to avoid DNS registration issues.
• DNS configuration: The server must point to itself (or another DC) for DNS if it will host DNS.
• NTFS volume: The database, logs, and SYSVOL must be on NTFS partitions.
• Administrator credentials: You need local admin rights on the server.
• Time synchronization: Accurate time is critical for Kerberos.
• Network connectivity: To other DCs (if adding to existing domain).

🛠️ Installation Steps (Server Manager GUI)

1. Open Server Manager → Add roles and features.
2. Select installation type: Role-based or feature-based installation.
3. Select the target server.
4. In the Server Roles list, check Active Directory Domain Services.
5. Add required features when prompted (e.g., .NET Framework, Group Policy Management tools).
6. Proceed through the wizard and click Install.

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

After installation, the server is not yet a domain controller – it's just a server with the AD DS binaries. You must promote it to a DC (next section).

1.3 Promoting Server to DC

🆙 What is Promotion?

Promotion is the process of configuring a server with the AD DS role to become a domain controller. During promotion, you either create a new domain (forest) or add the server to an existing domain as an additional DC.

🚀 Promotion Methods

• Server Manager (post-install): A notification flag appears; click "Promote this server to a domain controller".
• Active Directory Domain Services Configuration Wizard: Launched from Server Manager or via dcpromo.exe (older).
• PowerShell: Using Install-ADDSDomainController or Install-ADDSForest cmdlets.
• Unattended installation: Using answer files (for large deployments).

📝 Promotion Steps (GUI)

1. Deployment Configuration: Choose:
   • Add a domain controller to an existing domain: For additional DC.
   • Add a new domain to an existing forest: For a new child domain or tree.
   • Add a new forest: For the first DC in a new forest.
2. Domain Controller Options:
   • Select Domain Name System (DNS) server (usually checked).
   • Select Global Catalog (GC) (recommended for most DCs).
   • Set Directory Services Restore Mode (DSRM) password – this is a local administrator password for recovery mode.
3. DNS Options: If DNS is not delegated, you may see a warning – it's fine.
4. Additional Options: For existing domain, you can specify a source DC for replication.
5. Paths: Specify locations for database, log files, and SYSVOL (defaults under C:\Windows\NTDS and C:\Windows\SYSVOL).
6. Review Options: Verify settings and click Next.
7. Prerequisites Check: The wizard runs a series of tests (e.g., DNS resolution, connectivity). Fix any errors.
8. Install: Click Install. The server will reboot automatically.

⚙️ PowerShell Promotion Example

To add a DC to an existing domain:

Install-ADDSDomainController -DomainName "contoso.com"
-Credential (Get-Credential "CONTOSO\Administrator") -InstallDns:$true
-GlobalCatalog:$true -SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force)
-DatabasePath "C:\Windows\NTDS" -LogPath "C:\Windows\NTDS"
-SysvolPath "C:\Windows\SYSVOL"

1.4 Global Catalog Explained

🌐 Definition

The Global Catalog (GC) is a distributed data repository that contains a partial, read-only copy of all objects from every domain in the forest. It is stored on domain controllers that are designated as Global Catalog servers.

🔍 What is Stored in the GC?

• Every object in the forest, but only a subset of attributes (those most commonly used in searches, e.g., name, UPN, email, group memberships).
• Universal group memberships (essential for authentication across domains).
• The schema and configuration partitions are also present (but the GC refers to the partial replica of domain objects).

🎯 Purpose of the Global Catalog

• Forest-wide searches: Users can find objects (e.g., printers, users) across all domains.
• Authentication in multi-domain environments: When a user logs on, the GC provides universal group membership information, which is necessary to generate the user's access token.
• Exchange address book: Microsoft Exchange uses the GC to build the Global Address List (GAL).

📈 GC Placement Best Practices

• At least one GC per site: Especially in multi-domain forests, to avoid authentication referrals across WAN.
• Preferably all DCs as GCs: In small to medium forests (less than 100,000 objects), it's common to make every DC a GC. This simplifies design and ensures fast lookups.
• Consider replication load: GCs receive updates from all domains, so they have higher replication traffic. In very large forests, you may limit GCs to major sites.

⚙️ Enabling Global Catalog

During DC promotion, you can check the "Global Catalog" box. After promotion, you can change it in Active Directory Sites and Services:

1. Expand the site → Servers → select the DC.
2. Right-click NTDS Settings → Properties.
3. Check Global Catalog.

1.5 FSMO Roles (5 Master Roles)

🔑 What are FSMO Roles?

Active Directory uses a multi-master replication model, meaning any DC can accept changes. However, certain operations are too sensitive to be performed by multiple DCs simultaneously. For these, Flexible Single Master Operation (FSMO) roles designate a single DC as the authoritative master for that operation. There are five FSMO roles, divided into forest-wide and domain-wide roles.

🌲 Forest-Wide FSMO Roles

These roles exist once per forest.

• Schema Master: Controls all updates and modifications to the Active Directory schema. Schema changes (e.g., adding new attributes for Exchange) must be performed on the Schema Master. If this role is unavailable, you cannot extend the schema.
• Domain Naming Master: Manages the addition and removal of domains in the forest. It ensures that domain names are unique and that no duplicate names are created. It also handles cross-domain references.

🏛️ Domain-Wide FSMO Roles

These roles exist once per domain.

• Relative ID (RID) Master: Allocates sequences of relative IDs (RIDs) to each domain controller. When a new security principal (user, group, computer) is created, the DC assigns a SID comprising the domain SID and a RID. The RID Master ensures that RID pools do not overlap between DCs.
• PDC Emulator: Acts as a Windows NT 4.0 Primary Domain Controller for backward compatibility. It handles:
  • Password changes (urgent replication of password changes to the PDC Emulator).
  • Group Policy updates (default target for GPO edits).
  • Time synchronization (all domain members sync time with the PDC Emulator of the domain).
  • Domain-wide account lockout processing.
• Infrastructure Master: Updates cross-domain object references (e.g., when a user in one domain is added to a group in another domain). It compares its data with the Global Catalog and fixes stale references. The Infrastructure Master should not be on a Global Catalog server unless all DCs are GCs (in a single-domain forest, it's fine on a GC).

🔁 FSMO Role Placement Best Practices

• Schema Master and Domain Naming Master: Place on the same DC (typically the forest root domain controller) because they are forest-wide and changed infrequently.
• PDC Emulator: Place on a well-connected, high-performance DC; it handles the most real-time requests.
• RID Master: Can be on any DC, but ensure it's available to allocate RID pools.
• Infrastructure Master: In a multi-domain forest, place it on a DC that is not a Global Catalog (to avoid having up-to-date data already). In a single-domain forest, it can be on any DC.

🛠️ Transferring and Seizing FSMO Roles

If you need to move a role to another DC (e.g., for maintenance), you can transfer it gracefully. If the current role holder is permanently offline, you must seize the role (which is a more drastic operation).

Using GUI (Active Directory Users and Computers / Domains and Trusts / Schema snap-in):

• Right-click the domain or object → Operations Masters → select the appropriate tab → Change.

Using PowerShell:

        Move PDC Emulator role to DC2
Move-ADDirectoryServerOperationMasterRole -Identity "DC2" -OperationMasterRole PDCEmulator

Seize roles (if current holder is dead) – use -Force
Move-ADDirectoryServerOperationMasterRole -Identity "DC2" -OperationMasterRole SchemaMaster, DomainNamingMaster -Force

1.6 Read-Only Domain Controller (RODC)

🔍 Definition

A Read-Only Domain Controller (RODC) is a type of domain controller introduced in Windows Server 2008. It hosts a read-only copy of the Active Directory database for its domain. Unlike a writable DC, changes cannot be made directly on an RODC; they must be replicated from a writable DC.

🏢 When to Use an RODC

• Branch offices with poor physical security: RODCs can be placed in locations where the server could be stolen or compromised, without exposing writable credentials.
• Sites with limited IT staff: RODCs can be managed locally by non-administrative users (delegated administration).
• Locations with slow WAN links: Users can authenticate locally, but writes (password changes) are forwarded to a writable DC.

🔐 Security Features of RODC

• Credential caching: By default, RODCs do not store user passwords. They can be configured to cache passwords for specific users (e.g., branch office employees) for faster authentication, but administrative accounts are never cached.
• Read-only database: Even if an attacker gains physical access, they cannot modify AD data.
• Administrative role separation: A local user (e.g., branch office manager) can be granted rights to manage the RODC (like updating drivers) without any domain admin privileges.
• Replication filtering: You can filter which attributes replicate to the RODC (e.g., confidential attributes).

📉 Limitations of RODC

• Cannot perform schema updates, domain upgrades, or any write operations.
• Cannot be a Global Catalog? Actually, RODC can be a Global Catalog, but it will still be read-only.
• Cannot host FSMO roles (except possibly PDC emulator? No, all FSMO roles require writable DCs).
• Applications that require write access to AD (e.g., Exchange) cannot use RODC as a primary DC.

🛠️ Deploying an RODC

Prerequisites:

• Forest functional level must be at least Windows Server 2003.
• A writable DC must be available in the domain.
• You must pre-stage the RODC computer account (optional but recommended).

Promotion steps (similar to writable DC) but with an extra option:

1. Install AD DS role as usual.
2. During promotion, choose Add a domain controller to an existing domain.
3. In Domain Controller Options, check Read-only domain controller (RODC).
4. You can also specify a Delegated administrator account for the RODC (a local user who can manage the server).
5. Optionally, configure Password Replication Policy to specify which accounts can have their passwords cached on the RODC.

PowerShell example:

        Install-ADDSDomainController -DomainName "contoso.com"
-ReadOnlyReplica -SiteName "BranchOffice-Site"
-AllowPasswordReplicationAccountName "BRANCH\AllowedUsers" `
-Credential (Get-Credential "CONTOSO\Administrator")

🔑 Password Replication Policy (PRP)

The PRP controls which user and computer accounts can have their passwords cached on the RODC. It consists of two lists:

• Allowed list: Accounts whose passwords may be cached (e.g., branch office users).
• Denied list: Accounts that must never be cached (e.g., domain admins).

By default, no accounts are allowed. You must explicitly add users/groups to the allowed list. Administrative groups (Domain Admins, Enterprise Admins, etc.) are automatically in the denied list.

2.1 What is a Forest?

🔍 Definition

A forest is the topmost logical container in an Active Directory hierarchy. It is a collection of one or more domains that share a common schema, configuration partition, and global catalog. The forest defines the security boundary for Active Directory; all domains within a forest trust each other transitively by default, and administrative permissions do not cross the forest boundary unless explicitly established through trusts.

🧩 Components of a Forest

• Forest Root Domain: The first domain created in a forest. It holds the Schema and Configuration partitions and cannot be removed. All other domains are children or trees under this root (or joined via trusts).
• Schema Partition: Defines all object classes and attributes that can exist anywhere in the forest. Extending the schema (e.g., for Exchange) affects all domains.
• Configuration Partition: Stores forest-wide configuration data such as site topology, service definitions, and display specifiers.
• Global Catalog (GC): A partial replica of all objects in the forest, stored on designated domain controllers. It enables searches across domains and is essential for user logon in multi-domain environments (provides universal group membership).

🌲 Forest Functional Levels

Forest functional levels determine which advanced AD features are available across the entire forest. Raising the functional level requires all domain controllers to be running a minimum Windows Server version.

🌍 When to Use Multiple Forests

Although a single forest is sufficient for most organizations, multiple forests may be required for:

• Administrative isolation: Different business units that should not trust each other by default.
• Schema independence: Applications that require incompatible schema extensions.
• Mergers and acquisitions: Before consolidating directories.
• Test/development environments: Isolated forests for testing schema changes or upgrades.

🏢 Real-World Working Example – Creating a Production Active Directory Domain

🌐 Step 1: Domain Naming Strategy (Enterprise Best Practice)

• Public Website: abctech.com
• Internal Active Directory Domain: corp.abctech.com
• NetBIOS Name: CORP

🖥️ Step 2: Infrastructure & Server Planning

• Domain Controllers: Minimum 2 (High Availability)
• Primary DC: DC01 – 192.168.10.10
• Secondary DC: DC02 – 192.168.10.11
• Operating System: Windows Server 2016/2019/2022
• Forest Functional Level: Windows Server 2016
• DNS: AD-Integrated DNS

🏗️ Step 3: Active Directory Forest & Domain Design

• Forest Model: Single Forest (Recommended)
• Domain Model: Single Domain (corp.abctech.com)
• Site Topology: HeadOffice + BranchOffice
• Global Catalog: Enabled on both DCs

📁 Organizational Unit (OU) Structure – Enterprise Standard

• Users
• Computers
• Servers
• Domain Controllers
• Service Accounts
• Groups
• HR
• IT
• Finance

🔧 Step 4: Install Active Directory Domain Services (AD DS)

1. Configure static IP address
2. Rename server to DC01
3. Install Windows Updates
4. Open Server Manager → Add Roles and Features
5. Select Active Directory Domain Services
6. Install DNS Server role
7. Promote server → Add New Forest
8. Enter domain: corp.abctech.com
9. Set DSRM password
10. Complete installation and reboot

🔐 Step 5: Security Hardening & Administrative Model

• Create separate Domain Admin account
• Disable built-in Administrator (rename it)
• Implement Tiered Administration Model (Tier 0, 1, 2)
• Enable Advanced Audit Policies
• Disable SMBv1
• Enable LDAP Signing

📜 Step 6: Group Policy Configuration (Baseline Security)

• Password Policy (Complexity + 90 Days Expiry)
• Account Lockout Policy
• Windows Defender Policy
• Firewall Policy
• USB Restriction Policy
• Windows Update Policy

🌍 Step 7: DNS & Network Configuration

• Configure DNS Forwarders (ISP or 8.8.8.8)
• Verify SRV Records
• Check _msdcs zone replication

🔄 Step 8: Add Secondary Domain Controller (High Availability)

1. Install AD DS on DC02
2. Select "Add Domain Controller to Existing Domain"
3. Enable Global Catalog
4. Verify replication using repadmin /replsummary

💾 Step 9: Backup & Disaster Recovery Planning

• Install Windows Server Backup
• Schedule Daily System State Backup
• Test Restore Procedure in Lab
• Document DSRM password securely

📊 Step 10: Validation & Health Checks

• Run dcdiag
• Run repadmin /showrepl
• Verify Event Viewer logs
• Test Domain Join from Client Machine
• Test User Login Authentication

2.2 What is a Domain?

🔍 Definition

A domain is a logical grouping of network objects (users, groups, computers, printers) that share a common directory database and security policies. Domains are identified by a DNS name (e.g., corp.contoso.com) and serve as an administrative boundary.

🔒 Domain as a Security Boundary

Domain administrators have full control over objects within their domain, but not over objects in other domains (unless trusts exist). Key security aspects:

• Authentication boundary: Users authenticate to domain controllers in their own domain.
• Policy boundary: Group Policies can be linked at the domain level, affecting all objects in the domain.
• Administrative isolation: Domain Admins group grants full rights only within that domain.

🗂️ Domain Database (NTDS.DIT)

Each domain has its own copy of the domain partition stored in NTDS.DIT on every domain controller in that domain. This database contains all objects for that domain. The schema and configuration partitions are shared forest-wide.

📈 Domain Functional Levels

Domain functional levels enable features specific to that domain. Raising the level requires all DCs in the domain to run a minimum OS version.

🔗 Domain Naming and DNS

Every domain must have a valid DNS name. AD integrates with DNS in the following ways:

• Domain controllers register SRV records in DNS so clients can locate them.
• Clients use DNS to find a domain controller for their domain.
• DNS zones can be stored in AD (Active Directory-integrated zones) for secure, multi-master replication.

2.3 Organizational Units (OU)

🔍 Definition

An Organizational Unit (OU) is a container object within a domain used to organize other objects (users, groups, computers, and even other OUs). OUs provide a way to structure the directory hierarchically, mirroring business or operational divisions.

🎯 Purposes of OUs

• Delegation of administration: Grant non-administrative users control over objects within an OU (e.g., helpdesk resetting passwords for a specific department).
• Group Policy application: Link GPOs to OUs to apply settings to only the users/computers in that OU.
• Hiding objects: By setting permissions, you can hide OUs from certain users.
• Organizational clarity: Reflect the company structure (e.g., HR, IT, Sales) for easier management.

🧩 OU Hierarchy and Nesting

OUs can be nested to create a hierarchy. For example:

Company (domain)
├── HQ
│ ├── Users
│ │ ├── Executives
│ │ ├── IT
│ │ └── Sales
│ └── Computers
│ ├── Workstations
│ └── Servers
└── Branch Offices
├── NewYork
└── London
                             

GPOs applied at a higher level are inherited by child OUs (unless blocked). This allows for tiered policy application.

🏛️ Default OUs

When you create a new domain, several default containers and OUs are created:

• Domain Controllers OU: Contains all domain controller computer objects. Default GPOs are linked here.
• Users container: Legacy container for users (not an OU, cannot link GPOs). Best practice is to create custom OUs for users.
• Computers container: Legacy container for computers (not an OU). Domain-joined computers appear here until moved.
• Builtin container: Holds default local groups (e.g., Administrators, Users).

📐 Designing an OU Structure

Best practices for OU design:

• Keep it simple: Reflect the business, not every possible detail.
• Plan for delegation: Create OUs where administrative responsibility will be delegated.
• Plan for Group Policy: Structure OUs so that GPOs can be applied at the appropriate level (e.g., separate OUs for users and computers).
• Avoid deep nesting: Too many levels can complicate permission and policy troubleshooting.
• Use a pilot OU: For testing GPOs before wide deployment.

🛠️ How to Create and Delete Organizational Units (Step-by-Step Guide)

✅ Method 1: Create OU Using Active Directory Users and Computers (GUI)

1. Open Active Directory Users and Computers (ADUC)
2. Expand your domain (corp.abctech.com)
3. Right-click the domain → Select New → Organizational Unit
4. Enter OU Name (Example: IT, HR, Sales)
5. Check: Protect container from accidental deletion
6. Click OK

⚡ Method 2: Create OU Using PowerShell (Enterprise Method)

                             New-ADOrganizationalUnit -Name "IT" -Path "DC=corp,DC=abctech,DC=com"
                             

PowerShell method is recommended for automation and large enterprise deployments.

🏗️ Real-World OU Structure Example (Production)

corp.abctech.com
│
├── Tier-0
│   ├── Domain Controllers
│   └── Admin Accounts
│
├── Tier-1
│   ├── Servers
│   └── Service Accounts
│
├── Tier-2
│   ├── Users
│   ├── Workstations
│   ├── HR
│   ├── IT
│   └── Finance
                             

🔐 Delegating Control on an OU (Step-by-Step)

1. Right-click OU → Select Delegate Control
2. Add Helpdesk group
3. Select task (Reset Password, Create Users, etc.)
4. Complete wizard

Delegation allows least privilege access and improves security compliance.

📜 Linking Group Policy to an OU

1. Open Group Policy Management Console (GPMC)
2. Right-click OU → Link an Existing GPO
3. Select GPO (e.g., Password Policy, USB Restriction)
4. Confirm and test policy application

🗑️ How to Delete an Organizational Unit

Step 1: Remove Protection from Accidental Deletion

1. Right-click OU → Properties
2. Go to Object tab
3. Uncheck Protect object from accidental deletion

Step 2: Delete the OU

1. Right-click OU
2. Select Delete
3. Confirm deletion

PowerShell Deletion Method

                             Remove-ADOrganizationalUnit -Identity "OU=IT,DC=corp,DC=abctech,DC=com"
                             

📊 Best Practices for Enterprise OU Management

• Separate Users and Computers OUs
• Use Tiered Administrative Model
• Keep nesting levels minimal (3–4 levels max)
• Enable Active Directory Recycle Bin
• Document OU structure for audits
• Use naming standards (OU-HR, OU-IT, OU-Servers)

2.4 Tree vs Forest Trusts in Active Directory

🌲 What is a Domain Tree?

A Domain Tree is a collection of domains within the same Active Directory forest that share a contiguous DNS namespace. For example: contoso.com and asia.contoso.com.

• Automatically created parent-child trust
• Two-way trust by default
• Transitive across all domains in the tree
• Same forest security boundary

🌍 What is a Forest Trust?

A Forest Trust is a trust relationship between two separate Active Directory forests. It allows authentication and resource access between forests.

• Created manually by administrators
• Can be One-way or Two-way
• Transitive across all domains in both forests
• Used in mergers, acquisitions, partnerships

🔍 Types of Active Directory Trusts

• Parent-Child Trust – Automatic within forest
• Tree-Root Trust – Automatic between trees in same forest
• Forest Trust – Between separate forests
• External Trust – Between domain and external domain (non-transitive)
• Shortcut Trust – Improves authentication performance between distant domains

🔄 Trust Direction Explained

🔐 Authentication Types in Forest Trust

• Forest-Wide Authentication – All users authenticated automatically
• Selective Authentication – Admin must explicitly allow access per resource

📊 Comparison: Tree Trust vs Forest Trust

🛠️ How to Create a Forest Trust (Step-by-Step)

1. Open Active Directory Domains and Trusts
2. Right-click domain → Properties
3. Go to Trusts tab
4. Click New Trust
5. Enter DNS name of other forest
6. Select Forest Trust
7. Select trust direction (One-way or Two-way)
8. Choose authentication type
9. Complete the wizard

⚡ Create Forest Trust Using PowerShell

New-ADTrust -Name "xyzcorp.com" `
-SourceForest "abctech.com" `
-TargetForest "xyzcorp.com" `
-TrustType Forest `
-Direction Bidirectional
                             

🔍 Verify Trust Relationship

nltest /domain_trusts
Get-ADTrust -Filter *
                             

🏢 Real-World Enterprise Use Cases

• Mergers & Acquisitions
• Partner company collaboration
• Resource Forest Model
• Multi-national enterprise structure

🔐 Security Best Practices for Active Directory Trusts

• Use Selective Authentication when possible
• Monitor trust relationships regularly
• Limit Domain Admin access across forests
• Enable auditing for cross-forest logons
• Document trust agreements formally

2.5 Trust Relationships Explained (Active Directory Deep Guide)

🔗 What is a Trust in Active Directory?

A trust relationship is a logical authentication link between two domains or forests that allows users in one domain to access resources in another domain. Trusts enable cross-domain authentication using Kerberos and NTLM protocols.

🧩 Complete Types of Trusts in Active Directory

• Parent-Child Trust – Automatic, two-way, transitive (within same forest)
• Tree-Root Trust – Automatic between tree root domains
• Shortcut Trust – Manual trust to optimize authentication path
• External Trust – Between domains in separate forests (non-transitive)
• Forest Trust – Between two forest root domains (transitive)
• Realm Trust – Between Active Directory and non-Windows Kerberos realm

🔄 Trust Direction (Incoming vs Outgoing)

🔐 Transitive vs Non-Transitive Trust

• Transitive: Trust extends beyond immediate domains (A trusts B, B trusts C → A trusts C)
• Non-Transitive: Trust exists only between two domains directly

🛡 Authentication Scope Options

• Domain-wide / Forest-wide Authentication: All users automatically authenticated
• Selective Authentication: Explicit permission required for each server

🔐 How Kerberos Authentication Works Across Trusts

1. User logs into Domain A.
2. User requests access to resource in Domain B.
3. Domain A DC issues a referral TGT for Domain B.
4. User presents referral to Domain B DC.
5. Domain B issues service ticket.
6. User accesses resource.

This process uses Kerberos referral tickets and relies on the trust path.

🔎 SID Filtering (Security Protection)

SID filtering prevents malicious users from injecting fake SIDs from trusted domains. It is enabled by default for external trusts and recommended for forest trusts.

netdom trust domainA.com /domain:domainB.com /quarantine:yes
                             

🛠 How to Create a Trust (GUI Method)

1. Open Active Directory Domains and Trusts
2. Right-click domain → Properties
3. Select Trusts tab
4. Click New Trust
5. Enter DNS name of other domain/forest
6. Select trust type (Forest, External, etc.)
7. Choose trust direction
8. Select authentication scope
9. Complete wizard

⚡ Create Trust Using PowerShell

New-ADTrust -Name "partner.com" `
-SourceForest "abctech.com" `
-TargetForest "partner.com" `
-TrustType Forest `
-Direction Bidirectional
                             

🔍 Verify Trust Relationships

nltest /domain_trusts
Get-ADTrust -Filter *
netdom trust abctech.com /domain:partner.com /verify
                             

🚨 Trust Troubleshooting Commands

dcdiag
repadmin /replsummary
nltest /sc_query:domain.com
                             

🏢 Real-World Enterprise Use Cases

• Mergers & Acquisitions
• Resource Forest Model
• Partner Company Collaboration
• Hybrid On-Prem & Cloud Integration
• Multi-national corporate forests

🔐 Trust Security Best Practices

• Use one-way trusts when possible
• Enable SID filtering
• Limit Domain Admin access across forests
• Audit cross-domain authentication events
• Document trust relationships formally
• Regularly review and remove unused trusts

2.6 Designing AD Structure for Enterprises

🎯 Design Considerations

Designing an Active Directory structure is a critical task that must balance business requirements, security, scalability, and operational efficiency. Key factors to consider:

• Business structure: Departments, divisions, subsidiaries, geographical locations.
• Security requirements: Isolation needs (e.g., R&D must be separated from corporate network).
• Regulatory compliance: Data sovereignty, privacy laws (e.g., GDPR).
• Network constraints: WAN bandwidth, latency, and replication traffic.
• Administrative model: Centralized vs. decentralized IT management.
• Scalability: Expected growth in objects and domains.

🌲 Forest Design Decisions

• Single forest: Simplest, suitable for most organizations. All domains share schema and configuration. Provides full trust and collaboration. Security boundary is the forest.
• Multiple forests: Required for:
  • Legal or regulatory separation (e.g., subsidiaries that must operate independently).
  • Schema isolation (applications with conflicting schema extensions).
  • Test/development environments isolated from production.
  • Partner or extranet scenarios (limited trust).

📁 Domain Design Decisions

Within a forest, you need to decide how many domains to create. Options:

• Single domain model: All objects in one domain. Simplest to manage, all users and computers are under one administrative umbrella. Suitable for most small to medium organizations.
• Multiple domains model: May be needed for:
  • Decentralized administration: Each business unit manages its own domain.
  • Policy differences: Different password policies or account lockout settings (though fine-grained password policies in a single domain can address this).
  • Replication control: Large organizations with many objects may split domains to reduce replication traffic (less common now).
  • Legacy or political reasons: Mergers, acquisitions.

📂 OU Design Best Practices

• Keep the hierarchy simple: No more than 3–5 levels deep.
• Model after business functions, not individual users: Use OUs for departments, locations, or roles.
• Separate users and computers: Create top-level OUs for Users and Computers, then sub-OUs under each.
• Plan for GPO application: GPOs are processed in order: Local, Site, Domain, OU. Use OUs to scope policies.
• Delegate at the OU level: Assign administrative permissions to the appropriate OUs.
• Avoid moving objects frequently: GPO and permission inheritance changes can cause temporary access issues.

🏢 Real-World Example: Contoso Corporation

Contoso is a multinational company with headquarters in New York, a large R&D center in Munich, and sales offices in Tokyo and São Paulo. They have a single forest named contoso.com with one domain for simplicity. Within the domain, they create an OU structure:

        contoso.com (domain)
├── Users
│ ├── Executives
│ ├── IT
│ ├── Sales
│ ├── R&D
│ └── Finance
├── Computers
│ ├── Workstations
│ │ ├── NewYork
│ │ ├── Munich
│ │ ├── Tokyo
│ │ └── SaoPaulo
│ └── Servers
├── Groups
│ ├── Security
│ └── Distribution
└── Service Accounts
                         

They delegate password reset permissions for each location's helpdesk to the respective Workstations sub-OU. They apply GPOs at the domain level for basic security, at the location OUs for regional settings (e.g., time zone, language), and at department OUs for specific software deployments.

3.1 Creating & Managing Users in Active Directory

👤 What is a User Object in Active Directory?

A User Object in Active Directory represents a digital identity for a person, service, or application. It allows authentication, authorization, and access to network resources like files, email, printers, and applications.

📝 Step-by-Step: Create a User Account (GUI Method)

1. Open Active Directory Users and Computers (ADUC)
2. Navigate to the correct Organizational Unit (OU)
3. Right-click OU → New → User
4. Enter First Name, Last Name
5. Set User Logon Name (UPN) (e.g., john.smith@company.com)
6. Set password
7. Select options:
   • User must change password at next logon
   • Password never expires (avoid unless required)
   • Account disabled (if pre-staging)
8. Click Finish

⚡ Create User Using PowerShell (Enterprise Method)

New-ADUser -Name "John Smith" `
-GivenName John `
-Surname Smith `
-SamAccountName jsmith `
-UserPrincipalName jsmith@company.com `
-Path "OU=Sales,DC=company,DC=com" `
-AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) `
-Enabled $true `
-ChangePasswordAtLogon $true
                             

PowerShell is recommended for automation and bulk user provisioning.

📂 Bulk User Creation (CSV Method)

Import-Csv users.csv | ForEach-Object {
    New-ADUser -Name $_.Name `
    -GivenName $_.FirstName `
    -Surname $_.LastName `
    -SamAccountName $_.Username `
    -UserPrincipalName "$($_.Username)@company.com" `
    -Path "OU=Users,DC=company,DC=com" `
    -AccountPassword (ConvertTo-SecureString $_.Password -AsPlainText -Force) `
    -Enabled $true
}
                             

Used during:

• Company mergers
• New office setup
• HR onboarding automation

🔧 Managing User Accounts (Daily Admin Tasks)

• Reset Password: Right-click → Reset Password
  PowerShell: Set-ADAccountPassword -Identity jsmith -Reset
• Enable / Disable Account: Enable-ADAccount jsmith Disable-ADAccount jsmith
• Add to Group: Add-ADGroupMember -Identity "Sales_Group" -Members jsmith
• Move to another OU: Move-ADObject -Identity "CN=John Smith,OU=Sales,DC=company,DC=com" -TargetPath "OU=HR,DC=company,DC=com"

🔐 User Account Security Best Practices

• Follow Least Privilege Principle
• Use separate Admin account (no daily use)
• Enable Multi-Factor Authentication (if hybrid)
• Disable inactive accounts (90+ days)
• Never enable "Password Never Expires" unless required
• Monitor failed logon attempts

🔁 User Lifecycle Management (Joiner – Mover – Leaver Model)

• Joiner: Create account → Assign groups → Set permissions
• Mover: Update department → Change group membership → Move OU
• Leaver: Disable account → Remove from groups → Archive mailbox → Delete after retention period

📊 Advanced Monitoring & Reporting

• Find inactive users: Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00
• Find locked accounts: Search-ADAccount -LockedOut
• Audit logon activity via Event Viewer

🏢 Real-World Enterprise Example

ABC Technologies uses automated HR integration:

• HR adds employee → Account auto-created via script
• Department-based OU placement
• Group membership auto-assigned
• Access based on role (RBAC model)
• Termination triggers automatic disable process

3.2 Security vs Distribution Groups in Active Directory

🔑 What Are Active Directory Groups?

In Active Directory, groups are used to simplify management of users, permissions, and communication. Instead of assigning permissions to individual users, administrators assign permissions to groups — and users become members of those groups.

🛡️ Security Groups (Access Control Groups)

Security Groups are used to assign permissions to resources such as files, folders, printers, applications, and even Group Policies.

Key Features:

• Have a unique Security Identifier (SID)
• Can be used in Access Control Lists (ACLs)
• Can be nested (depending on scope)
• Appear in user access tokens during logon
• Can be mail-enabled (Exchange integration)

📧 Distribution Groups (Email Groups)

Distribution Groups are used only for email distribution. They do NOT have a SID and cannot be assigned permissions.

Key Features:

• Used only for email communication
• Cannot be used in ACLs
• Do not appear in access tokens
• Primarily used in Exchange environments

📊 Security vs Distribution Groups (Comparison Table)

🛠️ Step-by-Step: Create a Security or Distribution Group (GUI)

1. Open Active Directory Users and Computers (ADUC)
2. Navigate to correct OU
3. Right-click → New → Group
4. Enter group name (e.g., G_Sales)
5. Select:
   • Group Scope (Domain Local / Global / Universal)
   • Group Type (Security or Distribution)
6. Click OK

⚡ Create Group Using PowerShell

New-ADGroup -Name "G_Sales" `
-GroupScope Global `
-GroupCategory Security `
-Path "OU=Groups,DC=company,DC=com"

To create Distribution group:

New-ADGroup -Name "D_Sales" `
-GroupScope Global `
-GroupCategory Distribution `
-Path "OU=Groups,DC=company,DC=com"

🌍 Understanding Group Scope (Very Important)

• Domain Local: Used to assign permissions within same domain
• Global: Contains users from same domain
• Universal: Can contain users from multiple domains

🏢 Enterprise Best Practice: AGDLP Model

Microsoft recommends using the AGDLP model for permission management:

• A = Accounts (Users)
• G = Global Groups
• D = Domain Local Groups
• LP = Local Permissions

Example:

• Add Users → Global Group
• Add Global Group → Domain Local Group
• Assign Domain Local Group → Folder Permission

🔄 Converting Between Group Types

Set-ADGroup -Identity "MyGroup" -GroupCategory Distribution

⚠️ Be careful: converting a security group to distribution will remove its ability to hold permissions.

🔐 Security Best Practices

• Use naming convention (G_ for security, D_ for distribution)
• Avoid assigning permissions directly to users
• Review group membership regularly
• Limit nesting depth
• Audit privileged groups (Domain Admins, Enterprise Admins)

🏢 Real-World Corporate Example

ABC Technologies implements:

• G_Sales → Security group for shared drive access
• D_Sales → Distribution group for announcements
• Global groups nested into Domain Local groups
• Automated provisioning via PowerShell scripts

3.3 Group Scope in Active Directory (Global, Universal, Domain Local)

🌐 What is Group Scope?

In Active Directory, group scope defines:

• What objects the group can contain (membership rules)
• Where the group can be used (permission assignment location)
• How group membership replicates across the forest

🌍 Global Groups

Purpose: Used to organize users based on job roles within the same domain.

Can Contain:

• Users from same domain
• Computers from same domain
• Other Global groups (same domain)

Can Be Used In:

• Any domain in the forest
• Trusted forests

Replication:

• Stored in domain partition
• Replicates only inside its own domain

🏠 Domain Local Groups

Purpose: Assign permissions to resources located in the same domain.

Can Contain:

• Users from any domain
• Global groups from any domain
• Universal groups
• Domain local groups (same domain only)

Can Be Used In:

• Only in the domain where created

Replication:

• Replicates only inside its own domain

🌎 Universal Groups

Purpose: Used when membership spans multiple domains.

Can Contain:

• Users from any domain
• Global groups from any domain
• Other Universal groups

Can Be Used In:

• Any domain in the forest
• Trusted forests

Replication:

• Stored in Global Catalog
• Membership replicates forest-wide
• Frequent changes increase replication traffic

📊 Group Scope Comparison

🏢 Enterprise Best Practice: AGDLP Model

AGDLP = Accounts → Global → Domain Local → Permissions

• Add Users → Global group (G_Sales)
• Add Global group → Domain Local group (DL_Sales_RW)
• Assign DL group → Folder permission

🌍 Multi-Domain Enterprise Model: AGUDLP

AGUDLP = Accounts → Global → Universal → Domain Local → Permissions

• Users → Global group (per domain)
• Global groups → Universal group
• Universal group → Domain Local group (resource domain)
• Domain Local group → Permissions

🛠️ Create Groups Using PowerShell

# Global Group
New-ADGroup -Name "G_Sales" -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=company,DC=com"

# Domain Local Group
New-ADGroup -Name "DL_Sales_RW" -GroupScope DomainLocal -GroupCategory Security -Path "OU=Groups,DC=company,DC=com"

# Universal Group
New-ADGroup -Name "U_AllEmployees" -GroupScope Universal -GroupCategory Security -Path "OU=Groups,DC=company,DC=com"

🔄 Changing Group Scope (Important Rules)

• Global → Universal (Allowed if no nested global groups from other domains)
• Universal → Global (Only if no foreign members)
• Domain Local → Universal (Allowed under restrictions)

Set-ADGroup -Identity "G_Sales" -GroupScope Universal

🔐 Security & Performance Considerations

• Avoid deep nesting
• Limit Universal group changes
• Use naming conventions (G_, DL_, U_)
• Audit privileged group membership
• Follow AGDLP consistently

🎯 Real-World Example

ABC Technologies (Multi-domain forest):

• Domain1 → G_IT_Domain1
• Domain2 → G_IT_Domain2
• Both → U_IT_All
• U_IT_All → DL_ServerAccess
• DL_ServerAccess → File server permission

3.4 Computer Accounts in Active Directory

💻 What is a Computer Account?

A Computer Account in Active Directory represents a domain-joined device such as a workstation, laptop, server, or domain controller.

Just like user accounts, computer accounts are security principals. They have:

• A unique Security Identifier (SID)
• A password (machine password)
• An authentication relationship with domain controllers
• The ability to receive Group Policy

➕ How to Join a Computer to the Domain

Method 1 – GUI Method

1. Right-click This PC → Properties
2. Click Change settings
3. Select Change
4. Choose Domain
5. Enter domain name (e.g., contoso.com)
6. Provide domain credentials
7. Restart computer

Method 2 – PowerShell Method

Add-Computer -DomainName "contoso.com" `
-Credential CONTOSO\AdminUser `
-OUPath "OU=Workstations,OU=Computers,DC=contoso,DC=com" `
-Restart

🏗️ Pre-Staging Computer Accounts (Enterprise Best Practice)

Instead of letting users create computer objects automatically, administrators can pre-create (prestaged) computer accounts in the correct OU.

Benefits:

• Correct OU placement
• Proper Group Policy application
• Controlled delegation
• Improved security

🔑 Computer Account Password Management

Every domain-joined computer automatically changes its machine password every 30 days by default using the NetLogon service.

If the secure channel breaks (e.g., after restoring old image), fix it:

• PowerShell: Reset-ComputerMachinePassword -Server DC01
• NetDom: netdom resetpwd /s:DC01 /ud:domain\Admin /pd:*
• ADUC: Right-click computer → Reset Account

🗂️ Important Computer Account Attributes

• cn – Computer name
• sAMAccountName – Name with $ (WS-001$)
• dNSHostName – Fully qualified domain name
• operatingSystem – OS version
• pwdLastSet – Last machine password change
• lastLogonTimestamp – Last domain authentication
• userAccountControl – 4096 for workstations

🔄 Managing Computer Accounts with PowerShell

# List all computers
Get-ADComputer -Filter * -Properties OperatingSystem | Select Name, OperatingSystem

# Disable computer
Disable-ADAccount -Identity "WS-001$"

# Move to another OU
Move-ADObject -Identity "CN=WS-001,OU=Computers,DC=contoso,DC=com" `
-TargetPath "OU=Workstations,DC=contoso,DC=com"

# Find inactive computers (90 days)
Search-ADAccount -AccountInactive -ComputersOnly -TimeSpan 90.00:00:00

🔐 Computer Account Security Best Practices

• Restrict who can join computers to domain
• Use GPO to control local administrator group
• Enable LAPS (Local Administrator Password Solution)
• Monitor inactive computer accounts
• Disable unused machines before deletion
• Protect Domain Controllers OU

🖥️ Domain Controller Computer Accounts

Domain Controllers are special computer accounts:

• Located in Domain Controllers OU
• userAccountControl = 8192
• Member of Domain Controllers group
• Hold Active Directory database (NTDS.dit)

🏢 Real-World Enterprise Lifecycle

• Provisioning: Pre-stage account → Join to domain
• Management: Apply GPO → Patch → Monitor
• Decommission: Disable → Remove from domain → Delete after audit period

3.5 Password Policies & Account Lockout in Active Directory

🔐 What is a Domain Password Policy?

The Domain Password Policy defines password security rules for all users in an Active Directory domain. It is configured in the Default Domain Policy Group Policy Object (GPO).

⚙️ Where to Configure Password Policy

Open:

• Group Policy Management Console (GPMC)
• Edit Default Domain Policy
• Navigate to:
  Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy

📋 Important Password Policy Settings

• Enforce Password History: Prevent reuse of old passwords (Recommended: 24)
• Maximum Password Age: How long password is valid (Recommended: 60–90 days)
• Minimum Password Age: Prevent immediate reuse (Recommended: 1 day)
• Minimum Password Length: Recommended 12+ characters
• Password Complexity: Uppercase, lowercase, number, symbol
• Reversible Encryption: Keep Disabled (Security Risk)

🔒 Account Lockout Policy

Account lockout protects against brute-force password attacks.

• Lockout Threshold: Failed attempts before lock (Recommended: 5)
• Lockout Duration: 15–30 minutes
• Reset Lockout Counter After: 15–30 minutes

⛔ Unlocking Locked Accounts

• GUI: ADUC → Right-click User → Unlock Account
• PowerShell: Unlock-ADAccount -Identity jsmith

To identify lockout source:

Check PDC Emulator Event Viewer → Event ID 4740

🔁 Fine-Grained Password Policies (FGPP)

Introduced in Windows Server 2008, Fine-Grained Password Policies (FGPP) allow different password rules for different groups within the same domain.

Create FGPP Using PowerShell

New-ADFineGrainedPasswordPolicy -Name "AdminPolicy" `
-Precedence 100 `
-MinPasswordLength 15 `
-ComplexityEnabled $true `
-LockoutThreshold 3 `
-MaxPasswordAge "30.00:00:00"

Add-ADFineGrainedPasswordPolicySubject `
-Identity "AdminPolicy" `
-Subjects "CN=Domain Admins,CN=Users,DC=contoso,DC=com"

📊 View Effective Password Policy

Get-ADUserResultantPasswordPolicy -Identity jsmith

This shows which password policy actually applies to the user.

📈 Password Policy Precedence Rules

1. PSO applied directly to user
2. PSO applied via group (lowest precedence wins)
3. If none, Default Domain Policy applies

🔐 Enterprise Security Best Practices

• Use 12–16 character passwords minimum
• Encourage passphrases (e.g., MySecureCompany2024!)
• Enable Multi-Factor Authentication (MFA)
• Remove frequent forced password changes unless required
• Apply stricter policy to admin accounts
• Monitor account lockout spikes
• Enable Azure AD Password Protection (if hybrid)

🛡️ Common Security Risks

• Weak passwords
• Password spraying attacks
• Brute-force attacks
• Service accounts with expired passwords
• Shared admin credentials

🏢 Real-World Enterprise Example

• Standard Users: 12 characters, 60-day expiry
• Administrators: 15+ characters, 30-day expiry, MFA required
• Service Accounts: 25+ characters, managed via gMSA
• Lockout Threshold: 5 attempts

3.6 Delegation of Administrative Control in Active Directory

🎯 What is Delegation in Active Directory?

Delegation of Administrative Control allows you to grant limited administrative permissions to users or groups without giving them full Domain Admin rights.

Delegation follows the Principle of Least Privilege — users receive only the permissions necessary to perform their job.

🔧 How Delegation Works

Delegation is implemented using Access Control Lists (ACLs) on:

• Organizational Units (OUs)
• Containers
• Individual objects (Users, Groups, Computers)

Each permission grants specific rights such as:

• Create objects
• Delete objects
• Reset passwords
• Modify group membership
• Read attributes
• Write attributes

🛠️ Step-by-Step: Using the Delegation of Control Wizard

1. Open Active Directory Users and Computers (ADUC)
2. Right-click the target OU → Delegate Control
3. Add the security group (e.g., Helpdesk)
4. Select predefined tasks:
   • Reset user passwords
   • Create/delete user accounts
   • Manage groups
   • Read user information
5. Click Finish

🧩 Custom Delegation (Advanced)

Choose Create a custom task to delegate to assign very specific permissions. Example:

• Allow Helpdesk to only reset passwords
• Allow Team Lead to modify group membership only
• Allow Branch IT to manage computers only

⚡ Delegation Using PowerShell (Advanced Method)

$ou = "OU=Sales,DC=contoso,DC=com"
$user = "CONTOSO\Helpdesk"
$acl = Get-Acl "AD:$ou"

$identity = [System.Security.Principal.NTAccount]$user
$rights = [System.DirectoryServices.ActiveDirectoryRights]"ExtendedRight"
$type = [System.Security.AccessControl.AccessControlType]"Allow"
$inheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]"All"

$guid = [System.Guid]"00299570-246d-11d0-a768-00aa006e0529"  # Reset Password GUID

$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity, $rights, $type, $guid, $inheritance)
$acl.AddAccessRule($rule)
Set-Acl -Path "AD:$ou" -AclObject $acl

⚠️ Manual ACL modification is complex — use the wizard unless you understand AD schema GUIDs.

🏢 Common Delegation Scenarios (Enterprise Examples)

• Helpdesk: Reset passwords, unlock accounts
• HR Admin: Create and disable user accounts
• Application Team: Manage service accounts
• Branch Office IT: Join computers to domain
• Department Manager: Manage group membership

🔐 Delegation and Group Policy (GPO)

You can delegate control over Group Policy Objects (GPOs):

• Create GPOs
• Edit existing GPOs
• Link GPOs to OUs

Use Group Policy Management Console (GPMC) → Delegation tab.

🏗️ Tiered Administrative Model (Security Best Practice)

• Tier 0: Domain Controllers, Enterprise Admins
• Tier 1: Server Administrators
• Tier 2: Workstation & Helpdesk Admins

🔍 Auditing Delegated Activity

Enable auditing for Directory Service Changes:

• Event ID 5136 – Object modified
• Event ID 5137 – Object created
• Event ID 5141 – Object deleted
• Event ID 4723 – Password change
• Event ID 4724 – Password reset

Monitor logs on the PDC Emulator.

⚠️ Common Delegation Mistakes

• Granting Full Control unnecessarily
• Delegating at domain root instead of OU
• Using individual users instead of groups
• Not documenting delegated rights
• Ignoring periodic review of delegated permissions

📊 Delegation Best Practices

• Delegate at OU level only
• Use clearly named security groups (e.g., DL_Helpdesk_ResetPwd)
• Review permissions quarterly
• Use RBAC (Role-Based Access Control)
• Combine delegation with auditing

4.1 What is Group Policy?

🧩 Core Components of Group Policy (The Building Blocks)

Understanding Group Policy requires knowing its four fundamental components and how they work together:

📊 Local vs Domain Group Policy: Key Differences

⚙️ How GPOs Are Applied: The Step-by-Step Process

When a Windows computer starts or a user logs on, this is what happens behind the scenes:

📂 GPO Storage: Where Everything Lives

Active Directory (GPC) SYSVOL (GPT)
────────────────────────── ──────────────────────────
CN=Policies,CN=System,DC=domain \domain\SYSVOL\domain\Policies
├── {GPO-GUID-1} ├── {GPO-GUID-1}/
│ ├── cn={GPO-GUID-1} │ ├── GPT.INI (version info)
│ ├── displayName: "Default Domain Policy" │ ├── USER/
│ ├── versionNumber: 65537 (0x10001) │ │ └── Registry.pol
│ └── (other metadata) │ └── MACHINE/
└── {GPO-GUID-2} │ ├── Registry.pol
├── ... │ ├── Scripts/
│ └── Applications/
└── {GPO-GUID-2}/
└── ...
                             

Note: The version number must match between GPC and GPT for the GPO to be considered synchronized.

🛠️ Group Policy Management Tools: Which One to Use?

📁 ADMX Central Store: Why It Matters

\contoso.com\SYSVOL
└── contoso.com
└── Policies
└── PolicyDefinitions
├── en-US (language folder)
│ ├── inetres.adml
│ ├── System.adml
│ └── ...
├── inetres.admx
├── System.admx
└── ...
                                             

💻 Essential Group Policy Commands (Cheat Sheet)

🏢 Real-World Enterprise Example

❓ Common Group Policy Misconceptions (Cleared Up)

4.2 GPO Structure & Processing Order

🧩 LSDOU – The Processing Hierarchy

Group Policies are processed in a strict order, often remembered by the acronym LSDOU:

1. Local – Local computer policy (least priority).
2. Site – GPOs linked to the Active Directory site where the computer resides.
3. Domain – GPOs linked at the domain level.
4. OU – GPOs linked to the OU containing the computer or user, processed from parent OU down to child OU (deepest OU has highest priority).

For example, if a setting is defined in both a domain‑level GPO and an OU‑level GPO, the OU‑level setting wins (last writer wins). This order applies separately for computer and user configurations.

🔄 Inheritance, Blocking, and Enforcing

• Inheritance: By default, child OUs inherit GPOs linked to parent OUs.
• Block Inheritance: On a domain or OU, you can check “Block inheritance” to prevent GPOs from higher levels (site, domain, parent OUs) from applying to that container. However, enforced GPOs (see below) override block.
• Enforced (No Override): When you set a GPO link to “Enforced”, its settings cannot be overridden by any GPO lower in the hierarchy (including those that block inheritance). Enforced GPOs have the highest priority.

🔗 Linking GPOs

A GPO is not active until it is linked to a site, domain, or OU. One GPO can be linked to multiple containers. The order of processing for multiple GPOs linked to the same container is determined by the link order (lowest number processed last, thus highest priority). You can change link order in GPMC.

⚙️ Processing Details: Computer vs User Configuration

• Computer Configuration: Applied during system startup. It runs in the security context of the computer (SYSTEM).
• User Configuration: Applied during user logon. It runs in the context of the logged‑on user.

Both sections are independent; a GPO can contain settings for both computers and users. The actual application order for a given session is: computer policies first, then user policies (after logon).

⏱️ Refresh Interval and Background Processing

Group Policy is reapplied periodically in the background (every 90–120 minutes by default, with a random offset). This ensures that changes take effect even without a reboot or logoff. Security settings and some policies (like software installation) typically require a restart or logoff.

📊 GPO Versioning and Replication

Each GPO has a version number stored in both the GPC (AD) and GPT (SYSVOL). Clients compare these versions; if they differ, the client downloads the latest GPT. Domain controllers replicate both AD and SYSVOL, so GPO changes must replicate across all DCs before they are consistently applied. Use gpupdate /force to manually trigger a refresh.

4.3 Enforcing Password Policies in Active Directory

⚙️ Default Password Policy Settings (Where to Find Them)

Password policies are configured in the Default Domain Policy GPO (or any GPO linked to the domain) under:

Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy
                             

Here are the key settings with explanations and recommended values based on modern security guidelines:

🔒 Account Lockout Policy (Protecting Against Brute‑Force)

Located in the same GPO section (Account Policies → Account Lockout Policy), these settings determine how the domain responds to repeated failed logon attempts.

🔁 Fine‑Grained Password Policies (FGPP) – Multiple Policies in One Domain

The Default Domain Policy applies to all users in the domain. But what if you need stricter rules for administrators, or relaxed rules for service accounts? That's where Fine‑Grained Password Policies (FGPP) come in. Introduced in Windows Server 2008, FGPP allows you to create multiple password policies within a single domain and apply them to different groups of users.

🛠️ Step‑by‑Step: Create an FGPP Using Active Directory Administrative Center (ADAC)

1. Open Active Directory Administrative Center (from Server Manager or run dsac.exe).
2. Navigate to your domain → System → Password Settings Container.
3. In the right pane, click New → Password Settings.
4. Provide a name (e.g., "StrictAdminPolicy").
5. Set Precedence (e.g., 10 – lower number means higher priority).
6. Configure all password and lockout settings as desired.
7. In the Directly Applies To section, click Add and select the users or groups (e.g., "Domain Admins").
8. Click OK.

⚡ PowerShell Method (Faster for Automation)

    Create a new PSO
New-ADFineGrainedPasswordPolicy -Name "StrictAdmin" -Precedence 10
-MinPasswordLength 15 -ComplexityEnabled $true
-LockoutThreshold 3 -LockoutDuration "00:30:00"
-LockoutObservationWindow "00:30:00" -PasswordHistoryCount 24
-MaxPasswordAge "30.00:00:00"

Apply it to the Domain Admins group
Add-ADFineGrainedPasswordPolicySubject -Identity "StrictAdmin" `
-Subjects "CN=Domain Admins,CN=Users,DC=contoso,DC=com"

Verify
Get-ADFineGrainedPasswordPolicy -Filter * | Format-Table Name, Precedence, AppliesTo
                             

📊 Determining Which Password Policy Applies to a User

In a domain with FGPP, a user might be affected by multiple PSOs (via group membership). To see the effective policy:

                                 Get-ADUserResultantPasswordPolicy -Identity jsmith
                             

Or in ADAC, view the user and click "View resultant password settings".

🛡️ Modern Password Policy Best Practices (NIST & Microsoft Guidance)

Traditional password policies (frequent changes, complexity) often lead to user frustration and weaker passwords (e.g., "Summer2024!" then "Winter2024!"). Modern guidance from NIST (National Institute of Standards and Technology) and Microsoft recommends:

• Long passphrases over complex short passwords. Encourage sentences like "MyCatLikesFish2024!" – easier to remember, harder to crack.
• Remove mandatory periodic password changes for standard users unless there's evidence of compromise. Frequent changes often lead to weaker, predictable passwords.
• Implement Multi‑Factor Authentication (MFA) – this is the single most effective control against password‑based attacks.
• Ban common passwords (e.g., "Password123", "CompanyName2024") – use Azure AD Password Protection or custom banned password lists.
• Monitor for leaked credentials – use tools like Azure AD Identity Protection.
• Use FGPP to tailor policies for different user groups (admins, service accounts, etc.).

❌ Common Password Policy Mistakes (And How to Avoid Them)

🏢 Real-World Enterprise Example: Contoso Corporation

🔍 Troubleshooting Password Policy Issues

• User can't change password – "Password does not meet requirements": Check the effective policy (Get-ADUserResultantPasswordPolicy). The user might be subject to a stricter policy than expected.
• Account locked out frequently: Check event ID 4740 on PDC Emulator to see source. Could be a stale application with old credentials.
• FGPP not applying: Ensure the group is a global security group (universal also works) and that the user is a direct or nested member. Use Get-ADUserResultantPasswordPolicy to verify.
• Default Domain Policy not applying: Make sure the GPO is linked to the domain and not blocked/enforced incorrectly. Run gpresult /r on a client.

4.4 Software Deployment via GPO

📦 Overview

Group Policy can be used to deploy software packages (MSI, MSP, MSM, ZAP) to computers or users. This was a key feature for centralised software management, though modern environments often use SCCM or Intune. Still, GPO software deployment is useful in many scenarios.

📌 Assign vs Publish

• Assign: The software is installed automatically (advertised) and can be installed on demand. Assigned to computers: installation happens at next startup. Assigned to users: installation happens when the user logs on or clicks the advertised shortcut.
• Publish: The software is made available in “Add/Remove Programs” (Programs and Features) for users to install manually. Publishing is only for users, not computers.

🔧 Creating a Software Deployment GPO

1. Place the installer files (e.g., .msi) on a network share with appropriate permissions (Domain Computers have Read access).
2. Create or edit a GPO and navigate to Computer Configuration → Policies → Software Settings → Software installation (or User Configuration for user‑targeted).
3. Right‑click → New → Package. Browse to the network share path (UNC) of the .msi.
4. Select deployment method: Assigned or Published (if applicable).
5. Optionally configure advanced properties: transforms (.mst), upgrades, categories, etc.

Note: Always use UNC paths, not local paths. The client must have access to the share.

🔄 Software Upgrades and Removal

• Upgrades: In the software package properties, you can specify that this package upgrades an existing package (by name). You can also set mandatory upgrade vs optional.
• Removal: To uninstall, you can either:
  • Set the package to “Uninstall this application when it falls out of scope of management” – then if the GPO no longer applies (e.g., computer moved OU), the software is removed.
  • Explicitly set the package to “Remove” in the GPO.

📋 File Extensions and Application Association

When you publish an application, you can configure file extension associations. For example, if you publish Adobe Reader and associate .pdf files, when a user double‑clicks a .pdf, Windows Installer may prompt to install Adobe Reader.

🛠️ Troubleshooting Software Deployment

• Application not installing: Check that the client can access the UNC share (Domain Computers must have Read). Look in Event Viewer (Applications and Services Logs → Microsoft → Windows → Group Policy → Operational) for errors.
• Slow installation: Large packages over slow links – consider using Background Intelligent Transfer (BITS) or deploying via alternate methods.
• Multiple deployment GPOs: If two GPOs assign the same package, it may install twice. Use GPO precedence to avoid.

⚠️ Limitations and Modern Alternatives

• Only supports MSI and similar formats (ZAP files are for legacy non‑MSI, but limited).
• No bandwidth throttling, no scheduling (though you can use Group Policy to set install time via scripts).
• For complex deployments, consider Microsoft Configuration Manager (SCCM) or Intune.

4.5 Loopback Processing Mode

🔄 What is Loopback?

Loopback processing is a Group Policy feature that changes how user policies are applied when a user logs on to a specific computer. Normally, user policies are applied based on the user’s location in AD. With loopback, the computer’s location can also influence the user policies – effectively replacing or merging the user’s policies with those of the computer’s OU.

🎯 When to Use Loopback

• Terminal Servers / Remote Desktop Services: Users from anywhere (with their own user policies) log on to a shared server. You want to enforce server‑specific settings (e.g., remove access to local drives, lock down the desktop) regardless of the user’s normal OU.
• Kiosk computers: Public computers that need a locked‑down shell, even for users who normally have full desktops.
• Training rooms: Where students should get a restricted environment during class, but their regular desktop outside that room is unrestricted.

⚙️ How to Configure Loopback

Loopback is enabled by editing a GPO linked to the OU containing the computers (e.g., the Terminal Servers OU). Navigate to:

Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode.

Set it to Enabled, and choose one of two modes:

• Replace: The user’s normal GPOs (from their user object’s OU) are ignored. Only the computer’s GPOs (including those applied via the computer’s OU) determine user policy.
• Merge: The user’s normal GPOs are applied first, then the computer’s GPOs are applied. In case of conflict, the computer’s GPOs win (since they apply last).

🧪 Example: Terminal Server with Replace

Consider a terminal server in the OU “OU=TerminalServers”. A GPO linked to that OU has loopback enabled (Replace mode) and configures user settings: hide C: drive, disable control panel, set specific wallpaper. When a user (who normally gets their desktop from “OU=Sales” user policy) logs on to the terminal server, only the terminal server GPO’s user settings apply – their sales‑specific user policies are ignored. The result is a consistent, locked‑down session.

🧩 Merge Mode Example

If you want to retain some of the user’s settings but still enforce certain computer‑level overrides, use Merge. For instance, the user’s normal desktop background might be allowed, but the terminal server GPO enforces a screensaver timeout. Merge applies user policy first, then the computer’s user policy, so the screensaver timeout overrides.

🔁 Loopback and Processing Order

The processing order when loopback is enabled:

1. Computer policy is applied (as usual).
2. If loopback is enabled, the user policy application is modified:
   • Replace: The user’s normal GPOs are ignored; only the computer’s GPOs (linked to the computer’s OU) are used for user policy.
   • Merge: The user’s normal GPOs are applied, then the computer’s GPOs are applied, with computer’s GPOs taking precedence on conflicts.

⚠️ Important Considerations

• Loopback can cause unexpected results if not well documented. Users might wonder why their usual settings are missing.
• Be careful with security settings – a user could potentially escape restrictions if loopback is misconfigured.
• Loopback only affects user policy; computer policy is always applied normally.

4.6 Troubleshooting GPO Issues

🔍 Common GPO Problems (With Real-World Examples)

GPO issues generally fall into four categories. Here's how to recognize each:

🛠️ Essential Troubleshooting Tools (Your Diagnostic Kit)

Every administrator should be proficient with these tools. Think of them as your medical instruments for diagnosing GPO health.

Applications and Services Logs → Microsoft → Windows → Group Policy → Operational

Get GPO report
Get-GPOReport -Name "Default Domain Policy" -ReportType HTML -Path C:\report.html

Get GPO permissions
Get-GPPermission -Name "Default Domain Policy" -All

Force remote update
Invoke-GPUpdate -Computer WS001 -Force

Test WMI filter
Get-WmiObject -Query "Select * from Win32_OperatingSystem WHERE Version like '10.%'"
                                             

repadmin /replsummary # Check overall replication health
repadmin /showrepl # Detailed replication status
repadmin /syncall /AdeP # Force replication
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"" /srv:DC01
                                             

🔎 Step‑by‑Step Troubleshooting Flow (Follow This Order)

When a GPO isn't working as expected, follow this systematic process to identify the root cause. It's like a diagnostic flowchart:

🧪 Common GPO Errors and Their Fixes (With Event IDs)

💻 Advanced Troubleshooting with PowerShell (Real Scripts)

Here are some ready‑to‑use PowerShell snippets for common GPO troubleshooting tasks:

1. Get all GPOs linked to a specific OU
Get-ADOrganizationalUnit -Filter 'Name -eq "Sales"' | ForEach-Object {
$ouDN = $_.DistinguishedName
Get-GPInheritance -Target $ouDN | Select-Object -ExpandProperty GpoLinks
}

2. Find which GPOs apply to a specific user (simulate)
Get-GPResultantSetOfPolicy -User "CONTOSO\jsmith" -ReportType Html -Path C:\jsmith.html

3. Check if a specific GPO is being filtered out by WMI
$gpo = Get-GPO -Name "MyGPO"
$wmiFilter = $gpo.WmiFilter
if ($wmiFilter) {
Write-Host "WMI Filter: $($wmiFilter.Name) - Query: $($wmiFilter.Query)"
}

4. List all GPOs with their versions and check for mismatches
Get-GPO -All | Select DisplayName, ID, @{n="DomainVer";e={$.DomainVersion}}, @{n="SysVolVer";e={$.SysvolVersion}} |
Where-Object { $.DomainVer -ne $.SysVolVer }

5. Force Group Policy update on multiple remote computers
$computers = Get-ADComputer -Filter {Name -like "WS*"} | Select -Expand Name
Invoke-Command -ComputerName $computers -ScriptBlock { gpupdate /force /target:computer }

6. Get GPO permissions and export to CSV
Get-GPO -All | ForEach-Object {
$gpo = $_.DisplayName
Get-GPPermission -Name $gpo -All | Select @{n="GPO";e={$gpo}}, Trustee, Permission
} | Export-Csv GPO_Permissions.csv -NoTypeInformation
                             

📝 Best Practices to Prevent GPO Issues (Proactive Approach)

• Maintain a clear naming convention: e.g., "GPO_OU_Description" – so you know at a glance what a GPO does.
• Document every GPO: Use the "Comment" field in GPMC to describe purpose, linked locations, and last modified by.
• Use the Central Store for ADMX files: Ensures all admins see the same settings.
• Limit the number of GPOs per user/computer: Aim for fewer than 10; each GPO adds processing time.
• Test in a pilot OU first: Create a "Test" OU with representative users/computers, link new GPOs there, and verify before rolling out to production.
• Regularly review and clean up: Remove unused GPOs and unlinked GPOs. Use GPMC's "Starter GPOs" for templates.
• Back up GPOs frequently: Right‑click the Group Policy Objects container → Back Up All. Store backups securely.
• Monitor replication: Use tools like repadmin and dfsrdiag to ensure both AD and SYSVOL are healthy.
• Enable logging on problematic clients: Temporarily set verbose logging via reg key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics\GPSvcDebugLevel to 0x30002 (hex).

🏢 Real-World Troubleshooting Scenario: The Case of the Missing Drive Mapping

📋 Quick Troubleshooting Checklist (Print and Keep)

• ✅ Is the GPO linked to the right container?
• ✅ Is the link enabled? Is the GPO itself enabled?
• ✅ Does the security filter include the user/computer? (And do they have Apply permission?)
• ✅ If a WMI filter exists, does the client match the query?
• ✅ Is inheritance blocked on the target OU? If so, is the GPO enforced?
• ✅ On the client: run gpresult /r – is the GPO listed? Any denied GPOs?
• ✅ Check Event Viewer for GPO errors (Event IDs 1030, 1055, etc.).
• ✅ Verify client can reach a DC and DNS resolution works.
• ✅ Check GPO version across DCs – any mismatch?
• ✅ Test with a different user/computer in same OU to isolate.

5.1 Why DNS is Critical for Active Directory

🌐 The Role of DNS in AD

Active Directory Domain Services (AD DS) is completely dependent on DNS. Without properly functioning DNS, clients cannot locate domain controllers, domain controllers cannot replicate with each other, and many essential services fail. AD uses DNS as its locator service, replacing the NetBIOS-based browsing of older Windows NT domains.

🔍 How Clients Use DNS to Find Domain Controllers

When a domain‑joined computer starts up or a user logs on, the client must locate a domain controller for authentication. The process follows these steps:

1. The client queries its configured DNS server for SRV records in the domain. Specifically, it looks for _ldap._tcp.dc._msdcs. (e.g., _ldap._tcp.dc._msdcs.contoso.com).
2. DNS returns a list of domain controllers (by hostname) that provide LDAP services for that domain.
3. The client then performs an A/AAAA lookup for each hostname to obtain an IP address.
4. The client contacts one of the returned domain controllers to begin authentication.

This process is defined in RFC 2782 (DNS SRV) and is essential for AD to function. If DNS is misconfigured, clients will fail to find a DC, resulting in logon delays, inability to apply Group Policy, and overall network issues.

📌 DNS Zones and Active Directory Integration

DNS zones can be stored in two ways:

• Standard primary/secondary zones: Text files stored on DNS servers; replication is not integrated with AD.
• Active Directory‑integrated zones: The zone data is stored in the Active Directory database (in the Domain or Forest DNS application partition). This provides several benefits:
  • Multi‑master replication: Any domain controller that is also a DNS server can accept updates.
  • Secure dynamic updates: Only authenticated computers can update their records.
  • Automatic replication: Zone data replicates along with AD, simplifying management.
  • No single point of failure: If one DNS server fails, others continue to serve the zone.

For maximum reliability, it is strongly recommended to configure DNS zones as Active Directory‑integrated on all domain controllers that run the DNS Server role.

🔧 DNS Requirements for AD DS

Before promoting a server to a domain controller, you must ensure DNS is properly configured. Key requirements:

• DNS name resolution: The server must be able to resolve the domain name and locate other domain controllers.
• SRV record support: The DNS server must support SRV records (most modern DNS servers do).
• Dynamic updates: For clients to register their own records, the zone should allow dynamic updates (preferably secure).
• Delegation: If you are creating a child domain, the parent DNS zone must have delegation records pointing to the child’s DNS servers.

🛠️ Common DNS Issues in AD

• Missing SRV records: Domain controllers register SRV records automatically, but if dynamic updates are disabled or the records are deleted, clients cannot find DCs. Rebuild them by restarting the NetLogon service on the DC or using nltest /dsregdns.
• Stale records: Old records for decommissioned DCs can cause clients to attempt connections to non‑existent servers. Regularly scavenge DNS.
• Incorrect DNS server settings on clients: Clients must point to internal DNS servers that can resolve AD domains, not external DNS like 8.8.8.8.
• Replication lag: If a new DC is added but its DNS records haven’t replicated to all DNS servers, some clients may not see it.

5.2 SRV Records Explained

📋 What Are SRV Records?

Service (SRV) records are DNS resource records that specify the location of services. In Active Directory, SRV records tell clients which servers provide specific services for a domain, such as LDAP, Kerberos, and Global Catalog. They follow the format:

_service._protocol.domain TTL class SRV priority weight port target

For example:

_ldap._tcp.dc._msdcs.contoso.com 600 IN SRV 0 100 389 dc1.contoso.com

🧩 Important SRV Records in AD

Domain controllers register several SRV records automatically. The most important are:

🔍 How SRV Records Are Registered

When a domain controller starts, the NetLogon service registers its SRV records via dynamic DNS. The records are stored in the DNS zone(s) corresponding to the domain and forest. The registration includes:

• Priority and weight: Used for load balancing. Lower priority is preferred; among same priority, higher weight is chosen more often.
• Port: Typically 389 for LDAP, 88 for Kerberos, 3268 for Global Catalog.
• Target: The FQDN of the domain controller.

If a domain controller is also a Global Catalog server, it registers records in the gc._msdcs subdomain. For site awareness, it registers records in ._sites subdomains based on its subnet membership.

🛠️ Verifying and Troubleshooting SRV Records

Use the following tools to check SRV records:

• nslookup: Set type=SRV and query _ldap._tcp.dc._msdcs.contoso.com.
• dnscmd: dnscmd /enumrecords _msdcs.
• netdiag (older) or dcdiag /test:dns: Comprehensive DNS tests.
• PowerShell: Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.contoso.com" -Type SRV.

If SRV records are missing, try:

• Restarting the NetLogon service on the DC (reregisters all SRV records).
• Running nltest /dsregdns to force registration.
• Checking that the DNS zone allows dynamic updates and that the DC has permissions.
• Manually adding records (temporary fix; better to fix dynamic registration).

📁 SRV Records and Site Awareness

Clients can request domain controllers in a specific site by querying _ldap._tcp.._sites.dc._msdcs.. For this to work, the DC must be associated with a site via its subnet, and it must have registered the site‑specific SRV record. This is how clients ensure they contact a local DC, reducing authentication latency.

5.3 Multi‑Site AD Replication

🌍 What is Multi‑Site Replication?

In a multi‑site Active Directory environment, domain controllers are located in different physical locations (sites). Replication between sites must be managed carefully to optimise network bandwidth and ensure data consistency. AD uses a site topology to control replication flow.

🏢 Sites and Subnets

• Sites: Represent physical locations with good network connectivity (typically LAN speed). Sites are defined in Active Directory Sites and Services.
• Subnets: IP address ranges assigned to a site. When a client or DC’s IP falls within a subnet, it is associated with that site.

The primary purpose of sites is to:

• Direct clients to the nearest domain controller (site awareness).
• Optimise replication traffic between domain controllers.

🔄 Intra‑Site vs Inter‑Site Replication

• Intra‑site replication (within a site): Occurs frequently (every 15 seconds by default) and uses a notify‑push model. When a change occurs on a DC, it notifies its partners, and they pull the changes. Replication is not compressed.
• Inter‑site replication (between sites): Occurs according to a schedule (default every 180 minutes) and uses a pull model. Data can be compressed to save bandwidth (compressible by default). The schedule can be configured to occur during off‑peak hours.

🔗 Site Links and Costs

Site links connect two or more sites and define the replication path. Key properties:

• Cost: An arbitrary value (default 100) used to determine the preferred path. Lower cost is preferred.
• Replication interval: How often replication occurs (minimum 15 minutes, default 180).
• Schedule: When replication is allowed (e.g., only during business hours).
• Transport: IP (RPC over IP) or SMTP (rarely used). IP is the standard.

The Knowledge Consistency Checker (KCC) uses site link costs to build a least‑cost spanning tree for replication between sites. If multiple links exist, the KCC chooses the lowest cumulative cost path.

🧩 Bridgehead Servers

Inter‑site replication is performed by bridgehead servers – one per site, per directory partition, per transport. The KCC automatically selects a preferred bridgehead (or you can designate a preferred one). The bridgehead is responsible for sending and receiving replication data from other sites, reducing the replication burden on all DCs in the site.

If the bridgehead fails, the KCC will automatically promote another DC to act as bridgehead (unless you’ve configured manual preferences).

📦 Replication Protocols

• RPC over IP: Default for both intra‑site and inter‑site. Uses remote procedure calls. For inter‑site, it can be compressed.
• SMTP: Deprecated and rarely used; requires a certification authority and only replicates the configuration, schema, and application partitions (not domain partition).

⏱️ Replication Latency and Urgent Replication

In a multi‑site environment, changes may take time to replicate (site link interval). However, certain changes are considered urgent and replicate immediately (within 15 seconds) even across sites:

• Account lockouts.
• Password changes (when a user changes their password, the change is sent immediately to the PDC emulator; other DCs get it via normal replication).
• Changes to the LSA‑Secret (trusted domain objects).
• RID pool updates.

Urgent replication helps prevent security issues (like a user being locked out but still able to authenticate due to replication delay).

5.4 Replication Topology

🔁 The Knowledge Consistency Checker (KCC)

The Knowledge Consistency Checker (KCC) is a built‑in process that runs on every domain controller. Its job is to automatically generate and maintain the replication topology – both within a site and between sites. The KCC ensures that every directory partition is replicated to all DCs that need it, using a minimum number of connections while maintaining fault tolerance.

🧩 Intra‑Site Topology

Within a site, the KCC creates a ring topology where each DC has at least two inbound connections (for redundancy). The default intra‑site topology ensures that if one DC fails, replication can still flow through another path. The KCC reevaluates the topology every 15 minutes (configurable) and adjusts if DCs are added or removed.

The intra‑site replication connections are two‑way and use a notify‑push mechanism: when a DC has changes, it notifies its replication partners, who then pull the changes.

🌍 Inter‑Site Topology

For inter‑site replication, the KCC on the bridgehead servers in each site communicate to build a spanning tree based on site link costs. One KCC (in one site) is designated as the Inter‑Site Topology Generator (ISTG) for each site. The ISTG is responsible for calculating the inter‑site topology and telling other bridgeheads about it.

• ISTG: By default, the first DC in a site becomes the ISTG. If it fails, another takes over.
• The ISTG ensures that there is a replication path between every site that hosts a given directory partition.

🔌 Connection Objects

The KCC creates connection objects in the Active Directory configuration partition (CN=NTDS Settings,CN=,CN=Servers,CN=,CN=Sites,CN=Configuration,...). These objects define from which source a DC should replicate. Administrators can manually create connection objects, but it’s rarely necessary; the KCC’s automatic connections are sufficient. If you manually create connections, they may be overwritten unless you set a specific flag.

🔍 Replication Topology Example

Consider a forest with two sites (SiteA and SiteB), each with two DCs. The KCC in SiteA builds an intra‑site ring between its two DCs. Similarly in SiteB. The ISTG (say in SiteA) creates a site link between SiteA and SiteB. It then creates connection objects on the bridgehead in SiteA to replicate from the bridgehead in SiteB, and vice versa. The bridgeheads then replicate changes to their intra‑site partners.

SiteA:
  DC1  ←→  DC2  (intra‑site connections)
  DC1 (bridgehead)  ←→  DC3 (bridgehead in SiteB)  (inter‑site connection)
SiteB:
  DC3  ←→  DC4  (intra‑site connections)
                             

🛠️ Viewing and Modifying Topology

• Active Directory Sites and Services: Expand a site, then servers, then NTDS Settings to see inbound connection objects.
• repadmin /showconn: Displays all connection objects for a DC.
• repadmin /kcc: Forces the KCC to recalculate the topology immediately.
• PowerShell: Get-ADReplicationConnection -Filter *.

5.5 Monitoring Replication Health

🔍 Why Monitor Replication?

Replication is the heartbeat of Active Directory. If replication fails, domain controllers become inconsistent, leading to authentication failures, policy conflicts, and potential data loss. Regular monitoring ensures that all DCs are synchronised and that the topology is functioning correctly.

🛠️ Essential Tools for Replication Monitoring

• repadmin: The primary command‑line tool for diagnosing replication. It comes with Remote Server Administration Tools (RSAT). Key commands:
  • repadmin /replsummary – Summarises replication status across all DCs.
  • repadmin /showrepl – Shows detailed replication status per DC.
  • repadmin /queue – Displays pending replication operations.
  • repadmin /syncall – Forces replication between DCs.
  • repadmin /failcache – Shows failed replication attempts.
• dcdiag: Comprehensive domain controller health checker. Tests include:
  • /test:Replications – Checks replication status.
  • /test:Topology – Validates the KCC topology.
  • /test:Intersite – Checks inter‑site health.
• Event Viewer: Look for replication‑related events in:
  • Directory Service log (Event ID 1311, 1864, 1988, 2042, etc.)
  • DFS Replication log (for SYSVOL)
• PowerShell: Get-ADReplicationFailure, Get-ADReplicationPartnerMetadata, etc.
• Active Directory Replication Status Tool (a GUI tool from Microsoft).

📊 Key Replication Metrics

• USN (Update Sequence Number): Each DC tracks changes with USNs. Replication partners compare USNs to know what changes to request.
• High Watermark and UpToDateness Vector: Used to track the latest changes a DC has received from each source.
• Replication latency: Time taken for a change to appear on all DCs.

⚠️ Common Replication Errors and Their Fixes

📝 Using repadmin – Examples

# Summarise replication across the forest
repadmin /replsummary

# Show detailed replication status for a specific DC
repadmin /showrepl DC01.contoso.com

# Force replication of a specific directory partition
repadmin /syncall /e /A /P /d /q

# Check replication queue (pending changes)
repadmin /queue DC01.contoso.com

# Show replication failures in the last 3 days
repadmin /failcache *

# Remove lingering objects (use with caution)
repadmin /removelingeringobjects DC01.contoso.com DC=contoso,DC=com /advisory_mode
                             

📈 Proactive Replication Monitoring

• Set up monitoring alerts for Event IDs 1925, 1988, 2042, 1311, and 1864.
• Run repadmin /replsummary daily via a scheduled task and report any failures.
• Use System Center Operations Manager (SCOM) or third‑party tools to monitor replication health.
• Regularly review the number of lingering objects with repadmin /removelingeringobjects * /advisory_mode.
• Monitor replication latency by comparing timestamps on changes across DCs.

🔐 Best Practices for Healthy Replication

• Maintain at least two DCs per domain for redundancy.
• Ensure all DCs have accurate time sync (use the PDC emulator as the time source).
• Keep the tombstone lifetime at its default (180 days) and never set it lower without understanding the consequences.
• Regularly back up at least one DC per domain.
• Monitor and maintain DNS health (see 5.1).
• Keep replication schedules realistic; avoid setting intervals too short for slow WAN links.

6.1 Kerberos Authentication Explained

🔑 What is Kerberos?

Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications using secret‑key cryptography. It is the default authentication protocol in modern Active Directory domains. Kerberos was developed at MIT and named after the three‑headed dog of Greek mythology – fitting because it uses three parties: the client, the server, and a trusted third party (the Key Distribution Center).

In Active Directory, Kerberos is the foundation of secure authentication. It enables single sign‑on (SSO), mutual authentication, and reduced network exposure of credentials. Unlike older protocols such as NTLM, Kerberos never transmits passwords or password hashes over the network; instead, it uses tickets and session keys to prove identity.

🧩 Components of Kerberos

• KDC (Key Distribution Center): In Active Directory, every domain controller runs a KDC. It has two logical components:
  • Authentication Service (AS): Issues Ticket Granting Tickets (TGTs) after verifying the client’s identity.
  • Ticket Granting Service (TGS): Issues Service Tickets (STs) for specific services, based on a valid TGT.
• Principal: A unique identity such as a user, computer, or service. Each principal has a long‑term secret – typically a password (for users) or a computer account password (for machines).
• Ticket Granting Ticket (TGT): A credential that proves the client has been authenticated. It contains the client’s identity, a session key, and an expiration time. The TGT is encrypted with the KDC’s own key (the KRBTGT account’s key).
• Service Ticket (ST): A ticket that allows a client to authenticate to a specific service. It contains the client’s identity, a session key (different from the TGT session key), and is encrypted with the target service’s long‑term key.
• Authenticator: A timestamp encrypted with the session key. It proves that the client possesses the session key and that the message is recent (replay protection).
• Session Key: A temporary key generated by the KDC and used to encrypt communications between the client and the KDC, or between the client and a service. Session keys are short‑lived and never reused.

🔄 The Kerberos Authentication Flow (Detailed)

The Kerberos protocol consists of three main message exchanges, often called the “Kerberos 3‑legged dog”. We’ll explore each step in depth, including the contents of the messages.

1. AS Exchange (Authentication Service)

The goal of the AS exchange is for the client to obtain a TGT.

1. AS‑REQ (Client → KDC): The client sends an authentication request to the KDC’s Authentication Service. It includes:
   • The client’s principal name (e.g., user@REALM).
   • A timestamp encrypted with the client’s long‑term key (derived from the password). This is the pre‑authentication data (see below).
   • Optionally, the requested ticket lifetime and encryption types supported.
2. KDC processing: The KDC looks up the client’s key in its database (Active Directory). It decrypts the pre‑authentication timestamp and verifies that it is recent (within a few minutes). If successful, the KDC knows the client is genuine.
3. AS‑REP (KDC → Client): The KDC responds with:
   • A TGT, encrypted with the KDC’s own key (the KRBTGT account’s key). The TGT contains the client’s identity, a new session key (SK_TGT), the ticket lifetime, and other attributes. Because it’s encrypted with the KDC’s key, the client cannot read it, but it will store it.
   • The same session key (SK_TGT) is also encrypted separately with the client’s long‑term key, so the client can decrypt it.
4. Client processing: The client uses its long‑term key (derived from its password) to decrypt the session key SK_TGT. It stores this session key and the TGT in its ticket cache (memory). The TGT itself remains opaque to the client.

2. TGS Exchange (Ticket Granting Service)

When the client wants to access a service (e.g., a file server), it must obtain a Service Ticket (ST) for that service.

1. TGS‑REQ (Client → KDC): The client sends a request to the Ticket Granting Service. It includes:
   • The TGT (still encrypted with the KDC’s key).
   • An authenticator encrypted with the session key SK_TGT. This proves the client possesses the session key.
   • The Service Principal Name (SPN) of the target service (e.g., cifs/fileserver.contoso.com).
   • Optionally, requested options (e.g., delegation, renewable).
2. KDC processing: The KDC decrypts the TGT using its own key, extracts SK_TGT, and uses it to verify the authenticator. It then checks whether the client is authorized to access the requested service (by looking up the service’s account and any access controls). If all is well, it generates a Service Ticket (ST) for that service. The ST contains:
   • The client’s identity.
   • A new session key (SK_Service).
   • The ticket lifetime and other attributes.
   The ST is encrypted with the target service’s long‑term key (the password of the service account or computer account).
3. TGS‑REP (KDC → Client): The KDC returns:
   • The Service Ticket (encrypted with the service’s key).
   • The new session key SK_Service encrypted with SK_TGT.
4. Client processing: The client decrypts SK_Service using SK_TGT and stores it. It now has a valid Service Ticket for the target service.

3. AP Exchange (Client‑Service Authentication)

1. AP‑REQ (Client → Service): The client sends the Service Ticket (still encrypted with the service’s key) along with a new authenticator encrypted with SK_Service to the target service.
2. Service processing: The service decrypts the Service Ticket using its own long‑term key, extracting SK_Service and the client’s identity. It then uses SK_Service to verify the authenticator. If successful, the service knows the client is authentic and that the ticket is fresh.
3. AP‑REP (optional, Service → Client): The service may send back an authenticator encrypted with SK_Service to provide mutual authentication, proving that the service also possesses the correct key.

From this point onward, the client and service can communicate securely, optionally using the session key SK_Service to sign or encrypt application data.

🔐 Kerberos Pre‑Authentication

The initial AS‑REQ includes pre‑authentication data – typically a timestamp encrypted with the client’s long‑term key. This prevents an attacker from requesting a TGT for another user and then offline‑cracking the response. Without pre‑authentication, an attacker could request a TGT for any user and receive an encrypted TGT (which includes an encrypted session key) that could be cracked offline. This is the basis of the AS‑REP Roasting attack. In modern Active Directory, pre‑authentication is enabled by default for all user accounts. You can enforce it via Group Policy or on individual accounts.

Pre‑authentication can also use other mechanisms, such as public key cryptography (PKINIT), which uses certificates instead of passwords for the initial authentication.

🔑 Encryption Types and Keys

Kerberos supports multiple encryption types. The most important are:

• RC4‑HMAC (old, weak): Based on the MD4 hash of the password. Used for backward compatibility but vulnerable to attacks (e.g., pass‑the‑hash).
• AES128‑CTS‑HMAC‑SHA1 and AES256‑CTS‑HMAC‑SHA1 (strong): Modern encryption types, recommended. They are more secure and resistant to many attacks.
• DES (deprecated): No longer used in modern Windows.

The KDC and client negotiate the highest common encryption type. The domain functional level and Group Policy can restrict allowed encryption types. For best security, disable RC4 and require AES. This is done via Group Policy under Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → “Network security: Configure encryption types allowed for Kerberos”.

Each principal has a long‑term key derived from its password. For RC4, the key is the MD4 hash of the password. For AES, it’s derived using a PBKDF2 function. The KRBTGT account’s key is used to encrypt all TGTs – which is why the KRBTGT hash is the most sensitive secret in the domain.

🎫 Ticket Structure

A Kerberos ticket (TGT or ST) is not just a blob; it contains several fields:

• Ticket version number (5 for Kerberos 5).
• Realm – the domain that issued the ticket.
• Principal name – the client’s identity.
• Encrypted part – contains the session key, the client’s attributes, flags, start time, end time, renewal time, and authorization data (such as group memberships). This part is encrypted with the target’s key (KDC key for TGT, service key for ST).

The authorization data in a service ticket can include PAC (Privilege Attribute Certificate). The PAC contains the user’s security identifier (SID), group memberships, and other authorization information. The service uses this to build the user’s access token. The PAC is signed by the KDC to prevent tampering.

🌍 Cross‑Realm Authentication (Trusts)

Kerberos supports authentication across realms (domains/forests) through cross‑realm trusts. When a client in Realm A wants to access a service in Realm B, the KDC in Realm A issues a referral ticket for Realm B’s KDC, and the client then requests a service ticket from Realm B’s KDC. This relies on a shared inter‑realm key (the trust password) between the two KDCs.

In Active Directory, domain trusts (parent‑child, tree, forest, shortcut, external) automatically establish the necessary Kerberos trust relationships. For example, a user in a child domain can access a file server in the parent domain using Kerberos because the KDCs forward referrals using the trust key.

🔄 Kerberos Delegation

Delegation allows a service to act on behalf of a user when accessing other services. For example, a web server may need to access a database server using the user’s identity. Kerberos supports three types of delegation:

• Unconstrained delegation: The service can impersonate the user to any other service. This is dangerous because the service’s TGT (if forwarded) can be used anywhere. It should be avoided.
• Constrained delegation: The service is allowed to delegate only to specific services (using S4U2Proxy). This is more secure.
• Resource‑based constrained delegation: Introduced in Windows Server 2012, the target service controls which accounts are trusted for delegation. This is even more secure and easier to manage.

Delegation requires the user account to be trusted for delegation (the “Trust this user for delegation to specified services only” option in ADUC) and appropriate SPN configuration.

⏲️ Time Synchronization

Kerberos is extremely time‑sensitive. It relies on timestamps in authenticators to prevent replay attacks. By default, the maximum allowable time skew between a client and a KDC is 5 minutes. If clocks differ by more than this, authentication fails. In Active Directory, all domain members synchronize time with the domain controller hierarchy, with the PDC Emulator acting as the authoritative time source. Ensure time sync is working to avoid Kerberos errors.

🛡️ Security Considerations and Best Practices

• Enable AES encryption: Disable RC4 if possible to prevent attacks like Kerberoasting (which often targets RC4‑encrypted tickets).
• Protect the KRBTGT account: Regularly rotate its password (twice, with a delay) to invalidate any forged Golden Tickets.
• Use Managed Service Accounts (MSAs) / Group MSAs: These have automatic password rotation and long complex passwords, making Kerberoasting harder.
• Enable Kerberos armoring (FAST): Introduced in Windows Server 2012, Kerberos armoring protects the TGS exchange by using the TGT session key to encrypt the TGS request. This prevents offline cracking of service tickets.
• Monitor for anomalous Kerberos events: Event IDs 4768 (TGT requested), 4769 (ST requested), 4771 (pre‑auth failed), 4770 (TGT renewed). Look for unusual patterns (e.g., many requests for a service account).
• Set appropriate ticket lifetimes: Shorter lifetimes reduce the window for ticket theft. Use Group Policy to adjust “Maximum lifetime for service ticket” and “Maximum lifetime for user ticket”.
• Enforce pre‑authentication: Ensure all user accounts have “Do not require Kerberos preauthentication” unchecked (except for special cases like some UNIX integrations).
• Use constrained delegation: Avoid unconstrained delegation. Review delegation settings regularly.

📊 Kerberos Message Types Summary

6.2 NTLM vs Kerberos – Deep Dive Comparison

🔄 NTLM (NT LAN Manager) – The Legacy Protocol

NTLM is a family of authentication protocols developed by Microsoft and used in Windows operating systems. It evolved through several versions: NTLMv1 (introduced with Windows NT 3.5), NTLMv2 (introduced with Windows NT 4.0 SP4), and the NTLM2 Session variant. While largely superseded by Kerberos in domain environments, NTLM remains widely supported for backward compatibility, particularly with standalone systems, down‑level clients, and legacy applications.

How NTLM Works – Detailed Technical Flow:

1. Negotiation: The client sends a Negotiate message to the server, listing its supported NTLM version and features.
2. Challenge: The server responds with a Challenge message containing an 8‑byte random number (the nonce) for NTLMv1, or a more complex challenge for NTLMv2 that includes a timestamp and server name.
3. Authentication: The client computes a response by:
   • Hashing the user’s password (using MD4 for NTLMv1, HMAC‑MD5 for NTLMv2).
   • Using that hash to encrypt the challenge (or a derivative) – creating the LM Response (weak) and NT Response (stronger). NTLMv2 creates a more complex response that includes a client nonce and timestamp to prevent replay attacks.
   • Sending the responses back to the server.
4. Verification: The server forwards the challenge and response to a domain controller (or verifies locally if it’s a local account). The DC looks up the user’s password hash from the SAM or Active Directory, recomputes the expected response, and compares. If they match, authentication succeeds.
5. Result: The DC informs the server, which then grants or denies access.

NTLMv2 is a significant improvement over NTLMv1, using stronger cryptography and including a timestamp to mitigate replay attacks. However, it still lacks mutual authentication and is vulnerable to pass‑the‑hash and relay attacks if not properly secured.

🔑 Kerberos – The Modern Standard

As detailed in section 6.1, Kerberos is the default authentication protocol for Active Directory. It provides mutual authentication, supports delegation, and never transmits password hashes. It relies on tickets issued by a trusted Key Distribution Center (KDC) and uses symmetric key cryptography. Kerberos is far more secure and feature‑rich than NTLM, but it requires a properly configured domain infrastructure and time synchronisation.

🔍 Head‑to‑Head Comparison – Expanded

📊 When NTLM Is Used – Detailed Scenarios

• Authentication using IP addresses instead of hostnames: Kerberos tickets are issued to SPNs, which are tied to hostnames. If a client connects to a server using its IP address (e.g., \\192.168.1.10\share), it cannot request a ticket for that IP because no SPN exists. NTLM is used as a fallback.
• Accessing resources on non‑domain‑joined machines: Kerberos requires a domain trust. If the target server is in a workgroup, Kerberos cannot be used.
• Applications that hard‑code NTLM usage: Some legacy applications (e.g., older versions of SQL Server, custom in‑house apps) may only support NTLM.
• Authentication to down‑level operating systems: Windows NT 4.0 and earlier do not support Kerberos.
• Double‑hop without Kerberos delegation configured: For example, a web server (IIS) with Windows authentication attempting to access a remote SQL server using the user’s credentials. If Kerberos delegation is not set up, the double‑hop fails and may fall back to NTLM (if the service account permissions allow).
• Network connectivity issues to KDC: If a client cannot reach a domain controller (e.g., VPN disconnected, network outage), Kerberos fails and the client may attempt NTLM.
• Missing or misconfigured SPNs: If a service’s SPN is not registered correctly, clients cannot request a Kerberos ticket and fall back to NTLM.
• Anonymous authentication or guest access: Some anonymous connections may use NTLM.

🛡️ NTLM Attack Surface – In Depth

NTLM’s weaknesses have led to numerous attack techniques that are staples in penetration testing and real‑world breaches:

• Pass‑the‑Hash (PtH): An attacker extracts the NTLM hash of a user (from LSASS memory or a compromised system) and uses it to authenticate to other systems. Since NTLM uses the hash directly as the authentication secret, having the hash is equivalent to having the password. Mitigation: Use Kerberos, enable Credential Guard, use Protected Users group, and restrict NTLM.
• NTLM Relay: An attacker intercepts an NTLM authentication attempt and forwards (relays) it to another server, authenticating as the victim. This is especially dangerous when combined with protocols like SMB and HTTP. Mitigation: Enable SMB signing, require LDAP signing, use EPA (Extended Protection for Authentication), and disable NTLM where possible.
• LLMNR/NBT‑NS Poisoning: When a client fails to resolve a hostname via DNS, it broadcasts a request using LLMNR or NetBIOS. An attacker on the same subnet can respond, tricking the client into sending NTLM authentication to the attacker’s machine. The attacker can then crack the hash or relay it. Mitigation: Disable LLMNR and NetBIOS via Group Policy, and enforce SMB signing.
• NTLMv1 Downgrade: An attacker can force a client to use the weaker NTLMv1 protocol, which is vulnerable to offline cracking (e.g., using rainbow tables). Mitigation: Disable NTLMv1 entirely via Group Policy and network security settings.
• Offline Cracking: Captured NTLMv2 responses can be cracked offline (using tools like Hashcat) to recover the plaintext password, especially if the password is weak. Strong password policies help mitigate this.

🔧 Detailed NTLM Hardening and Migration Strategies

Moving away from NTLM requires a phased approach. Here’s a step‑by‑step guide:

1. Audit NTLM Usage: Enable auditing via Group Policy to identify which applications, servers, and clients are using NTLM. Use the following policies:
   • Network security: Restrict NTLM: Audit Incoming NTLM traffic – set to “Enable auditing for all accounts”.
   • Network security: Restrict NTLM: Audit NTLM authentication in this domain – set to “Enable all”.
   • Monitor Event IDs 8001, 8002, 8003, 8004 (NTLM authentication events) in the “Microsoft-Windows-NTLM/Operational” log.
2. Fix Kerberos Issues: Many NTLM fallbacks are due to missing SPNs. Ensure all critical services have proper SPNs registered. Use setspn to list and verify. Also ensure DNS is healthy.
3. Enable NTLMv2 and Reject v1: Set Network security: LAN Manager authentication level to “Send NTLMv2 response only. Refuse LM & NTLM”. This disables the older, weaker protocols.
4. Require NTLMv2 Session Security: Enable “Network security: Minimum session security for NTLM SSP based (clients/servers)” to require 128‑bit encryption and NTLMv2 session security.
5. Restrict NTLM by Policy: Move from audit to restrict:
   • Set Network security: Restrict NTLM: Incoming NTLM traffic to “Deny all domain accounts” or “Deny all accounts”.
   • Set Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers to “Deny all” or “Deny all domain accounts”.
   • Use exceptions lists for servers that still require NTLM (e.g., “Allow server exceptions”).
6. Implement SMB Signing: For all systems, enable SMB signing (at least for domain controllers). This prevents NTLM relay attacks. Policy: Microsoft network server: Digitally sign communications (always) and Microsoft network client: Digitally sign communications (always).
7. Disable LLMNR and NetBIOS over TCP/IP: Via Group Policy (Computer Configuration → Administrative Templates → Network → DNS Client) and network adapter settings.
8. Migrate Applications: Work with application owners to update or replace legacy applications that require NTLM. For .NET applications, consider using System.Net.Kerberos or configuring SPNs.

🧪 Testing and Validation

After hardening, validate that NTLM usage has dropped and that critical services still function:

• Use klist on clients to view Kerberos tickets.
• Use nltest /dsgetdc: to ensure DC discovery.
• Monitor Event Logs for NTLM rejections (Event ID 8005).
• Perform application testing for all critical line‑of‑business applications.

📈 Comparison of Security Posture

🔁 Transition from NTLM to Kerberos – Real‑World Example

A large enterprise with legacy file servers (Windows Server 2003) decides to migrate to Windows Server 2022. The old servers used NTLM extensively. The migration plan includes:

• Phasing out old servers and replacing with new ones.
• Ensuring all new servers have correct SPNs (automatically registered for domain‑joined machines).
• Configuring Group Policy to first audit, then restrict NTLM.
• Training helpdesk to recognise Kerberos-related errors (e.g., time skew, SPN missing).
• Using tools like klist and setspn to troubleshoot.
• After six months, setting “Deny all” for NTLM, with exceptions only for a few verified legacy systems isolated in a separate network segment.

The result: reduced attack surface, fewer authentication failures, and compliance with security mandates.

6.3 Least Privilege Model – Comprehensive Implementation Guide

🔐 What is Least Privilege? The Foundation of Zero Trust

The principle of least privilege is a cornerstone of information security. It dictates that any entity (user, application, process, or device) should be granted only the minimum set of permissions, rights, and access necessary to perform its legitimate functions – and no more. This principle is fundamental to reducing attack surface, limiting blast radius, and preventing lateral movement in the event of a compromise.

In the context of Active Directory, least privilege is not merely a recommendation; it is a critical control mandated by numerous compliance frameworks (ISO 27001, NIST 800-53, PCI DSS, CIS Benchmarks). Despite this, many organisations still operate with over‑privileged accounts, granting users administrative rights they do not need, and allowing service accounts to roam freely with excessive privileges.

🧩 The Principle in Depth: Beyond Users

Least privilege applies to multiple layers:

• User accounts: Standard users should not have local admin rights on their workstations. They should not be members of privileged AD groups.
• Administrative accounts: Admins should use separate accounts for privileged tasks, and those accounts should have narrowly scoped permissions (e.g., only able to manage specific OUs).
• Service accounts: Many service accounts are configured as Domain Admins out of convenience. This is a critical vulnerability. Service accounts should have only the specific permissions required to run their service (e.g., read/write to a particular file share, permission to update a specific attribute).
• Computer accounts: Computers themselves have accounts in AD. They should not have unnecessary privileges (e.g., a file server does not need to be able to create user accounts).
• Applications and processes: Even within an application, the principle applies. A web server process should not run as SYSTEM; it should run with a least‑privileged service account.

👥 Tiered Administrative Model – The Microsoft Enterprise Access Model

Microsoft's Enterprise Access Model (formerly the Tiered Administration Model) is a proven framework for implementing least privilege in Active Directory. It divides the environment into three tiers, with strict controls on what accounts can access which resources.

• Tier 0 (Identity and Control Plane):
  • Includes: Domain controllers, Active Directory, Azure AD Connect, AD FS servers, PKI (Certificate Authority) servers, and any system with direct control over the identity store.
  • Admins: Only Tier 0 administrators can log on to these systems. These admins have accounts that are members of groups like Domain Admins, Enterprise Admins, Schema Admins, or built‑in Administrators on DCs.
  • Security boundary: Compromise of Tier 0 gives the attacker complete control over the entire forest.
• Tier 1 (Server and Application Infrastructure):
  • Includes: File servers, application servers, database servers, web servers, and other infrastructure servers that do not control identity.
  • Admins: Tier 1 administrators manage these servers. They may have local admin rights on these machines but should not have any Tier 0 access.
  • Security boundary: Compromise of Tier 1 gives the attacker access to application data and server control, but not to the identity layer.
• Tier 2 (User Workstations and Devices):
  • Includes: End‑user workstations, laptops, tablets, and other user devices.
  • Admins: Tier 2 administrators (often helpdesk) can manage these devices – resetting local passwords, installing software, etc. They should not have access to Tier 0 or Tier 1 systems.
  • Security boundary: Compromise of a Tier 2 device gives the attacker a foothold on a user's machine, but not on servers or identity systems.

The Golden Rule: Accounts from a higher tier can log on to lower‑tier systems, but accounts from a lower tier cannot log on to higher‑tier systems. For example:

• A Tier 0 admin (using their Tier 0 account) can log on to a file server (Tier 1) to perform maintenance.
• A Tier 1 admin (using their Tier 1 account) must never log on to a domain controller (Tier 0). If they need to perform a Tier 0 task, they must use a separate Tier 0 account (and ideally a separate PAW).

🛡️ Implementing Tier Separation

To enforce tier separation, you need a combination of technical controls:

• Separate administrative accounts: Each administrator should have at least two accounts: one for daily work (Tier 2) and one for their administrative role (Tier 1 or Tier 0). In high‑security environments, admins may have separate accounts for each tier they manage.
• Privileged Access Workstations (PAWs): As described below, PAWs are dedicated workstations for administrative tasks. They are configured to only allow logon by administrative accounts and are hardened against compromise.
• Logon restrictions: Use Group Policy or fine‑grained logon rights to restrict where admin accounts can log on. For example, configure "Deny log on locally" and "Deny log on through Remote Desktop" for Tier 0 accounts on all non‑Tier 0 systems.
• Just Enough Administration (JEA): Limit what admins can do on target systems (see below).
• Just‑In‑Time (JIT) access: Grant temporary membership in privileged groups only when needed (see 6.6).

🖥️ Privileged Access Workstations (PAWs) – Detailed Implementation

A PAW is a hardened workstation used exclusively for administrative tasks. It is the most effective control against credential theft for high‑privileged accounts. PAWs are mandatory for Tier 0 administrators and strongly recommended for Tier 1.

Key characteristics of a PAW:

• Dedicated purpose: Used only for administration – no email, no web browsing, no document editing. This reduces the attack surface dramatically.
• Clean operating system: Fresh installation with only necessary administrative tools (RSAT, custom scripts, etc.).
• Application control: Use AppLocker or Windows Defender Application Control (WDAC) to allow only authorised applications.
• Device guard / Credential Guard: Enabled to protect LSASS from credential theft.
• BitLocker: Full disk encryption to protect data at rest.
• Network isolation: Ideally, the PAW is not on the same network as user workstations. It may have restricted internet access (e.g., through a filtered proxy).
• Regular patching: PAWs must be kept up‑to‑date with security patches, often using a dedicated update infrastructure.
• Separate administrative accounts: Only privileged accounts (Tier 0 or Tier 1) are allowed to log on to the PAW. Standard user accounts are blocked.

PAW Deployment Options:

• Physical PAW: A dedicated physical machine. Most secure but more expensive.
• Virtual PAW: A virtual machine on a secure host (e.g., a dedicated virtualization server). Allows easier management and isolation.
• Cloud‑based PAW: Using Windows 365 or Azure Virtual Desktop to provide a cloud‑hosted administrative workstation. This can be very effective for hybrid environments.

📉 Just Enough Administration (JEA) – Granular Delegation

JEA is a PowerShell‑based technology that allows you to delegate specific administrative tasks without granting full administrative rights. It works by creating a constrained PowerShell session endpoint (a "JEA endpoint") that connects to a target machine. When a user connects to this endpoint, they are mapped to a virtual account (temporary, with just‑in‑time privileges) that has only the permissions necessary to run a predefined set of commands.

Benefits of JEA:

• Principle of least privilege: Users get only the exact permissions they need, not full admin rights.
• Reduced lateral movement: Even if a user's credentials are stolen, the attacker can only run the allowed commands, not take over the machine.
• Full auditing: Every command run through JEA is logged (with detailed transcription), providing an audit trail.
• No permanent elevation: The virtual account exists only for the duration of the session.

Example JEA Scenario: Helpdesk staff need to reset user passwords and manage group memberships on domain controllers (Tier 0). Instead of making them Domain Admins, you create a JEA endpoint on the DCs that exposes only the Reset-ADAccountPassword and Add-ADGroupMember cmdlets, constrained to specific OUs. The helpdesk connects to the endpoint, performs the task, and the session ends. They never have a full interactive logon on the DC.

Implementing JEA:

1. Create a role capability file (.psrc) that defines which cmdlets and functions are available.
2. Create a session configuration file (.pssc) that maps users/groups to the role capability and specifies the virtual account.
3. Register the JEA endpoint using Register-PSSessionConfiguration.
4. Configure WinRM and firewall rules to allow connections.
5. Train users to connect using Enter-PSSession -ComputerName DC01 -ConfigurationName JEA-Endpoint.

🔑 Local Administrator Password Solution (LAPS) – In Depth

LAPS (Local Administrator Password Solution) is a Microsoft tool that automatically manages local administrator passwords on domain‑joined computers. It solves the problem of identical local admin passwords across many machines – a common vector for lateral movement in Pass‑the‑Hash attacks.

How LAPS Works:

1. LAPS is installed on each workstation/server (via Group Policy or endpoint management).
2. A client‑side extension periodically generates a new, random password for the local administrator account (or any specified local account).
3. The password is stored in Active Directory as an attribute (ms-Mcs-AdmPwd) on the computer object. The password is encrypted during transmission and storage.
4. Only authorised users (e.g., helpdesk) are granted read access to this attribute. They can retrieve the password when needed (e.g., for remote support).
5. The old password is then changed after use.

Key Benefits:

• Unique local admin passwords for every machine – if one machine is compromised, its local admin password cannot be used on others.
• Passwords are strong and rotated regularly (configurable).
• Auditing: Access to passwords is logged in AD.
• Integration with existing AD infrastructure.

Implementation Steps:

1. Download and install LAPS on management workstations (for GPO administration).
2. Extend the AD schema to add the LAPS attributes (run Update-LapsADSchema).
3. Delegate permissions to computer objects so that machines can update their own password attribute.
4. Create a GPO to deploy the LAPS client and configure policy (e.g., password complexity, rotation frequency).
5. Delegate read access to the password attribute to authorised helpdesk groups.
6. Test and deploy.

📋 Comprehensive Least Privilege Implementation Plan

Moving to a least‑privilege model is a journey. Here is a phased, practical plan:

Phase 1: Discovery and Inventory

• Identify all privileged groups in AD: Domain Admins, Enterprise Admins, Schema Admins, Administrators, Backup Operators, Account Operators, Server Operators, Print Operators, etc.
• List all members of these groups. Use tools like Get-ADGroupMember or Netwrix Auditor.
• Document service accounts and their current privileges (many are over‑privileged).
• Identify where users are local administrators on their own workstations (via local group membership or Group Policy).
• Run tools like BloodHound to visualise attack paths and identify over‑privileged accounts.
• Use PingCastle or Purple Knight to assess the current security posture.

Phase 2: Design and Planning

• Define the tier boundaries (Tier 0, 1, 2) for your organisation.
• Design the new administrative structure:
  • Create new groups for each tier and function (e.g., "Tier0-Admins", "Tier1-FileServer-Admins", "Tier2-Helpdesk").
  • Plan separate admin accounts for each administrator (e.g., user_jdoe, admin_jdoe_t0, admin_jdoe_t1).
  • Design PAW deployment (which admins get PAWs, where they will be located).
• Plan the rollout of LAPS and JEA for specific use cases.
• Develop a communication and training plan for administrators and users.

Phase 3: Implementation and Hardening

• Create dedicated admin accounts: For each administrator, create the required separate accounts. Use a naming convention (e.g., first.last, first.last_adm, first.last_t0).
• Populate new groups: Add the new admin accounts to the appropriate tier groups.
• Deploy PAWs: For Tier 0 admins (and optionally Tier 1), set up PAWs. Harden them using security baselines (e.g., Microsoft Security Compliance Toolkit).
• Implement logon restrictions:
  • Use Group Policy to configure "Deny log on locally", "Deny log on through Remote Desktop", etc., for privileged accounts on lower‑tier systems.
  • Configure "Allowed logon workstations" (userWorkstations attribute) for Tier 0 accounts to restrict them to PAWs.
• Remove over‑privileged memberships: Carefully remove users from overly privileged groups (e.g., Domain Admins) after verifying they have alternative access.
• Restrict local admin rights on workstations:
  • Remove "Domain Users" from the local Administrators group using Group Policy (Restricted Groups).
  • Add only specific groups (e.g., "Tier2-Helpdesk") to local Administrators where needed.
  • Use LAPS to manage the built‑in local Administrator password.
• Harden service accounts:
  • Replace manually managed service accounts with Group Managed Service Accounts (gMSAs) where possible. gMSAs have automatic password rotation and are least‑privilege by design.
  • Review permissions for each service account and reduce them to the minimum required.
  • Never use Domain Admins as service accounts.
• Implement JEA for key delegation scenarios: Start with one or two critical tasks (e.g., password reset on DCs).

Phase 4: Monitoring and Auditing

• Enable auditing for privileged group changes (Event IDs 4728, 4732, 4756, etc.).
• Monitor logon events for privileged accounts (Event ID 4672 – special privileges assigned). Alert on any logon of a Tier 0 account to a non‑PAW machine.
• Use a SIEM to correlate and alert on anomalous behaviour.
• Regularly review membership of privileged groups (monthly).
• Run periodic security assessments with tools like PingCastle to track progress.

Phase 5: Ongoing Maintenance and Improvement

• Establish a process for requesting and approving temporary privilege elevation (JIT).
• Regularly rotate passwords for critical accounts (including KRBTGT – twice, with a delay).
• Keep up with Microsoft security recommendations and adjust policies accordingly.
• Conduct regular penetration testing focused on AD attack paths.

🔍 Common Pitfalls and How to Avoid Them

• Pitfall: Creating admin accounts but still using the old ones. Solution: Monitor logons and enforce use of new accounts. Eventually disable old accounts.
• Pitfall: PAWs not truly isolated (e.g., users browse the web on them). Solution: Enforce strict application control and web filtering; educate users.
• Pitfall: Service accounts with expired passwords causing outages. Solution: Use gMSAs or managed service accounts (MSAs) with automatic password management.
• Pitfall: "Temporary" membership in privileged groups becoming permanent. Solution: Implement JIT access with approval workflows.
• Pitfall: LAPS not deployed to all machines. Solution: Use GPO to enforce LAPS installation and monitor compliance.

📊 Measuring Success: KPIs for Least Privilege

• Percentage of users with local admin rights on workstations: Target 0% (except for specific, justified exceptions).
• Number of Domain Admin members: Should be a very small, documented set (ideally fewer than 5).
• Coverage of LAPS: 100% of domain‑joined workstations and servers.
• Number of service accounts with Domain Admin privileges: 0.
• Percentage of administrative logons originating from PAWs: For Tier 0, target 100%.
• Reduction in attack paths as identified by BloodHound.

6.4 Protecting Admin Accounts – The Crown Jewels of Active Directory

🎯 Why Admin Accounts Are Prime Targets – Understanding the Threat Landscape

Administrative accounts are the crown jewels of any Active Directory environment. These accounts possess elevated privileges that allow them to reset passwords, modify group memberships, change security policies, configure domain controllers, and ultimately control the entire identity infrastructure. Attackers specifically target these accounts because compromising just one can lead to full domain compromise, often within hours.

The statistics are sobering: according to numerous breach reports, over 90% of organisations have experienced some form of credential theft, and privileged account compromise is a leading cause of major breaches. Attackers use techniques like spear‑phishing, password spraying, pass‑the‑hash, and token theft to capture admin credentials. Once they have a foothold, they move laterally, escalate privileges, and establish persistence.

🔑 Separate Admin Accounts – The Non‑Negotiable Foundation

The single most effective control to protect admin accounts is to ensure that every administrator has at least two separate accounts:

• Standard user account: Used for day‑to‑day activities – email, web browsing, document editing, and non‑administrative access to resources. This account should have no administrative privileges whatsoever. It should be a member of only standard user groups (e.g., Domain Users) and subject to regular security policies (password expiration, MFA if available).
• Administrative account(s): Used exclusively for privileged tasks. These accounts:
  • Should have a naming convention that clearly distinguishes them (e.g., first.last_adm, first.last_t0 for Tier 0, first.last_t1 for Tier 1).
  • Must have strong, unique passwords (ideally 20+ characters, randomly generated).
  • Should not be used for email, web browsing, or any interactive logon on untrusted systems.
  • Should be members of only the necessary privileged groups (e.g., Domain Admins for Tier 0, specific server admin groups for Tier 1).
  • Should be configured with additional security controls (see below).

In high‑security environments, administrators may need multiple admin accounts for different tiers. For example, a senior administrator might have:

• john.doe – Standard user account.
• john.doe_t0 – Tier 0 admin account (used only on PAWs to manage DCs).
• john.doe_t1 – Tier 1 admin account (used to manage file servers and applications).

This separation ensures that if a lower‑tier admin account is compromised, the attacker cannot directly access higher‑tier systems.

🛡️ Multi‑Factor Authentication (MFA) for Admin Accounts – Raising the Bar

Passwords alone are no longer sufficient to protect privileged accounts. Phishing, password reuse, and credential theft are too common. Multi‑factor authentication (MFA) adds a critical layer of security, requiring something the user knows (password) and something they have (smart card, token, phone) or something they are (biometric).

Options for MFA with Active Directory:

• Smart Cards (Physical or Virtual):
  • Physical smart cards (e.g., Common Access Cards, PIV cards) store a certificate and private key. Windows can be configured to require smart card logon for interactive sessions, RDP, and even for administrative tools like PowerShell.
  • Virtual smart cards use the Trusted Platform Module (TPM) on the device to emulate a smart card, providing similar security without a physical card.
  • Smart cards are FIPS 140‑2 compliant and provide strong, certificate‑based authentication.
  • Configuration: Use Group Policy to set "Interactive logon: Require smart card" for admin accounts, and deploy certificate infrastructure (AD CS).
• Windows Hello for Business (WHfB):
  • WHfB replaces passwords with strong two‑factor authentication on modern devices. It uses a PIN (something you know) and biometrics (fingerprint, facial recognition) or a TPM (something you have).
  • It integrates with on‑premises AD (via hybrid or key trust models) and Azure AD.
  • For on‑premises only, you can deploy WHfB with certificate trust, using AD CS.
• Azure AD / Third‑Party MFA for Hybrid Environments:
  • If you have hybrid identity (Azure AD Connect), you can use Azure AD Conditional Access to require MFA for privileged roles (e.g., Global Administrator). This does not directly protect on‑premises admin logons but can protect cloud‑connected admin activities.
  • Third‑party MFA solutions (e.g., Duo Security, RSA SecurID) can integrate with Windows logon via RADIUS or custom agents, providing MFA for RDP and interactive logons.

Implementation Best Practices:

• Start with Tier 0 admin accounts – require smart card or WHfB for all interactive logons.
• For Tier 1 and Tier 2 admin accounts, consider MFA for RDP access (e.g., via RD Gateway with MFA).
• Ensure you have a break‑glass procedure for emergency access when MFA is unavailable (e.g., a highly secured, offline emergency account).

🔒 Restricting Admin Logon Hours and Workstations – Reducing Attack Surface

Even with separate accounts and MFA, you can further limit exposure by restricting where and when admin accounts can log on.

Logon Workstation Restrictions:

• In Active Directory, each user account has a userWorkstations attribute (visible in ADUC under the "Account" tab → "Log On To…"). This allows you to specify a list of computer names (NetBIOS names) from which the user is allowed to log on.
• For Tier 0 admin accounts, this should be restricted to only their assigned Privileged Access Workstations (PAWs). For example, you might allow logon only from PAW-JDOE-01 and PAW-JDOE-02.
• This control is effective against attackers who have stolen credentials but are trying to use them from an unauthorised machine. However, it is not foolproof – an attacker who compromises the PAW itself can still use the account.
• Implementation: Use a script or tool to set the userWorkstations attribute. Note that this attribute has a character limit and can only specify up to 8 workstations (in the legacy UI). For more flexibility, use the userWorkstations attribute with comma‑separated values via PowerShell.

Logon Hour Restrictions:

• AD allows you to restrict the hours during which a user can log on to the domain. This is configured in ADUC under the "Account" tab → "Logon Hours".
• For admin accounts, you can restrict logon to business hours (e.g., 8 AM – 6 PM, Monday to Friday). This limits the window in which an attacker can use stolen credentials, especially if the attack occurs outside normal hours.
• However, be cautious: some administrative tasks (e.g., patching, disaster recovery) may need to occur outside these hours. You may need to create a separate process for after‑hours access (e.g., a JIT elevation workflow).

PowerShell Example to Set Logon Workstations:

# Set logon workstations for a Tier 0 admin account
Set-ADUser jdoe_t0 -LogonWorkstations "PAW-JDOE-01,PAW-JDOE-02"
                             

🔐 Protected Users Group – The Built‑In Security Booster

Introduced in Windows Server 2012 R2, the Protected Users global group is one of the most powerful yet underutilised security controls in Active Directory. When you add a user to this group, they automatically receive non‑configurable, hard‑coded protections that significantly reduce their attack surface.

Protections Applied to Protected Users:

• No NTLM authentication: Members cannot authenticate using NTLM, NTLMv2, or any other NTLM variant. This completely blocks pass‑the‑hash and NTLM relay attacks for these accounts.
• No Kerberos delegation: Unconstrained or constrained delegation cannot be used with Protected Users accounts. This prevents attackers from using delegation to impersonate the user.
• No DES or RC4 encryption in Kerberos: The KDC will only issue tickets using AES encryption. This mitigates attacks that target weak encryption (e.g., Kerberoasting with RC4).
• No credential delegation (CredSSP): Protections against credential forwarding via CredSSP (used in some Remote Desktop scenarios).
• Reduced Kerberos ticket lifetime: The TGT lifetime is set to 4 hours (down from the default 10). This limits the window of opportunity for ticket theft.
• No offline credential caching: The user's credentials are not cached on the local machine, reducing the risk of credential theft from memory.

Implementation Guidance:

• Add all Tier 0 admin accounts (Domain Admins, Enterprise Admins, etc.) to the Protected Users group.
• Consider adding Tier 1 and Tier 2 admin accounts as well, after verifying that no legacy applications rely on NTLM or weak Kerberos encryption for these accounts.
• Be aware that Protected Users cannot authenticate to down‑level servers (pre‑Windows Server 2008) that do not support AES Kerberos. Ensure all servers that admins need to access are at a supported level.
• Test thoroughly in a pilot group before rolling out widely.

PowerShell to Add Users to Protected Users Group:

Add-ADGroupMember -Identity "Protected Users" -Members "jdoe_t0", "asmith_t0"
                             

📜 Just‑In‑Time (JIT) Administration – Eliminating Standing Privileges

The concept of JIT administration is simple: no user should have permanent privileged access. Instead, they request elevation for a specific task, receive temporary membership in a privileged group, and lose that access after the task is complete (or after a short, predefined period). This drastically reduces the attack surface because there are no standing privileged accounts that an attacker can target.

JIT Implementation Options:

• Microsoft Identity Manager (MIM) Privileged Access Management (PAM):
  • MIM PAM uses a bastion forest – a separate, hardened Active Directory forest that is highly trusted but isolated. Users request elevation, and their membership in privileged groups is granted for a limited time using time‑based group membership (via the msDS-NeverRevealGroup and msDS-RevealOnDemandGroup attributes).
  • MIM PAM provides extensive auditing, approval workflows, and integration with existing AD.
  • It is complex to set up but provides the highest level of security for on‑premises environments.
• Azure AD Privileged Identity Management (PIM):
  • For hybrid or cloud‑only environments, Azure AD PIM provides JIT access to Azure AD roles (e.g., Global Administrator) and Azure resources. It can also manage just‑in‑time access for on‑premises roles if you use Azure AD Connect and configure PIM for Groups.
  • PIM includes approval workflows, activation notifications, and detailed audit logs.
• Third‑Party PAM Solutions:
  • Tools like CyberArk Privileged Access Security, BeyondTrust PowerBroker, and Thycotic Secret Server provide comprehensive privileged account management, including JIT elevation, session isolation, and credential vaulting.
  • These solutions often integrate with AD to manage group memberships dynamically.
• Manual or Scripted JIT:
  • For smaller environments, you can implement a simple JIT process using scheduled scripts and temporary group membership. For example, a helpdesk ticket could trigger a script that adds a user to a group for 4 hours, then removes them.
  • This is less secure than a full PAM solution but better than permanent standing privileges.

Example JIT Workflow (with MIM PAM):

1. Admin requests elevation to Domain Admin via a web portal, specifying a reason and duration.
2. Manager approves the request (or it is auto‑approved based on policy).
3. MIM adds the admin's account to the "Domain Admins" group in the bastion forest for the specified duration.
4. The admin performs necessary tasks using a PAW that trusts the bastion forest.
5. After the time expires, the membership is automatically removed. All actions are logged.

🕵️ Monitoring Admin Activity – Visibility is Security

Even with all the preventive controls in place, you must assume that some attacks will succeed. Comprehensive monitoring and alerting on administrative activity is essential for early detection and response.

Critical Event IDs to Monitor:

Building an Effective Monitoring Strategy:

• Enable Advanced Audit Policies: Use Group Policy to enable detailed auditing on domain controllers and critical servers. At minimum, enable:
  • Audit Account Management (Success, Failure)
  • Audit Logon Events (Success, Failure)
  • Audit Privilege Use (Success, Failure)
  • Audit Directory Service Access (Success, Failure)
• Centralise Log Collection: Forward all critical events to a SIEM (e.g., Azure Sentinel, Splunk, QRadar). This enables correlation, alerting, and long‑term retention.
• Create Alerts for Anomalies:
  • Alert on any addition of a user to a privileged group (especially if done outside approved hours).
  • Alert on logon of a Tier 0 account from a non‑PAW machine.
  • Alert on multiple failed logons for admin accounts (potential brute force).
  • Alert on changes to the AdminSDHolder container.
  • Alert on DCSync attempts (Event ID 4662 with control access right "DS-Replication-Get-Changes").
• Regularly Review Admin Activity: Even with alerts, conduct periodic manual reviews of admin actions. Use tools like Get-ADEvent or SIEM reports to generate weekly summaries.

🛡️ Additional Hardening Measures for Admin Accounts

• Disable inactive admin accounts: Regularly review and disable or delete admin accounts that are no longer needed (e.g., former employees).
• Rename or disable built‑in Administrator account: The built‑in Administrator account (SID S-1-5-21-...-500) is a well‑known target. Rename it via Group Policy and consider disabling it (but ensure you have another account with equivalent privileges).
• Set "Account is sensitive and cannot be delegated": For Tier 0 accounts, enable this flag (in ADUC) to prevent them from being delegated to services. This is automatically enforced by Protected Users, but can be set manually for other accounts.
• Use fine‑grained password policies: Apply stricter password policies (e.g., 20+ characters, no expiry) to admin accounts via FGPP.
• Implement Credential Guard: On all PAWs and admin workstations, enable Windows Defender Credential Guard to protect LSASS from credential theft.
• Restrict RDP access: Use Remote Desktop Gateway (RD Gateway) with MFA for any remote admin access. Block direct RDP to domain controllers and other sensitive servers.
• Secure the PAW: Ensure PAWs are themselves hardened with application whitelisting, limited internet access, and regular patching.

📋 Comprehensive Admin Account Protection Checklist

🔁 Break‑Glass (Emergency) Accounts

No matter how well you protect your admin accounts, there may be emergencies where normal access is unavailable (e.g., network outage, MFA system failure, or compromise of all regular admin accounts). For these scenarios, you must have break‑glass accounts – highly secured, emergency access accounts.

Characteristics of Break‑Glass Accounts:

• Extremely long, complex passwords (30+ characters, randomly generated), stored in a secure, offline location (e.g., a physical safe with dual‑control access).
• Not subject to normal password expiration (to avoid the risk of expiry during an emergency).
• Excluded from MFA requirements (since MFA might be unavailable).
• Strictly limited in number (e.g., two accounts per forest).
• Logon restricted to specific, highly secure workstations (maybe even physically isolated).
• Audited every time they are used; any use triggers an immediate security alert.
• Passwords are changed immediately after any use.

Store the passwords in a sealed envelope or a password manager with strict access controls. Document the procedure for using break‑glass accounts and test it periodically.

6.5 AD Attack Techniques – Understanding the Adversary's Playbook

🎭 Understanding the Adversary – The Mindset of an Attacker

To effectively harden Active Directory, you must think like an attacker. Adversaries are not random; they follow a methodical process, often leveraging the very features and protocols designed to make AD functional against itself. Understanding these techniques is crucial because it allows you to implement targeted defences and recognise early warning signs of compromise.

The attacks covered in this section – Pass‑the‑Hash, Golden Ticket, Silver Ticket, DCSync, Kerberoasting, and AS‑REP Roasting – represent some of the most common and devastating techniques used in real‑world breaches. They abuse fundamental components of AD: NTLM authentication, Kerberos ticketing, and replication protocols. By understanding how each attack works at a technical level, you can better appreciate the mitigations and monitoring strategies that follow.

🔑 Pass‑the‑Hash (PtH) – The Classic Lateral Movement Technique

What it is: Pass‑the‑Hash is an attack that allows an attacker to authenticate to remote systems using the NTLM hash of a user's password, without ever needing the plaintext password. This works because NTLM authentication protocols use the hash as the secret – if you have the hash, you can impersonate the user.

Technical Deep Dive – How PtH Works:

1. Initial Compromise: The attacker gains a foothold on a workstation or server through phishing, unpatched software, or other means. They may have limited privileges initially.
2. Credential Extraction: Using tools like Mimikatz, Windows Credential Editor, or even custom scripts, the attacker extracts NTLM hashes from the LSASS (Local Security Authority Subsystem Service) process memory. LSASS caches credentials of logged‑on users to enable single sign‑on. If a Domain Admin has recently logged on to that machine (even remotely via RDP), their hash may be present.
3. Hash Reuse: The attacker now has the NTLM hash of a privileged user. They use tools like Mimikatz's sekurlsa::pth or Invoke-TheHash PowerShell scripts to create a new logon session using the hash. This new session can authenticate to other machines on the network that accept NTLM authentication.
4. Lateral Movement: The attacker uses the hash to connect to file servers, database servers, or other workstations. They may use tools like PsExec, WMI, or Scheduled Tasks to execute code remotely. Each new compromised machine becomes a hunting ground for more credentials.
5. Goal: Domain Controller Access: The attacker repeats the process, moving laterally until they reach a domain controller. Once on a DC, they can extract the KRBTGT hash (leading to Golden Ticket) or create new admin accounts.

Why PtH is so Effective:

• No need to crack the hash – the hash itself is the authentication credential.
• Works across the network; attacker does not need to be on the same machine.
• Many organisations still have widespread NTLM usage, especially in mixed environments.
• Local admin hash reuse (identical local admin passwords across many machines) makes PtH trivial.

Advanced PtH Variants:

• Overpass‑the‑Hash (Pass‑the‑Key): Instead of using NTLM, the attacker converts the hash into a Kerberos ticket, allowing Kerberos authentication. This can bypass some NTLM restrictions.
• Pass‑the‑Ticket: Using stolen Kerberos tickets instead of hashes.

Comprehensive Mitigations:

• Enable Windows Defender Credential Guard: Credential Guard uses virtualization‑based security to protect LSASS secrets. Even if an attacker has admin rights, they cannot extract hashes from a protected LSASS. Requires Windows 10 Enterprise/Education or Windows Server 2016+.
• Restrict and Phase Out NTLM: Follow the NTLM hardening steps in section 6.2. If NTLM is not used, PtH becomes ineffective (though Overpass‑the‑Hash may still work if RC4 is enabled).
• Use Protected Users Group: As covered in 6.4, members of Protected Users cannot use NTLM authentication, directly blocking PtH.
• Implement Least Privilege: Ensure that only necessary users have local admin rights on workstations. If an attacker compromises a standard user, they cannot extract hashes of other users (since they can't run Mimikatz with admin rights).
• LAPS for Local Admin Passwords: Use LAPS to give every machine a unique local admin password. This prevents lateral movement using shared local admin hashes.
• Disable WDigest: WDigest protocol (disabled by default in modern Windows) caches plaintext passwords. Ensure it's disabled via Group Policy.
• Network Segmentation: Isolate critical systems (Tier 0) on separate network segments with strict firewall rules. An attacker on a workstation should not be able to reach a domain controller directly.
• Monitor for PtH Activity: Look for Event ID 4624 (logon) with Logon Type 3 (network) and Logon Process "NtLmSsp". Correlate with unusual source IPs. Also monitor for Event ID 4672 (special privileges assigned) for accounts that shouldn't have them.

👑 Golden Ticket Attack – The Ultimate Persistence

What it is: A Golden Ticket attack allows an attacker to forge a TGT (Ticket Granting Ticket) for any user, including non‑existent ones, with any group memberships (like Domain Admins). The forged ticket is signed with the KRBTGT account's password hash, making it indistinguishable from a real ticket.

Technical Deep Dive – How Golden Ticket Works:

1. KRBTGT Hash Extraction: The attacker must first obtain the KRBTGT hash. This requires domain admin or equivalent privileges, typically achieved by compromising a domain controller or extracting the hash from a DC's LSASS (if Credential Guard is not enabled) or from the NTDS.dit database (if backups are compromised).
2. Ticket Forgery: Using Mimikatz (or similar tools), the attacker runs kerberos::golden with parameters:
   • /user: – Any username, often a fake or existing admin (e.g., "Administrator").
   • /domain: – The domain FQDN.
   • /sid: – The domain SID.
   • /krbtgt: – The KRBTGT hash.
   • /id: – The desired user RID (500 for built‑in admin).
   • /groups: – Group RIDs (e.g., 512 for Domain Admins).
   • /startoffset /endoffset /renewoffset: – To set ticket validity (can be years).
   • /ptt: – Injects the ticket into current session.
3. Ticket Injection: The forged TGT is injected into the attacker's current logon session. The Windows Kerberos package now treats the attacker as the forged user.
4. Unlimited Access: With the forged TGT, the attacker can request Service Tickets for any resource in the domain. They can access file servers, databases, domain controllers, etc., all while appearing as a legitimate user.

Why Golden Ticket is so Dangerous:

• Indistinguishable: The forged ticket is signed with the real KRBTGT key, so it looks exactly like a real ticket. Logs show normal Kerberos activity.
• Persistence: The ticket can be forged with a lifetime of years. Even if the attacker's original entry point is discovered and cleaned, the Golden Ticket remains valid until the KRBTGT password is changed twice.
• No Need for Password Changes: If the target user changes their password, the Golden Ticket remains valid because it was forged independently of the user's key.
• Privilege Escalation: The attacker can grant themselves any group membership, including Enterprise Admins, Schema Admins, etc.

Comprehensive Mitigations:

• Protect Domain Controllers at All Costs: DCs are Tier 0 assets. Implement PAWs, strict access controls, and monitoring to prevent compromise. If an attacker cannot get the KRBTGT hash, they cannot forge Golden Tickets.
• Regularly Rotate the KRBTGT Password:
  • The KRBTGT account has two passwords (old and new) to allow for replication. To invalidate existing Golden Tickets, you must change the password twice, with a delay between changes (to allow replication).
  • Microsoft recommends changing the KRBTGT password every 180 days (or after any suspected compromise).
  • Use a script to automate this process, ensuring you don't break existing Kerberos operations.
  • Important: Changing the KRBTGT password will invalidate all TGTs, causing a temporary authentication storm. Plan carefully.
• Enable Kerberos Armoring (FAST): Kerberos armoring (Flexible Authentication Secure Tunneling) protects the TGS exchange by requiring that TGS requests be signed with the TGT session key. This makes it harder to use forged tickets in some scenarios. Enable via Group Policy: "Computer Configuration → Administrative Templates → System → Kerberos → Support for Kerberos armoring."
• Monitor for Anomalous Ticket Usage:
  • Look for Event ID 4768 (TGT requested) with unusual ticket lifetimes (e.g., >10 hours).
  • Monitor for Event ID 4769 (Service Ticket requested) where the account name is highly privileged and the source is unusual.
  • Use a SIEM to baseline normal Kerberos activity and alert on deviations.
  • Enable advanced auditing for Kerberos ticket events.
• Implement Just‑In‑Time Administration: With JIT, there are no standing privileged accounts. Even if an attacker forges a Golden Ticket for a user, that user may not have permanent privileged access. However, JIT does not prevent the attacker from forging tickets for built‑in privileged groups.
• Use Managed Service Accounts (MSAs) and Group MSAs: For service accounts, use gMSAs which have automatic password rotation and are managed by AD, reducing the risk of service account compromise leading to Silver Tickets.

🔗 Silver Ticket Attack – The Stealthier Cousin

What it is: A Silver Ticket is a forged Service Ticket (ST) for a specific service. Unlike a Golden Ticket (which forges a TGT), a Silver Ticket forges an ST, allowing access to a particular service (e.g., a file server, SQL server, or even a domain controller's CIFS service) without ever contacting the KDC.

Technical Deep Dive – How Silver Ticket Works:

1. Service Account Hash Extraction: The attacker needs the NTLM hash of the service account (e.g., the computer account of a file server, or a dedicated service account). This can be obtained by compromising the server itself, extracting from LSASS, or from the NTDS.dit if the account is a domain user.
2. Ticket Forgery: Using Mimikatz's kerberos::golden with the /service parameter (or dedicated tools), the attacker forges an ST for that specific service. They specify the target user, domain SID, service account hash, and service SPN (e.g., cifs/fileserver.contoso.com).
3. Service Access: The attacker presents the forged ST directly to the target service. The service decrypts the ticket using its own hash and grants access, never contacting the KDC.

Why Silver Tickets are Dangerous:

• No KDC Contact: Because the attacker never contacts the KDC, there are no corresponding Event IDs 4768 or 4769 on domain controllers. The only logs are on the target service itself (if it logs authentication).
• Persistence: As long as the service account password doesn't change, the Silver Ticket remains valid. Service account passwords (especially computer accounts) change every 30 days by default, but if the attacker has the hash, they can forge tickets until the password changes.
• Targeted Access: An attacker can forge a ticket for a specific high‑value service, like the CIFS service on a domain controller, to access the SYSVOL share and potentially extract more hashes.

Mitigations:

• Protect Service Account Hashes: Apply the same protections as for user accounts. Use Credential Guard on servers to protect LSASS.
• Use Group Managed Service Accounts (gMSAs): gMSAs have automatic, complex password rotation managed by AD. The password changes frequently, limiting the window for Silver Ticket abuse.
• Monitor Service Ticket Usage: On critical servers, enable auditing for logon events. Look for unusual access patterns or access from unexpected source IPs.
• Implement Least Privilege for Service Accounts: Ensure service accounts have only the permissions they need. A service account used for a web server should not be able to access domain controllers.
• Regularly Change Service Account Passwords: For accounts that cannot use gMSAs, implement a regular password rotation policy.

🔄 DCSync Attack – Replicating Your Way to Domain Dominance

What it is: DCSync is a technique that abuses the Directory Replication Service (DRS) Remote protocol (MS‑DRS). An attacker with appropriate privileges (by default, Domain Admins, Enterprise Admins, and Domain Controllers) can impersonate a domain controller and request replication of sensitive data, including password hashes for all users.

Technical Deep Dive – How DCSync Works:

1. Privilege Acquisition: The attacker must first gain credentials that have the necessary replication rights. This is often achieved via a Golden Ticket or by compromising a Domain Admin account.
2. Mimikatz DCSync: Using Mimikatz's lsadump::dcsync command (or tools like Impacket's secretsdump.py), the attacker specifies a target domain controller and a user account (or all users).
3. Replication Request: The tool sends a DRSGetNCChanges request to the target DC, asking for replication updates for the specified objects. The DC, believing the request comes from an authorised replicating partner, sends back the requested data, which includes password hashes (NTLM, LM if enabled, and Kerberos keys).
4. Harvesting: The attacker now has the password hashes for all users, including the KRBTGT account. They can use these for further attacks (Pass‑the‑Hash, Golden Ticket) or crack them offline.

Why DCSync is Dangerous:

• No Need to Compromise Every DC: The attacker only needs to contact one DC and have the right privileges. They don't need to be on the DC itself.
• Complete Credential Harvest: In one fell swoop, the attacker can obtain the hashes for every account in the domain.
• Difficult to Detect: Replication is a normal DC function. DCSync requests look like legitimate replication traffic, though they originate from a non‑DC source.

Comprehensive Mitigations:

• Restrict Replication Permissions: By default, only Domain Controllers, Enterprise Admins, and Domain Admins have the right to replicate. Audit these groups regularly and ensure no unnecessary accounts are members. Consider creating a dedicated security group for replication and removing these rights from built‑in groups (advanced, requires careful testing).
• Enable Advanced Auditing for Replication:
  • Monitor Event ID 4662 – "An operation was performed on an object."
  • Look for events where the object type is %{19195a5b-6da0-11d0-afd3-00c04fd930c9} (the schemaIDGUID for the Domain‑DNS object) and the access mask includes Control Access (right 100) for the control access right DS-Replication-Get-Changes (GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2).
  • Alert on any 4662 event with these attributes originating from an IP that is not a known domain controller.
• Use Protected Users and Tiering: Ensure that accounts with replication rights are in Tier 0 and protected with MFA, PAWs, and JIT.
• Monitor for DCSync Tools: Use network monitoring to detect tools like Mimikatz or Impacket communicating on RPC ports used for replication (TCP 135, 445, and dynamically assigned RPC ports). This is challenging but possible with advanced threat protection solutions.
• Deploy Advanced Threat Protection: Tools like Microsoft Defender for Identity specifically detect DCSync activity by analysing replication requests and alerting when a non‑DC makes a replication request.

📊 Kerberoasting – Attacking Service Accounts

What it is: Kerberoasting is an attack that targets service accounts. Any domain user can request a Service Ticket (ST) for any service account that has a Service Principal Name (SPN) registered. The ST is encrypted with the service account's NTLM hash. The attacker extracts the encrypted portion of the ticket and offline‑cracks it to recover the service account's password.

Technical Deep Dive – How Kerberoasting Works:

1. SPN Discovery: The attacker enumerates all accounts with SPNs using tools like Get-ADUser -Filter {ServicePrincipalName -ne "$null"} or built‑in tools like setspn -Q */*.
2. Ticket Request: The attacker requests a Service Ticket for a target service account (e.g., for the SPN MSSQLSvc/sqlserver.contoso.com) using any valid domain user account (even a low‑privileged one).
3. Ticket Extraction: The attacker receives an ST encrypted with the service account's NTLM hash. They extract the encrypted portion (the "ciphertext") using tools like Mimikatz (kerberos::list) or Rubeus (Rubeus.exe kerberoast).
4. Offline Cracking: The attacker takes the extracted hash and cracks it offline using tools like Hashcat or John the Ripper. If the service account has a weak password, it will be cracked, revealing the plaintext password.

Why Kerberoasting is Dangerous:

• Low Privilege Required: Any authenticated domain user can request service tickets.
• Offline Attack: Cracking happens offline, so there's no network noise or account lockouts.
• Service Accounts Often Have Weak Passwords: Many service accounts are manually managed with passwords that rarely change and are often set to "PasswordNeverExpires".
• Potential for Privilege Escalation: If a service account is over‑privileged (e.g., Domain Admin), cracking it gives the attacker high privileges.

Comprehensive Mitigations:

• Use Group Managed Service Accounts (gMSAs): gMSAs have complex, 120‑character random passwords that change automatically every 30 days. They are nearly impossible to crack and render Kerberoasting ineffective because the password is not known to any user.
• Use Managed Service Accounts (MSAs): For older systems, use MSAs (for single servers). They also have automatic password management.
• Strong Passwords for Service Accounts: If you must use standard user accounts as service accounts, ensure they have extremely strong, randomly generated passwords (20+ characters) and change them frequently. Use a password manager.
• Enable AES Encryption: Kerberoasting often targets RC4‑encrypted tickets because they are easier to crack. Disable RC4 and require AES for Kerberos (via Group Policy). This forces attackers to crack AES hashes, which are more difficult.
• Monitor for Unusual Service Ticket Requests:
  • Look for Event ID 4769 – A Kerberos service ticket was requested. Filter for accounts that are not typical service accounts, or for multiple requests from the same user for many different services.
  • Alert on 4769 events where the ticket encryption type is 0x17 (RC4) if you have disabled RC4.
  • Use tools like AADInternals or commercial SIEM rules to detect Kerberoasting.
• Limit SPN Registration: Only allow authorised users to register SPNs. By default, all users can register SPNs on their own accounts, but limit who can register on others.

🌙 AS‑REP Roasting – Attacking Users Without Pre‑Authentication

What it is: AS‑REP Roasting targets user accounts that have the Kerberos pre‑authentication requirement disabled. When pre‑auth is disabled, the KDC will send an AS‑REP (containing encrypted data) without first verifying the user's timestamp. An attacker can request this AS‑REP for any such user and then offline crack the encrypted portion to recover the user's password.

Technical Deep Dive – How AS‑REP Roasting Works:

1. Find Vulnerable Accounts: The attacker enumerates users with the DONT_REQ_PREAUTH flag set (userAccountControl attribute). Tools like Rubeus (Rubeus.exe asreproast) can do this.
2. Request AS‑REP: The attacker sends an AS‑REQ for one of these users without pre‑authentication data. The KDC responds with an AS‑REP that includes encrypted data (the session key encrypted with the user's password hash).
3. Extract and Crack: The attacker extracts the encrypted part and cracks it offline to recover the password.

Mitigations:

• Ensure All User Accounts Require Pre‑Authentication: This is the default in modern AD. Periodically audit for accounts that have pre‑auth disabled. Use PowerShell: Get-ADUser -Filter {userAccountControl -band 4194304} (4194304 is the DONT_REQ_PREAUTH flag).
• Use Strong Passwords: Even with pre‑auth disabled, a strong password makes cracking infeasible.
• Monitor for AS‑REP Requests: Look for Event ID 4768 (TGT requested) where pre‑authentication was not required (failure code 0x6).

🛡️ Comprehensive Attack Detection and Response Table

🔁 Attack Chain Example: From Foothold to Domain Dominance

To illustrate how these attacks are combined, here's a realistic attack chain:

1. Initial Access: Attacker phishes a user and gains access to a workstation (Tier 2).
2. Credential Harvesting: Using Mimikatz, they extract hashes from LSASS. They find a local admin hash (thanks to LAPS not being deployed).
3. Lateral Movement (PtH): They use the local admin hash to move to a file server (Tier 1).
4. Privilege Escalation: On the file server, they find a service account with SPN and weak password. They perform Kerberoasting and crack the password, revealing it's a Domain Admin account.
5. Domain Admin Access: They use the cracked Domain Admin credentials to log on to a domain controller (Tier 0).
6. Persistence (Golden Ticket): On the DC, they extract the KRBTGT hash and forge a Golden Ticket, ensuring persistent access even if the compromised accounts are cleaned.
7. Credential Harvesting (DCSync): Using DCSync, they extract all user hashes from AD, including the KRBTGT hash again, and crack high‑value target passwords.
8. Goal Achieved: The attacker now has full, persistent control over the entire domain.

Each step in this chain could have been prevented or detected with the controls discussed in this module.

6.6 Hardening & Monitoring Best Practices – The Complete Implementation Guide

🛡️ Introduction: Defence in Depth for Active Directory

Hardening Active Directory is not a single task or a one‑time project. It is an ongoing process of implementing security controls, continuously monitoring for threats, and adapting to new attack techniques. This section consolidates and expands upon all the hardening recommendations from previous sections into a comprehensive, actionable framework. We will cover not only what to implement, but how to implement it, why it matters, and how to verify its effectiveness.

The approach is based on the defence in depth principle: multiple layers of security controls ensure that if one layer fails, others still provide protection. We'll organise the recommendations into logical domains, providing detailed implementation steps, PowerShell commands, Group Policy settings, and monitoring guidance.

📋 Comprehensive Hardening Checklist – Expanded

Below is the expanded checklist with detailed implementation guidance for each item. Use the status column to track progress in your environment.

1. Domain Controllers (Tier 0) – The Crown Jewels

Domain controllers are the most critical assets in Active Directory. Compromise of a DC leads to full domain compromise. Therefore, they must be protected with the highest level of security.

• Physical Security: DCs should be in locked, access‑controlled server rooms or racks with video surveillance. For virtual DCs, ensure the hypervisor host is equally secured and that only authorised administrators have access.
• Operating System Hardening:
  • Install only the minimum required roles and features. DCs should not run file services, web servers, or any other workload.
  • Apply the latest security patches promptly. Use a patch management solution (e.g., WSUS, SCCM) with a dedicated maintenance window for DCs.
  • Enable Credential Guard on DCs (Windows Server 2016+) to protect LSASS. Use Group Policy: Computer Configuration → Administrative Templates → System → Device Guard → Turn on Virtualization Based Security. Set to "Enabled with UEFI lock" and select "Enabled with Credential Guard".
  • Enable Windows Defender Antivirus with real‑time protection and cloud‑delivered protection. Exclude AD database files (ntds.dit, logs) as per Microsoft recommendations to avoid performance issues.
  • Configure BitLocker on all drives (OS and data) to protect against physical theft. Use Group Policy to manage recovery keys and store them securely in AD.
• Network Security:
  • Place DCs on a dedicated management network segment (Tier 0 network) with strict firewall rules. Only allow necessary protocols (e.g., RPC, LDAP, Kerberos, SMB) from authorised sources (e.g., other DCs, PAWs).
  • Block all outbound internet access from DCs. They should not need to browse the web or access external resources.
  • Enable LDAP signing and LDAP channel binding to prevent LDAP relay attacks. Configure via Group Policy:
    • Network security: LDAP client signing requirements → Set to "Require signing".
    • Domain controller: LDAP server signing requirements → Set to "Require signing".
    • Domain controller: LDAP server channel binding token requirements → Set to "Always".
  • Disable NTLMv1 and enforce NTLMv2 with 128‑bit encryption (see section 6.2 for detailed steps).
  • Enable SMB signing on DCs: Microsoft network server: Digitally sign communications (always) and Microsoft network client: Digitally sign communications (always).
• Auditing and Logging:
  • Enable advanced auditing on DCs for critical categories: Account Logon, Account Management, DS Access, Logon/Logoff, and Privilege Use.
  • Forward all security logs to a central SIEM for analysis and long‑term retention.
  • Monitor specifically for events indicating DCSync attempts (4662 with replication GUID), unusual Kerberos activity (4768/4769), and changes to privileged groups.

2. Administrative Accounts – Separate, Protect, Monitor

Administrative accounts are the primary target for attackers. Implement the following controls for all admin accounts, with stricter measures for Tier 0.

• Separate Accounts (Standard vs Admin):
  • Create a policy requiring every administrator to have at least two accounts. Enforce via regular audits and technical controls (e.g., disabling admin rights on standard accounts).
  • Use a clear naming convention: e.g., first.last for standard, first.last_adm for admin, first.last_t0 for Tier 0.
  • Implement a process for requesting and approving new admin accounts, tied to HR onboarding.
• Protected Users Group:
  • Add all Tier 0 admin accounts to the Protected Users group. This enforces AES Kerberos, blocks NTLM, and disables delegation.
  • Consider adding Tier 1 and Tier 2 admins after testing. Be aware that Protected Users cannot authenticate to down‑level servers (pre‑2008 R2).
  • PowerShell: Add-ADGroupMember -Identity "Protected Users" -Members "jdoe_t0", "asmith_t0".
• Multi‑Factor Authentication (MFA):
  • Require smart card authentication for all interactive logons of Tier 0 accounts. Deploy a Public Key Infrastructure (PKI) with Active Directory Certificate Services (AD CS) and issue smart cards or virtual smart cards.
  • For Tier 1 and Tier 2, use Windows Hello for Business or integrate with a third‑party MFA solution for RDP access (e.g., Duo Security).
  • Configure Group Policy: Interactive logon: Require smart card → Enabled for admin accounts (use Group Policy filtering).
• Logon Restrictions:
  • Logon Workstations: Restrict Tier 0 admin accounts to specific PAWs. Use the userWorkstations attribute. Example: Set-ADUser jdoe_t0 -LogonWorkstations "PAW-JDOE-01,PAW-JDOE-02".
  • Logon Hours: Restrict logon hours to business hours where feasible. Use ADUC or PowerShell: Set-ADUser jdoe_t0 -LogonHours (New-Object byte[] 21) (complex, but can be scripted).
• Just‑In‑Time (JIT) Administration:
  • Implement a PAM solution (e.g., Microsoft Identity Manager PAM, Azure AD PIM, or third‑party) to grant temporary privileged access.
  • If a full PAM solution is not feasible, consider using scheduled scripts to add users to privileged groups for limited durations, with proper approval workflows.
  • Audit all JIT activations and alert on any activations outside approved hours or without approval.
• Regular Auditing of Privileged Groups:
  • Run a weekly script to list members of Domain Admins, Enterprise Admins, Schema Admins, and other sensitive groups. Compare against an approved list.
  • Alert on any unauthorised additions.
  • Use tools like Get-ADGroupMember and export to CSV for review.

3. Authentication Policies – Strengthening the First Line of Defence

• Password Policies (Fine‑Grained):
  • Create separate Password Settings Objects (PSOs) for different user tiers. For example:
    • Standard users: Minimum 12 characters, complexity enabled, history 24, max age 90 days (modern guidance suggests removing mandatory expiry, but compliance may require it).
    • Admins: Minimum 16‑20 characters, complexity enabled, history 24, max age 30‑60 days.
    • Service accounts: Minimum 20 characters, complexity enabled, history 24, no expiry (if using gMSAs, they handle their own rotation).
  • Apply PSOs using ADAC or PowerShell: Add-ADFineGrainedPasswordPolicySubject -Identity "AdminPSO" -Subjects "cn=Admins,ou=Groups,dc=contoso,dc=com".
• Account Lockout Policies:
  • Set account lockout threshold to 5‑10 invalid attempts.
  • Set lockout duration to 30‑60 minutes (or 0 for manual unlock in high‑security environments).
  • Set reset counter after 30‑60 minutes.
  • Monitor lockout events (Event ID 4740) to identify potential brute‑force attacks.
• Kerberos Policy:
  • Enforce AES encryption: Set Network security: Configure encryption types allowed for Kerberos to AES128_HMAC_SHA1 and AES256_HMAC_SHA1. Uncheck RC4 and DES.
  • Reduce ticket lifetimes: Set Maximum lifetime for service ticket to 600 minutes (10 hours) or less. Maximum lifetime for user ticket to 10 hours. Maximum lifetime for user ticket renewal to 7 days.
  • Enable Kerberos armoring (FAST) if all clients support it (Windows 8/2012+).
• NTLM Restriction:
  • Follow the phased approach in 6.2: audit → restrict → deny.
  • Use Group Policy: Network security: Restrict NTLM: Incoming NTLM traffic → start with "Deny all domain accounts" after thorough testing.
  • Monitor Event ID 8005 (NTLM rejection) to identify any broken applications.

4. Group Policy Security Settings – Hardening the OS

Group Policy is the primary tool for configuring security settings on domain‑joined machines. The following settings should be applied at appropriate levels (domain, OU).

• User Account Control (UAC):
  • User Account Control: Run all administrators in Admin Approval Mode → Enabled.
  • User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode → "Prompt for consent on the secure desktop" (or "Prompt for credentials" for higher security).
  • User Account Control: Only elevate executables that are signed and validated → Enabled (optional, may break some apps).
• Network Access and Security:
  • Network access: Do not allow anonymous enumeration of SAM accounts and shares → Enabled.
  • Network access: Restrict anonymous access to Named Pipes and Shares → Enabled.
  • Network security: Do not store LAN Manager hash value on next password change → Enabled.
  • Network security: LAN Manager authentication level → "Send NTLMv2 response only. Refuse LM & NTLM".
  • Microsoft network client: Digitally sign communications (always) → Enabled (for all domain members).
  • Microsoft network server: Digitally sign communications (always) → Enabled (especially on servers).
• Windows Firewall:
  • Enable Windows Firewall with Advanced Security via GPO for all profiles (Domain, Private, Public).
  • Create inbound rules to allow only necessary traffic (e.g., RDP from management subnets, file sharing from authorised clients).
  • Block all inbound traffic by default and create explicit allow rules.

5. Local Administrator Password Solution (LAPS) – Eliminating Shared Local Admin

LAPS is a critical control to prevent lateral movement using local admin credentials. Implement it on all workstations and servers.

• Installation and Configuration:
  1. Download LAPS from Microsoft and install on management workstations.
  2. Extend the AD schema: Run Update-LapsADSchema in an elevated PowerShell session on a DC.
  3. Delegate permissions to computer objects so that machines can update their own ms-Mcs-AdmPwd attribute. Use the Set-LapsADComputerSelfPermission cmdlet.
  4. Create a GPO to deploy the LAPS client. The GPO should be linked to OUs containing computers.
  5. Configure LAPS policy in the GPO:
     • Computer Configuration → Administrative Templates → LAPS
     • Set "Enable local admin password management" to Enabled.
     • Configure password settings: complexity, length (recommended 14+ characters), and expiration (e.g., 30 days).
  6. Delegate read access to the password attribute (ms-Mcs-AdmPwd) to authorised helpdesk groups.
  7. Test on a pilot OU before broad deployment.
• Monitoring LAPS:
  • Monitor Event ID 10003 (password successfully changed) and 10004 (password retrieval) on clients.
  • Audit access to LAPS passwords via AD auditing (enable success/failure on the ms-Mcs-AdmPwd attribute).
  • Periodically verify that all machines have a valid LAPS password (report using Get-LapsADPassword).

6. Monitoring and Auditing – Visibility is Security

You cannot defend what you cannot see. Comprehensive monitoring and auditing are essential for detecting attacks in progress and investigating incidents.

• Enable Advanced Audit Policies: Use Group Policy to configure the following audit settings (at minimum):

  Category	Subcategory	Setting
  Account Logon	Audit Kerberos Authentication Service	Success, Failure
  Account Logon	Audit Kerberos Service Ticket Operations	Success, Failure
  Account Logon	Audit Credential Validation	Success, Failure
  Account Management	Audit User Account Management	Success, Failure
  Account Management	Audit Security Group Management	Success, Failure
  Account Management	Audit Computer Account Management	Success, Failure
  DS Access	Audit Directory Service Access	Success, Failure
  DS Access	Audit Directory Service Changes	Success, Failure
  DS Access	Audit Directory Service Replication	Success, Failure
  Logon/Logoff	Audit Logon	Success, Failure
  Logon/Logoff	Audit Special Logon	Success, Failure
  Privilege Use	Audit Sensitive Privilege Use	Success, Failure

• Centralised Log Collection:
  • Deploy a SIEM (e.g., Azure Sentinel, Splunk, QRadar) and configure all domain controllers and critical servers to forward security logs.
  • Use Windows Event Forwarding (WEF) if a SIEM is not immediately available, but a SIEM is strongly recommended for correlation and alerting.
  • Retain logs for at least one year (or as required by compliance).
• Critical Event IDs to Monitor and Alert:

  Event ID	Description	Alert Condition
  4662	An operation was performed on an object.	When object type is Domain‑DNS and access includes DS‑Replication‑Get‑Changes (DCSync detection).
  4672	Special privileges assigned to new logon.	Any occurrence for a user who should not have admin privileges.
  4720	A user account was created.	Any account creation, especially outside business hours.
  4728/4732/4756	Member added to security group.	Addition to any privileged group (Domain Admins, etc.).
  4768	A Kerberos authentication ticket (TGT) was requested.	Requests for sensitive accounts from unusual sources; requests with long lifetimes.
  4769	A Kerberos service ticket was requested.	Multiple requests from same user for different SPNs (Kerberoasting).
  4776	The domain controller attempted to validate the credentials for an account.	NTLM failures for admin accounts.
  4740	A user account was locked out.	Multiple lockouts may indicate brute‑force.
  5136/5137/5141	Directory service object modified/created/deleted.	Changes to critical objects (AdminSDHolder, Domain Controllers OU).

• Threat Hunting with BloodHound:
  • Regularly run BloodHound (or its open‑source alternatives) to map attack paths in your AD. Use the collected data to identify and remediate:
    • Over‑privileged users and groups.
    • Shortest paths to Domain Admin.
    • Kerberoastable accounts with weak passwords.
    • Unconstrained delegation endpoints.
  • Integrate BloodHound into your regular security assessment cycle (e.g., quarterly).
  • Use the BloodHound-CE (Community Edition) or enterprise versions for continuous monitoring.

7. Regular Security Assessments – Staying Ahead of Attackers

• Penetration Testing:
  • Engage third‑party experts to conduct annual (or more frequent) penetration tests focused on Active Directory.
  • Ensure the test includes attempts to exploit the techniques covered in section 6.5 (PtH, Golden Ticket, Kerberoasting, etc.).
  • Remediate findings promptly and retest.
• Automated Assessment Tools:
  • PingCastle: Run PingCastle regularly (e.g., monthly) to generate an AD security report. Focus on the "Health Check" and "CART" (risk analysis). Address indicators with high risk scores.
  • Purple Knight: Another excellent free tool that provides a comprehensive security assessment and prioritised recommendations.
  • Microsoft Security Compliance Toolkit: Use the included "Policy Analyzer" to compare your GPOs against Microsoft's security baselines.
• Account and Group Cleanup:
  • Quarterly review of all user accounts: disable and remove accounts for former employees, contractors, and inactive users.
  • Review group memberships, especially nested groups. Remove users from groups they no longer need.
  • Identify and disable service accounts with weak passwords or excessive privileges. Migrate to gMSAs where possible.
• Backup and Disaster Recovery Validation:
  • Perform regular (e.g., monthly) test restores of a domain controller from backup. Verify that you can perform an authoritative restore if needed.
  • Store backups offline or in an immutable format to protect against ransomware.
  • Document and practice the procedure for recovering a domain if all DCs are lost.

8. SMB Hardening – Closing a Major Attack Vector

Server Message Block (SMB) is a common target for attackers. Proper hardening is essential.

• Disable SMBv1:
  • SMBv1 is ancient and insecure. Disable it on all systems via Group Policy (Windows Server 2012+ and Windows 8+).
  • Use PowerShell: Set-SmbServerConfiguration -EnableSMB1Protocol $false on servers, and Disable-WindowsOptionalFeature -Online -FeatureName "SMB1Protocol" on clients.
  • Monitor for any systems that still have SMBv1 enabled (vulnerability scanners can detect this).
• Enable SMB Signing:
  • SMB signing ensures integrity and prevents relay attacks. Enable it on all domain controllers and critical servers.
  • Group Policy: Microsoft network server: Digitally sign communications (always) → Enabled.
  • For clients, enable Microsoft network client: Digitally sign communications (always) to require signing for outgoing connections.
• Block SMB at Firewalls:
  • At the perimeter firewall, block outbound SMB ports (TCP 139, 445) to prevent data exfiltration and SMB relay to external hosts.
  • On internal firewalls, restrict SMB traffic to only necessary communication paths (e.g., between workstations and file servers).
• Enable SMB Encryption:
  • For Windows Server 2012+ and Windows 8+, you can require SMB encryption for specific shares or for all traffic. This provides confidentiality and integrity.
  • Use PowerShell: Set-SmbShare -Name "ShareName" -EncryptData $true.

9. DNS Security – Protecting the Locator Service

DNS is critical for AD functionality and can be attacked in various ways (e.g., DNS spoofing, cache poisoning, tunnelling).

• DNSSEC:
  • Implement DNSSEC for your Active Directory‑integrated DNS zones to ensure data integrity and authenticity.
  • This is complex to deploy but provides strong protection against DNS spoofing.
• Secure Dynamic Updates:
  • Configure all AD‑integrated zones to allow only secure dynamic updates. This ensures that only authenticated computers can register their own records.
  • In DNS Manager, right‑click zone → Properties → General → Dynamic updates → "Secure only".
• DNS Logging and Monitoring:
  • Enable DNS debug logging on domain controllers (carefully, as it can be verbose). Monitor for:
    • Queries for unusual domains (potential data exfiltration via DNS tunnelling).
    • High volumes of failed queries (possible reconnaissance).
    • Queries for known malicious domains (use threat intelligence feeds).
  • Forward DNS logs to your SIEM for correlation.
• Restrict Zone Transfers:
  • Limit zone transfers to only authorised DNS servers (typically only other domain controllers).
  • In DNS Manager, zone properties → Zone Transfers → "Only to servers listed on the Name Servers tab".

📈 Continuous Improvement – The Security Lifecycle

Security is not a destination but a continuous cycle. Establish a regular cadence for the following activities:

• Weekly: Review alerts from SIEM, check for unusual logon patterns, verify backup success.
• Monthly: Run PingCastle or Purple Knight, review privileged group memberships, audit LAPS password health.
• Quarterly: Conduct a full AD security assessment (including BloodHound), review and update security policies, perform a test restore.
• Annually: Engage external penetration testers, review and update the AD hardening checklist, provide security training to administrators.

🔁 Integrating with Incident Response

Hardening and monitoring must be integrated with your incident response (IR) plan. Ensure that:

• IR playbooks include specific steps for AD compromise scenarios (e.g., Golden Ticket, DCSync).
• The IR team has access to SIEM and can quickly query AD logs.
• There is a clear process for rotating the KRBTGT password in case of suspected compromise.
• Communication channels are established with the AD administration team for rapid response.

📊 Sample Hardening Roadmap

Here's a phased roadmap to implement these best practices in a typical environment:

7.1 Installing the Active Directory PowerShell Module

📦 What is the Active Directory PowerShell Module?

The Active Directory PowerShell module is a collection of cmdlets (pronounced "command-lets") that allow administrators to manage Active Directory objects from the PowerShell command line or scripts. It provides a powerful, scriptable interface to perform virtually any task that can be done through the GUI – and many that cannot. The module is part of the Remote Server Administration Tools (RSAT) and is available on Windows Server (with the AD DS role) and on Windows client operating systems (with RSAT installed).

🔧 Installation on Windows Server (with AD DS Role)

If the server is already a domain controller (or has the AD DS role installed), the PowerShell module is installed automatically. However, you may need to import it or ensure the feature is enabled.

Steps:

1. Open Server Manager.
2. Click Add roles and features.
3. Proceed through the wizard until you reach the Features page.
4. Expand Remote Server Administration Tools → Role Administration Tools → AD DS and AD LDS Tools.
5. Check Active Directory module for Windows PowerShell.
6. Complete the installation.

Using PowerShell to install the feature:

# Install the AD PowerShell module on a server (requires administrator privileges)
Install-WindowsFeature -Name RSAT-AD-PowerShell

# Verify installation
Get-Module -Name ActiveDirectory -ListAvailable
        

After installation, you can import the module into your current session with Import-Module ActiveDirectory. However, the module is typically auto‑loaded when you use any AD cmdlet.

💻 Installation on Windows Client (Windows 10/11)

On client operating systems, you need to install RSAT (Remote Server Administration Tools) and then enable the AD PowerShell module.

Method 1: Via Settings (Windows 10 v1809+ / Windows 11)

1. Open Settings → Apps → Optional features.
2. Click Add a feature.
3. Search for RSAT: Active Directory Domain Services and Lightweight Directory Services Tools.
4. Select it and click Install.

Method 2: Via PowerShell (as Administrator)

# For Windows 10/11 (modern versions)
Add-WindowsCapability -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0" -Online

# For older Windows 10 versions, you might need to download RSAT separately
        

After installation, the module is available. You can verify by running:

Get-Command -Module ActiveDirectory | Measure-Object
        

This should show over 100 available cmdlets.

🧪 Testing the Module

Once installed, test that the module works and can connect to your domain:

# Import the module (if not auto-loaded)
Import-Module ActiveDirectory

# Get basic domain information
Get-ADDomain

# Get a specific user (e.g., administrator)
Get-ADUser Administrator
        

If you receive errors, check that:

• You are running PowerShell as an administrator (for some operations).
• The computer is domain‑joined or you have specified alternate credentials.
• DNS resolution is working and you can reach a domain controller.

🔄 Updating the Module

The AD PowerShell module is updated with Windows updates and new RSAT versions. To ensure you have the latest version, keep your operating system updated. You can check the module version with:

Get-Module ActiveDirectory | Select-Object Version
        

🔐 Permissions Required

To use AD cmdlets effectively, your account needs appropriate permissions in Active Directory. Common requirements:

• Read operations: Most read cmdlets work for any authenticated user (unless restricted).
• Create/delete/modify users and groups: Requires delegated permissions on the target OUs, or membership in appropriate groups (e.g., Account Operators, Domain Admins).
• High‑privilege operations: Changing domain‑wide settings may require Domain Admin or Enterprise Admin rights.

When scripting, consider using -Credential parameter to specify a service account with the necessary permissions.

7.2 Creating Users via PowerShell – From Basics to Advanced

👤 The New-ADUser Cmdlet

The New-ADUser cmdlet is the primary tool for creating user objects. It has dozens of parameters to set all common user attributes. Mastering this cmdlet is essential for efficient user provisioning.

Basic User Creation

The simplest user creation requires only a few parameters:

New-ADUser -Name "John Smith" -SamAccountName "jsmith" -UserPrincipalName "jsmith@contoso.com" -GivenName "John" -Surname "Smith" -Path "OU=Users,OU=Sales,DC=contoso,DC=com" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) -Enabled $true
        

Parameter breakdown:

• -Name – The display name (also sets the CN).
• -SamAccountName – The pre‑Windows 2000 logon name (max 20 characters).
• -UserPrincipalName – The modern logon name (user@domain).
• -GivenName and -Surname – First and last name.
• -Path – The OU where the user will be created.
• -AccountPassword – A secure string representing the password. Must be converted from plaintext.
• -Enabled $true – Enables the account immediately. Without this, the account is created but disabled.

Important: Always use ConvertTo-SecureString to handle passwords securely. Avoid storing plaintext passwords in scripts.

Setting Additional Attributes

New-ADUser supports many common attributes directly as parameters:

New-ADUser -Name "Jane Doe" -SamAccountName "jdoe" -UserPrincipalName "jdoe@contoso.com" -GivenName "Jane" -Surname "Doe" -Path "OU=Users,OU=IT,DC=contoso,DC=com" -AccountPassword (ConvertTo-SecureString "P@ssw0rd456" -AsPlainText -Force) -Enabled $true -Department "IT" -Title "Network Engineer" -Company "Contoso Ltd." -Office "London" -PhoneNumber "+44 20 1234 5678" -EmailAddress "jane.doe@contoso.com" -Manager "CN=John Smith,OU=Users,OU=Sales,DC=contoso,DC=com"
        

Using Splatting for Readability

For complex user creation with many parameters, use splatting to improve readability and maintainability:

$userParams = @{
    Name = "Robert Johnson"
    SamAccountName = "rjohnson"
    UserPrincipalName = "rjohnson@contoso.com"
    GivenName = "Robert"
    Surname = "Johnson"
    Path = "OU=Users,OU=Finance,DC=contoso,DC=com"
    AccountPassword = (ConvertTo-SecureString "P@ssw0rd789" -AsPlainText -Force)
    Enabled = $true
    Department = "Finance"
    Title = "Accountant"
    Company = "Contoso Ltd."
    Office = "New York"
    PhoneNumber = "+1 212 555 1234"
    EmailAddress = "robert.johnson@contoso.com"
    Manager = "CN=Jane Doe,OU=Users,OU=IT,DC=contoso,DC=com"
    StreetAddress = "123 Main St"
    City = "New York"
    State = "NY"
    PostalCode = "10001"
    Country = "US"
}

New-ADUser @userParams
        

Creating Users with Custom Attributes

If you need to set attributes that are not directly available as parameters, use the -OtherAttributes parameter with a hashtable:

New-ADUser -Name "Alice Wonder" -SamAccountName "awonder" -UserPrincipalName "awonder@contoso.com" -Path "OU=Users,DC=contoso,DC=com" -AccountPassword (ConvertTo-SecureString "P@ssw0rdABC" -AsPlainText -Force) -Enabled $true -OtherAttributes @{
    extensionAttribute1 = "Employee123"
    employeeID = "EMP001"
    employeeNumber = "12345"
    wWWHomePage = "http://internal/employees/alice"
}
        

Setting Password and Account Options

Control account behaviour with additional parameters:

• -ChangePasswordAtLogon $true – Forces user to change password at next logon.
• -PasswordNeverExpires $true – Sets the password to never expire (use with caution).
• -CannotChangePassword $true – Prevents user from changing their own password.
• -AccountNotDelegated $true – Account is sensitive and cannot be delegated.

New-ADUser -Name "Temp User" -SamAccountName "tempuser" -UserPrincipalName "tempuser@contoso.com" -Path "OU=Users,DC=contoso,DC=com" -AccountPassword (ConvertTo-SecureString "TempP@ss" -AsPlainText -Force) -Enabled $true -ChangePasswordAtLogon $true -PasswordNeverExpires $false
        

Creating Users in Different Domains or with Alternate Credentials

Use the -Server parameter to target a specific domain controller, and -Credential to run as a different user:

$cred = Get-Credential "CONTOSO\svc_powershell"
New-ADUser -Name "Remote User" -SamAccountName "remoteuser" -UserPrincipalName "remoteuser@contoso.com" -Path "OU=Users,DC=contoso,DC=com" -AccountPassword (ConvertTo-SecureString "RemoteP@ss" -AsPlainText -Force) -Enabled $true -Server "dc02.contoso.com" -Credential $cred
        

Error Handling and Validation

When scripting user creation, always include error handling to avoid script termination on errors:

try {
    New-ADUser -Name "Test User" -SamAccountName "testuser" -UserPrincipalName "testuser@contoso.com" -Path "OU=Users,DC=contoso,DC=com" -AccountPassword (ConvertTo-SecureString "TestP@ss" -AsPlainText -Force) -Enabled $true -ErrorAction Stop
    Write-Host "User created successfully." -ForegroundColor Green
} catch {
    Write-Warning "Failed to create user: $($_.Exception.Message)"
}
        

Creating Users with Home Folders and Profile Paths

You can set home directories and profile paths during creation, but note that the actual folder creation on the file server must be handled separately (e.g., with New-Item or by a separate script).

New-ADUser -Name "User With Home" -SamAccountName "uwh" -UserPrincipalName "uwh@contoso.com" -Path "OU=Users,DC=contoso,DC=com" -AccountPassword (ConvertTo-SecureString "HomeP@ss" -AsPlainText -Force) -Enabled $true -HomeDrive "H:" -HomeDirectory "\\fileserver\homes\uwh" -ProfilePath "\\fileserver\profiles\uwh"
        

7.3 Bulk User Import via CSV – Automating Large‑Scale Provisioning

📊 The Power of CSV Import

In real‑world scenarios, you rarely create users one by one. Instead, you receive data from HR systems, spreadsheets, or other sources in CSV (Comma‑Separated Values) format. PowerShell excels at processing CSV files and creating AD users in bulk, saving countless hours and eliminating manual errors.

📁 Preparing the CSV File

A well‑structured CSV file is essential. Typically, each column corresponds to a user attribute. For example:

FirstName,LastName,SamAccountName,UPN,Department,Title,ManagerEmail,Password
John,Smith,jsmith,jsmith@contoso.com,Sales,Manager,jdoe@contoso.com,P@ssw0rd1
Jane,Doe,jdoe,jdoe@contoso.com,IT,Engineer,jsmith@contoso.com,P@ssw0rd2
Bob,Johnson,bjohnson,bjohnson@contoso.com,Finance,Accountant,jdoe@contoso.com,P@ssw0rd3
        

Tips for CSV preparation:

• Include all required attributes: at minimum, Name, SamAccountName, and UPN.
• Use friendly column names that map directly to parameters.
• Ensure passwords are handled securely – consider generating random passwords in the script instead of storing them in the CSV.
• Include a column for OU Path if users go to different OUs.

🔄 Basic Bulk Import Script

The simplest bulk import uses Import-Csv and a loop:

# Import the CSV file
$users = Import-Csv -Path "C:\scripts\newusers.csv"

# Loop through each row and create the user
foreach ($user in $users) {
    try {
        New-ADUser -Name "$($user.FirstName) $($user.LastName)" `
            -SamAccountName $user.SamAccountName `
            -UserPrincipalName $user.UPN `
            -GivenName $user.FirstName `
            -Surname $user.LastName `
            -Department $user.Department `
            -Title $user.Title `
            -Path "OU=Users,OU=$($user.Department),DC=contoso,DC=com" `
            -AccountPassword (ConvertTo-SecureString $user.Password -AsPlainText -Force) `
            -Enabled $true `
            -ChangePasswordAtLogon $true `
            -ErrorAction Stop
        
        Write-Host "Created user: $($user.SamAccountName)" -ForegroundColor Green
    } catch {
        Write-Warning "Failed to create user $($user.SamAccountName): $($_.Exception.Message)"
    }
}
        

🔐 Generating Random Passwords

Storing passwords in a CSV is insecure. A better approach is to generate random strong passwords during the import and save them to a secure file for distribution.

# Function to generate a random password
function Generate-RandomPassword {
    param(
        [int]$Length = 14
    )
    Add-Type -AssemblyName System.Web
    return [System.Web.Security.Membership]::GeneratePassword($Length, 2)
}

$users = Import-Csv -Path "C:\scripts\newusers.csv"
$passwordLog = @()

foreach ($user in $users) {
    $password = Generate-RandomPassword
    try {
        New-ADUser -Name "$($user.FirstName) $($user.LastName)" `
            -SamAccountName $user.SamAccountName `
            -UserPrincipalName "$($user.SamAccountName)@contoso.com" `
            -GivenName $user.FirstName `
            -Surname $user.LastName `
            -Department $user.Department `
            -Title $user.Title `
            -Path "OU=Users,OU=$($user.Department),DC=contoso,DC=com" `
            -AccountPassword (ConvertTo-SecureString $password -AsPlainText -Force) `
            -Enabled $true `
            -ChangePasswordAtLogon $true `
            -ErrorAction Stop
        
        # Log the password securely (this file should be protected)
        $passwordLog += [PSCustomObject]@{
            SamAccountName = $user.SamAccountName
            Password = $password
        }
        
        Write-Host "Created user: $($user.SamAccountName)" -ForegroundColor Green
    } catch {
        Write-Warning "Failed to create user $($user.SamAccountName): $($_.Exception.Message)"
    }
}

# Export password log to encrypted file (or store securely)
$passwordLog | Export-Csv -Path "C:\scripts\passwords.csv" -NoTypeInformation
        

Important: The password log must be stored securely (encrypted, restricted access) and ideally delivered to managers via a secure channel. Consider using Protect-CmsMessage for encryption.

🏢 Handling Multiple OUs

If users belong to different departments or locations, include an OU column in the CSV:

FirstName,LastName,SamAccountName,Department,OUPath
John,Smith,jsmith,Sales,"OU=Sales,OU=Users,DC=contoso,DC=com"
Jane,Doe,jdoe,IT,"OU=IT,OU=Users,DC=contoso,DC=com"
        

Then in the script:

New-ADUser -Name "$($user.FirstName) $($user.LastName)" -Path $user.OUPath ...
        

🔗 Setting Manager Relationships

If your CSV includes manager information (e.g., by SamAccountName or email), you can set the manager attribute after creation, or during creation if you have the manager's Distinguished Name.

# Assuming CSV has a "ManagerSam" column
$manager = Get-ADUser -Identity $user.ManagerSam
Set-ADUser -Identity $user.SamAccountName -Manager $manager.DistinguishedName
        

For bulk operations, it's more efficient to set manager after all users are created, using a second loop.

📈 Advanced: Adding Users to Groups

Often, new users need to be added to standard groups (e.g., "All Employees", "VPN Users"). Extend the script to handle group memberships:

# After creating the user, add to default groups
$defaultGroups = @("All Employees", "VPN Users", "Company Communications")
foreach ($group in $defaultGroups) {
    try {
        Add-ADGroupMember -Identity $group -Members $user.SamAccountName -ErrorAction Stop
        Write-Host "  Added to group: $group" -ForegroundColor Yellow
    } catch {
        Write-Warning "  Failed to add to group $group : $($_.Exception.Message)"
    }
}
        

🛡️ Error Handling and Logging

For production scripts, comprehensive logging is essential. Create a log file with success/failure details:

$logFile = "C:\scripts\user_creation_log_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
$users = Import-Csv -Path "C:\scripts\newusers.csv"

foreach ($user in $users) {
    $status = "Success"
    $message = ""
    try {
        # ... user creation code ...
    } catch {
        $status = "Failed"
        $message = $_.Exception.Message
    }
    # Write to log
    "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss'),$($user.SamAccountName),$status,$message" | Out-File -FilePath $logFile -Append
}
        

🚀 Real‑World Example: HR Integration Script

A typical HR integration script might:

1. Download a CSV from an HR system (e.g., Workday, SAP) via API or SFTP.
2. Validate the data (check for missing required fields).
3. Generate random passwords.
4. Create user accounts in the appropriate OUs.
5. Set manager relationships (by looking up manager employee ID).
6. Add users to standard groups based on department/location.
7. Create home directories on a file server.
8. Send an email to the manager with the username and password.
9. Log all actions and report on success/failure.

Such a script can be scheduled to run daily, ensuring new hires are provisioned automatically.

7.4 Querying AD Objects – Get‑ADUser, Get‑ADGroup, Get‑ADComputer

🔍 The Get‑AD* Cmdlet Family

The ability to query Active Directory efficiently is fundamental to automation, reporting, and troubleshooting. PowerShell provides a set of Get‑ cmdlets for each major object type: Get-ADUser, Get-ADGroup, Get-ADComputer, Get-ADOrganizationalUnit, and more. These cmdlets support powerful filtering, property selection, and searching across the directory.

Basic Usage – Get-ADUser

The simplest query retrieves a single user by identity:

Get-ADUser -Identity jsmith
        

By default, only a few attributes are returned. To get all attributes, use -Properties *:

Get-ADUser -Identity jsmith -Properties *
        

To get specific attributes:

Get-ADUser -Identity jsmith -Properties Department, Title, Manager, LastLogonDate
        

Filtering with the -Filter Parameter

The -Filter parameter is the most flexible way to query multiple objects. It uses a PowerShell expression language similar to the Where-Object syntax.

Common filter examples:

# All users in the Sales department
Get-ADUser -Filter "Department -eq 'Sales'"

# Users created in the last 7 days
$cutoff = (Get-Date).AddDays(-7)
Get-ADUser -Filter "Created -ge '$cutoff'"

# Users who have never logged on (LastLogonDate is null)
Get-ADUser -Filter "LastLogonDate -notlike '*'"

# Users with a specific title
Get-ADUser -Filter "Title -like '*Manager*'"

# Users in a specific OU (using SearchBase)
Get-ADUser -Filter * -SearchBase "OU=Sales,OU=Users,DC=contoso,DC=com"

# Users who are enabled
Get-ADUser -Filter "Enabled -eq 'True'"

# Users with password never expires
Get-ADUser -Filter "PasswordNeverExpires -eq 'True'" -Properties PasswordNeverExpires
        

Filter syntax notes:

• Use single quotes around string values.
• Operators: -eq, -ne, -like, -notlike, -ge, -le, -and, -or, -not.
• For boolean attributes, use 'True' or 'False' as strings.
• For dates, use a string representation that PowerShell can convert.

Using LDAP Filters

For complex queries or performance, you can use traditional LDAP filters with the -LDAPFilter parameter:

Get-ADUser -LDAPFilter "(&(objectCategory=person)(objectClass=user)(department=Sales))"
        

This is particularly useful when you need to use LDAP matching rules or when working with tools that generate LDAP filters.

Selecting Properties and Formatting Output

Use Select-Object to choose specific properties for display or export:

Get-ADUser -Filter "Department -eq 'Sales'" -Properties Department, Title, LastLogonDate | Select-Object Name, SamAccountName, Department, Title, LastLogonDate
        

For CSV export, pipe directly to Export-Csv:

Get-ADUser -Filter * -Properties Department, Title | Select-Object Name, SamAccountName, Department, Title | Export-Csv -Path "C:\reports\all_users.csv" -NoTypeInformation
        

Querying Groups – Get-ADGroup and Get-ADGroupMember

To get group information:

# Get a specific group
Get-ADGroup -Identity "Domain Admins"

# Get all groups in a specific OU
Get-ADGroup -Filter * -SearchBase "OU=Groups,DC=contoso,DC=com"

# Get group membership (recursive)
Get-ADGroupMember -Identity "Domain Admins" -Recursive

# Get group membership including nested groups as objects
Get-ADGroupMember -Identity "Sales Team" | Get-ADUser -Properties Department
        

Querying Computers – Get-ADComputer

# Get all computers in a specific OU
Get-ADComputer -Filter * -SearchBase "OU=Workstations,OU=Computers,DC=contoso,DC=com"

# Find computers with a specific operating system
Get-ADComputer -Filter "OperatingSystem -like '*Windows 10*'" -Properties OperatingSystem

# Find computers that haven't logged on in 90 days
$cutoff = (Get-Date).AddDays(-90)
Get-ADComputer -Filter "LastLogonDate -lt '$cutoff'" -Properties LastLogonDate | Select-Object Name, LastLogonDate
        

Advanced Queries with Calculated Properties

You can create calculated properties to transform data on the fly:

Get-ADUser -Filter "Enabled -eq 'True'" -Properties LastLogonDate, PasswordLastSet | Select-Object Name, SamAccountName, @{Name='LastLogon'; Expression={$_.LastLogonDate}}, @{Name='PasswordAge'; Expression={ if ($_.PasswordLastSet) { (Get-Date) - $_.PasswordLastSet } else { 'Never' } }}
        

Performance Considerations

• Avoid -Properties * if possible: Requesting all attributes generates more network traffic and slows down queries. Request only the properties you need.
• Use filtering at the source: The -Filter parameter is more efficient than retrieving all objects and then using Where-Object. The filter is processed by the domain controller.
• Page size: For very large result sets, use -ResultPageSize (default 256) to control how many objects are returned per page.
• Search scope: Use -SearchBase to limit the search to a specific OU, reducing the search space.

Exporting to Different Formats

# Export to CSV
Get-ADUser -Filter * -Properties Department | Select-Object Name, SamAccountName, Department | Export-Csv users.csv -NoTypeInformation

# Export to HTML (simple report)
Get-ADUser -Filter "Department -eq 'Sales'" -Properties Department, Title | Select-Object Name, SamAccountName, Title | ConvertTo-Html | Out-File sales_users.html

# Export to JSON (for integration with other systems)
Get-ADUser -Filter * -Properties Department | Select-Object Name, SamAccountName, Department | ConvertTo-Json | Out-File users.json
        

Using the AD Drive (AD:)

The Active Directory provider creates a PS drive AD: that lets you navigate AD like a file system. This can be useful for exploring and for simple scripts.

# Navigate to the domain root
cd AD:

# List OUs and containers
dir

# Navigate into an OU
cd "OU=Sales,DC=contoso,DC=com"

# Get user objects in the current path
dir
        

However, for scripting, the Get‑ cmdlets are generally more powerful and flexible.

7.5 Automating Group Management – Adding, Removing, and Reporting

👥 The Importance of Group Automation

Group management is one of the most frequent administrative tasks. Users join and leave teams, project memberships change, and access requirements evolve. Manual group management is error‑prone and time‑consuming. PowerShell enables you to automate group membership based on rules, schedule clean‑up tasks, and generate compliance reports.

Adding Users to Groups

The Add-ADGroupMember cmdlet adds one or more members to a group.

# Add a single user to a group
Add-ADGroupMember -Identity "Sales Team" -Members "jsmith"

# Add multiple users
Add-ADGroupMember -Identity "Sales Team" -Members "jsmith", "jdoe", "bjohnson"

# Add users from a CSV
$users = Import-Csv "C:\scripts\sales_newhires.csv"
foreach ($user in $users) {
    Add-ADGroupMember -Identity "Sales Team" -Members $user.SamAccountName
}
        

Note: The -Members parameter accepts SamAccountName, Distinguished Name, or SID. For bulk adds, using SamAccountName is convenient.

Removing Users from Groups

Use Remove-ADGroupMember similarly:

# Remove a user from a group
Remove-ADGroupMember -Identity "Sales Team" -Members "jsmith" -Confirm:$false

# Remove multiple users
Remove-ADGroupMember -Identity "Sales Team" -Members "jdoe", "bjohnson" -Confirm:$false
        

The -Confirm:$false suppresses confirmation prompts for automation.

Bulk Group Membership Operations from CSV

A common scenario is a CSV file with two columns: User and Group. You can process this to add or remove memberships.

$memberships = Import-Csv "C:\scripts\group_memberships.csv"
# CSV format: User,Group,Action (Add or Remove)

foreach ($item in $memberships) {
    try {
        if ($item.Action -eq "Add") {
            Add-ADGroupMember -Identity $item.Group -Members $item.User -ErrorAction Stop
            Write-Host "Added $($item.User) to $($item.Group)" -ForegroundColor Green
        } elseif ($item.Action -eq "Remove") {
            Remove-ADGroupMember -Identity $item.Group -Members $item.User -Confirm:$false -ErrorAction Stop
            Write-Host "Removed $($item.User) from $($item.Group)" -ForegroundColor Yellow
        }
    } catch {
        Write-Warning "Failed on $($item.User) / $($item.Group): $($_.Exception.Message)"
    }
}
        

Synchronising Group Membership with a Source of Truth

Often, you want a group's membership to exactly match a list from an external system (e.g., HR database, project management tool). The approach is to:

1. Get the current group members.
2. Get the desired members from the source.
3. Add members who are in the desired list but not in the current list.
4. Remove members who are in the current list but not in the desired list.

$groupName = "Project X Team"
$desiredMembers = @("jsmith", "jdoe", "bjohnson")  # Could come from CSV or API

# Get current members (SamAccountName only)
$currentMembers = Get-ADGroupMember -Identity $groupName | Select-Object -ExpandProperty SamAccountName

# Find members to add (in desired but not current)
$toAdd = $desiredMembers | Where-Object { $_ -notin $currentMembers }

# Find members to remove (in current but not desired)
$toRemove = $currentMembers | Where-Object { $_ -notin $desiredMembers }

# Add new members
foreach ($user in $toAdd) {
    Add-ADGroupMember -Identity $groupName -Members $user
    Write-Host "Added $user"
}

# Remove departed members
foreach ($user in $toRemove) {
    Remove-ADGroupMember -Identity $groupName -Members $user -Confirm:$false
    Write-Host "Removed $user"
}
        

Automating Group Cleanup – Stale Members

Over time, groups accumulate stale members (e.g., users who have left the company or changed roles). A scheduled script can identify and remove these.

# Find users who are disabled but still members of important groups
$disabledUsers = Get-ADUser -Filter "Enabled -eq 'False'" | Select-Object -ExpandProperty SamAccountName

$importantGroups = @("Domain Admins", "Enterprise Admins", "VPN Users")

foreach ($group in $importantGroups) {
    $members = Get-ADGroupMember -Identity $group | Select-Object -ExpandProperty SamAccountName
    $toRemove = $members | Where-Object { $_ -in $disabledUsers }
    
    foreach ($user in $toRemove) {
        Remove-ADGroupMember -Identity $group -Members $user -Confirm:$false
        Write-Host "Removed disabled user $user from $group"
    }
}
        

Reporting Group Membership

Regular reports on group membership are essential for audits and access reviews.

# Generate a report of all members of a specific group, with user details
Get-ADGroupMember -Identity "Sales Team" -Recursive | Get-ADUser -Properties Department, Title | Select-Object Name, SamAccountName, Department, Title | Export-Csv "sales_team_report.csv" -NoTypeInformation

# Report on all members of multiple groups
$groups = @("Sales Team", "IT Team", "Finance Team")
$report = @()

foreach ($group in $groups) {
    $members = Get-ADGroupMember -Identity $group -Recursive | Get-ADUser -Properties Department
    foreach ($member in $members) {
        $report += [PSCustomObject]@{
            GroupName = $group
            UserName = $member.Name
            SamAccountName = $member.SamAccountName
            Department = $member.Department
        }
    }
}

$report | Export-Csv "all_group_memberships.csv" -NoTypeInformation
        

Nested Group Management

Groups can contain other groups. Managing nested groups requires recursion.

# Get all members of a group, including nested groups (recursive)
Get-ADGroupMember -Identity "All Employees" -Recursive | Get-ADUser | Select-Object Name, SamAccountName

# Find all groups that a user is a member of (transitive)
Get-ADUser -Identity jsmith -Properties MemberOf | Select-Object -ExpandProperty MemberOf | Get-ADGroup | Select-Object Name
        

Creating Groups Automatically

You can create groups based on rules, such as all users in a department.

# Create a group for each department (if not already present)
$departments = Get-ADUser -Filter * -Properties Department | Where-Object { $_.Department } | Select-Object -ExpandProperty Department -Unique

foreach ($dept in $departments) {
    $groupName = "Department_$dept"
    # Check if group exists
    if (-not (Get-ADGroup -Filter "Name -eq '$groupName'" -ErrorAction SilentlyContinue)) {
        New-ADGroup -Name $groupName -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=contoso,DC=com" -Description "All users in $dept department"
        Write-Host "Created group $groupName"
    }
}
        

Integrating with Dynamic Groups (via Script)

While Active Directory doesn't have native dynamic groups (unlike Azure AD), you can simulate them with scheduled scripts that update group membership based on user attributes.

# Maintain a group of all users in the Sales department
$groupName = "Sales Department Users"
$salesUsers = Get-ADUser -Filter "Department -eq 'Sales'" | Select-Object -ExpandProperty SamAccountName
$currentMembers = Get-ADGroupMember -Identity $groupName | Select-Object -ExpandProperty SamAccountName

# Add new sales users
$toAdd = $salesUsers | Where-Object { $_ -notin $currentMembers }
foreach ($user in $toAdd) {
    Add-ADGroupMember -Identity $groupName -Members $user
}

# Remove non‑sales users
$toRemove = $currentMembers | Where-Object { $_ -notin $salesUsers }
foreach ($user in $toRemove) {
    Remove-ADGroupMember -Identity $groupName -Members $user -Confirm:$false
}
        

This script can be scheduled to run daily, ensuring the group always reflects the current Sales department.

Advanced: Managing Group Membership with Approval Workflow

For higher‑security groups (e.g., Domain Admins), you can implement a JIT (Just‑In‑Time) workflow using PowerShell:

1. User submits a request (e.g., via email, web form, or Teams).
2. A script processes the request, checks approval, and adds the user to the group for a limited time.
3. A scheduled job removes the user after the time expires.

This is complex but achievable with PowerShell, Exchange Web Services, and scheduled tasks.

Error Handling and Logging in Group Management Scripts

As with user creation, always include error handling and logging:

function Add-UserToGroupWithLogging {
    param(
        [string]$User,
        [string]$Group
    )
    try {
        Add-ADGroupMember -Identity $Group -Members $User -ErrorAction Stop
        Write-Log -Message "Added $User to $Group" -Level INFO
        return $true
    } catch {
        Write-Log -Message "Failed to add $User to $Group: $($_.Exception.Message)" -Level ERROR
        return $false
    }
}
        

8.1 What is Azure Active Directory (Azure AD)?

☁️ Definition and Purpose

Azure Active Directory (Azure AD) is Microsoft’s cloud‑based identity and access management service. It provides authentication and authorisation for a wide range of Microsoft cloud services, including Microsoft 365, Azure, and thousands of other SaaS applications. Unlike on‑premises Active Directory, which is a directory service for Windows domain networks, Azure AD is designed for the cloud – it is a multi‑tenant, highly available identity platform that supports modern authentication protocols such as OAuth 2.0, OpenID Connect, and SAML.

🧩 Key Features of Azure AD

• Identity as a Service (IDaaS): Azure AD provides authentication, single sign‑on (SSO), and multi‑factor authentication (MFA) for cloud applications.
• Multi‑tenant architecture: Each organisation gets a dedicated tenant (a logical container) isolated from others, yet the service is shared across tenants for scalability.
• Application integration: Thousands of pre‑integrated applications (SaaS apps like Salesforce, Dropbox, etc.) can be connected for SSO and provisioning.
• Conditional Access: Policy‑based controls that evaluate signals (user, location, device, risk) to allow or block access.
• Self‑service capabilities: Users can reset passwords, manage groups, and access applications through a portal (My Apps).
• Identity protection and governance: Azure AD Identity Protection detects risks, and Privileged Identity Management (PIM) provides just‑in‑time access.
• Device identity management: Supports Azure AD Join, Hybrid Azure AD Join, and mobile device management (MDM) integration.

🏢 Azure AD Tenants and Subscriptions

An Azure AD tenant is a dedicated instance of Azure AD that is automatically created when your organisation signs up for a Microsoft cloud service (e.g., Microsoft 365, Azure). Each tenant is associated with one or more DNS domains (e.g., contoso.com) and is isolated from other tenants. Within a tenant, you can create users, groups, and applications.

An Azure subscription is a billing and management container for Azure resources. It is trusts an Azure AD tenant for identity. In other words, the subscription uses the tenant to authenticate users who can then manage resources within that subscription. One tenant can have multiple subscriptions, and one subscription is associated with exactly one tenant.

🔐 Licensing – Azure AD Free vs Premium

Azure AD comes in several editions:

• Free: Included with Microsoft 365 or Azure subscriptions. Provides user and group management, on‑premises directory sync, basic SSO, and self‑service password change for cloud users.
• Microsoft Entra ID P1: Adds advanced features like dynamic groups, self‑service password reset (cloud and on‑premises with writeback), Conditional Access, and Microsoft Identity Manager integration.
• Microsoft Entra ID P2: Includes all P1 features plus Azure AD Identity Protection and Privileged Identity Management (PIM).

For hybrid scenarios, at least P1 is recommended to leverage features like password writeback, device writeback, and advanced Conditional Access policies.

🌐 Azure AD vs On‑Premises AD – High‑Level Comparison

While both are identity solutions, they serve different purposes:

• On‑premises AD is for managing Windows devices, servers, and applications in a corporate network. It uses Kerberos, LDAP, and NTLM.
• Azure AD is for cloud applications and services. It uses REST APIs, OAuth, SAML, and OpenID Connect. It does not have OUs, Group Policy, or domains in the traditional sense (instead, it has a flat structure with administrative units).

In a hybrid environment, you synchronise on‑premises AD with Azure AD, giving users a single identity for both on‑premises and cloud resources.

8.2 On‑Premises AD vs Azure AD – Detailed Comparison

🔍 Understanding the Differences

While both are called “Active Directory,” they are fundamentally different products designed for different environments. This section provides a detailed comparison to help you understand when to use each and how they complement each other in a hybrid setup.

📊 Feature Comparison Table

🔗 When to Use Each

• Use On‑Premises AD when:
  • You have Windows servers and workstations that need to be domain‑joined and managed via Group Policy.
  • You run applications that require Kerberos or LDAP authentication.
  • You need to manage resources in a corporate network with complex OU structures.
• Use Azure AD when:
  • You need to provide access to cloud applications (Microsoft 365, SaaS apps).
  • You want modern authentication with MFA and Conditional Access.
  • You need to manage identities for users who primarily use cloud resources.

🔄 The Hybrid Approach

Most organisations today use a hybrid model: they maintain on‑premises AD for internal resources and synchronise identities to Azure AD for cloud access. This gives users a single identity (same username/password) for both worlds, while leveraging the strengths of each platform.

In a hybrid environment, you use Azure AD Connect to synchronise user and group objects from on‑premises AD to Azure AD. You can also enable password hash sync or pass‑through authentication so that users use the same password for cloud services. Additionally, you can configure seamless SSO to automatically sign users in when they are on corporate devices.

8.3 Azure AD Connect – The Bridge Between On‑Prem and Cloud

🔗 What is Azure AD Connect?

Azure AD Connect is Microsoft’s tool for synchronising on‑premises directories (Active Directory) with Azure AD. It is the essential component for hybrid identity. It handles identity synchronisation, optional password hash sync, pass‑through authentication, and federation configuration. Azure AD Connect replaces older sync tools like DirSync and Azure AD Sync.

⚙️ Installation and Configuration

Azure AD Connect is installed on a dedicated Windows server (could be a domain‑joined server, not necessarily a DC). The installation wizard guides you through:

1. Selecting sync options: Choose between Express Settings (for single AD forest) or Custom Settings.
2. Connecting to Azure AD: Provide global admin credentials for your Azure AD tenant.
3. Connecting to on‑premises AD: Provide enterprise admin credentials for your on‑premises AD.
4. Configuring domain/OU filtering: Choose which domains and OUs to synchronise.
5. Identifying users uniquely: Select the source anchor (usually objectGUID) and user principal name (UPN) attribute.
6. Optional features: Enable password hash sync, pass‑through authentication, federation, seamless SSO, device writeback, etc.
7. Configure sync: Choose whether to start synchronisation immediately.

The sync engine runs every 30 minutes by default, replicating changes from on‑prem AD to Azure AD.

🔄 Synchronisation Scenarios

Azure AD Connect supports three main authentication methods for cloud access:

• Password Hash Synchronization (PHS): Hashes of user passwords are synchronised from on‑prem AD to Azure AD. Users use the same password for cloud services, and Azure AD performs the authentication. This is the simplest to set up and provides fallback for other methods. It also enables leaked credential detection.
• Pass‑Through Authentication (PTA): Password validation is done directly by an on‑premises agent. The password hash never leaves the on‑premises environment. Suitable for organisations with security policies that forbid password hashes in the cloud. Requires installing an agent on one or more servers.
• Federation (with AD FS): Authentication is delegated to an on‑premises federation service (e.g., Active Directory Federation Services). This is the most complex but allows for advanced claims, smart card authentication, and integration with third‑party identity providers.

You can also combine PHS as a backup for PTA or federation.

🛡️ Password Writeback

When enabled, password writeback allows users to change or reset their passwords in the cloud (e.g., via Azure AD SSPR) and have the new password written back to on‑premises AD. This requires Azure AD Premium P1 or P2 and specific permissions. It is a critical feature for a unified self‑service experience.

📁 Device Writeback

Device writeback enables devices registered in Azure AD (via Azure AD Join or Hybrid Join) to be written back to on‑premises AD for conditional access scenarios. This is useful for on‑premises applications that need device‑aware authentication.

🔍 Filtering and Attribute Mapping

You can control which objects are synchronised using:

• Domain/OU filtering: Select specific OUs to sync.
• Attribute filtering: Use rules to filter based on user attributes (e.g., sync only users with a specific department).
• Group filtering: Sync only members of specific groups (less common).

Azure AD Connect also provides a rich attribute mapping editor, allowing you to customise how on‑prem attributes map to Azure AD attributes. This is done through the Synchronization Rules Editor.

🧪 Staging Server and Disaster Recovery

It is recommended to deploy a staging server – a separate Azure AD Connect server that is configured in staging mode. This server imports the same sync configuration but does not export changes to Azure AD. It can be used to preview changes, test configuration updates, and quickly take over if the primary server fails.

📈 Monitoring and Health

Use the Azure AD Connect Health portal to monitor sync health, view alerts, and gain insights into sync performance. It provides a dashboard for sync errors, authentication health (for PTA and AD FS), and performance metrics. Install the Health agents on your sync server and, if using AD FS, on your federation servers.

8.4 Single Sign‑On (SSO) – Seamless Authentication

🔑 What is Single Sign‑On?

Single Sign‑On (SSO) allows users to sign in once with a single set of credentials and access multiple applications without being prompted again. In a hybrid context, SSO means that when a user is signed into their domain‑joined computer, they are automatically signed into Azure AD and connected cloud applications without re‑entering their password.

🔄 How SSO Works in Hybrid Scenarios

Azure AD provides Seamless SSO (also called Seamless Single Sign‑On). When enabled, it automatically signs users in when they are on a corporate device connected to the corporate network. It works with both Password Hash Sync and Pass‑Through Authentication.

Technical Flow:

1. User accesses a cloud application (e.g., outlook.office.com) from a domain‑joined device.
2. Azure AD attempts to authenticate the user. It sends a challenge to the device asking for Kerberos authentication.
3. The device, being domain‑joined, has a Kerberos ticket for the AZUREADSSO computer account (a special account created in on‑prem AD).
4. The device responds with the Kerberos ticket, which is validated by Azure AD (via a connection to on‑prem DCs).
5. If successful, the user is signed in without a password prompt.

This entire process is transparent to the user – they get a seamless experience.

⚙️ Enabling Seamless SSO

Seamless SSO is enabled during Azure AD Connect configuration (or can be enabled later). The steps:

1. In Azure AD Connect, select the “Enable single sign‑on” option during custom installation.
2. Azure AD Connect creates a computer account named AZUREADSSO in the on‑premises AD domain (in the same container as domain controllers). This account represents Azure AD in the on‑prem environment.
3. The Kerberos decryption key for this account is securely shared with Azure AD.
4. You must ensure that the AZUREADSSO account’s password is managed – it should be updated regularly (Azure AD Connect can do this automatically).
5. On clients, the Intranet zone settings in Internet Explorer/Edge must include the Azure AD URLs (e.g., https://autologon.microsoftazuread-sso.com). This is usually done via Group Policy.

📋 Group Policy Settings for Seamless SSO

To ensure clients send Kerberos tickets to Azure AD, you need to add the following URLs to the Local Intranet zone:

• https://autologon.microsoftazuread-sso.com
• https://aadg.windows.net.nsatc.net (for some Microsoft apps)

This is done via Group Policy: User Configuration → Preferences → Windows Settings → Registry or via Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page → Site to Zone Assignment List.

Additionally, ensure that the “Allow updates to status bar via script” setting is enabled.

🔐 Security Considerations

• The AZUREADSSO computer account’s password should be rotated regularly (Azure AD Connect does this automatically every 30 days).
• Seamless SSO only works for users who are in scope for synchronisation and have Kerberos tickets.
• It does not work for non‑domain‑joined devices (e.g., personal devices, mobile). Those users will be prompted for password (or use other methods like WHfB).
• If an attacker gains access to the AZUREADSSO account, they could potentially impersonate users. Hence, protect it like a Tier 0 asset.

🌍 Other SSO Options

• Federation (AD FS): Provides SSO with more flexibility, such as support for smart cards and complex claims. Users authenticate to AD FS, which then issues SAML tokens for Azure AD.
• Third‑party IdP integration: Azure AD supports federation with non‑Microsoft identity providers (e.g., Okta, Ping) via SAML.
• Primary Refresh Token (PRT): On Windows 10/11 devices that are Azure AD joined or hybrid joined, a PRT is issued, enabling SSO across applications.

8.5 Designing a Hybrid Identity Architecture

🏗️ Introduction to Hybrid Identity Design

Designing a hybrid identity architecture involves making strategic decisions about how on‑premises AD and Azure AD will work together. The goal is to provide a seamless, secure, and manageable identity experience for users, whether they are accessing on‑premises resources or cloud applications. This section covers the key design considerations, scenarios, and best practices.

🎯 Key Design Decisions

When designing a hybrid identity solution, you need to answer several questions:

• Authentication method: Password hash sync, pass‑through authentication, or federation? (See comparison below.)
• User experience: Will you enable seamless SSO? Self‑service password reset with writeback?
• Device strategy: Will devices be Azure AD joined, hybrid joined, or both?
• Application requirements: Do you have on‑premises apps that need modern authentication? (Azure AD App Proxy may be needed.)
• Compliance and security: Are there regulations that restrict where password hashes can be stored?
• Identity governance: Will you use Azure AD PIM, access reviews, and entitlement management?

🔍 Comparison of Authentication Methods

🖥️ Device Identity Options

In a hybrid environment, you can register devices in Azure AD to enable conditional access based on device state. Two main options:

• Azure AD Join: Devices are joined directly to Azure AD, not to on‑prem AD. Suitable for cloud‑native organisations or devices that don't need on‑prem resources.
• Hybrid Azure AD Join: Devices are joined to on‑prem AD and also registered in Azure AD. This gives you single sign‑on to both on‑prem and cloud resources. It’s the most common choice for existing on‑prem environments.

Hybrid Azure AD Join requires Azure AD Connect to synchronise computer objects and a configuration that allows devices to auto‑register. This is typically done via Group Policy or an AD FS claim rule.

🔄 Synchronisation Scope and Filtering

You don’t have to synchronise all objects to Azure AD. Common filtering strategies:

• Sync all users and groups: Simplest, but may synchronise unnecessary objects.
• Sync only users with a license: Filter based on an attribute (e.g., extensionAttribute) that indicates cloud licensing.
• Sync only specific OUs: Exclude OUs containing service accounts or legacy users.

Use Azure AD Connect’s filtering options to implement these strategies. Remember that groups synchronised can contain members from filtered‑out OUs; careful planning is needed.

🏛️ Identity Governance and Security

Hybrid identity opens up advanced governance capabilities:

• Privileged Identity Management (PIM): Enable just‑in‑time access to Azure AD roles and Azure resources.
• Conditional Access: Create policies that require MFA, compliant devices, or trusted locations for access to cloud apps.
• Access Reviews: Periodically review group memberships and app assignments to ensure least privilege.
• Identity Protection: Detect and remediate risks like leaked credentials or anomalous sign‑ins.

📈 Sample Hybrid Architecture Scenarios

Scenario A: Small to Medium Business (SMB) – Simple and Cost‑Effective

• Single on‑prem AD forest.
• Azure AD Connect with Password Hash Sync and Seamless SSO.
• Azure AD Premium P1 licenses for Conditional Access and password writeback.
• Hybrid Azure AD Join for all workstations (via GPO).
• Intune for device management (optional).

Scenario B: Large Enterprise with Security Constraints – No Hashes in Cloud

• Azure AD Connect with Pass‑Through Authentication (with multiple agents for HA).
• Seamless SSO enabled.
• Password Hash Sync also enabled as a backup (if allowed).
• Federation (AD FS) may be used if existing, but PTA is simpler.
• Strict Conditional Access policies requiring MFA and compliant devices.

Scenario C: Highly Regulated with Smart Cards and Claims

• Azure AD Connect with federation to AD FS.
• AD FS farm with smart card authentication.
• Custom claims rules to pass on‑prem attributes to Azure AD.
• Azure AD Premium P2 for PIM and Identity Protection.

🔁 Migration Strategies – Moving from On‑Prem Only to Hybrid

A phased migration is recommended:

1. Assessment: Inventory on‑prem AD, identify sync scope, choose authentication method.
2. Pilot: Deploy Azure AD Connect in staging mode, test with a small set of users.
3. Rollout: Enable sync for all users, configure seamless SSO and writeback.
4. Device Registration: Implement Hybrid Azure AD Join via GPO.
5. Conditional Access: Gradually introduce policies.
6. Optimise: Enable PIM, access reviews, and identity protection.

📋 Best Practices Summary

• Always deploy at least two Azure AD Connect servers (primary + staging).
• Monitor sync health using Azure AD Connect Health.
• Keep the AZUREADSSO account secure; let Azure AD Connect manage its password.
• Use a dedicated service account for sync with minimal privileges.
• Test changes in staging mode before applying to production.
• Plan for disaster recovery – know how to force a sync server takeover.
• Regularly review sync errors and resolve them.
• Combine PHS with PTA for redundancy (if feasible).
• Educate users about self‑service password reset.

9.1 Active Directory Database (NTDS.DIT) Internals

🗄️ What is NTDS.DIT?

The NTDS.DIT (NT Directory Services Directory Information Tree) file is the heart of Active Directory. It is a database file that stores all directory data – users, groups, computers, passwords, and schema information. Every domain controller has its own copy of the NTDS.DIT for its domain, plus forest‑wide data (configuration and schema). The file is located in %SystemRoot%\NTDS\ by default.

⚙️ The Extensible Storage Engine (ESE)

NTDS.DIT is built on the Extensible Storage Engine (ESE) (also known as Jet Blue), the same database technology used in Exchange Server. ESE is an indexed, embedded database engine that provides high‑performance, transactional data storage. It uses a B‑tree (balanced tree) structure for indexes and stores data in 8 KB pages.

Key ESE concepts:

• Pages: The fundamental unit of storage (8 KB). Database contents are stored across many pages.
• Tables: Logical groupings of data. AD uses several tables: datatable (object data), sd_table (security descriptors), link_table (linked attributes), etc.
• Indexes: B‑tree structures that allow fast lookup by attribute (e.g., index on objectGUID, cn).
• Transaction logs: All changes are first written to a log file (edb.log, edb00001.log, ...) before being committed to the database. This ensures consistency and enables recovery.
• Checkpoint: A file (edb.chk) that tracks which log entries have been written to the database.

📁 Database Structure

The NTDS.DIT file contains multiple internal tables:

• MSysObjects: System table tracking all tables and indexes.
• MSysLocales: Locale information.
• MSysDefrag: Used for online defragmentation.
• datatable: Stores most directory objects. Each row is an object, and columns represent attributes. Not all attributes are stored in the datatable – some are stored in separate tables (e.g., security descriptors).
• sd_table: Stores security descriptors (ACLs) for objects, de‑duplicated to save space.
• link_table: Stores linked attributes (e.g., group memberships, manager‑directReports).

Attributes themselves are stored using various data types: strings, integers, binary large objects (BLOBs), and multi‑valued attributes. The schema defines which attributes are present and their characteristics.

✍️ How Data is Written and Updated

ESE follows a write‑ahead logging protocol:

1. A transaction begins (e.g., updating a user’s phone number).
2. The changes are recorded in the transaction log file (edb.log).
3. The log is forced to disk to ensure durability.
4. The database is updated in memory and later (asynchronously) written to the main database file (ntds.dit).
5. The checkpoint advances, indicating that all log entries up to a certain point have been flushed.

This design provides high performance (writes are sequential to logs) and ensures that even if the server crashes, logs can be replayed to bring the database to a consistent state.

🔄 Log File Management and Circular Logging

By default, AD uses circular logging. This means that after log files are no longer needed (their data has been checkpointed and they are not required for backup or recovery), they are overwritten. This keeps disk usage low but means you cannot perform point‑in‑time recovery from logs alone – you rely on backups.

If you need to support log shipping or advanced recovery, you can disable circular logging (not recommended for AD). The log files are located in the same folder as the database (%SystemRoot%\NTDS) and are named edb.log, edb00001.log, etc.

📏 Database Size and Growth

The size of NTDS.DIT depends on the number of objects, the number of attributes populated, and the size of security descriptors. A typical enterprise with 50,000 users might have a database size of 1‑2 GB. Very large environments (500,000+ objects) can see databases of 10‑20 GB or more. The database automatically grows as needed, but it never shrinks automatically. You must perform an offline defragmentation (see 9.3) to reclaim unused space.

🛡️ Database Security

The NTDS.DIT file is highly sensitive – it contains password hashes and other secrets. By default, only the SYSTEM account and administrators have access. It is encrypted with Boot Key (also stored in the registry) to protect against offline attacks. However, an attacker with physical access to the server could still potentially extract data. Hence, BitLocker and physical security are essential.

9.2 Tombstone Lifecycle & Active Directory Recycle Bin

⚰️ What are Tombstones?

When an object is deleted in Active Directory, it is not immediately removed from the database. Instead, it is converted into a tombstone – a special placeholder that retains a subset of the object’s attributes (e.g., objectGUID, objectSID, last known parent). This allows replication partners to learn about the deletion and propagate it, and also allows for authoritative restore scenarios. After a configurable period, the tombstone is permanently removed by the garbage collection process.

⏱️ Tombstone Lifetime (TSL)

The default tombstone lifetime is 180 days for domains created with Windows Server 2003 SP1 and later. This value determines how long a tombstone remains in the database before being permanently removed. It is critical for disaster recovery: if a domain controller is offline longer than the TSL, it will be out of sync and must be forcibly demoted.

You can view the tombstone lifetime in the configuration partition:

Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com" -Properties tombstoneLifetime
        

A value of 0 means the default (180 days) is used. You can adjust it (not recommended unless necessary) using ADSI Edit or PowerShell.

🗑️ How Tombstones Work

1. User or administrator deletes an object (e.g., a user).
2. The object’s isDeleted attribute is set to TRUE.
3. Most attributes are stripped (only a few are retained: objectGUID, objectSid, distinguishedName (with \0ADEL: prefix), lastKnownParent, etc.).
4. The tombstone is replicated to all other DCs, informing them of the deletion.
5. After the tombstone lifetime expires, the garbage collection process removes the tombstone from the database.

♻️ Active Directory Recycle Bin

Introduced in Windows Server 2008 R2, the Active Directory Recycle Bin provides a way to restore deleted objects without restoring from backup. When enabled, deleted objects are preserved in a “deleted objects” container, and most attributes are retained, allowing a full restore.

How it works:

• When an object is deleted, it is moved to the “Deleted Objects” container (a special container visible when you enable “Advanced Features” in ADUC).
• The object retains nearly all its attributes (unlike a tombstone).
• The object enters a “deleted” state but can be restored with the Restore-ADObject PowerShell cmdlet or via ADAC.
• After the tombstone lifetime, the object is transitioned to a “recycled” state and eventually removed.

Enabling the Recycle Bin:

# Enable the Recycle Bin (requires Schema Admin and Enterprise Admin)
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"
        

This change is irreversible. Once enabled, you cannot disable it. It raises the forest functional level to Windows Server 2008 R2 or higher.

Restoring a deleted object:

# Find deleted objects
Get-ADObject -Filter "Deleted -eq 'True' -and Name -eq 'jsmith'" -IncludeDeletedObjects

# Restore the object
Get-ADObject -Identity "CN=jsmith\0ADEL:abcdef12-3456-7890-abcd-ef1234567890,CN=Deleted Objects,DC=contoso,DC=com" -IncludeDeletedObjects | Restore-ADObject
        

📋 Best Practices

• Enable the Active Directory Recycle Bin on all forests – it's a lifesaver for accidental deletions.
• Never set tombstone lifetime lower than the longest expected offline period for a DC (e.g., if you have remote offices with poor connectivity, keep it at 180 days).
• Monitor for lingering objects (objects that have been deleted on one DC but not replicated due to offline DC) using repadmin /removelingeringobjects.

9.3 Offline Maintenance: NTDSUtil & Database Defragmentation

🛠️ What is NTDSUtil?

NTDSUtil is a command‑line tool that provides management capabilities for Active Directory databases. It is the primary tool for offline maintenance tasks such as database defragmentation, integrity checks, moving database files, and authoritative restores. NTDSUtil must be run locally on a domain controller (or from an administrative workstation with RSAT, but offline operations require the DC to be stopped).

🧹 Offline Defragmentation (Compaction)

Over time, the AD database can become fragmented and contain unused space. This happens due to object deletions and modifications. An offline defrag (also called compaction) rebuilds the database file, reclaiming space and optimizing performance. It does not reorganize data for faster access – it simply creates a new, compacted database file.

Steps to perform offline defragmentation:

1. Log on to the domain controller with administrative privileges.
2. Open an elevated command prompt.
3. Stop the Active Directory Domain Services: net stop ntds (or use Services.msc).
4. Start NTDSUtil: type ntdsutil and press Enter.
5. At the ntdsutil: prompt, type activate instance ntds (if you have multiple instances; otherwise skip).
6. Type files to enter the file management menu.
7. Type info to see current database paths and sizes.
8. Type compact to C:\temp\ntds (or any path with enough free space – at least 110% of current database size). This creates a compacted copy.
9. After compaction completes, type quit twice to exit NTDSUtil.
10. Replace the original database file with the compacted one. The default paths are:
    • Database: C:\Windows\NTDS\ntds.dit
    • Logs: C:\Windows\NTDS\ (you may need to move logs separately, but usually you just replace the database).
    Copy the compacted file over the original: copy C:\temp\ntds\ntds.dit C:\Windows\NTDS\ntds.dit.
11. Restart AD DS: net start ntds.

Note: After compaction, you may also need to move the log files if they were in a different location. Typically, the logs are left untouched.

🔍 Integrity Checks

NTDSUtil can also perform a semantic database analysis to check for corruption. This is useful after a suspected corruption or before a major upgrade.

# In NTDSUtil (after activating instance)
semantic database analysis
go
        

This runs a series of checks and reports any errors. It does not fix errors – it only reports them. To fix, you may need to restore from backup or perform an authoritative restore.

📂 Moving Database and Log Files

If you need to move the database or logs to another drive (e.g., for performance or space reasons), use NTDSUtil:

# At ntdsutil prompt
files
move db to D:\NTDS
move logs to E:\NTDSLogs
        

These commands require AD DS to be stopped.

🔄 Recovery Mode Operations

NTDSUtil is also used for authoritative restores (covered in 9.5) and for resetting the Directory Services Restore Mode (DSRM) password:

# Reset DSRM password
ntdsutil
set dsrm password
reset password on server null
        

📈 Best Practices for Offline Maintenance

• Perform offline defragmentation only when necessary (e.g., after large object deletions, before major upgrades).
• Always have a current backup before any offline maintenance.
• Plan maintenance during off‑peak hours.
• Consider performing online defragmentation (which runs continuously) as a background process – it reclaims space but does not compact the file.
• Monitor event logs for ESE errors (Event ID 474, 475, etc.) that indicate database problems.

9.4 Backup & Disaster Recovery Strategies

💾 Why AD Backup is Critical

Active Directory is the identity store for your entire organisation. If AD is lost, access to all resources is lost. A proper backup and disaster recovery (DR) strategy ensures that you can restore AD functionality in case of accidental deletion, corruption, hardware failure, or ransomware attack. AD backup is not optional – it is a fundamental requirement for business continuity.

🛡️ What to Back Up

• System State: On a domain controller, the system state includes the AD database (NTDS.DIT), SYSVOL, registry, boot files, COM+ class registration database, and other critical components. This is the minimum required to restore AD.
• Full Server Backup: Backing up the entire server (system state plus data drives) is recommended for bare‑metal recovery.
• Back up at least one DC per domain. Ideally, back up all DCs, but at minimum, ensure you have a recent backup of one DC per domain.

📦 Backup Tools

• Windows Server Backup (WSB): Built‑in feature that can back up system state and volumes. It supports scheduled backups to local disks, network shares, or removable media. It is free and simple, but has limitations (e.g., no cloud backup).
• Microsoft Azure Backup: Extends on‑premises backups to the cloud using the Microsoft Azure Recovery Services (MARS) agent. Supports system state backup for DCs.
• Third‑party tools: Veeam, Commvault, Backup Exec, etc., offer advanced features like application‑aware backups, granular restore, and offsite replication.

Using Windows Server Backup for System State:

# Install Windows Server Backup (if not already)
Install-WindowsFeature -Name Windows-Server-Backup

# Perform a one‑time system state backup to a network share
wbadmin start systemstatebackup -backupTarget:\\backupserver\share -quiet
        

🔄 Backup Frequency and Retention

• Frequency: At least daily backups. In dynamic environments, consider more frequent backups (e.g., every 6 hours).
• Retention: Keep at least 30 days of backups, or longer based on compliance requirements. Use grandfather‑father‑son retention policies.
• Offsite storage: Store copies offsite (e.g., in Azure, another datacenter) to protect against site‑wide disasters.

🧪 Testing Backups

A backup is only as good as its ability to be restored. Regularly test your backups by performing test restores in a lab environment. Verify that:

• You can restore system state to an alternate location.
• The restored AD is functional and can replicate.
• You can perform authoritative restores if needed.

🚨 Disaster Recovery Scenarios

• Single DC failure: If one DC fails, you can simply rebuild it (clean install, promote new DC). No restore needed if other DCs exist.
• All DCs in a domain lost: You must restore from backup (authoritative or non‑authoritative) on a DC, then bring up additional DCs via promotion.
• Accidental deletion of objects: Use the Recycle Bin (if enabled) or perform an authoritative restore.
• Database corruption: Restore from a known good backup.
• Ransomware attack: Isolate infected systems, restore from clean backups, and rebuild DCs.

📋 Best Practices Summary

• Back up at least one DC per domain daily.
• Store backups on a different server or in the cloud.
• Test restores quarterly.
• Document recovery procedures step by step.
• Include AD recovery in your overall disaster recovery plan.
• Consider using a dedicated backup service account with appropriate permissions.

9.5 Authoritative vs Non‑Authoritative Restore

🔄 Understanding Restore Types

When you restore Active Directory from backup, you have two choices: non‑authoritative (the default) or authoritative. The difference lies in how the restored data is treated during replication.

• Non‑authoritative restore: The restored DC receives updates from other DCs after restoration. Any changes that occurred after the backup will be replicated back to the restored DC, bringing it up to date. This is used when you are recovering a single DC that has failed, and other DCs are healthy.
• Authoritative restore: The restored data is marked as the authoritative version. When replication occurs, the restored data overwrites the data on other DCs. This is used to undo accidental deletions or changes (e.g., someone deleted a whole OU).

🛠️ Performing a Non‑Authoritative Restore

Non‑authoritative restore is the default restore mode. Steps (using Windows Server Backup):

1. Boot the DC into Directory Services Restore Mode (DSRM). This is a special mode where AD is offline. You can enter DSRM by pressing F8 during boot or by configuring boot options.
2. Log in with the DSRM local administrator account (password set during DC promotion).
3. Open an elevated command prompt.
4. Run wbadmin get versions to list available backups.
5. Restore system state: wbadmin start systemstaterecovery -version:MM/DD/YYYY-HH:MM -backupTarget:\\server\share
6. After restore completes, reboot normally. The DC will start AD DS and replicate with other DCs to catch up.

🔁 Performing an Authoritative Restore

Authoritative restore requires using NTDSUtil after a non‑authoritative restore, to mark specific objects as authoritative.

1. Follow steps 1‑5 above to perform a non‑authoritative restore of system state.
2. After the restore, do not reboot (or reboot into DSRM again). You must be in DSRM.
3. Run ntdsutil at a command prompt.
4. Type authoritative restore to enter the authoritative restore menu.
5. To restore an entire subtree (e.g., an OU), use: restore subtree "OU=Sales,DC=contoso,DC=com"
6. To restore a single object: restore object "CN=John Smith,OU=Sales,DC=contoso,DC=com"
7. NTDSUtil will ask for confirmation and then update the object’s version number to be higher than on other DCs.
8. Type quit twice to exit.
9. Reboot normally. The restored objects will replicate to other DCs as authoritative.

Important: Authoritative restore increments the uSNChanged of the restored objects, making them newer than any existing copies. After replication, the authoritative objects overwrite others. Be careful – if you restore an entire domain, you can cause divergence.

🆚 When to Use Each

⚠️ Caveats and Considerations

• Authoritative restore increments update sequence numbers; if you restore a large subtree, replication traffic may spike.
• If you accidentally restore objects that were legitimately deleted, you may reintroduce them. Ensure you are certain about what you are restoring.
• The Recycle Bin is often a better choice for accidental deletions (it’s simpler and doesn’t require a restore from backup).

9.6 Managing Schema Extensions

📜 What is the Active Directory Schema?

The schema defines the structure of all objects and attributes in Active Directory. It is a forest‑wide database stored in the Schema partition. Every object class (e.g., user, group) and attribute (e.g., telephoneNumber) is defined in the schema. Applications like Exchange, Skype for Business, and third‑party software may extend the schema to add new classes or attributes they need.

🔧 Schema Master FSMO Role

Schema modifications can only be performed on the Schema Master (one per forest). This FSMO role holder is authoritative for all schema changes. To extend the schema, you must have Schema Admin privileges and be connected to the Schema Master.

➕ Extending the Schema

Schema extensions are typically performed using:

• LDIFDE: Import an LDIF file containing schema modifications. This is common for Exchange and other Microsoft products.
• Scripts (e.g., PowerShell with AD module): Using Set-ADObject to modify schema objects (advanced).
• Built‑in installation programs: Many products include schema extension as part of their setup (e.g., Exchange prepares the schema automatically).

Example: Extending schema for Exchange 2019

Microsoft provides an LDIF file (SchemaUpdate.ldf) that must be imported using LDIFDE:

# Run on Schema Master with Schema Admin rights
ldifde -i -f SchemaUpdate.ldf -c DC=X DC=contoso,DC=com
        

The -c parameter replaces the placeholder DC with your actual domain distinguished name.

🛡️ Permissions Required

• Membership in the Schema Admins group (forest‑wide).
• Access to the Schema Master DC.
• Often Enterprise Admin rights may also be needed to modify certain schema objects.

📋 Best Practices for Schema Extensions

• Test first: Always test schema extensions in a lab environment that mirrors production.
• Document: Keep a record of all schema extensions, including when and why they were applied.
• Back up: Take a full system state backup of the Schema Master before extending.
• Plan maintenance windows: Schema changes replicate forest‑wide and may cause temporary performance impacts.
• Use the vendor’s recommended method: Follow instructions carefully; some extensions require specific preparation (e.g., raising functional levels).
• Limit Schema Admins: Keep the Schema Admins group empty except when performing extensions. Add members only temporarily.

🚫 Removing Schema Extensions

Schema extensions are permanent. Once a class or attribute is added, it cannot be removed (only deactivated). Deactivation makes it unavailable for new objects but does not remove existing data. To deactivate, you must use ADSI Edit to mark the attribute as defunct. This is risky and should only be done if absolutely necessary, and after consulting Microsoft support.

📊 Monitoring Schema Changes

Enable auditing for directory service changes. Look for Event ID 5136 (a directory service object was modified) on the Schema Master. Monitor for unexpected schema modifications, which could indicate compromise.

9.7 Time Synchronization (W32Time)

⏰ Why Time Sync Matters

Kerberos authentication relies on time stamps to prevent replay attacks. By default, Kerberos requires that client and server times be within 5 minutes of each other. If clocks drift beyond this, authentication fails. Therefore, accurate time synchronization across all domain members is critical.

📊 Time Hierarchy in Active Directory

Windows time synchronization follows a hierarchical model:

1. Forest root PDC emulator: The authoritative time source for the entire forest. It should be configured to sync with an external reliable time source (e.g., a hardware clock, NIST, pool.ntp.org).
2. Other domain controllers: Sync with the forest root PDC (or with other DCs in the same site).
3. Domain members (servers and workstations): Sync with any DC in their domain (usually the one that authenticated them).

This hierarchy ensures that all systems have a consistent time.

⚙️ Configuring the PDC Emulator

To configure the PDC emulator to sync with an external NTP source:

# On the PDC emulator, run as administrator
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync
        

For higher accuracy, use more specific NTP servers (e.g., time.windows.com, time.nist.gov). You can also use Group Policy to configure time settings across all DCs.

🔍 Troubleshooting Time Sync

Common commands:

• w32tm /query /status – Show current time source and offset.
• w32tm /query /peers – List configured NTP peers.
• w32tm /monitor – Check time against domain controllers.
• w32tm /resync – Force a resynchronization.

If you see errors, check that the time service is running, firewall ports (UDP 123 for NTP) are open, and the external source is reachable.

⚠️ Common Time Sync Issues

• Time drift on virtualised DCs: Virtual machines may drift due to host time changes. Disable time synchronization between the host and guest for DCs (let them sync from PDC).
• Firewall blocking NTP: Ensure UDP 123 is allowed outbound from the PDC.
• Misconfigured hierarchy: Some DCs might be pointed to external sources directly, breaking the hierarchy. Use Group Policy to enforce sync from the PDC.

📅 Group Policy for Time Sync

You can configure all client machines to use the domain hierarchy by default. No extra config is needed. However, you can enforce settings via Computer Configuration → Administrative Templates → System → Windows Time Service.

🔒 Security Considerations

• NTP is not authenticated by default. In high‑security environments, consider using authenticated NTP (with certificates) or use a hardware appliance.
• Prevent unauthorized time changes by restricting who can change system time (local policy).

9.8 Upgrading Active Directory (2008 → 2022)

📈 Why Upgrade?

Upgrading Active Directory brings new features, security improvements, and performance enhancements. It also ensures continued support from Microsoft. Common upgrade paths include moving from Windows Server 2008/2008 R2 to 2012/2012 R2, 2016, 2019, or 2022. This section covers the general process and considerations.

🗺️ Upgrade Approaches

• In‑place upgrade: Upgrade the operating system on existing domain controllers. This is possible but not recommended for DCs due to risk of issues. Use only for simple environments.
• Migration: Add new DCs running the new OS, transfer FSMO roles, then decommission old DCs. This is the preferred method – it’s safer and allows rollback.

📋 Pre‑upgrade Checklist

• Verify current forest and domain functional levels.
• Check hardware compatibility (64‑bit required, adequate RAM/disk).
• Ensure all DCs are healthy (dcdiag /v, repadmin /replsummary).
• Back up system state of all DCs.
• Review application compatibility (e.g., Exchange, SQL).
• Upgrade any prerequisite software (e.g., .NET Framework, PowerShell).

🔄 Migration Steps (Add new DCs, then decommission old)

1. Prepare the new server: Install Windows Server (e.g., 2022) and join it to the domain.
2. Install AD DS role: Promote the new server to a DC (adds it to the existing domain).
3. Transfer FSMO roles: Move FSMO roles to the new DCs (optional, but recommended to have them on newer OS). Use Move-ADDirectoryServerOperationMasterRole.
4. Move GC role: Ensure the new DC is a Global Catalog (if needed).
5. Verify replication: Wait for replication to complete and verify with repadmin /showrepl.
6. Decommission old DCs: Demote old DCs gracefully (dcpromo /forceremoval if needed, but clean removal is better).
7. Raise functional levels: After all old DCs are removed, you can raise forest and domain functional levels to the new OS level (optional, required to enable new features).

📊 Functional Level Features

Raising the functional level enables new features:

• 2008 R2: Recycle Bin, DFSR for SYSVOL.
• 2012: Virtual DC cloning, Group Managed Service Accounts (gMSAs).
• 2012 R2: Improvements to DC cloning, Authentication Policies.
• 2016: Privileged Access Management (PAM), Azure AD Join support.
• 2019/2022: Further security enhancements, time service improvements.

🚨 Important Considerations

• Mixed environment: During migration, you will have DCs of different OS versions. This is supported but ensure all DCs are healthy.
• SYSVOL replication: If upgrading from 2008 (FRS) to a newer version, you must migrate SYSVOL from FRS to DFSR. This is a critical step; follow Microsoft guides carefully.
• Time sync: Ensure the PDC emulator (wherever it is) is configured correctly.
• PowerShell: Use Get-ADDomain and Get-ADForest to check current levels.

🧪 Testing

Before production, test the entire migration in a lab that mirrors your environment. Validate that all applications work after the upgrade.

9.9 Migrating Active Directory to New Hardware / Cloud

🔄 Migration Scenarios

You may need to move AD to new hardware (e.g., server refresh) or to the cloud (Azure VMs). The approach is similar to upgrading: add new DCs, transfer roles, remove old ones. However, cloud migration adds considerations like network connectivity, latency, and hybrid configurations.

🏢 Migrating to New On‑Premises Hardware

This is straightforward: deploy new servers, promote them as DCs, transfer FSMO roles, and demote old servers. Follow the same steps as in 9.8. Ensure replication is healthy before decommissioning.

☁️ Migrating to Azure (IaaS)

Placing DCs in Azure can provide disaster recovery, offload authentication for hybrid users, and enable hybrid scenarios.

Steps:

1. Plan networking: Ensure connectivity between on‑premises and Azure via VPN or ExpressRoute. DCs in Azure must be able to communicate with on‑prem DCs.
2. Deploy Azure VMs: Create VMs with appropriate size (DS series recommended for DCs).
3. Configure time sync: Disable host time sync for DC VMs (let them sync from on‑prem PDC).
4. Promote to DCs: Join the domain and promote as additional DCs.
5. Configure Sites and Services: Create a new site in AD Sites and Services representing the Azure region. Assign subnets to that site and create site links with appropriate costs.
6. Move FSMO roles (optional): You may keep FSMO roles on‑prem or move to Azure.
7. Decommission old hardware: Once Azure DCs are fully functional and replicating, demote old on‑prem DCs as needed.

📡 Important Azure Considerations

• Availability Sets / Availability Zones: Deploy at least two DCs in different fault domains for high availability.
• Disk performance: Use Premium SSDs for NTDS and logs to ensure adequate IOPS.
• Network Security Groups (NSGs): Restrict RDP and other management ports; allow AD traffic (TCP 135, 139, 445, 389, 636, 3268, 3269, etc.) only from trusted sources.
• Backup: Use Azure Backup to protect DC VMs.
• Do not run other workloads on DCs: Keep DCs dedicated to AD.

🔄 Hybrid Identity with Azure AD

When moving to Azure, you may also consider Azure AD Connect for hybrid identity. This is separate from IaaS DCs. IaaS DCs extend your on‑prem domain into Azure; Azure AD Connect synchronises to the cloud identity.

📉 Decommissioning Old Hardware

After all roles are transferred and replication is stable, gracefully demote old DCs. Use dcpromo /forceremoval only if the DC is unreachable. Then perform metadata cleanup if needed.

9.10 AD Health Checks (Best Practices Analyzer & Manual Checks)

🩺 Why Health Checks Matter

Regular health checks help you detect issues before they become critical. They ensure that replication is working, backups are valid, and the directory is free from errors. A proactive approach saves downtime and headaches.

🛠️ Built‑in Tools

• Best Practices Analyzer (BPA) for AD DS: Part of Server Manager, BPA scans domain controllers against Microsoft’s best practices and reports warnings, errors, and informational messages. It covers configuration, security, and performance.
• dcdiag: The domain controller diagnostics tool performs comprehensive tests (connectivity, replication, DNS, etc.). Run dcdiag /v /c on each DC.
• repadmin: Use repadmin /replsummary to get a quick replication overview. repadmin /showrepl shows detailed replication status.
• Event Viewer: Check the Directory Service, DNS Server, and System logs for errors.
• PowerShell: Use cmdlets like Test-ADDSDomainControllerInstallation, Get-ADReplicationFailure, Get-ADDomainController with health checks.

📋 Manual Health Checklist

Perform these checks regularly (e.g., weekly) on each DC:

📊 Using Best Practices Analyzer

BPA can be run from Server Manager. Select “Active Directory Domain Services”, then click “Best Practices Analyzer” on the right. Review the results and address any errors. Common BPA warnings include:

• Time source not configured on PDC.
• SYSVOL replication not using DFSR.
• LDAP signing not enabled.
• DNS delegation issues.

🚨 Automated Health Monitoring

For large environments, automate health checks with scripts and integrate with a monitoring system (e.g., SCOM, Nagios, PRTG). Create scheduled tasks that run key commands and send alerts on failure.

# Example: PowerShell script to email replication failures
$repl = repadmin /replsummary
if ($repl -match "error") {
    Send-MailMessage -To "admin@contoso.com" -Subject "AD Replication Errors" -Body $repl -SmtpServer smtp.contoso.com
}
        

📅 Recommended Frequency

• Daily: Automated alerts for critical failures (replication, services).
• Weekly: Run dcdiag and repadmin, review event logs.
• Monthly: Full BPA scan, review backup status.
• Quarterly: Test restore, review security settings.

10.1 Fine‑Grained Password Policies (Password Settings Objects – PSO)

🔐 What are Fine‑Grained Password Policies?

In earlier versions of Windows Server (pre‑2008), only one password policy could exist per domain – the one defined in the Default Domain Policy. This was a significant limitation for organisations that needed different password requirements for different groups (e.g., stricter policies for administrators, more lenient for service accounts). Fine‑Grained Password Policies (FGPP), introduced in Windows Server 2008, allow you to create multiple password policies within a single domain and apply them to specific users or global security groups.

📦 Password Settings Objects (PSOs)

A Password Settings Object (PSO) is a container that holds all the settings for a fine‑grained password policy. Each PSO contains:

• Precedence: A number that determines which PSO wins when multiple PSOs apply to a user. Lower numbers have higher priority.
• Password settings: Same as domain‑level policy – minimum length, complexity, history, age, etc.
• Lockout settings: Account lockout threshold, duration, and observation window.
• Applies to: Users or global security groups (cannot be applied directly to computer objects).

🛠️ Creating and Managing PSOs

PSOs are created in the Password Settings Container (CN=Password Settings Container,CN=System,DC=domain,DC=com). You can manage them using:

• Active Directory Administrative Center (ADAC): The easiest GUI method. Navigate to the domain → System → Password Settings Container, then use the “New” menu to create a PSO.
• PowerShell: The New-ADFineGrainedPasswordPolicy cmdlet.

PowerShell Example:

# Create a PSO for administrators
New-ADFineGrainedPasswordPolicy -Name "AdminsPSO" `
    -Precedence 10 `
    -MinPasswordLength 16 `
    -ComplexityEnabled $true `
    -LockoutThreshold 3 `
    -LockoutDuration "00:30:00" `
    -LockoutObservationWindow "00:30:00" `
    -PasswordHistoryCount 24 `
    -MaxPasswordAge "60.00:00:00" `
    -MinPasswordAge "1.00:00:00"

# Apply the PSO to a group
Add-ADFineGrainedPasswordPolicySubject -Identity "AdminsPSO" -Subjects "Domain Admins"
        

📊 PSO Precedence and Evaluation

When a user belongs to multiple groups that have PSOs applied, the precedence value determines which PSO takes effect. The rule is: the PSO with the lowest precedence number wins. If a user has a PSO directly applied (not through a group), that PSO is considered first (and takes precedence over group‑based PSOs). The evaluation order is:

1. PSOs directly applied to the user object.
2. PSOs applied to global security groups the user is a member of (lowest precedence among those).
3. If no PSO applies, the domain default password policy (from Default Domain Policy) is used.

You can view the resultant PSO for a user with:

Get-ADUserResultantPasswordPolicy -Identity jsmith
        

🔁 PSO Replication and Scope

PSOs are stored in the Configuration partition and replicate to all domain controllers in the forest. However, they apply only within the domain where they are created. If you have multiple domains, you need separate PSOs in each domain.

📋 Best Practices for PSOs

• Use groups (e.g., “AdminsPSO_Group”) to apply PSOs, not individual users, for easier management.
• Plan precedence numbers carefully – leave gaps (e.g., 10, 20, 30) to insert new policies later.
• Test PSOs on a pilot group before applying to critical groups.
• Document each PSO – its purpose, precedence, and target groups.
• Monitor for users who are not covered by any PSO – they will fall back to the domain policy.
• Never apply PSOs to protected users (Protected Users group) without testing, as their own protections may conflict.

10.2 GPO Inheritance, Blocking & Enforcing

🔄 The LSDOU Model Revisited

Group Policy processing follows the LSDOU order: Local, Site, Domain, and finally OU (with nested OUs processed from parent to child). By default, policies from higher levels are inherited by lower levels, and policies linked at lower levels (closer to the object) have higher precedence – they overwrite conflicting settings from higher levels. This default behaviour can be modified using Block Inheritance and Enforced (No Override).

🚫 Block Inheritance

Block Inheritance is a setting applied to a domain or an OU. When enabled, it prevents GPOs from higher‑level containers (site, domain, parent OUs) from being inherited by objects in that container. However, there is an exception: GPOs that are set to Enforced will still apply, even through a Block Inheritance setting.

How to enable Block Inheritance:

• In Group Policy Management Console (GPMC), right‑click the domain or OU → Block Inheritance.
• You'll see a blue exclamation mark on the container indicating block is enabled.

Use case: You have a divisional OU where you do not want any domain‑level policies to apply (e.g., a quarantine OU). You enable Block Inheritance, then link only the specific GPOs needed.

🔒 Enforced (No Override)

Enforced is a setting applied to a GPO link. When a GPO is enforced, its settings cannot be overridden by any GPO lower in the hierarchy, regardless of Block Inheritance or precedence. Enforced GPOs have the highest priority.

How to enforce a GPO:

• In GPMC, right‑click the GPO link → Enforced.
• You'll see a small lock icon on the link.

Use case: Security‑critical settings (e.g., password policy) are often enforced at the domain level to ensure they cannot be overridden by lower‑level GPOs.

⚖️ Interaction Between Block Inheritance and Enforced

The rules are simple:

• Enforced GPOs always apply (unless the GPO itself is disabled or security filtered out).
• Block Inheritance blocks non‑enforced GPOs from higher levels.
• Enforced GPOs from higher levels still apply even if Block Inheritance is enabled.

Example scenario:

• Domain GPO “Security Baseline” is enforced.
• OU “Finance” has Block Inheritance enabled.
• Result: The enforced “Security Baseline” GPO still applies to Finance objects. Any other domain‑level (non‑enforced) GPOs are blocked.

📊 Link Order and Precedence

When multiple GPOs are linked to the same container (e.g., an OU), the order of processing is determined by the link order. The GPO with the lowest link number is processed last and has the highest priority. You can change the link order in GPMC by selecting the container and using the up/down arrows on the linked GPOs list.

🧪 Practical Example: Designing GPO Inheritance

Consider a company with the following structure:

• Domain: contoso.com
• OU: Workstations (contains all workstations)
• OU: Workstations\Sales
• OU: Workstations\IT

GPOs:

• GPO1 (Domain): Corporate screensaver (enforced).
• GPO2 (Workstations OU): Basic security settings.
• GPO3 (Sales OU): Sales‑specific wallpaper.
• GPO4 (IT OU): IT‑specific PowerShell execution policy.

What happens?

• All workstations get the enforced corporate screensaver (GPO1).
• All workstations get basic security (GPO2).
• Sales workstations additionally get Sales wallpaper (GPO3).
• IT workstations get IT PowerShell policy (GPO4).

If the Sales OU had Block Inheritance enabled, GPO2 would not apply (unless enforced).

10.3 WMI Filtering for Dynamic Targeting

🔍 What is WMI Filtering?

Windows Management Instrumentation (WMI) filtering allows you to dynamically target GPOs based on attributes of the target computer, such as operating system version, hardware configuration, installed software, or network configuration. A WMI filter is a query that is evaluated on the target machine; if the query returns true, the GPO is applied. This enables precise, conditional application of Group Policy without creating multiple OUs.

🔧 Creating a WMI Filter

WMI filters are created in GPMC under the WMI Filters node. You write a WQL (WMI Query Language) query that returns a result set. If the result set is non‑empty, the filter evaluates to true.

Common examples:

# Apply to Windows 10 only
Select * from Win32_OperatingSystem where Version like "10.%"

# Apply to Windows Server 2019 or later
Select * from Win32_OperatingSystem where Version like "10.0.17763%" or Version like "10.0.20348%"

# Apply to laptops (chassis type = 8, 9, 10, 14)
Select * from Win32_SystemEnclosure where ChassisTypes = 8 or ChassisTypes = 9 or ChassisTypes = 10 or ChassisTypes = 14

# Apply to machines with more than 8 GB RAM
Select * from Win32_ComputerSystem where TotalPhysicalMemory > 8589934592
        

You can test WMI queries locally using PowerShell: Get-WmiObject -Query "Select * from Win32_OperatingSystem".

🔗 Linking a WMI Filter to a GPO

1. In GPMC, select the GPO.
2. In the right pane, click the Scope tab.
3. Under WMI Filtering, select the desired filter from the dropdown.
4. The GPO will now only apply to computers that satisfy the filter.

⚖️ Performance Considerations

• WMI filters are evaluated on the target machine during policy processing. A poorly written query can slow down policy application.
• Keep queries simple and avoid complex joins.
• Test queries thoroughly before deploying to production.
• WMI filters apply to computer policy only (they run in the computer context). They cannot be used for user policy targeting (you can use item‑level targeting in Preferences for that).

📋 Best Practices

• Use WMI filters sparingly – prefer OU structuring when possible, as it’s simpler and faster.
• Document each filter with its purpose and query.
• Use a naming convention (e.g., “Filter_Win10”, “Filter_8GB_RAM”).
• Be aware that WMI filters are not replicated across domains – they exist per domain.

🔁 Example: Deploying Software to Specific OS Versions

You have an application that only runs on Windows 10 21H2 and later. Instead of creating a separate OU for those machines, you create a WMI filter:

Select * from Win32_OperatingSystem where Version like "10.0.19044%" or Version like "10.0.19045%" or Version like "10.0.22000%"
        

Link this filter to the GPO that installs the software. Now, only eligible machines receive it.

10.4 Security Filtering vs Delegation

🔑 Understanding the Concepts

Two fundamental but often confused concepts in Group Policy are Security Filtering and Delegation. Both involve permissions, but they serve very different purposes.

• Security Filtering: Controls which users and computers receive and apply a GPO.
• Delegation: Controls who can manage the GPO (edit, delete, modify security).

🛡️ Security Filtering

By default, a new GPO is linked to the container where it's created, and its security filtering is set to “Authenticated Users” with Read and Apply Group Policy permissions. This means the GPO applies to all authenticated users and computers. To restrict the GPO to specific groups, you modify security filtering.

How it works:

• You grant a security group (e.g., “Sales Users”) the Read and Apply Group Policy permissions on the GPO.
• You remove “Authenticated Users” (or leave it, but then it still applies – so typically you remove it).
• Only members of that group will have the GPO applied.

Important: Security filtering works for both user and computer configurations. For computer configuration settings, the computer account must have Read and Apply permissions. So if you're filtering a computer configuration GPO to a specific computer group, ensure that group contains computer accounts.

Example: A GPO that deploys finance software should be filtered to the “Finance Computers” group.

👥 Delegation

Delegation controls administrative access to the GPO itself. In GPMC, you can delegate the following tasks:

• Edit settings
• Delete or modify security
• Link GPOs
• Read (view) settings

Delegation is configured on the Delegation tab of a GPO (or at domain level for linking rights). You add users or groups and assign the appropriate permissions. For example, you might delegate “Edit settings” to the “GPO Admins” group.

Common delegation scenarios:

• Helpdesk needs to link GPOs to specific OUs (delegate “Link GPOs” on the OU).
• A security team needs to edit security‑related GPOs (delegate “Edit settings” on those GPOs).
• Auditors need read‑only access to all GPOs (delegate “Read” on the domain’s GPOs).

🔍 Comparison Table

⚠️ Common Mistakes

• Removing Authenticated Users from security filtering without adding another group – the GPO applies to no one.
• Adding users to security filtering with only Read permission (they need Apply Group Policy).
• Confusing delegation with security filtering – e.g., granting a user Edit permissions thinking that will make the GPO apply to them.

📋 Best Practices

• Use security groups for security filtering, not individual users.
• For computer settings, filter on computer groups.
• Document who has delegation rights on critical GPOs.
• Regularly review delegation to ensure least privilege.

10.5 ADMX Central Store

📂 What is the ADMX Central Store?

Administrative Template files (.ADMX) define the registry‑based policy settings available in Group Policy. Prior to Windows Vista/Server 2008, these files (.ADM) were stored locally on each administrative machine, leading to versioning conflicts and management headaches. The ADMX Central Store is a central repository in SYSVOL that stores all .ADMX and .ADML (language‑specific) files. When you edit a GPO from any machine with GPMC, it reads the templates from the Central Store, ensuring everyone uses the same set of policy definitions.

🛠️ Creating the Central Store

Creating the Central Store is simple – you create a folder in SYSVOL:

1. On any domain controller, navigate to \\contoso.com\SYSVOL\contoso.com\Policies.
2. Create a folder named PolicyDefinitions.
3. Copy all .ADMX and .ADML files from a client or server’s C:\Windows\PolicyDefinitions folder into this new folder. Include subfolders for each language (e.g., en-US, de-DE).

After this, any administrator editing a GPO from any domain‑joined machine will automatically use the Central Store. The local PolicyDefinitions folder is no longer used (except as a fallback).

📥 Adding Custom or Third‑Party ADMX Files

Many applications (e.g., Office, Chrome, Adobe Reader) provide ADMX files for managing their settings via Group Policy. To make them available to all administrators:

1. Download the ADMX files from the vendor.
2. Copy the .ADMX files to the root of the Central Store (PolicyDefinitions).
3. Copy the corresponding .ADML language files to the appropriate language subfolder (e.g., PolicyDefinitions\en-US).
4. Replication will distribute them to all DCs.

Now, when you edit a GPO, you'll see the new administrative template categories and settings.

🔄 Replication and Versioning

Because the Central Store is in SYSVOL, it replicates to all domain controllers. However, it does not automatically update when you install new Windows versions or service packs. You must manually copy new ADMX files when you introduce newer OS versions. For example, when you deploy Windows 11, copy its ADMX files to the Central Store to manage Windows 11‑specific policies.

📋 Best Practices

• Maintain a “master copy” of your Central Store on a file server or source control to track changes.
• Update the Central Store whenever you introduce a new OS version or application.
• Test new ADMX files in a lab before deploying to production.
• Use a naming convention for custom ADMX files to easily identify them.
• Document the version and source of each ADMX file.

10.6 GPO Logging & Troubleshooting

🔍 Why Troubleshoot GPOs?

Group Policy issues are among the most common problems in Active Directory – settings not applying, unexpected results, slow logons, or errors. Effective troubleshooting requires a systematic approach and knowledge of the right tools. This section covers the essential tools and techniques for diagnosing GPO problems.

🛠️ Essential Troubleshooting Tools

• gpresult: Shows the Resultant Set of Policy (RSoP) for a user or computer. Run gpresult /r for summary, gpresult /h report.html for detailed HTML report.
• rsop.msc: Graphical RSoP snap‑in (though deprecated, still useful for quick checks).
• Group Policy Results Wizard in GPMC: Simulates policy application for a target computer/user across the network.
• Group Policy Modeling Wizard in GPMC: Simulates “what if” scenarios (e.g., moving a computer to a different OU).
• Event Viewer: Look in Applications and Services Logs → Microsoft → Windows → Group Policy → Operational for detailed errors.
• PowerShell: Get-GPOReport -Guid -ReportType HTML -Path report.html to export GPO details.
• gpupdate: Force a remote group policy update with Invoke-GPUpdate -Computer PC001 -RandomDelayInMinutes 0.

📋 Step‑by‑Step Troubleshooting Process

1. Check the basics: Is the client connected to the domain? Can it reach a domain controller (DNS)? Run nltest /dsgetdc:.
2. Run gpresult: On the affected machine, run gpresult /r (or gpresult /scope:computer for computer settings). Look for:
   • Which GPOs are listed as “Applied”.
   • Any “Denied” GPOs and the reason (e.g., security filtering, WMI filter failed).
   • The “Last time Group Policy was applied”.
3. Check security filtering: Verify that the computer account (for computer policies) or user account (for user policies) has Read and Apply Group Policy permissions on the GPO. Also check if “Authenticated Users” was removed.
4. Check WMI filters: If a WMI filter is attached, test it manually on the client: Get-WmiObject -Query "your query". If it returns nothing, the filter fails.
5. Check inheritance: Is Block Inheritance enabled on the OU? Is the GPO enforced? These can override normal processing.
6. Check GPO status: Is the GPO enabled (both computer and user sections can be disabled)? In GPMC, look for a red “X”.
7. Check replication: If a GPO was recently modified, it may not have replicated to all DCs. Compare version numbers in GPMC (Domain and Sysvol columns). Use repadmin /syncall to force replication.
8. Check Event Viewer: Look for GroupPolicy operational logs for errors (Event IDs 5000‑5999). Also check System and Application logs.

📊 Common GPO Errors and Fixes

💻 Advanced Troubleshooting with PowerShell

# Get all GPOs that apply to a specific computer (simulate)
Get-GPResultantSetOfPolicy -ComputerName WS001 -ReportType Html -Path C:\rsop.html

# Get permissions for a GPO
Get-GPPermission -Guid "GPO-GUID" -All

# Force a remote group policy update
Invoke-GPUpdate -Computer WS001 -RandomDelayInMinutes 0

# Test a WMI filter remotely
Invoke-Command -ComputerName WS001 -ScriptBlock { Get-WmiObject -Query "Select * from Win32_OperatingSystem" }
        

10.7 Advanced Scripts via GPO

📜 Script Types in Group Policy

Group Policy can execute scripts at various points: computer startup/shutdown and user logon/logoff. These scripts can be batch (.bat), VBScript (.vbs), or PowerShell (.ps1). Advanced scripting allows you to perform complex configurations that go beyond built‑in policy settings.

🚀 PowerShell Scripts via GPO

PowerShell is the modern choice for scripting. To deploy PowerShell scripts via GPO:

1. Place the script in a network share accessible by all target computers (e.g., \\contoso.com\SYSVOL\contoso.com\scripts\myscript.ps1).
2. In a GPO, navigate to Computer Configuration → Policies → Windows Settings → Scripts → Startup (or Shutdown, or User Configuration → Logon/Logoff).
3. Double‑click the script type, click Add, browse to the script, and optionally add parameters.
4. For PowerShell scripts, ensure the execution policy allows them. You can set the policy via GPO: Computer Configuration → Policies → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Execution.

⚙️ Advanced Script Examples

Example 1: Map network drives based on group membership

# Logon script (PowerShell)
$salesDrive = "\\fileserver\sales"
$itDrive = "\\fileserver\it"

# Remove existing mapped drives (optional)
Get-SmbMapping | Where-Object { $_.LocalPath -eq "S:" } | Remove-SmbMapping -Force -UpdateProfile

# Map based on group membership
if ( (Get-ADGroupMember -Identity "Sales Team" -Recursive | Select-Object -ExpandProperty SamAccountName) -contains $env:USERNAME ) {
    New-SmbMapping -LocalPath "S:" -RemotePath $salesDrive -Persist $true
} elseif ( (Get-ADGroupMember -Identity "IT Team" -Recursive | Select-Object -ExpandProperty SamAccountName) -contains $env:USERNAME ) {
    New-SmbMapping -LocalPath "I:" -RemotePath $itDrive -Persist $true
}
        

Example 2: Install software if not present (startup script)

# Computer startup script (PowerShell)
$softwareName = "7-Zip"
$installerPath = "\\fileserver\software\7z1900-x64.msi"

if (-not (Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*$softwareName*" })) {
    msiexec /i $installerPath /quiet /norestart
}
        

🔄 Script Ordering and Timing

• Startup scripts: Run in the system context, before the user logs on. They have access to the entire machine but not user profiles.
• Logon scripts: Run in the user context, after the user logs on but before the desktop appears (synchronous by default).
• Shutdown/Logoff scripts: Run when the system shuts down or user logs off, with limited time to complete.

You can configure script timeout and whether to run them synchronously or asynchronously via GPO settings under Administrative Templates → System → Scripts.

🔐 Security Considerations for Scripts

• Store scripts on a secure, highly available network share. Use DFS for redundancy.
• Ensure the share permissions allow “Read” for Domain Computers (for startup scripts) and Domain Users (for logon scripts).
• Sign your PowerShell scripts with a trusted certificate to prevent tampering and set execution policy to “RemoteSigned”.
• Log script execution – include logging in your scripts and collect logs centrally.
• Avoid storing credentials in scripts. Use Group Managed Service Accounts (gMSAs) or other secure methods.

📊 Comparing Scripts to Preferences

Group Policy Preferences (e.g., drive maps, registry settings) are easier to configure and manage than scripts. However, scripts offer unlimited flexibility and logic (if/then, loops, external calls). Use preferences for simple, declarative tasks; use scripts for complex conditional logic.

10.8 GPO Backup, Restore & Migration

💾 Why Backup GPOs?

Group Policy Objects are critical configuration assets. Accidental deletion, misconfiguration, or corruption can affect thousands of users. Regular backups of GPOs allow you to restore to a known good state. Backups are also essential when migrating GPOs between domains (e.g., from test to production) or forests.

🛠️ Backing Up GPOs

Using GPMC:

1. Open GPMC, right‑click Group Policy Objects (or a specific GPO).
2. Select Back Up All (or Back Up for a single GPO).
3. Choose a location (e.g., a network share) and optionally provide a description.
4. GPMC creates a folder with a timestamp and saves each GPO as a set of files (including the GPT and GPC information).

Using PowerShell:

# Backup all GPOs to a folder
Backup-GPO -All -Path "\\backupserver\GPOBackups" -Comment "Monthly backup $(Get-Date)"

# Backup a single GPO
Backup-GPO -Name "Default Domain Policy" -Path "\\backupserver\GPOBackups"
        

🔄 Restoring GPOs

Using GPMC:

1. In GPMC, right‑click Group Policy Objects → Manage Backups.
2. Browse to the backup location, select the GPO and backup version.
3. Click Restore. This overwrites the existing GPO (if present).

Using PowerShell:

# Restore a GPO from backup
Restore-GPO -Name "Sales GPO" -Path "\\backupserver\GPOBackups" -BackupId 
        

Restoring a GPO does not affect its links. If you restore to a different domain (migration), you will need to handle security principals (see below).

🌉 Migrating GPOs Between Domains

Migrating GPOs from one domain to another (e.g., test to production) requires careful handling of security principals (users, groups) that may differ between domains. GPMC provides a Migration Table to map source principals to destination principals.

Migration steps:

1. Back up the GPO in the source domain.
2. Copy the backup folder to a location accessible from the destination domain.
3. In the destination domain, open GPMC, right‑click Group Policy Objects → Open Migration Table Editor.
4. Create a migration table that maps source domain users/groups to destination equivalents (e.g., CONTOSO\SalesGroup to FABRIKAM\SalesGroup).
5. Right‑click Group Policy Objects → Import Settings. Point to the backup, choose to import, and apply the migration table.
6. The GPO is created in the destination domain with translated security principals.

Using PowerShell for migration:

# Import a GPO with a migration table
Import-GPO -BackupId  -Path "\\backupserver\GPOBackups" -TargetName "Sales GPO" -MigrationTable "\\server\migrationtable.migtable"
        

📋 Best Practices

• Schedule regular GPO backups (e.g., weekly).
• Store backups in a secure, off‑site location.
• Include GPO backups in your overall disaster recovery plan.
• Test restoration in a lab periodically.
• Use migration tables when moving GPOs between domains to avoid broken permissions.
• Document the purpose of each GPO in the backup description.

10.9 GPO Security: Preventing Tampering

🛡️ The Importance of GPO Security

GPOs contain critical security settings, software deployment configurations, and scripts. If an attacker (or a disgruntled administrator) can modify GPOs, they can compromise the entire domain – for example, by adding a malicious script to a startup GPO. Protecting GPOs from unauthorised changes is therefore paramount.

🔒 Default GPO Permissions

By default, the following groups have permissions on GPOs:

• Domain Admins: Full control.
• Enterprise Admins: Full control.
• SYSTEM: Full control.
• Authenticated Users: Read access (required for GPOs to be applied).
• Domain Computers: Read access (for computer policies).

Additional groups (e.g., “GPO Admins”) may be delegated edit rights.

📋 Hardening GPO Permissions

• Restrict who can create GPOs: By default, any domain user can create GPOs. Change this via GPMC: right‑click Group Policy Objects → Delegate → remove “Authenticated Users” from “Create GPOs” and add only specific groups.
• Limit edit permissions: Only grant “Edit settings” to users/groups that absolutely need it. Use groups, not individual users.
• Protect the “Default Domain Policy” and “Default Domain Controllers Policy”: These are critical. Consider removing edit rights from all except Domain Admins.
• Use Protected Groups: Ensure that members of groups like “GPO Admins” are also in Protected Users and use PAWs.
• Audit changes: Enable auditing on the GPO containers (in AD) to track modifications (see below).

🔍 Auditing GPO Changes

To detect tampering, you must audit changes to GPOs. This involves two parts: auditing changes to the GPO container in AD, and auditing changes to the GPT files in SYSVOL.

Audit AD changes (GPC):

1. Enable advanced auditing on domain controllers for “Directory Service Changes”.
2. Monitor Event ID 5136 (a directory service object was modified), 5137 (created), 5141 (deleted). Filter for objects in the CN=Policies,CN=System,DC=... container.

Audit SYSVOL changes (GPT):

1. Enable auditing on the SYSVOL share and folder using File Server Resource Manager or advanced audit policies (Object Access).
2. Monitor Event ID 4663 (an attempt was made to access an object) for the \Policies folder.

Using PowerShell to get GPO version history:

# Get GPO version (user and computer) – changes when GPO is edited
Get-GPO -Name "Sales GPO" | Select-Object DisplayName, ModificationTime, UserVersion, ComputerVersion
        

🔁 Protecting Against Ransomware

Ransomware often targets GPOs to disable defences or deploy ransomware via startup scripts. To mitigate:

• Implement the “Golden Image” approach – store a read‑only copy of critical GPOs.
• Use a separate administrative forest (bastion forest) for managing GPOs in production (privileged access workstation model).
• Regularly back up GPOs and store backups offline.
• Monitor for unexpected GPO changes and alert immediately.

📋 Best Practices Summary

• Delegate GPO management to the smallest possible group.
• Use security groups for delegation, not individual users.
• Restrict GPO creation to authorised administrators.
• Enable auditing on GPO containers and SYSVOL.
• Regularly review delegated permissions.
• Consider using Microsoft’s “Protected Users” and PAWs for GPO administrators.

10.10 Group Policy Preferences vs Policies

🔄 Understanding the Difference

Group Policy has two main types of settings: Policies and Preferences. They behave differently and serve different purposes.

• Policies: Enforced settings that cannot be changed by the user. They are applied and re‑applied every 90‑120 minutes (background refresh). If a user changes a policy‑controlled setting, it will be reverted at the next refresh. Policies are stored in the Registry.pol file.
• Preferences: Configurable settings that are applied once and then can be changed by the user. Preferences are not enforced – if a user modifies a preference setting, it stays changed. Preferences are stored in the registry under normal user keys and can be targeted via item‑level targeting.

📁 Where to Find Them

In the Group Policy Editor, both appear under the same nodes (e.g., “Administrative Templates” are policies, while “Preferences” are a separate folder under both Computer and User Configuration).

• Policies: Under Computer Configuration → Policies → Administrative Templates and similar for User Configuration.
• Preferences: Under Computer Configuration → Preferences and User Configuration → Preferences. Inside, you'll find subfolders for Windows Settings (e.g., Drive Maps, Environment, Files, Folders, Ini Files, Registry, Shortcuts) and Control Panel Settings.

🎯 Item‑Level Targeting in Preferences

One of the most powerful features of Preferences is item‑level targeting. You can configure a preference item (e.g., a drive map) to apply only when certain conditions are met, such as:

• User is a member of a specific group.
• Computer is in a specific IP range.
• Operating system version matches a pattern.
• Specific environment variable is set.
• Time of day.

This is configured by clicking the “Targeting” button in the properties of a preference item. You can combine multiple conditions with AND/OR logic.

🔍 Comparison Table