05 Active Directory Practice

Welcome to the Active Directory Practice Path.

Active Directory is one of the most important technologies to understand if you want to work in:

• ethical hacking
• penetration testing
• red teaming
• SOC operations
• incident response
• identity security
• enterprise security

Many organizations still rely heavily on Microsoft Active Directory to manage:

• users
• computers
• authentication
• authorization
• security policies
• administrative privileges
• enterprise applications

Because Active Directory connects identities, systems and privileges across an organization, a single security weakness can sometimes create a much larger attack path.

Do not think of Active Directory as just a Windows server. Think of it as an enterprise identity and trust system.

Path Objective

By completing this practice path, you should develop practical understanding of:

• Active Directory architecture
• forests and domains
• domain controllers
• users
• groups
• computers
• Organizational Units
• Group Policy
• authentication
• Kerberos
• NTLM
• service accounts
• permissions
• administrative privileges
• credential exposure
• Active Directory enumeration
• attack-path analysis
• lateral movement concepts
• privilege escalation concepts
• defensive monitoring
• remediation
• reporting

All offensive-security practice should remain inside TryHackMe, GoHackersCloud Labs, your own Active Directory lab, or another environment where you have explicit authorization.

Recommended Active Directory Journey

Follow this sequence:

Windows Fundamentals
        ↓
Active Directory Architecture
        ↓
Domains & Domain Controllers
        ↓
Users, Groups & Computers
        ↓
Organizational Units
        ↓
Group Policy
        ↓
Authentication
        ↓
Kerberos & NTLM
        ↓
AD Enumeration
        ↓
Permissions & Privileges
        ↓
Service Accounts
        ↓
Credential Security
        ↓
Attack Paths
        ↓
Lateral Movement Concepts
        ↓
Defensive Monitoring
        ↓
Remediation
        ↓
AD Challenges

05 Active Directory Practice

---
title: "05 Active Directory Practice"
description: "Develop practical Active Directory security skills through structured TryHackMe practice covering domains, domain controllers, users and groups, Kerberos, NTLM, Group Policy, permissions, service accounts, attack paths, defensive monitoring and remediation."
---

# 05 Active Directory Practice

Welcome to the **Active Directory Practice Path**.

Active Directory is one of the most important technologies to understand if you want to work in:

- ethical hacking
- penetration testing
- red teaming
- SOC operations
- incident response
- identity security
- enterprise security

Many organizations still rely heavily on Microsoft Active Directory to manage:

- users
- computers
- authentication
- authorization
- security policies
- administrative privileges
- enterprise applications

Because Active Directory connects identities, systems and privileges across an organization, a single security weakness can sometimes create a much larger attack path.

> **Do not think of Active Directory as just a Windows server. Think of it as an enterprise identity and trust system.**

# Path Objective

By completing this practice path, you should develop practical understanding of:

- Active Directory architecture
- forests and domains
- domain controllers
- users
- groups
- computers
- Organizational Units
- Group Policy
- authentication
- Kerberos
- NTLM
- service accounts
- permissions
- administrative privileges
- credential exposure
- Active Directory enumeration
- attack-path analysis
- lateral movement concepts
- privilege escalation concepts
- defensive monitoring
- remediation
- reporting

All offensive-security practice should remain inside **TryHackMe, GoHackersCloud Labs, your own Active Directory lab, or another environment where you have explicit authorization**.

# Recommended Active Directory Journey

Follow this sequence:

```text
Windows Fundamentals
        ↓
Active Directory Architecture
        ↓
Domains & Domain Controllers
        ↓
Users, Groups & Computers
        ↓
Organizational Units
        ↓
Group Policy
        ↓
Authentication
        ↓
Kerberos & NTLM
        ↓
AD Enumeration
        ↓
Permissions & Privileges
        ↓
Service Accounts
        ↓
Credential Security
        ↓
Attack Paths
        ↓
Lateral Movement Concepts
        ↓
Defensive Monitoring
        ↓
Remediation
        ↓
AD Challenges

Stage 01 — Understand Active Directory

Active Directory is Microsoft’s directory service for centrally managing enterprise identities and resources.

Instead of managing every computer independently, organizations can manage systems through a centralized directory.

A simplified environment may look like:

                    Active Directory
                           |
                    Domain Controller
                           |
          --------------------------------
          |              |               |
        Users          Computers       Groups
          |              |               |
          --------------------------------
                           |
                    Enterprise Access

The Domain Controller plays a critical role in managing authentication and directory information.

Stage 02 — Understand the Domain

A domain represents a logical administrative boundary.

Example:

corp.example.local

A domain may contain:

Users
Computers
Groups
Policies
Servers
Service Accounts
Administrative Accounts

When users authenticate to a domain, Active Directory helps determine who they are and what they are permitted to access.

Stage 03 — Domain Controllers

Domain Controllers provide core Active Directory services.

They commonly handle:

• authentication

• authorization

• directory queries

• Group Policy

• Kerberos

• directory replication

Because of their importance, Domain Controllers are among the most sensitive systems in an enterprise environment.

Security Perspective

Ask:

Who can access the Domain Controller?

Who has administrative privileges?

Which services are exposed?

What logs are generated?

How are privileged accounts protected?

Stage 04 — Forests and Trees

Larger Active Directory environments may contain multiple domains.

Conceptually:

Forest
│
├── corp.example.local
│
├── europe.corp.example.local
│
└── asia.corp.example.local

A forest represents the highest-level Active Directory security structure.

You do not need to master complex forest architectures immediately.

Start by understanding that relationships between domains can create additional trust and security considerations.

Stage 05 — Users

Users represent identities within Active Directory.

Examples may include:

john.smith

alice.admin

svc_backup

helpdesk.user

Different accounts may serve very different purposes.

Common categories include:

• standard users

• administrators

• service accounts

• application accounts

• privileged users

Security Questions

Ask:

What privileges does this user have?

Which groups does the user belong to?

Where can the user log in?

What resources can the user access?

Is the account still required?

Stage 06 — Groups

Groups simplify permission management.

Instead of assigning permissions individually, organizations commonly assign access to groups.

Conceptually:

User
  ↓
Group
  ↓
Permission
  ↓
Resource

Examples could include:

HR Users

Finance Users

Helpdesk

Server Administrators

Domain Admins

Group membership is extremely important during Active Directory security assessments.

Stage 07 — Computers

Computers are also objects inside Active Directory.

Examples include:

WORKSTATION01

FILESERVER01

WEB01

DC01

Computer accounts participate in domain authentication and trust relationships.

Learn to recognize:

• workstations

• servers

• domain controllers

• application servers

• administrative systems

Stage 08 — Organizational Units

Organizational Units, or OUs, help administrators organize Active Directory objects.

A simplified structure may look like:

corp.local
│
├── Users
│
├── Servers
│
├── Workstations
│
├── Finance
│
├── HR
│
└── IT

OUs can also become important because Group Policy may be applied to them.

Stage 09 — Group Policy

Group Policy allows administrators to centrally configure Windows systems.

Policies may control:

• password settings

• security settings

• scripts

• software configuration

• firewall rules

• desktop settings

• user restrictions

• system behavior

Conceptually:

Domain
   ↓
Organizational Unit
   ↓
Group Policy
   ↓
Users / Computers

Poorly designed or overly permissive policies can introduce security risk.

Stage 10 — Authentication in Active Directory

Authentication is central to Active Directory.

A user may log in to a workstation using domain credentials.

Conceptually:

User
 ↓
Windows Workstation
 ↓
Domain Authentication
 ↓
Domain Controller
 ↓
Identity Verified
 ↓
Access Granted

Two important authentication technologies are:

• Kerberos

• NTLM

Stage 11 — Kerberos Fundamentals

Kerberos is the primary authentication protocol used in modern Active Directory environments.

At a high level:

User
 ↓
Requests Authentication
 ↓
Domain Controller
 ↓
Ticket Issued
 ↓
User Requests Service Access
 ↓
Service Ticket
 ↓
Resource Access

The important idea is:

Kerberos uses tickets to allow authenticated users to access services.

You do not need to memorize every Kerberos message immediately.

Understand the main components first.

Stage 12 — Kerberos Components

Become familiar with terms such as:

KDC

TGT

Service Ticket

SPN

Principal

At a conceptual level:

KDC

Key Distribution Center.

TGT

Ticket Granting Ticket.

Service Ticket

Used when accessing a specific service.

SPN

Service Principal Name associated with a service.

These concepts become important when analyzing Active Directory authentication and security weaknesses.

Stage 13 — NTLM Fundamentals

NTLM is an older authentication technology still encountered in many Windows environments.

You should understand that organizations may use both:

Kerberos
NTLM

depending on:

• system configuration

• application compatibility

• authentication conditions

Legacy authentication deserves additional security attention because older protocols may provide fewer protections.

Stage 14 — Active Directory Enumeration

Enumeration is the process of understanding the environment.

During authorized assessments, your objective is to answer questions such as:

What domain am I in?

Who are the users?

What groups exist?

Which computers exist?

Who has administrative privileges?

What service accounts exist?

What trusts exist?

Where are permissions assigned?

Enumeration is often more important than immediately searching for exploits.

Stage 15 — Build an Identity Map

Start mapping identities and privileges.

Example:

Alice
  ↓
Helpdesk
  ↓
Password Reset Permission
  ↓
Server Admin
  ↓
Critical Server

This begins to reveal potential relationships between accounts and privileges.

Stage 16 — Privileged Groups

Some groups provide significant administrative power.

Examples commonly encountered include:

Domain Admins

Enterprise Admins

Administrators

Account Operators

Server Operators

Backup Operators

Exact environments vary.

Do not simply identify privileged groups.

Ask:

Who belongs to them?

Why?

Is membership permanent?

Is the access still required?

Could another privilege path lead into the group?

Stage 17 — Least Privilege

Active Directory security depends heavily on least privilege.

The principle is simple:

Users and systems should receive only the access required to perform their responsibilities.

Consider:

Standard User
      ↓
Required Application

rather than:

Standard User
      ↓
Local Administrator
      ↓
Domain Administrator

Excessive privilege creates unnecessary attack paths.

Stage 18 — Permissions and ACLs

Active Directory objects use permissions to determine who may perform certain actions.

Permissions may affect:

• users

• groups

• computers

• OUs

• Group Policy

• directory objects

A permission relationship can look like:

User A
  ↓
Permission
  ↓
Group B

If that permission allows User A to modify Group B, and Group B has administrative privileges, the relationship may become security-sensitive.

Stage 19 — Service Accounts

Service accounts are used by applications and services.

Examples might include:

svc_sql

svc_backup

svc_web

svc_monitoring

Service accounts deserve particular attention because they may have:

• long-lived credentials

• high privileges

• broad server access

• weak password-management practices

Security Questions

Ask:

Does this service account still exist for a reason?

What privileges does it have?

Where can it authenticate?

Is the password regularly managed?

Could a managed service account be used instead?

Stage 20 — Credential Security

Credentials are one of the most sensitive elements in Active Directory.

Security weaknesses may involve:

• weak passwords

• reused passwords

• credentials stored insecurely

• credentials exposed in scripts

• credentials embedded in configuration

• excessive administrative logons

Think in terms of:

Credential
   ↓
Identity
   ↓
Privilege
   ↓
Resource

The value of a credential depends heavily on the privileges associated with the account.

Stage 21 — Administrative Tiering

Organizations should separate different levels of administrative access.

Conceptually:

High-Privilege Administration

        ↓

Server Administration

        ↓

Workstation Administration

        ↓

Standard User Activity

Highly privileged credentials should not be routinely used on lower-trust systems.

This reduces the risk of credential exposure.

Stage 22 — Active Directory Attack Paths

A major concept in Active Directory security is the attack path.

Attackers may not begin with administrative access.

Instead, privileges may be chained.

For example:

Compromised User
      ↓
Local Admin Access
      ↓
Server Access
      ↓
Exposed Credential
      ↓
Privileged Account
      ↓
Domain Control

The individual weaknesses may appear unrelated until the relationships are mapped.

Stage 23 — Think in Relationships

Instead of looking only at systems, begin looking at relationships.

Examples:

User → Group

Group → Computer

User → Permission

Service Account → Server

Administrator → Workstation

Computer → Domain

Domain → Trust

Active Directory security is largely about understanding how these relationships create access.

Stage 24 — Graph-Based Thinking

An AD environment can be thought of as a graph.

User A
  |
Member Of
  ↓
Group A
  |
Admin To
  ↓
Server A
  |
Session
  ↓
Admin User

This type of relationship mapping is extremely useful for understanding privilege paths.

Stage 25 — Local Administrator Access

Local administrative privileges can become highly significant.

If one account has administrative access to multiple systems, compromise of that account may affect multiple machines.

Conceptually:

Admin User
 ├── Workstation A
 ├── Server B
 └── Server C

Organizations should minimize shared administrative access.

Stage 26 — Password and Authentication Security

Review security controls such as:

• password policies

• account lockout

• MFA

• privileged access controls

• service-account management

• legacy authentication

Avoid evaluating password security in isolation.

Consider the overall authentication architecture.

Stage 27 — Kerberos Security Concepts

As your understanding grows, explore security concepts associated with:

• service accounts

• tickets

• SPNs

• privileged authentication

• delegation

The objective is not merely to learn named techniques.

Understand what security condition makes a technique possible.

For example:

Identity Configuration
        ↓
Permission or Authentication Weakness
        ↓
Security Exposure

Stage 28 — Delegation Fundamentals

Kerberos delegation allows services to access resources on behalf of users.

This can be legitimate and necessary.

However, delegation introduces additional trust relationships.

Think:

User
 ↓
Service A
 ↓
Delegated Access
 ↓
Service B

Ask:

• Why is delegation required?

• Which identities can use it?

• Which systems trust it?

• Is the configuration broader than necessary?

Stage 29 — Lateral Movement Concepts

Lateral movement describes movement from one system or identity to another after initial access.

Conceptually:

Workstation
    ↓
Credential / Trust
    ↓
Server
    ↓
Additional Identity
    ↓
Another System

The exact method can vary.

Focus on the underlying principle:

Existing trust and permissions can allow access to additional systems.

Stage 30 — Privilege Escalation Concepts

Privilege escalation means moving from lower privilege to higher privilege.

In Active Directory this might involve:

Standard User
      ↓
Permission Relationship
      ↓
Privileged Group
      ↓
Administrative Access

The critical question is:

Which relationship allowed the privilege boundary to be crossed?

Stage 31 — Domain Trusts

Organizations may create trust relationships between domains.

Conceptually:

Domain A
   ↓
 Trust
   ↓
Domain B

Trusts allow identities in one domain to access resources in another under defined conditions.

During security analysis, understand:

• what trusts exist

• why they exist

• their direction

• which users benefit

• whether they increase exposure

Stage 32 — Active Directory Misconfigurations

Common security problems can involve:

• excessive group membership

• weak permissions

• legacy accounts

• unnecessary privileges

• poor service-account security

• insecure authentication

• inappropriate delegation

• weak Group Policy

• uncontrolled administrative access

Do not treat every configuration difference as a vulnerability.

Understand the security impact.

Stage 33 — Defensive Visibility

Active Directory also provides important defensive telemetry.

SOC and identity-security teams may investigate:

• authentication events

• failed logins

• privileged logins

• account creation

• group membership changes

• password changes

• account lockouts

• service-account activity

• policy changes

This is where your SOC skills connect with Active Directory security.

Stage 34 — Authentication Investigation

Consider a sequence such as:

10:01 — Multiple Failed Logins

10:04 — Successful Authentication

10:05 — Privileged Group Access

10:08 — Remote System Access

A defender should correlate these events rather than analyzing each independently.

Ask:

Which user?

Which source system?

Which target?

What authentication method?

Was the activity expected?

What happened next?

Stage 35 — Privileged Account Monitoring

Privileged identities deserve increased monitoring.

Examples include:

• domain administrators

• server administrators

• backup administrators

• service accounts

• identity administrators

Security teams should understand where privileged accounts authenticate and whether that behavior matches expectations.

Stage 36 — Group Membership Monitoring

Changes to privileged groups can be highly significant.

Example:

Standard User
      ↓
Added to
      ↓
Privileged Group

A defender should investigate:

Who made the change?

Which account was added?

Why was it added?

Was the change approved?

How long did membership remain?

What did the user do afterward?

Stage 37 — Active Directory Security Assessment Methodology

Develop a repeatable assessment workflow.

1. Confirm Scope

2. Identify Domain

3. Understand Architecture

4. Enumerate Users

5. Enumerate Groups

6. Enumerate Computers

7. Identify Privileged Accounts

8. Identify Service Accounts

9. Review Permissions

10. Review Authentication

11. Review Group Policy

12. Identify Trust Relationships

13. Map Potential Attack Paths

14. Validate Findings Safely

15. Assess Impact

16. Collect Evidence

17. Recommend Remediation

18. Report

Stage 38 — Prioritize Identity Risk

Not every issue has equal importance.

Consider:

Exposure
   +
Privilege
   +
Reachability
   +
Impact
   ↓
Identity Risk

For example, a weak configuration involving a low-privileged inactive test account may have less impact than the same weakness involving a highly privileged service account.

Context matters.

Stage 39 — Active Directory Remediation

Common security improvements include:

• removing unnecessary privileges

• reducing privileged-group membership

• enforcing least privilege

• securing service accounts

• strengthening authentication

• reducing legacy protocols

• protecting administrative accounts

• improving Group Policy

• separating administrative tiers

• monitoring privileged activity

• reviewing trust relationships

The objective is not simply:

Find the attack path.

The professional objective is:

Understand why the attack path exists and how to remove it.

Stage 40 — Reporting Active Directory Findings

A professional Active Directory finding should explain the relationship that creates risk.

Use a structure such as:

Finding Title:

Affected Domain:

Affected Objects:

Description:

Permission / Trust Relationship:

Evidence:

Attack Path:

Security Impact:

Likelihood:

Risk:

Root Cause:

Recommended Remediation:

Validation:

Active Directory Practice Worksheet

Use this during meaningful TryHackMe exercises.

Domain:

Domain Controller:

Current User:

Current Host:

Domain Users Identified:

Important Groups:

Privileged Groups:

Computers:

Service Accounts:

Authentication Mechanisms:

Interesting Permissions:

Group Policy Observations:

Trust Relationships:

Potential Attack Paths:

Validated Findings:

Affected Assets:

Security Impact:

Detection Opportunities:

Recommended Remediation:

Lessons Learned:

Build an Active Directory Map

For larger exercises, create a simplified map.

Example:

Domain: corp.local
│
├── DC01
│
├── FILE01
│
├── WEB01
│
│
├── Users
│   ├── alice
│   ├── bob
│   └── svc_backup
│
└── Groups
    ├── Domain Users
    ├── Helpdesk
    ├── Server Admins
    └── Domain Admins

Then add relationships.

alice
  ↓
Helpdesk
  ↓
Permission
  ↓
Server Admins
  ↓
FILE01

This makes complicated environments easier to understand.

Active Directory Skills Checklist

Before completing this path, evaluate yourself.

Architecture

• I understand what Active Directory is

• I understand domains

• I understand forests

• I understand Domain Controllers

• I understand Organizational Units

Identity

• I understand users

• I understand groups

• I understand computer accounts

• I understand service accounts

Policy

• I understand Group Policy

• I understand why centralized configuration matters

• I understand least privilege

Authentication

• I understand Kerberos conceptually

• I understand NTLM conceptually

• I understand tickets

• I understand service authentication

Enumeration

• I can identify the domain

• I can identify important users

• I can identify privileged groups

• I can identify computers

• I can identify service accounts

Permissions

• I understand AD permissions

• I understand why ACL relationships matter

• I understand delegated privileges

• I can recognize risky privilege relationships

Attack Paths

• I understand attack-path thinking

• I understand privilege escalation conceptually

• I understand lateral movement conceptually

• I can map relationships between identities and systems

Defensive Security

• I understand authentication monitoring

• I understand privileged-account monitoring

• I understand group-change monitoring

• I can connect AD activity to SOC investigation

Reporting

• I can document an AD security finding

• I can explain an attack path

• I can identify likely root cause

• I can recommend remediation

Think Like an Active Directory Security Professional

When approaching an AD environment, ask:

What domain am I working with?

Who are the important users?

Which accounts are privileged?

Which systems are important?

Which accounts administer those systems?

What groups create privilege?

What permissions connect identities?

What service accounts exist?

Which authentication methods are used?

Where are credentials likely to be exposed?

What trust relationships exist?

What attack paths are possible?

What would defenders see?

How can the path be removed?

This mindset is more valuable than memorizing individual Active Directory attack techniques.

From TryHackMe to GoHackersCloud Labs

Your progression should gradually become less guided.

Windows Fundamentals
        ↓
TryHackMe AD Practice
        ↓
AD Challenges
        ↓
GoHackersCloud AD Labs
        ↓
Enterprise Pentesting Labs
        ↓
AD Security Runbooks
        ↓
Independent Assessment
        ↓
Enterprise Attack-Path Analysis

At the advanced stage, you should be able to receive an unfamiliar Active Directory environment and systematically determine:

What exists?

Who has access?

Where are privileges concentrated?

Which relationships create risk?

What evidence proves the risk?

How should it be remediated?

What’s Next?

➡️ 06 Cloud Security Practice

Next, we move from traditional enterprise identity into modern cloud environments.

You will connect many of the concepts learned throughout this practice journey:

• identity

• permissions

• authentication

• networking

• exposed services

• configuration

• logging

• monitoring

• attack paths

• privilege escalation

• incident investigation

But the environment changes.

Instead of primarily thinking about:

User → Group → Computer → Domain

you will begin thinking about:

Identity
   ↓
Role / Permission
   ↓
Cloud Resource
   ↓
Workload
   ↓
Data

The Cloud Security Practice Path will prepare you to reason across AWS, Azure, Google Cloud and cloud-native security scenarios from both defensive and authorized offensive-security perspectives.