Maester now ships with 300+ Active Directory security tests across 20 categories. If you still run hybrid identity, that matters a lot more than another shiny AI feature.
My take: this is a genuinely welcome move. I already like Maester because it turns security review into something repeatable and scriptable instead of a once-a-year spreadsheet exercise. Extending that model into on-premises and hybrid AD is the right call, because plenty of environments still depend on AD even when Entra ID gets most of the attention.
What is new in Maester for Active Directory?
The new release adds AD-focused checks for users, groups, computers, SPNs, domain and forest settings, domain controllers, sites and subnets, password policies, GPOs, DACLs, DNS, trusts, replication, schema, and broader configuration state.
A few categories stand out because they catch the kind of problems that quietly survive for years:
- user accounts with passwords that never expire
- accounts trusted for delegation
- users with Kerberos pre-auth disabled
- DES-only Kerberos settings
- GPOs containing cpassword
- AD and Sysvol GPO version mismatches
- privileged or unresolved ACEs in DACLs
That is a good scope. Not just identity objects, but the plumbing around them. In real environments, the ugly stuff is often in DNS, old GPOs, stale trusts, or ACL drift nobody reviewed after the last migration.
Why I think this is the right direction
What I like here is the operating model. Maester keeps AD testing opt-in, and that is the correct default. Connect-Maester -Service All does not touch AD, and AD-tagged tests stay excluded until you explicitly connect to Active Directory in that PowerShell session. That is a sensible design for something that may run in mixed environments and pipelines.
It also fits how engineers actually work. If you already use PowerShell-based AI and automation audit patterns or broader workflow automation, adding AD checks into the same scheduled job or self-hosted runner is much easier than introducing another separate scanning product.
And yes, I also like that this stays close to the admin surface area. You need a Windows Server with the AD role or a domain-joined machine, PowerShell 5.1 or later, and the ActiveDirectory and GroupPolicy modules. No mystery appliance, no black-box SaaS collector.
How to run the new AD tests
The source gives the core commands, and they are refreshingly straightforward:
Install-Module Maester -Scope CurrentUser -Force
mkdir ~/maester-tests
cd ~/maester-tests
Install-MaesterTests
Import-Module Maester -Force
Connect-Maester -Service ActiveDirectory
Invoke-Maester -Path "./ad" -OutputFolder "./ad-results" -SkipGraphConnect -NonInteractive
You can also target specific areas instead of running everything:
Invoke-Maester -Path "./ad/user" -OutputFolder "./ad-results" -SkipGraphConnect -NonInteractive
Invoke-Maester -Path "./ad/gpostate" -OutputFolder "./ad-results" -SkipGraphConnect -NonInteractive
Invoke-Maester -Tag "AD.User" -OutputFolder "./ad-results" -SkipGraphConnect -NonInteractive
That path-based structure is practical. It makes it easy to separate quick daily checks from heavier weekly reviews.
What changes in practice
For most teams, this is not a replacement for a proper AD security assessment. It is better thought of as continuous hygiene testing. That is exactly why I like it.
The second-order effect is the important part: once these checks live in scheduled tasks or CI on a self-hosted Windows runner, drift becomes visible earlier. A weak password policy, a broken GPO permission, or a stale delegation setting stops being tribal knowledge and starts becoming an artifact you can track.
If you are building internal security automation, or even custom MCP server development that surfaces operational findings to engineers, Maester output becomes useful input data rather than just a point-in-time report.
What I would watch
The main limitation is obvious: full coverage requires Domain Admin or equivalent permissions. That is understandable, but treat it carefully. If security is the point, do not turn the testing account into another over-privileged forever-account without review.
Also, CI guidance is realistic: use a self-hosted Windows agent that can actually reach a domain controller and has the RSAT modules installed. Cloud-hosted runners are not going to help much here.
My bottom line: this is one of the better Maester expansions so far. It solves a real problem, it matches how Windows and identity teams already operate, and it gives hybrid shops a practical way to keep checking AD without buying into another heavyweight platform.
