Maester is an open source PowerShell test automation framework that continuously monitors the security configuration of a Microsoft 365 tenant for authorized administrators and defenders.
| Tool | maester365/maester — PowerShell-based test automation framework for monitoring Microsoft 365 security configuration |
| Category | Security configuration testing / posture management |
| Primary Use | Running automated configuration and security tests against an Entra ID / Microsoft 365 tenant you administer, exporting results and wiring them into CI/CD pipelines |
| Safe Use | Intended for authorized tenant administrators and security teams assessing their own Microsoft 365 environments; purely defensive posture validation, no exploitation functionality |
| Telemetry Note | Runs authenticated Microsoft Graph and related API queries under an admin-controlled account; defenders observe it as legitimate read-heavy Graph activity from known automation identities in their own audit logs |
Maester occupies a niche that commercial CSPM products charge heavily for: continuous, test-driven validation of a Microsoft 365 tenant's security configuration. Written in PowerShell and distributed through the PowerShell Gallery, the project has accumulated over a thousand stars and an active contributor base, and the README makes clear it is squarely a defensive tool — there is nothing here an attacker would run against a tenant they don't control. Every test authenticates as an administrator of the tenant being assessed, which makes Maester a posture-management instrument rather than an attack tool by construction.
The core workflow is refreshingly minimal: Connect-Maester establishes authenticated sessions against the tenant, and Invoke-Maester executes the full built-in test suite. The tests ship inside the module itself, so there is no separate test corpus to download or synchronize — updating the module with Update-Module Maester -Force updates the tests. This bundling decision is architecturally significant: it means the test definitions are versioned alongside the engine, avoiding the drift that plagues frameworks where checks live in a separate repository from the code that interprets them.
Version 3.0 is the headline story in the current README, and it comes with real breaking changes. The preview build now requires PowerShell 7.4 or later and drops support for Windows PowerShell 5.1 entirely — a sensible modernization given how much of the Microsoft Graph SDK assumes modern PowerShell behavior, but one that will bite automation pipelines still pinned to 5.1. The README warns explicitly that automation installing with -AllowPrerelease, or using maester_version: preview in the GitHub Action, will get 3.0 unless operators pin -RequiredVersion 2.3.0 or switch to maester_version: latest. That is the kind of migration guidance that tells you the maintainers have production users depending on scheduled runs.
The test format itself was rewritten for 3.0. Checks are now native tests expressed as a pair of files: Test.<ID>.ps1, a PowerShell function carrying a [MaesterTest(...)] attribute, and Test.<ID>.md containing the description and remediation steps. This pairing of executable assertion with human-readable remediation is the pattern popularized by tools like PSRule and Inspec, and it is the right one — a failed check that tells the operator exactly how to fix the finding is worth far more than a boolean. For teams with investments in the old format, Convert-MtTest migrates Pester-style tests, and legacy Pester 5.7.1+ tests still run unconverted.
Custom test authoring is treated as a first-class workflow rather than an afterthought. New-MtTest -Id CONTOSO.1001 -Title 'Guest invitations are restricted' -Service Graph scaffolds a custom/Test.CONTOSO.1001.* pair; Get-MtTest -Path ./custom validates the test without ever touching a tenant, and Invoke-MtTest runs a single test in isolation. The example ID naming convention (CONTOSO.1001) hints at the intended audience: enterprises with their own baseline numbering who want house-policy checks sitting beside the community-maintained corpus. Per-tenant configuration lives in a maester-config.json passed via -Path, keeping test logic and environment parameters cleanly separated.
Reporting and notification coverage is broad. Results export to CSV, Excel, HTML, JSON, or Markdown, which covers both human review and machine ingestion into a SIEM or GRC pipeline. Notifications can be pushed to email, Teams, or Slack, meaning a scheduled run that detects a regression — say, a conditional access policy quietly disabled — can page the responsible team without anyone opening a dashboard. For an authorized internal security team, this turns Maester from a point-in-time audit script into a regression detector for tenant drift.
CI/CD integration is where the tool earns its devops and config-as-code topic tags. Beyond GitHub Actions — where it is published on the marketplace and moved to a dedicated maester365/maester-action repository, with a deprecation notice covering the old maester365/maester action path — the README lists Azure DevOps and GitLab pipelines as supported runners. Because it is built natively for GitHub, it plays well with Actions features like artifact upload and workflow-run summaries, so test results land directly in the run view an engineer already watches.
National cloud support deserves mention because it is often the deciding factor for government-adjacent work. Connect-Maester -Environment accepts Global, China, USGov, and USGovDOD, letting operators point the framework at the sovereign cloud instance their tenant actually lives in. Few open source tooling projects bother with USGovDOD endpoints, and its presence here signals that Maester has real adoption inside environments with strict compliance boundaries.
Operationally, two cautions stand out from the README. First, the maintainers recommend against ExchangeOnlineManagement v3.9.2 due to connection errors in that upstream module — a reminder that Maester's reliability is partly hostage to the Microsoft module ecosystem. Second, upgrading from 2.x requires cleanup: tests written by the old Install-MaesterTests are no longer used and should be removed via Update-MaesterTests -Path ./maester-tests unless custom content lives there. Building from source is straightforward via ./build/Build-LocalMaester.ps1, and the module/ folder is a git-ignored build artifact published to the Gallery from CI. For defenders who own their tenant and want evidence-based assurance that its configuration matches baseline, Maester is one of the most mature open source options in the Microsoft 365 ecosystem.
maester365/maester.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.