Video summary

Active Directory Security Testing in Maester 2.2

Main summary

Key takeaways

Technology

Summary (Maester 2.2 / 2.0 focus: Active Directory security & operational testing)

  • Maester isn’t “dead” (Active Directory remains important). The discussion references Microsoft and conference messaging emphasizing AD persistence and valid long-term use cases, even though net-new use cases may be limited.
  • Maester’s value proposition: a test-driven platform where teams write and consume reusable checks to monitor, manage, and secure identity systems—particularly Active Directory (AD). It began with examples/samples, then expanded quickly through community contributions.

Community & adoption

  • Maester has grown to hundreds of contributors (spoken as ~130–140+).
  • It has seen 600,000+ downloads (with expectation of approaching 1M).
  • A major early catalyst was Michael, who provided a large set of working CISA-related AD tests, significantly expanding the test catalog.

Active Directory tests in Maester 2.0

  • The episode’s theme is that Maester 2.0’s big addition was AD-focused tests, particularly those written by Michael.
  • These tests combine operational health patterns with security assessments, informed by years of tool analysis and observed patterns across different AD forests/domains.

How Maester AD tests compare to other tools

The speakers compare Maester with tools such as:

  • PingCastle
  • Testimo
  • Locksmith
  • and others

Key distinction: many tools provide valuable checks, but Maester aims to bring them into a single central platform and to align checks around common operational/security themes for consistent “health check”-style assessment.

Maester’s AD tests are described as initially grounded in prior market/tool analysis (≈6 years ago) and then continually improved.

Pass/fail vs deeper investigation (metadata, tagging)

Some tests are binary pass/fail, but Maester adds more deeper metadata so teams can:

  • Flag which findings are worth regular monitoring/investigation
  • Use tagging (introduced previously) to track trends over time (e.g., whether anti-patterns are increasing or decreasing)

Example anti-pattern (operational): group nesting

  • Group nesting may be functional/intended, but long chains (4–6+ groups) become operationally confusing (hard to determine effective permissions) and can indirectly increase risk/incidents.

“Source of truth” for best practices / rules

Maester relies heavily on:

  • Community feedback
  • External guidance and best-practice documentation from multiple teams
  • Microsoft’s extensive AD documentation

The episode argues Microsoft continues to produce strong documentation and updates for legacy/older platforms—AD is framed as roughly ~30 years old but still actively documented and operationally improved.

Running AD assessments: workflow and permissions

Interactive mode

  • Can run in a PowerShell session with network connectivity (“line of sight”) to a domain controller.
  • Requires the AD PowerShell module for some interactions, but most data can be gathered using LDAP-style querying.

Permissions model

  • Most tests are read-only; therefore, typical domain user accounts can gather subset results.
  • For “tier-0”-like depth, higher privileges (tier zero endpoints / naming contexts) may be needed to run all tests and gain more analytical coverage.

Automation mode

  • Use a local runner or integrate into pipeline/container workflows (e.g., ensure connectivity to a DC from a controlled runtime).
  • Explicit selection/tagging is required to run AD tests—AD is not assumed by default.

Dependency direction: toward LDAP/NET over AD PowerShell module

The near-term direction is to reduce dependency on the Active Directory PowerShell module:

  • Discussion notes Locksmith moving away from the module and using largely LDAP query-level approaches.

Benefits:

  • Better eventual cross-platform potential (e.g., running from Linux/macOS or non-domain-joined systems)
  • Broader automation scenarios

Some AD-adjacent protocols may still be used (e.g., SMB lookups), but the goal is module independence.

Merging multi-scan results into one report

Maester already supports combining results from multiple runs:

  • A commandlet exists to merge results into a single HTML report.

Planned ergonomics include smoother execution across different test sets without PowerShell session conflicts (e.g., DLL/module conflicts when loading multiple workloads into one session).

Maester 3.0 roadmap (engine improvements)

Direction teased for Maester 3:

  • A new test execution engine separated from per-test licensing code
  • Improved performance via multi-threading/parallel tests
  • Running in environments like Azure Functions
  • Likely keep Pester for backward compatibility, but implement a more scalable core engine

This is framed as a major shift to improve licensing/engine management and execution efficiency.

Performance & safety guidance (important)

The episode addresses AD scanning concerns directly:

  • It’s unlikely to “take down” AD unless the environment already has performance problems.
  • However, it can generate a significant number of LDAP calls and depends on PowerShell runtime behavior.

Primary risk: PowerShell caching/memory usage

  • PowerShell can cache data in memory; for large ADs, caching may become huge.
  • Memory limits can cause scans to take hours and potentially run out of memory.

Strong recommendation

  • Do not run directly on a domain controller.
  • Run from a privileged workstation or controlled environment.
  • Prefer targeted test selection rather than default full cache population.

Practical strategy for big environments

  • Use tags/exclude to split tests into batches, then merge reports afterward to avoid memory/time constraints.

Multi-domain / multi-forest realities

  • Current limitation: AD tests are effectively single-domain at a time.
  • Aggregation is possible but may require “surgery” (piece JSONs together / merge into HTML).
  • Future automation is expected to simplify aggregation across multi-domain / multi-forest setups.

Tiering model testing (AD security administration)

The episode includes a focused discussion of AD tiering, mentioning:

  • ESAE
  • EAM (management forest / reduced implicit trust)

The more common operational model discussed is tier 0 / tier 1 / tier 2 based on access control groups and object-level protections.

Maester intent:

  • Codify Microsoft tiering guidance into codified tests
  • Some existing tests relate to legacy/unsafe ACL inheritance and DA-like practices, which can connect to tiering hygiene
  • Some tiering-related discovery tests are noted to have performance impact and may require improvement

Beyond AD: what else Maester could monitor

Maester can support unit-test style posture/state validation, not just “configuration change” tooling.

Example (on-prem, bespoke):

  • Build fresh VMs daily
  • Run Maester checks to verify endpoint baseline configurations are applied correctly (e.g., profiles/groups, BitLocker, tune policies, build status reporting)

GPO pain point addressed

  • GPOs are powerful but often lack strong reporting for the actual resulting state on endpoints.
  • Maester can validate “what’s applied” rather than trusting assumed configuration.

DSC-adjacent comparison

  • Maester is framed as more approachable for unit testing and reporting than DSC’s author/compile/deploy workflow.
  • Maester focuses on evidence-based state validation with human-readable results, complementing IaC/config-management tools.

Product sponsors / segment

  • The video includes a sponsor segment for AppGubScore (Entra app governance/risk visibility), but the technical core discussion remains on Maester.

Main speakers / sources

  • Michael (Michael Soul) — co-maintainer; major contributor to AD tests (including CISA-related tests); discusses Maester 2.x AD testing and roadmap.
  • Sam — co-host / contributor; provides context on Maester history and integration/usage questions.
  • Fabian — referenced as part of the original Maester work (history contributor; not the main speaker in the excerpt).
  • Jake — referenced as presenting and as someone building/iterating on related tooling concepts (mentions Locksmith).
  • Steve — referenced in the context of NLM troubleshooting/telemetry discussion (likely a Microsoft team member; not fully identified).

Original video