We talk about why Maester exists (starting with a Conditional Access policy that looked right in the portal but protected no one for a year), and then walk through what's new in 3.0: the new test engine, drift tracking between runs, tests that skip themselves when the tenant isn't licensed, framework mappings, and the affected objects view. We also cover MaesterCloud for MSPs who manage many tenants, and community Packs.

If the episode inspires you to write your own checks, try the brand new Test Builder: pick the attributes of your test in a form, see the rule for each one, and get the code for your test as you go.

For the full story, head over to the Syncro blog, where Rich has written up the episode with a TL;DR and a list of what to do on Monday: Maester 3.0: First Look at Microsoft 365 Security Testing. You can also watch it on Vimeo.

If you run Maester on a schedule, read the Maester 3.0 announcement before your next run picks up the new version.

If you're using Maester interactively and want to see what's coming, the preview is exactly where we want you. Try it, and tell us what breaks.

This post has two halves. The first half covers what most of you will notice: you no longer install a tests folder, and the way a test is written has changed. The second half is the technical detail for people who build pipelines on Maester, write a lot of custom tests, or just want to know how it works.

Maester 2.x and 3.0 side by side​

In 2.x a check came in two parts: a function in the module, and a Pester It block in a *.Tests.ps1 file that you copied into your own folder. Pester found and ran those files, so selecting, skipping and reporting all went through Pester.

Anatomy of a native test​

A Maester 3.0 test is a pair of files. Every test that ships with Maester is written this way, and your own tests use the same format.

Here's a real built-in test, MT.1012, shortened:

function Test-MtCaMfaForRiskySignIn {
    [MaesterTest(
        Id                = 'MT.1012',
        Title             = 'At least one Conditional Access policy is configured to require MFA for risky sign-ins.',
        Severity          = 'High',
        Category          = 'Maester/Entra',
        Tag               = ('CA', 'Maester'),
        Service           = 'Graph',            # skipped when Graph is not connected
        License = 'AAD_PREMIUM_P2',   # skipped when the tenant has no Entra ID P2
        Author            = 'f-bader'
    )]
    [CmdletBinding()]
    [OutputType([bool])]
    param ()

    $policies = Get-MtConditionalAccessPolicy | Where-Object { $_.state -eq 'enabled' }
    # ... decide, then:
    Add-MtTestResultDetail -Result $markdown
    return $result
}

Notice what isn't there: no connection check, no licence check, and no outer try/catch. The test declares what it needs, and the engine handles the rest. In 2.x every check carried that boilerplate, and every check got it slightly differently.

The attribute is read, never run​

Maester reads [MaesterTest] straight from the file's syntax tree. Listing tests, building the catalog and doing a dry run never execute any test code. That's why the values have to be constants: quoted strings, $true/$false, or a list in parentheses.

The Markdown file​

Disabled Conditional Access policies must say why they are disabled, in the form `Disabled: <reason>`.

#### Remediation action

1. In the Microsoft Entra admin center, open **Protection** > **Conditional Access** > **Policies**.
2. For each policy listed below, add the reason to its name, or delete the policy.

<!--- Results --->
%TestResult%

Everything above <!--- Results ---> is the description in the report. %TestResult% is replaced with what you pass to Add-MtTestResultDetail -Result. The report shows the description even for tests that didn't run, so readers always see what a test is about.

What a test returns​

The function's job is to return a verdict. The engine turns it into a result row:

Parameters you can tune​

A test's param() block lists the values a user can change per tenant: thresholds, switches, objects to exclude. Each parameter needs a one-line description, and [MaesterParameter(Kind = ...)] tells a user interface what kind of object to offer.

param(
    # Longest validity period, in days, that a certificate may be issued for.
    [ValidateRange(1, 3650)]
    [int] $MaximumValidityDays = 365,

    # Members of these groups are exempt from this check.
    [MaesterParameter(Kind = 'Entra.Group')]
    [string[]] $ExcludedGroups
)

Values are set in maester-config.json and checked against the param() block before the test runs:

{
  "TestSettings": [
    { "Id": "MT.1198", "Parameters": { "MaximumValidityDays": 180 } },
    { "Id": "MT.1012", "Severity": "Critical" },
    { "Id": "MT.1005", "Enabled": false, "Reason": "Handled by another control" }
  ]
}

That last row matters if you used to delete test files to turn tests off. In 3.0 the built-in tests come from the module, so disable a test in the config instead.

Write your first native test​

The whole loop works offline until you actually run against a tenant:

# 1. Create Custom/Test.CONTOSO.1001.ps1 and Custom/Test.CONTOSO.1001.md
New-MtTest -Id CONTOSO.1001 -Title 'Guest invitations are restricted' -Service Graph -Severity High

# 2. Validate the metadata. No tenant connection needed.
Get-MtTest -Path ./Custom

# 3. Run just this test while you write it
Connect-Maester
Invoke-MtTest -Path ./Custom/Test.CONTOSO.1001.ps1

# 4. See what a full run would do, without running anything
Invoke-Maester -Path . -DryRun

Use a prefix of your own for IDs (CONTOSO.1001). The MT., CIS., CISA., EIDSCA., ORCA., AD- and AZDO. prefixes belong to the built-in tests.

Your existing Pester tests keep working​

Custom tests written for 2.x (*.Tests.ps1) still run, and their results appear in the same report. You just need Pester 5.7.1 or later installed yourself, because Maester no longer installs it. When you're ready to move over, Convert-MtTest -Path ./Custom converts them to native tests and tells you what needs a manual touch.

The life of an Invoke-Maester run​

Everything below is PowerShell except one step, which runs in a small C# engine that ships inside the module.

1. Resolve the run config

   Merge the config layers into one object: selection, test settings, environment overrides, output options.

2. Find the test sources

   Built-in tests always come from the module. -Path adds your custom folder; -SkipBuiltIn runs your custom tests only.

3. Discover tests from metadata

   Built-ins come from a catalog file in the module. Custom native tests are read from their syntax trees; Pester files get a static inventory.

4. Work out the selection

   Combine -Tag, -ExcludeTag, -TestId, -ExcludeTestId, the include switches and the config. Stale 2.x copies of built-in tests in your folder are skipped.

5. Build the tenant context

   Which services are connected, which licences the tenant has, tenant type, cloud and platform.

6. Plan: apply the gates

   Each test passes the gates in order, or gets a row with a reason code. Parameters from config are bound and type-checked here.

7. ExecuteC#

   The engine runs each planned test, captures its output, enforces timeouts and decides the outcome. Families expand into instances first.

8. Run Pester-format custom tests

   Pester is imported only now, and only if you have Pester tests. Without Pester, those tests become Error rows and everything else still runs.

9. Build the result and write the outputs

   Native and Pester rows merge into one result: HTML report, JSON, Markdown, CSV/Excel, NUnit or JUnit XML, mail and Teams.

Gates and reason codes​

Every test passes through the same gates, in the same order. The first gate that fails decides the result and the reason code, so the report always tells you why a test didn't run.

The six results are unchanged from 2.x:

The HTML report has a new reason column and filter, so a page full of skipped tests now explains itself.

Configuration layers​

Config files are found from -Path: the folder, its tests subfolder, and up to five parent folders. Layers merge from the bottom up, and each one only needs the settings it changes.

Pipelines can skip discovery entirely with -Config (a path, a hashtable or both) or the MAESTER_CONFIG environment variable.

The C# engine​

The engine is a 37 KB DLL loaded as a nested module, and it does three jobs:

Reliable timeouts, cancellation, and catching every way a script can end are hard to get right in pure PowerShell, so that part is C#. Everything else (selection, gates, config, families, results) stays in PowerShell. The scheduler is built for parallel runs, but 3.0 runs one test at a time on your session to stay as close to 2.x behaviour as possible.

The DLL is committed to the repository, so you never need the .NET SDK. CI rebuilds it from source on every change and fails if the bytes differ.

Families: one test, many results​

Some checks run once per item: once per Entra recommendation, per Defender for Identity health issue, per drift folder. In 2.x these were Pester -ForEach blocks. In 3.0 the test names an InstanceSource function in the same file, and each item becomes its own row, such as MT.1024.<suffix>. -TestId MT.1024.* selects the whole family. The source only runs when the test actually runs, never during discovery or a dry run.

Results and outputs​

The result JSON keeps its 2.x shape, so anything that reads it keeps working. Schema 2.1 only adds fields: ReasonCode, ReasonDetail, Source, Format (Native or Pester), Parameters and Diagnostics on each row; TenantContext, RunMetadata and Selection at the top level.

Maester now writes the NUnit 2.5 or JUnit XML file itself, for native and Pester tests together, with the same test-case names your pipelines expect. A run split across processes or containers merges back into one report with Merge-MtMaesterResult -SameRun.

What to do when you move to 3.0​

1. Run Maester on PowerShell 7.4 or later.

2. Update the module, remove Maester 2.x, and start a new session:

   Update-Module Maester -AllowPrerelease -Force
   Uninstall-Module Maester -MaximumVersion 2.99.99 -AllVersions
   

3. Clean up your tests folder with Update-MaesterTests -Path ./maester-tests -WhatIf, then without -WhatIf. It removes the 2.x copies of the built-in tests and keeps your custom tests and config.

4. If you disabled built-in tests by deleting their files, disable them in maester-config.json instead.

5. If you have Pester-format custom tests, install Pester 5.7.1 or later, or convert them with Convert-MtTest.

6. If a custom test calls a built-in Test-Mt* function, call Invoke-MtTest -Id <ID> instead. The check functions are no longer exported.

7. Try your usual command with -DryRun first to see what would run.

A few results can come out differently from 2.x. The main one: a built-in test that throws is now Error, not Failed, so your failed count can go down and your error count up. The upgrade guide lists every change, and the native test guide covers the format in full. Both are in the preview docs from 8 October.

Tell us what breaks​

This is the biggest change to Maester since it started. All 747 built-in checks moved to the new format, with tests that hold selection and tags to their 2.x behaviour, but your tenants and pipelines will find things ours didn't. If something breaks, please open an issue with the command you ran and what you saw. The work is in maester365/maester#2334 if you want to dig in.

Contributions have been paused during the rewrite. They reopen once 3.0 is on main, and new checks should use the native format from then on.

2.2 went wide. 2.3 goes deep: the objects behind every failed check, AI agents in Microsoft Entra, the latest CIS benchmark, the Macs and code repositories in your estate, and a hard look at how Maester itself handles the data it collects from your tenant.

Highlights​

• Security hardening for the report, email, and pipeline output. Please update.
• 14 Microsoft Entra Agent ID checks for orphaned, over-privileged, and unowned AI agent identities
• CIS Microsoft 365 Foundations Benchmark v7.0.0, with updated logic and guidance across the CIS checks
• 4 new Entra ID checks for dynamic group rules (including the memberOf operator Microsoft retires on November 3) and app registration credentials
• 4 macOS checks for Intune compliance and enrollment
• 7 Azure DevOps checks for GitHub Advanced Security Secret Protection, Code Security, and Copilot code review
• Multi-forest Active Directory, Kerberos (GSSAPI) over SSH for testing AD from Linux and macOS, and severity ratings for the AD checks
• A new Affected objects report that shows every policy, user, app, and group behind your failed checks, plus optional user identity redaction
• A rebuilt HTML report that's about 85% smaller and opens without a single network request
• A clearer Connect-Maester that ends with a per-service summary and keeps going when one service fails
• More reliable runs: Graph retries, sovereign cloud fixes, PIM license fallback, and skips that are no longer reported as errors

Security hardening​

A Maester report is built from data in your tenant, and some of that data is controlled by people you don't fully trust. Anyone who can register an app or accept a guest invite can choose a display name.

Jan-Henrik Damaschke privately reported that a crafted display name could break out of the report's embedded data and run script when the report was opened (GHSA-65g9-g8h8-qw5g). Thank you for the responsible disclosure. That's fixed, and we went looking for related problems while we were there:

• Report data is escaped before it's embedded, so values can no longer end the script block
• Markdown injection: tenant-controlled names are now escaped in 48 checks, so a name can't render as a fake link, a tracking image, or a broken table. As a backstop, the report only renders images that are embedded or hosted on maester.dev
• Email alerts: Send-MtMail now HTML-encodes every dynamic value, and Invoke-Maester validates -MailTestResultsUri before the run starts
• GitHub Actions: token and input handling in our workflows has been tightened

We recommend everyone update to 2.3, and run Update-MaesterTests so your test files pick up the escaping changes too. If you write custom tests, wrap any tenant-controlled value in Get-MtSafeMarkdown before adding it to a result.

Special thanks to Fabian Bader for the email hardening and Travis McDade for the GitHub Actions hardening.

Security checks for Microsoft Entra Agent ID​

AI agents are getting their own identities in Microsoft Entra, and they come with all the identity problems you already know: no owner, no sponsor, stale credentials, too many permissions. They're also new enough that most tenants have no process for reviewing them yet.

Fourteen new preview checks (MT.1200, MT.1201, MT.1203 to MT.1213, and MT.1223) cover the Agent ID lifecycle:

• Orphaned objects: agent identities, agent users, and blueprint principals whose parent no longer exists
• Ownership and sponsorship: agents and blueprints that need active, enabled owners and assigned sponsors
• Inactive agents: enabled agent identities with no sign-in activity in 180 days
• Privileged access: agents holding privileged directory roles, membership in role-assignable groups, or high-risk Microsoft Graph permissions, including foreign and multi-tenant agents
• Blueprint hygiene: expired or long-lived credentials, allAllowed permission inheritance, unassigned app roles, and wildcard or plain-HTTP redirect URIs

The Agent ID Graph APIs are still in preview, so these checks are tagged Preview and need the preview scopes. Several of them make a Graph call per object, so those are also tagged LongRunning:

Connect-Maester -IncludePreview
Invoke-Maester -IncludePreview -IncludeLongRunning

Special thanks to Agnivesh for building this coverage.

CIS Microsoft 365 Foundations Benchmark v7.0.0​

The CIS checks now follow v7.0.0 of the benchmark. This is more than a version bump:

• Two controls moved from Level 2 to Level 1 (device compliance, and blocking users from registering applications)
• The attachment-filter check verifies that all 53 CIS default extensions are blocked, not just that the filter is on, and the comprehensive filter list picks up apk and library
• The DKIM check now excludes initial (onmicrosoft.com) and coexistence domains entirely, instead of passing them automatically
• SharePoint guest access expiration must be exactly 30 days
• The Microsoft 365 group audit only looks at unified groups, matching the new benchmark audit
• The Teams app permission policy check has been retitled and drops the retired "Microsoft apps" step
• The guest dynamic group control (5.1.3.1) is no longer in the benchmark, so we've removed it

Rationale, impact, and remediation text has been refreshed across the CIS documentation. If you report against CIS, expect some results to change after you update.

Special thanks to Morten Mynster for the v7.0.0 update.

More Entra ID checks​

Four new checks look at things that are easy to set up once and forget:

MT.1198 closes a gap that app management policies leave open. Those policies only apply to credentials added after the policy takes effect, so a tenant can pass MT.1002 and still authenticate with multi-year certificates issued years ago.

memberOf dynamic groups stop updating on November 3​

Microsoft sent its final reminder on October 5:

After November 3, dynamic groups that use the memberOf operator stop updating. Their membership freezes, and anything that relies on them, like license assignments and Conditional Access policies, keeps working from that stale membership.

Run Maester 2.3 and MT.1197 finds these groups for you. It lists each affected group with its source groups, assigned licenses, and any Conditional Access policies that reference it, so you can see what breaks before it does:

Invoke-Maester -Tag "MT.1197"

MT.1197 checks dynamic groups. The retirement also covers administrative units and entitlement management policies that use memberOf, so review those as well.

Special thanks to Agnivesh for the dynamic group checks and Simon Vedder for the app registration credential checks.

macOS coverage in Intune​

Until now, Maester's Apple coverage stopped at certificate and token expiry. Four new checks look at the Macs themselves:

The three compliance checks only count policies that are actually assigned. MT.1217 looks at every Automated Device Enrollment profile, and flags any that create an admin account without rotating its password, since that gives every Mac the same static local admin password.

On the Windows side, the BitLocker (MT.1123) and Attack Surface Reduction (MT.1178) checks now detect settings configured through the Settings catalog.

Special thanks to Daniel Lystad for the macOS checks and Roy Klooster for the Settings catalog fixes.

Azure DevOps: Advanced Security and Copilot code review​

GitHub Advanced Security for Azure DevOps is now sold as two separate plans, Secret Protection and Code Security. The existing AZDO.1026 check only covered the old bundled offering, so organizations on the new plans got no signal at all.

Six new checks, AZDO.1039 to AZDO.1044, cover each plan from three angles: whether new repositories are enrolled automatically, whether existing repositories are enrolled, and whether the protections are actually on (push protection for secrets, dependency and CodeQL alerts for code). Splitting these matters. Auto-enrollment only applies to new repositories, so an organization can have the toggle on and still leave a large share of its existing repositories unprotected.

A seventh preview check, AZDO.1045, reports whether Copilot code review is allowed for repositories.

Special thanks to Sebastian Claesson for these checks.

Active Directory: multi-forest and cross-platform​

The Active Directory checks we shipped in 2.2 got a lot of real-world feedback, and 2.3 acts on it:

• Multi-forest targeting: Connect-Maester accepts -ActiveDirectoryDomain and -ActiveDirectoryForest so you can target child domains and separate forests
• Kerberos over SSH: run AD checks from Linux and macOS through GSSAPI-authenticated SSH, with domain controller discovery through DNS SRV records
• Richer forest data: FSMO role holders, UPN and SPN suffixes, and cross-forest references
• More resilient LDAP: individual queries recover from missing attributes instead of failing the whole collection, and AD libraries only load when you actually test AD
• Computer name targeting when collecting domain state
• Connection fixes: WinRM falls back to HTTP with Negotiate encryption when HTTPS fails and you've supplied credentials, and a domain controller without LDAPS or StartTLS now gives a clear error
• Cache scoped to the target: switching between domains no longer returns cached data from the previous one
• SYSVOL on PowerShell 7.2: SYSVOL content collection now works on PowerShell 7.2
• Easier troubleshooting: -Verbose now shows each step of the LDAP connection, certificate problems are detected and explained, and a new troubleshooting guide covers the common connection errors. On Linux and macOS, Maester skips StartTLS by default because of an upstream .NET bug

The AD checks also have severity ratings now. Checks that match a checkpoint in the CERT-FR (ANSSI) Active Directory checklist take their severity from it and link to it in their docs. Inventory-only checks are rated Info. A small number that need a closer look are still unrated. The AD checks also have their own pages in the Tests section of maester.dev, so you can browse them like any other suite.

The AD checks are still in preview and we're still working through feedback, so keep it coming.

Special thanks to Mike Soule for the refactor and connection fixes, Agnivesh for the severity ratings and AD test pages, and everyone who ran the preview against their own domains and told us what broke.

See what your failed checks actually affect​

A Maester report tells you which checks failed. The question that usually comes next is what does this affect? Which Conditional Access policies, which users, which apps? Until now, the answer was buried in the details of each result.

The new Affected objects report turns that around. Run Maester with -IncludeAffectedObjects and the HTML report gets a new page that lists every object your checks pointed at, alongside every check that pointed at it:

Invoke-Maester -IncludeAffectedObjects

• One tile per object type, showing how many objects have failed checks. The tiles work like tabs: All objects shows everything, and selecting a type, such as User, shows only that type
• Sorted for remediation: by severity, Critical first, then by the number of failed checks, so the objects to fix first are at the top
• Filters for severity and result. Select Failed, and each row shows only its failed checks. One click on the clear filter button resets everything
• Expand a row to see each check that referenced the object, and select a check to open its result without leaving the page
• Select the object's name to open it in the admin portal

A second tab, Data touched, lists everything the run read, with a tile for each area: Intune, Entra roles, PIM alerts, and so on. It's a quick way to see the scope of what Maester looked at.

The same list is also saved next to your results as <name>-affected-objects.json, and as a CSV when you use -ExportCsv, so you can feed it into your own tooling. Nothing is collected unless you pass the switch.

Running Maester from the GitHub Action? Set include_affected_objects: true and the report and JSON file are included in the uploaded results:

- uses: maester365/maester-action@main
  with:
    tenant_id: ${{ secrets.AZURE_TENANT_ID }}
    client_id: ${{ secrets.AZURE_CLIENT_ID }}
    include_affected_objects: true

Redact user identities​

Sharing a report outside your security team? -RedactUserIdentity replaces user display names, UPNs, and object IDs with a stable token:

# Redact the HTML report, keep real identifiers in the JSON, CSV, and other exports
Invoke-Maester -IncludeAffectedObjects -RedactUserIdentity HtmlOnly

# Redact every output
Invoke-Maester -RedactUserIdentity AllOutputs

Two things to know before you rely on it. This is pseudonymization, not anonymization: the token is an unsalted hash, so anyone with a list of candidate users can reverse it. And it's best effort: only users the run read from Microsoft Graph (plus the signed-in account) are replaced, and email and Teams notifications aren't redacted.

Special thanks to Thomas Naunheim for building the Affected objects report and redaction.

A smaller, faster report​

The HTML report has been rebuilt on a much smaller stack. It looks the same, and filters, search, deep links, keyboard navigation, and multi-tenant reports all work as before, but:

• The report app is about 85% smaller (2.24 MB down to 335 kB)
• The favicon is embedded, so a report opens with no network requests at all. That helps when you open reports offline, send them by email, or host them behind a strict Content Security Policy
• Reports no longer embed each test's internal PowerShell error record. That shaved 40% off a real 764-test report, and stops local file paths (like your user name) from leaking into reports you share
• The result panel slides in more smoothly, the theme toggle is instant, the table no longer jumps when you select a row, and long test IDs are truncated instead of overlapping the title

Special thanks to Jan-Henrik Damaschke for the rebuild.

A clearer Connect-Maester​

Connect-Maester -Service All used to print a stream of warnings, even for services you never meant to use. Now it finishes with a single table that shows what happened to each service:

Service                Status     Details
-------                ------     -------
Microsoft Graph        Connected  admin@contoso.com
Azure                  Connected  admin@contoso.com
Dataverse              Skipped    No environment found, set DataverseEnvironmentUrl in maester-config.json
Exchange Online        Connected  admin@contoso.com
Security & Compliance  Connected  admin@contoso.com
Microsoft Teams        Connected  admin@contoso.com
SharePoint Online      Skipped    -SharePointClientId was not provided

• One failure no longer stops the rest. Previously, a sign-in error from one service stopped Connect-Maester, and every service after it was never tried. Now that service is marked Failed with the first line of the error, and the rest still connect
• Missing modules show the Install-Module command you need
• The full details are still available with -Verbose
• Admin consent: Global Readers and other non-admins who hit "Approval required" now get clear steps to get consent, instead of a cryptic User canceled authentication

Special thanks to Morten Mynster for the idea and proposal behind the connection summary, and Rafał Fitt for the admin consent guidance.

More reliable runs​

A lot of this release is about Maester behaving well in tenants that aren't quite like ours:

• Transient Graph errors: 500 and 502 responses are retried, with backoff, for requests that are safe to repeat
• PIM licensing: when the PIM API rejects a tenant's license, role lookups fall back to role assignments instead of erroring out the CIS checks that depend on them
• Sovereign clouds: requests that were hard-coded to the global Graph endpoint now use the cloud you connected to
• Long runs: Connect-Maester -ClientTimeout passes a longer HTTP timeout through to Microsoft Graph
• Skips stay skips: a check that skipped from inside its own error handling was reported as Error. That affected 17 checks, and it's now fixed centrally, so your custom tests benefit too
• Azure DevOps: a saved ADOPS sign-in with an expired token no longer turns every Azure DevOps test into an error. The tests now skip with "Not connected to Azure DevOps"
• Copilot Studio: when the agent query fails, the MT.1113 to MT.1122 skips now say why (for example, a missing Dataverse permission) instead of dumping raw JSON to the console
• ORCA checks in scripts: when the module was imported from inside a script (as many CI pipelines do), every ORCA check failed with Cannot find type [PolicyInfo]. The ORCA classes now load in the module's own scope
• No runtime downloads for role tiers: the privileged-role classification used by the permanent role and PIM alert checks now ships with the module instead of being downloaded from GitHub at runtime. It's refreshed automatically through a reviewed pull request each month
• Exposure Management: the XSPM identity queries use the correct Advanced Hunting schema, and the external data sources they use can be pointed at your own mirrors
• Fewer false positives: the MFA checks ignore risk-scoped Conditional Access policies, break-glass accounts are excluded from risk recommendations, MT.1011 explains why browser-scoped policies don't match, and checks that can't be verified now skip with a reason instead of failing silently

Special thanks to Nathan McNulty, Sebastian Claesson, Matthias, Rafał Fitt, eduardarbona, Sam Erde, and Massimo Mazzariol.

Website and docs​

• EIDSCA test pages now include the remediation action for each setting
• "Edit this page" links work again
• Product names and accessibility were cleaned up across the docs
• And yes, the homepage will now tell you how to pronounce Maester 🔊

Thank you to every contributor​

Maester 2.3 includes contributions from 25 people:

• Agnivesh for the Agent ID and dynamic group checks, Active Directory severity ratings, and generated docs fixes.
• Beerd Veldman for fixing typos across the docs.
• Daniel Lystad for the four macOS checks.
• eduardarbona for fixing false positives and silent failures in several Entra and Global Secure Access checks.
• Fabian Bader for hardening Send-MtMail against HTML injection.
• Haris Habib for handling missing DKIM signing configurations.
• Jan Bakker for teaching the homepage how to say "Maester".
• Jan-Henrik Damaschke for responsibly disclosing the report vulnerability and rebuilding the report.
• John Flores for branding and accessibility fixes across the docs.
• Massimo Mazzariol for fixes to BitLocker, Azure DevOps, Entra recommendation links, and unit tests.
• Matthias for the Graph client timeout, the CISA DKIM coexistence fix, and clearer Entra Connect guidance.
• Michael Morten Sonne for documenting the risks of client secret authentication.
• Mike Soule for multi-forest, cross-platform Active Directory support, AD connection fixes, and the AD troubleshooting guide.
• Morten Mynster for updating the CIS checks to v7.0.0 and proposing the Connect-Maester connection summary.
• Nathan McNulty for Graph retries, the PIM fallback, the embedded role classification, and XSPM data sources.
• Rafał Fitt for admin consent guidance in Connect-Maester and fixing the XSPM identity queries.
• Roy Klooster for Settings catalog support in the BitLocker and ASR checks.
• Sam Erde for MFA check fixes, telemetry timeouts, and agent instructions for contributors.
• Sebastian Claesson for the Azure DevOps Advanced Security checks and sovereign cloud fixes.
• Simon Vedder for the app registration credential checks.
• Stefan Wey for EIDSCA remediation docs and fixing "Edit this page".
• Thomas Naunheim for the Affected objects report and user identity redaction.
• Thomas S. Schmidt for centralizing the module preamble.
• Travis McDade for hardening our GitHub Actions workflows.
• Merill Fernando for security hardening, the Connect-Maester summary, report polish, and release and automation improvements.

Thank you as well to everyone who reviewed a pull request, reported an issue, tested a preview build, or ran the AD checks against a domain we'll never see. Your feedback shaped this release.

Get Maester 2.3​

Update the module and your test collection:

Update-Module Maester
Update-MaesterTests

Then explore what's new:

# Affected objects report
Invoke-Maester -IncludeAffectedObjects

# Microsoft Entra Agent ID (preview)
Connect-Maester -IncludePreview
Invoke-Maester -Tag "MT.1200", "MT.1201", "MT.1203", "MT.1204", "MT.1205", "MT.1206", "MT.1207", "MT.1208", "MT.1209", "MT.1210", "MT.1211", "MT.1212", "MT.1213", "MT.1223" -IncludePreview -IncludeLongRunning

# Dynamic groups and app registration credentials
Invoke-Maester -Tag "MT.1196", "MT.1197", "MT.1198", "MT.1199"

# macOS
Invoke-Maester -Tag "MT.1214", "MT.1215", "MT.1216", "MT.1217"

# CIS Microsoft 365 Foundations Benchmark v7.0.0
Invoke-Maester -Tag "CIS"

Maester now tests the agents you're deploying, the Macs and repositories they run on, and itself, and shows you exactly which objects each failure affects. Go check the agent identities in your tenant before someone else does.

A sneak peek at Maester 3.0​

While 2.3 was coming together, we started on something much bigger: a rewrite of how Maester discovers and runs tests. It's still early, and the details may change, but here's where it's heading:

• A native test engine. Maester 3.0 runs its checks itself instead of through Pester. Pester becomes optional, and your existing custom Pester tests keep working alongside the native ones. There's also a converter if you want to move them over.
• Built-in tests ship inside the module. No more copying hundreds of test files into your repo or keeping them up to date with Update-MaesterTests. Your tests folder only holds your own tests and configuration.
• The engine handles connections and licences. Each check declares which services and licences it needs, and the engine decides whether to run or skip it, with a consistent reason.
• More control over each run. Pick tests by ID, preview a run with -DryRun, and keep your settings in a single run configuration file.
• Ready for parallel runs. 3.0 still runs one test at a time, but it's built so a later release can run tests in parallel.

One heads-up: Maester 3.0 will need PowerShell 7.4 or later. If you're still on Windows PowerShell 5.1, now is a good time to plan the move.

It's a big change under the hood, and it gives us the room to build what's next without fighting the framework. You can follow along, and share your feedback, in the Maester 3.0 RFC.

Thank you to our Maester Cloud supporters​

A big thank you to everyone who supports Maester Cloud. Your support is what lets Merill Fernando spend more time on open-source Maester, and much of what's in this release comes from that time.

If you'd like to help too, take a look at the Maester Cloud supporters page.

Happy testing! 🎉

Since 2.1.0 shipped in May, the community has kept up an incredible pace: 261 commits and 311 new tests. Maester now stretches all the way from your on-premises Active Directory to AI data security with Microsoft Purview, SharePoint Online, GitHub, Global Secure Access, and Intune.

Highlights​

• 269 Active Directory checks across identity, policy, infrastructure, DNS, trusts, replication, and access control
• 5 Microsoft Purview checks to get your data security foundations ready for Copilot and AI
• 12 new SharePoint Online checks across the CIS and CISA baselines, now cross-platform with PnP.PowerShell
• 5 CIS GitHub organization controls and first-class GitHub connectivity
• 9 Global Secure Access checks for Private Access, forwarding profiles, Compliant Network, and Internet Access
• 4 Intune endpoint security checks for LAPS, attack surface reduction, App Control for Business, and Managed Installer
• New Entra ID checks covering agent risk, directory sync safeguards, Conditional Access gaps, legacy MSOnline, and privileged first-party apps
• A sharper report with markdown summaries, per-test durations, and critical findings sorted first
• Contributor credits across maester.dev, so the people writing these tests get the recognition they deserve

Deep Active Directory coverage​

This is the big one. Maester can now test your on-premises Active Directory alongside Microsoft 365 and Microsoft Entra.

The release adds 269 opt-in AD checks across 19 areas, including:

• Users, groups, computers, and service principal names
• Password policy and fine-grained password policy
• Domain, forest, domain controller, site, subnet, and replication health
• DNS, trusts, schema, and directory configuration
• Group Policy inventory and state
• DACL and privileged access analysis

AD testing is opt-in by design. Connect-Maester -Service All will not touch your domain controllers. When you're ready, connect explicitly:

Connect-Maester -Service ActiveDirectory
Invoke-Maester -Path "./ad" -SkipGraphConnect -NonInteractive

This first release is a preview, and we'd love your feedback: how the results look in your environment, how the checks perform in larger domains, and where the thresholds or remediation guidance could be better. Open an issue or come chat in the Maester Discord.

Special thanks to Mike Soule for building and validating this massive new area of Maester.

Microsoft Purview and AI data security​

Everyone is rolling out Copilot right now. Far fewer teams have checked whether their data security foundations are ready for it.

The new MT.1172 to MT.1176 checks confirm the basics are in place before AI starts touching your data:

• Unified audit log ingestion is enabled
• Sensitivity labels for files are published
• An Insider Risk Management policy covers risky AI usage
• A DLP policy covers the Microsoft 365 Copilot location
• A retention policy covers Microsoft Copilot interactions

Special thanks to Ofir Gavish for adding the Microsoft Purview coverage.

SharePoint Online: CIS, CISA, and PnP.PowerShell​

Maester now talks to SharePoint Online through PnP.PowerShell, and it works cross-platform.

This release adds six CIS Microsoft 365 Foundations Benchmark checks for SharePoint sharing and download controls, plus six new CISA SCuBA checks. The two existing CISA SharePoint checks moved over to the same connection, completing all eight CISA SharePoint baseline controls.

The new checks cover:

• Default sharing scope and permission
• Anyone-link expiration and permissions
• OneDrive external sharing
• Verification-code reauthentication
• Guest sharing and B2B integration
• Protection against downloading malicious files

Special thanks to Morten Mynster, Henrik Piecha, Simon Albers, and PulpyJuice for the SharePoint implementations and follow-up work.

GitHub security and easier GitHub Actions setup​

Your identity perimeter doesn't stop at Microsoft 365, and now Maester doesn't either. 2.2 adds first-class GitHub connectivity and five CIS GitHub organization controls:

• Strict base repository permissions
• Restricted repository creation
• Restricted repository deletion
• Restricted team creation
• Restricted issue deletion

Connect to your GitHub organization and run them alongside the rest of your security tests:

Connect-Maester -Service GitHub
Invoke-Maester -Tag "CIS GH"

Setting up Maester in GitHub Actions also got a whole lot easier. From a maester-tests repository, Maester can now detect your Git remote, create the federated credential, and set the Actions secrets for you:

Connect-Maester -Service Azure
New-MtMaesterApp -GitHubActions -SetGitHubSecrets

Special thanks to Travis McDade for the GitHub connection and CIS controls, and Loïc Michel for the zero-configuration GitHub Actions setup.

Global Secure Access​

If you're rolling out Microsoft Entra Global Secure Access, nine new preview checks look for the configuration mistakes that are easy to make and hard to spot:

These checks add one new read-only Graph permission, NetworkAccess.Read.All, to the default scopes.

Special thanks to Christopher Brumm for developing the checks, validating them against a live tenant, and lining them up with the Microsoft Zero Trust Assessment so the two don't overlap.

More Intune and Entra ID checks​

Four new Intune checks cover endpoint controls at the heart of a modern Windows security baseline:

• MT.1177: Windows LAPS configuration
• MT.1178: Attack Surface Reduction rules
• MT.1179: App Control for Business
• MT.1180: Managed Installer

On the Entra ID side, new checks catch high agent-risk sign-ins, Conditional Access policies with no target resources, legacy MSOnline PowerShell authentication, high-privilege first-party apps without explicit assignment, DMARC on verified domains, BitLocker recovery-key restrictions, and the protected onPremisesObjectIdentifier update path.

Special thanks to Ofir Gavish, ExeqZ, Jan Bakker, and Matthias for this new coverage.

Reports, automation, and contributor credits​

The report keeps getting sharper:

• Markdown summaries you can drop into pipelines and pull requests
• Per-test durations in the HTML report
• Critical findings sorted to the top
• Filtered NotRun results hidden by default, with a status filter if you want them back
• Less warning noise for tests you've intentionally filtered out
• Smarter skipping for tests your licenses don't cover

Behind the scenes, releases now go through automated smoke tests against a demo tenant before they ship, along with better version tracking across the module and tests.

And our favorite change in this release: maester.dev now credits the people behind every test. Authorship is derived from Git history and shown right on each test's documentation page, along with the new contributors page. New contributions are picked up automatically, so the credits grow with the project.

Thank you to every contributor​

Maester 2.2 includes contributions from 26 people:

• Artem Borodai for making role lookups more resilient.
• Brian Reid for improving the managed-domain and MFA policy checks.
• Christopher Brumm for the nine Global Secure Access checks.
• Christopher Edwards for license-aware skips in the Intune and Defender for Office 365 tests.
• ExeqZ for the high agent-risk Conditional Access check.
• Henrik Piecha for originating and co-authoring the SharePoint Online CIS coverage.
• Jan Bakker for five new Entra and CIS checks and stronger Conditional Access error handling.
• Jean-Philippe George for improving license-aware results, parameter handling, and documentation.
• Jon Gross for fixing error handling in a tricky tenant edge case.
• Jon Hope for fixing ORCA and Conditional Access role-lookup edge cases.
• Loïc Michel for the zero-configuration GitHub Actions and OIDC setup.
• Massimo Mazzariol for documenting Microsoft Graph scopes in connection results.
• Matthias for the DMARC coverage and verified-domain fixes.
• Merill Fernando for release, report, website, and automation improvements.
• Mike Soule for building and validating the 269 Active Directory checks.
• Morten Mynster for SharePoint Online CIS and CISA coverage, PnP.PowerShell support, and report and build fixes.
• Ofir Gavish for the Microsoft Purview and Intune endpoint security checks.
• PulpyJuice for co-authoring the CISA SharePoint Online follow-up.
• Sam Erde for release automation, code scanning, generated documentation, version tracking, and report quality.
• seick for fixing workload identity policy handling and completing permission documentation.
• Simon Albers for the SharePoint Online implementation adopted in this release.
• Stephan van Rooij for the markdown summary report.
• Thomas Naunheim for improved delegated-permission support and error handling.
• Thomas S. Schmidt for fixing Defender for Identity health-response handling.
• Travis McDade for GitHub connectivity and the CIS GitHub organization controls.
• Truls Thorstad Dahlsveen for expanding the permissions documentation.

Thank you as well to everyone who reviewed a pull request, reported an issue, tested a preview build, improved the docs, or shared a "this failed in my tenant" edge case. That feedback is what turns a big pile of checks into a security testing framework you can rely on.

Thank you to Maester's Founding Supporters​

This release also marks a new chapter for me personally. I (Merill) am now working on Maester full time: maintaining the open core, keeping the checks current as Microsoft 365 changes, and giving this community the focus it deserves.

The people and organizations below were the first to back that decision through Maester Cloud. Their support creates the space for me to do this work every day, while keeping Maester's core framework and tests open and available to everyone. Every person who runs Maester benefits from their early belief in what this project can become.

My heartfelt thanks to:

• CyberDrain / CIPP
• Derek Morgan
• Daniel Bradley
• Stefan Wey / Alweys
• Integrency
• Conflux Cloud
• Greenwire Solutions
• Martin Heusser
• Erica Zelickowski
• Ben Seaba
• St Vincent's Institute
• Devote
• Crimson Owl Technologies
• Zitac
• Stevez Gomes
• TDC Erhverv
• Paul Schnackenburg
• Fired Synapse Technologies, Joe Bales
• UpTime IT Management
• Jan Bakker
• Declarative Ltd
• Blue Hybrid
• Steel Shed
• GRC Softwaremanagement AG
• Bastien Perez
• Horizons Consulting, Inc.
• 365Vantage
• conode Systemhaus GmbH
• SECOTRON (Thomas Geens)
• David Wanderer
• Jeff Weitz
• Kim Gramenske
• Thomas & Hutton
• De Technische Jongens
• Langtech Inc.
• MSX Security - Marcus Burnap

Their names now have a permanent place on the Maester Cloud Founding Supporters wall. The Maester Manifesto explains the open-source future they are helping make possible.

Get Maester 2.2​

Update the module and your test collection:

Update-Module Maester
Update-MaesterTests

Then explore the new areas:

# Active Directory (explicit opt-in)
Connect-Maester -Service ActiveDirectory
Invoke-Maester -Path "./ad" -SkipGraphConnect -NonInteractive

# Microsoft Purview and AI data security
Invoke-Maester -Tag "MT.1172", "MT.1173", "MT.1174", "MT.1175", "MT.1176"

# CIS GitHub controls
Connect-Maester -Service GitHub
Invoke-Maester -Tag "CIS GH"

# Global Secure Access preview checks
Invoke-Maester -Tag "MT.1187", "MT.1188", "MT.1189", "MT.1190", "MT.1191", "MT.1192", "MT.1193", "MT.1194", "MT.1195"

# Intune endpoint security
Invoke-Maester -Tag "MT.1177", "MT.1178", "MT.1179", "MT.1180"

Maester 2.2 stretches from your domain controllers to your AI rollout, your SharePoint sharing settings, and your GitHub organization. And for the first time, the people building that coverage get their names on it.

Happy testing! 🎉

This release brings Maester into more of the places security teams live every day: Azure DevOps, Microsoft Defender for Endpoint, Copilot Studio, entitlement management, multi-tenant operations, and the report experience itself.

Highlights​

• Azure DevOps security tests: 37 optional tests covering OAuth, SSH, audit logs, public projects, PAT policy, pipeline hardening, Advanced Security, and privileged Azure DevOps roles.
• Copilot Studio and AI agent tests: 10 new checks for risky agent sharing, authentication, HTTP configuration, email exfiltration paths, author authentication, MCP tools, dormant agents, hard-coded credentials, custom instructions, and orphaned ownership.
• Microsoft Defender for Endpoint checks: 24 antivirus and endpoint security tests covering cloud protection, network protection, real-time monitoring, PUA protection, signature updates, sample submission, scan behavior, and local admin merge.
• Multi-tenant reporting: run Maester across multiple tenants and merge the results into a single report with a tenant selector.
• CIS Microsoft 365 Foundations Benchmark 6.0.1 updates: CIS coverage and documentation have been refreshed to align with the newer benchmark.
• New Entra ID and entitlement management checks: new tests catch stale access package references, invalid approvers, orphaned resources, and hybrid identity risks.
• Better report and operations experience: deep links to individual test results, improved markdown severity output, cleaner skipped/investigate counts, and more resilient build and release automation.

Azure DevOps tests​

Maester now includes an optional Azure DevOps security test suite. The tests are discovered automatically and run when you connect to Azure DevOps using the community ADOPS PowerShell module.

Install-Module Maester, ADOPS
Connect-ADOPS -Organization <your-organization>
Invoke-Maester

The suite includes 37 tests across organization, repository, pipeline, artifact, and PAT controls. It covers high-impact settings such as third-party OAuth app access, SSH authentication, auditing, public projects, external guests, job authorization scope, queue-time variables, classic pipeline creation, marketplace tasks, Shell Task argument validation, TFVC creation, Project Collection Administrators, leaked PAT auto-revocation, and full-scoped PAT restrictions.

This work was led by Sebastian Claesson, with follow-up fixes and documentation improvements from the wider community.

Copilot Studio and AI agent security​

AI agents are quickly becoming part of the Microsoft 365 attack surface, so Maester now includes checks for Copilot Studio agents.

The new MT.1113 to MT.1122 tests look for:

• Broadly shared agents
• Agents without user authentication
• Risky HTTP configurations
• Email sending with AI-controlled inputs
• Dormant published agents
• Author or maker authentication on connections
• Hard-coded credentials in topics
• MCP server tools that need review
• Missing custom instructions for generative orchestration
• Orphaned ownership

These checks use Dataverse data for the Copilot Studio environment configured in maester-config.json, helping teams review agent risk alongside their existing Entra, Exchange, Teams, and Microsoft 365 security tests.

Special thanks to Truls for adding Copilot Studio support to Maester, with follow-up cleanup and polish from Sam and Merill.

Defender for Endpoint coverage​

This release adds a large Microsoft Defender for Endpoint test set, covering practical endpoint security baseline checks such as archive scanning, behavior monitoring, cloud protection, email and script scanning, real-time monitoring, network protection, PUA protection, signature update cadence, sample submission, and more.

The Defender work also adds reusable helper functions for reading MDE configuration and policy state, making it easier to build more endpoint checks in future releases.

Special thanks to Boris Drogja for adding the MDE support, with follow-up test cleanup from Sam Erde.

Multi-tenant reports​

For consultants, managed service providers, partners, and organizations with multiple tenants, Maester can now merge results from multiple tenant runs into a single report.

Merge-MtMaesterResult -Path ./results/ | Get-MtHtmlReport | Out-File ./report.html

The report automatically detects multi-tenant results and shows a tenant selector in the sidebar. Each tenant keeps its own dashboard, charts, filters, config view, and results. You can also use tenant-specific configuration files such as maester-config.{TenantId}.json for different emergency access accounts and severity overrides per tenant.

Read more in the multi-tenant reports announcement.

Special thanks to Sebastian Claesson for building the multi-tenant report experience.

More Entra ID coverage​

Maester now has additional checks for entitlement management and hybrid identity risks, including:

• MT.1106: Catalog resources must have valid roles
• MT.1107: Access packages and catalogs should not reference deleted groups
• MT.1108: Access packages should not reference inactive or orphaned assignment policies
• MT.1109: Access package approval workflows must have valid approvers
• MT.1110: Catalogs should not contain resources without associated access packages
• MT.1147: Do not sync krbtgt_AzureAD to Entra ID

These are the kinds of configuration issues that are easy to miss until access reviews, entitlement cleanup, or hybrid identity incidents force the conversation. Maester can now flag them continuously.

Special thanks to Nico Wyss for the entitlement management tests and Fabian Bader for the krbtgt_AzureAD hybrid identity check.

CIS, tags, and test inventory​

The CIS Microsoft 365 Foundations Benchmark content has been refreshed for v6.0.1, with updated descriptions, coverage tables, and test mappings.

We also added generated tag inventory support using Get-MtTestInventory, building on the Maester tags improvements. This gives contributors a clearer view of the tags already in use and helps users select tests by suite, product area, practice, or capability without guessing.

Special thanks to Benjamin Metz for adding the CIS tests, Morten Mynster for the CIS v6.0.1 refresh, and Sam Erde for the tag inventory and tag documentation automation.

Report and platform improvements​

The report keeps getting sharper. Since 2.0 we have added direct links to individual test results, improved markdown output with severity details, fixed long organization names in the sidebar, improved skipped and investigate counts in alerts, and cleaned up several report build and dependency issues.

Behind the scenes, the project also gained CodeQL scanning, PR-triggered website build validation, dependency review, safer workflow permissions, issue forms, automatic Entra role definition update automation, and a consolidated module build script.

These are not always the flashiest release notes, but they make Maester easier to maintain, easier to trust, and easier for contributors to extend.

Special thanks to Sam Erde for report deep links, build automation, CodeQL and workflow hardening, and release plumbing; and to Morten Mynster for report template and UI improvements.

Contributors​

Maester continues to be a community project, and this release shows it.

Special callouts for this release:

• Sam Erde for report deep links, tag documentation automation, build automation, CodeQL and workflow hardening, docs, and release quality.
• Sebastian Claesson for the Azure DevOps test suite and multi-tenant reporting work.
• Boris Drogja for adding Microsoft Defender for Endpoint support.
• Truls for adding Copilot Studio support.
• Nico Wyss for the entitlement management tests.
• Fabian Bader for the krbtgt_AzureAD hybrid identity check.
• Benjamin Metz for adding the CIS tests.
• Thomas Naunheim for continued review, test coverage, and project improvements.
• Morten Mynster for major contributions across tests, CIS updates, and report/template improvements.
• Frode Flaten, Brian Reid, Anas, Ricardo Mestre, Matt Cave, Brian Veldman, and everyone who opened issues, reviewed PRs, tested preview builds, or fixed docs.

And thank you to everyone using Maester in real tenants. The feedback, edge cases, and "this failed in my environment" reports are what turn good ideas into reliable security checks.

Get the update​

Update Maester and your tests:

Update-Module Maester
Update-MaesterTests

Then explore the new areas:

# Azure DevOps tests
Connect-ADOPS -Organization <your-organization>
Invoke-Maester

# Copilot Studio / AI agent tests
Connect-Maester -Service Dataverse
Invoke-Maester -Tag AIAgent

# Defender for Endpoint tests
Invoke-Maester -Tag Defender

# Multi-tenant report
Merge-MtMaesterResult -Path ./results/ | Get-MtHtmlReport | Out-File ./report.html

This release is a big step toward making Maester the continuous security validation layer for Microsoft 365, Entra, Defender, Azure DevOps, and the new AI surfaces that are arriving fast.

🎯 Highlights at a Glance​

• 300+ New AD Security Tests covering every aspect of your directory infrastructure
• 20 Test Categories from users and groups to DNS, GPOs, and DACL analysis
• Intelligent Caching with Get-MtADDomainState for efficient data collection
• Hybrid Ready - Perfect for organizations with on-premises AD and Entra ID
• Validated Against Live DCs - All tests validated on Windows Server 2025 Domain Controllers

Why Active Directory Testing Matters​

Active Directory remains the backbone of identity and access management for millions of organizations worldwide. Despite the shift to cloud, over 90% of Fortune 1000 companies still rely on AD for authentication and authorization. A compromised AD can lead to:

• Complete domain takeover
• Lateral movement across your network
• Ransomware deployment at scale
• Data exfiltration and theft

Maester's new AD testing capabilities help you identify misconfigurations, security gaps, and compliance issues before attackers do.

📊 Test Coverage Overview​

Identity & Access Management​

Domain Infrastructure​

Security Configuration​

Network & Integration​

🔍 Key Test Categories Explained​

User Security Tests​

Identify risky user configurations that could lead to compromise:

# Run all user security tests
Connect-Maester -Service ActiveDirectory
Invoke-Maester -Path "./ad/user" -SkipGraphConnect

Sample Tests:

• Test-MtAdUserPasswordNeverExpiresCount - Find accounts with non-expiring passwords
• Test-MtAdUserDelegationAllowedCount - Detect accounts trusted for delegation
• Test-MtAdUserNoPreAuthCount - Identify AS-REP Roasting vulnerabilities
• Test-MtAdUserKerberosDesOnlyCount - Find legacy DES-only accounts
• Test-MtAdUserBuiltInAdminEnabledDetails - Monitor built-in Administrator accounts

Group Policy Security​

Analyze GPO configurations for security issues:

# Run GPO security tests
Connect-Maester -Service ActiveDirectory
Invoke-Maester -Path "./ad/gpostate" -SkipGraphConnect

Sample Tests:

• Test-MtAdGpoCpasswordFoundCount - Detect encrypted passwords in GPOs
• Test-MtAdGpoNoAuthenticatedUsersCount - Find GPOs missing critical permissions
• Test-MtAdGpoVersionMismatchCount - Identify AD/Sysvol version mismatches
• Test-MtAdGpoWmiFilterCount - Audit WMI filter usage

DACL Analysis​

Deep-dive into Access Control Lists:

# Run DACL analysis tests
Connect-Maester -Service ActiveDirectory
Invoke-Maester -Path "./ad/dacl" -SkipGraphConnect

Sample Tests:

• Test-MtAdDaclPrivilegedAllowAceCount - Find privileged ACE entries
• Test-MtAdDaclDenyAceCount - Audit deny authorization entries
• Test-MtAdDaclUnresolvedSidCount - Detect orphaned SIDs in ACLs
• Test-MtAdDaclConflictObjectCount - Find conflict objects (CNF)

🚀 Getting Started​

Prerequisites​

• Windows Server with Active Directory role, or domain-joined machine
• PowerShell 5.1 or later
• ActiveDirectory and GroupPolicy PowerShell modules
• Domain Admin or equivalent permissions (for full coverage)

Active Directory testing is always opt-in. Connect-Maester -Service All does not connect to AD, and Invoke-Maester excludes every AD-tagged test until Connect-Maester -Service ActiveDirectory succeeds in the current PowerShell session.

Installation​

# Install or update Maester
Install-Module Maester -Scope CurrentUser -Force

# Install Maester tests
md ~/maester-tests
cd ~/maester-tests
Install-MaesterTests

Running AD Tests​

# Import the Maester module
Import-Module Maester -Force

# Explicitly validate the Active Directory connection
Connect-Maester -Service ActiveDirectory

# Run all AD tests
Invoke-Maester -Path "./ad" -OutputFolder "./ad-results" -SkipGraphConnect -NonInteractive

# Run specific categories
Invoke-Maester -Path "./ad/user" -OutputFolder "./ad-results" -SkipGraphConnect -NonInteractive
Invoke-Maester -Path "./ad/gpostate" -OutputFolder "./ad-results" -SkipGraphConnect -NonInteractive

# Run with specific tags
Invoke-Maester -Tag "AD.User" -OutputFolder "./ad-results" -SkipGraphConnect -NonInteractive

Using the AD Test Runner​

For convenience, use the included test runner script:

# From the repository root on a domain controller
.\build\activeDirectory\Run-ADTests-And-CopyReports.ps1 -ConnectActiveDirectory

# With verbose output
.\build\activeDirectory\Run-ADTests-And-CopyReports.ps1 -ConnectActiveDirectory -Verbose

📈 Understanding Test Results​

Test Output Format​

Tests return standardized results:

Sample Output​

# Example: Password Policy Test
Connect-Maester -Service ActiveDirectory

Test-MtAdPasswordComplexityRequired
# Returns: $true (complexity enabled - good)

Test-MtAdPasswordMinLength
# Returns: 7 (below recommended 14+)

Test-MtAdAccountLockoutThreshold
# Returns: 0 (disabled - security risk!)

HTML Reports​

Generate professional HTML reports for stakeholders:

Connect-Maester -Service ActiveDirectory
Invoke-Maester -Path "./ad" -OutputFolder "./reports" -SkipGraphConnect -NonInteractive
# Open ./reports/TestResults-*.html

🔐 Security Recommendations​

Based on AD test results, consider these best practices:

Password Policies​

• ✅ Set minimum password length to 14+ characters
• ✅ Enable account lockout (threshold ≤ 5 attempts)
• ✅ Configure lockout duration to 30+ minutes
• ✅ Implement fine-grained password policies for privileged accounts

User Accounts​

• ✅ Disable accounts with passwords that never expire
• ✅ Remove delegation from non-DC accounts
• ✅ Eliminate DES-only Kerberos accounts
• ✅ Monitor dormant enabled accounts (>90 days)

Group Policy​

• ✅ Remove cpassword entries from GPOs
• ✅ Ensure all GPOs have Authenticated Users permission
• ✅ Resolve AD/Sysvol version mismatches
• ✅ Audit and remove unlinked GPOs

Domain Controllers​

• ✅ Disable SMBv1 on all DCs
• ✅ Enable SMB signing
• ✅ Use standard LDAP/LDAPS ports (389/636)
• ✅ Keep DC OS versions current

🔄 Integration with CI/CD​

Run AD tests in your automation pipelines from a self-hosted Windows agent that can reach a domain controller and has the required RSAT modules installed. Cloud-hosted runners do not have access to your AD environment.

GitHub Actions​

name: AD Security Tests
on:
  schedule:
    - cron: '0 2 * * *'  # Daily at 2 AM

jobs:
  test:
    runs-on: [self-hosted, windows, ad-connected]
    steps:
      - name: Run Maester AD Tests
        shell: pwsh
        run: |
          Install-Module Maester -Force
          Import-Module Maester
          $testPath = Join-Path $env:RUNNER_TEMP 'maester-tests'
          Install-MaesterTests -Path $testPath -SkipPesterCheck
          Connect-Maester -Service ActiveDirectory
          Invoke-Maester -Path (Join-Path $testPath 'ad') -Tag 'AD' -SkipGraphConnect -NonInteractive

Azure DevOps​

trigger:
- main

pool:
  name: 'AD-connected Windows agents'

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Install-Module Maester -Force
      Import-Module Maester
      $testPath = Join-Path $env:AGENT_TEMPDIRECTORY 'maester-tests'
      Install-MaesterTests -Path $testPath -SkipPesterCheck
      Connect-Maester -Service ActiveDirectory
      Invoke-Maester -Path (Join-Path $testPath 'ad') -Tag 'AD' -OutputFolder "$(Build.ArtifactStagingDirectory)" -SkipGraphConnect -NonInteractive

🧪 Test Development & Validation​

All 300+ tests were developed following a rigorous 20-phase methodology:

1. Phase 1-6: Core objects (Computers, SPNs, Password Policies, DNS, Domain, DCs)
2. Phase 7-10: Policy and structure (GPO, Groups, Users, OUs)
3. Phase 11-14: Infrastructure (Sites, Trusts, Schema, Config)
4. Phase 15-20: Advanced security (DC details, Forest, Security Accounts, Replication, GPO State, DACL)

Each test includes:

• PowerShell test function
• Pester unit tests
• Markdown documentation with security context
• Validation against live Domain Controllers

📚 Available Commands​

New AD-Specific Cmdlets​

🤝 Contributing​

Active Directory testing is an ongoing effort. We welcome contributions for:

• New test categories (e.g., Certificate Services, ADFS)
• Additional test cases for existing categories
• Performance optimizations
• Documentation improvements

See our Contributing Guide to get started.

🙏 Thank You​

This massive undertaking wouldn't be possible without the Maester community. Special thanks to all contributors who helped design, implement, and validate these 300+ tests.

🚀 Get Started Today​

# Update Maester
Update-Module Maester -Force

# Install latest tests
cd ~/maester-tests
Update-MaesterTests

# Explicitly validate the Active Directory connection
Connect-Maester -Service ActiveDirectory

# Run AD tests on your domain controller
Invoke-Maester -Path "./ad" -SkipGraphConnect -NonInteractive

📖 Resources​

• Full AD Test Documentation
• GitHub Repository
• Join us on Discord
• Report Issues

Happy AD Testing! 🏰🔒

If you're like me and manage multiple Azure tenants that span across national clouds, you probably know the pain of having to open separate reports for each one. Not anymore!

Quick Stats​

• 🚀 Run Maester tests across multiple tenants in a single pipeline run
• 🔥 Switch between tenants in one report using the sidebar
• 🤝 Full dashboard per tenant, charts, filters, everything
• 🔐 Each tenant uses its own service connection with read-only permissions
• ⚙️ Tenant-specific maester-config.{TenantId}.json support

Single tenant reports continue to work exactly as before. The tenant selector only appears when there are multiple tenants in the report.

Get Started​

Check out the documentation to get your multi-tenant monitoring up and running:

• Documentation: Multi-Tenant Overview
• Documentation: Merging Results
• Documentation: Tenant-specific Configuration
• Documentation: Azure DevOps Pipeline

Contributor​

• Sebastian Claesson

Overview​

Maester now includes an optional suite of Azure DevOps security and resource limit tests. The tests are bundled with Maester and are automatically discovered when you run Invoke-Maester. However, they are only executed if you have an active connection to an Azure DevOps organization using the community ADOPS PowerShell module. Without a connection, the tests are skipped.

Each test includes a markdown document with rationale and remediation guidance, and a PowerShell script containing the implementation. The tests are inspired by Learn - Azure DevOps Security Best Practices and cover a subset of the available settings.

To get started:

Install-Module Maester, ADOPS
Connect-ADOPS -Organization <your-organization>
Invoke-Maester

That's it — Maester detects the Azure DevOps connection and runs the tests automatically alongside any other configured tests.

Some tests use unsupported Azure DevOps REST API endpoints that may change without notice. These tests use the -Force flag internally to bypass the unsupported API warning.

Permissions​

• At least a Basic access level license in Azure DevOps
• Certain tests require organization-level permissions such as "Project Collection Administrator" (e.g., AZDO.1030) or tenant-level permissions such as "Azure DevOps Administrator" (e.g., AZDO.1032-1036).

Manage policies as Administrator - Azure DevOps

Available tests​

Quick Stats​

• 🔢 37 tests in total
• 🔴 2 Critical | 🟠 22 High | 🟡 10 Medium | 🔵 3 Info

Azure DevOps Pipeline Example​

For automated monitoring, the following pipeline runs Maester tests (including the Azure DevOps tests) on a schedule and publishes the results to an Azure Web App. The pipeline connects to both Microsoft Graph (for Entra ID tests) and Azure DevOps.

Prerequisites:

• An app registration with the required Maester permissions
• A workload identity federation service connection in Azure DevOps
• An Azure Web App to host the report (see Maester results on Azure Web App)

Update the following variables in the pipeline to match your environment:

trigger: none

variables:
  ServiceConnection: <your-service-connection>
  WebAppSubscriptionId: <your-subscription-id>
  WebAppResourceGroup: <your-resource-group>
  WebAppName: <your-web-app-name>
  TenantId: <your-tenant-id>
  ClientId: <your-client-id>
  DevOpsOrganization: <your-devops-organization>

schedules:
- cron: "0 6 * * *"
  displayName: Daily at 06:00
  always: true
  branches:
    include:
    - main

jobs:
- job: maester
  pool:
    vmImage: ubuntu-latest

  steps:
  - checkout: self
    fetchDepth: 1

  - task: AzurePowerShell@5
    inputs:
      azureSubscription: '$(ServiceConnection)'
      ScriptType: 'InlineScript'
      pwsh: true
      azurePowerShellVersion: latestVersion
      Inline: |
        # Install modules
        Install-Module 'Maester', 'Pester', 'Microsoft.Graph.Authentication', 'ADOPS' -SkipPublisherCheck -Confirm:$false -Force

        # Connect to Microsoft Graph
        $graphToken = Get-AzAccessToken -ResourceUrl 'https://graph.microsoft.com' -AsSecureString
        Connect-MgGraph -AccessToken $graphToken.Token -NoWelcome

        # Connect to Azure DevOps
        $DevOpsToken = ConvertFrom-SecureString -SecureString (Get-AzAccessToken -AsSecureString -TenantId '$(TenantId)').Token -AsPlainText
        Connect-ADOPS -Organization '$(DevOpsOrganization)' -OAuthToken $DevOpsToken

        # Prepare output folder
        $date = (Get-Date).ToString("yyyyMMdd-HHmm")
        $TempOutputFolder = "$PWD/temp$date"
        New-Item -ItemType Directory -Force -Path $TempOutputFolder
        New-Item -ItemType File -Force -Path "$TempOutputFolder/index.html"

        # Install and run Maester tests
        mkdir maester-tests
        cd maester-tests
        Install-MaesterTests .\tests
        Invoke-Maester -OutputHtmlFile "$TempOutputFolder/index.html" -Verbosity Normal

        # Publish to Azure Web App
        $FileName = "$PWD/MaesterReport$date.zip"
        Compress-Archive -Path "$TempOutputFolder/*" -DestinationPath $FileName
        Select-AzSubscription -Subscription '$(WebAppSubscriptionId)'
        Publish-AzWebApp -ResourceGroupName '$(WebAppResourceGroup)' -Name '$(WebAppName)' -ArchivePath $FileName -Force
    displayName: 'Run Maester tests and publish report'

This pipeline only includes Microsoft Graph and Azure DevOps connections. To add Exchange Online, Teams, or Security & Compliance, see the advanced connection guide.

Documentation​

• Setting up Maester in Azure DevOps Pipelines
• Maester results on Azure Web App
• Deploy Maester Web App with Bicep

Contributor​

• Sebastian Claesson

🎯 Highlights at a Glance​

• Brand new reporting capabilities with print, markdown, and Excel export views
• New Security Tests covering Intune, Entra ID, Conditional Access and Azure
• Microsoft Security Exposure Management (XSPM) Integration - Leverage Defender insights
• Enhanced HTML Report with print, markdown, and Excel export views
• Emergency Access Accounts Configuration - Define your break-glass accounts
• New Maester App Management Commands - Simplified DevOps pipeline setup

Here's a deeper dive into what's new in Maester 2.0:

New Reporting Capabilities​

The Maester report has been completely redesigned with new views and capabilities.

🔐 New Security Tests​

We've added over 15 new tests to help you secure your Microsoft 365 environment. Here are the highlights:

Intune Security​

Identity & Access Management​

Azure Security​

Why it matters:

• Prevent shadow IT by restricting tenant and group creation
• Protect your hybrid identity by blocking on-prem sync attacks
• Secure your Azure backup infrastructure

How to use:

# Run all new tests
Invoke-Maester -Tag "MT.1068", "MT.1069", "MT.1070"

# Run all Entra tests
Invoke-Maester -Tag "Entra"

🛡️ Microsoft Security Exposure Management (XSPM) Tests​

A brand new category! Integrate with Microsoft Security Exposure Management to test for exposure risks across your environment.

New XSPM Tests​

Why it matters:

• Identify attack paths before attackers do
• Prioritize remediation based on exposure risk
• Leverage Microsoft's threat intelligence

How to use:

# Run XSPM tests
Invoke-Maester -Tag "XSPM"

# Check for credential exposure
Invoke-Maester -Tag "XSPM" -Path ./tests/XSPM

📊 Enhanced HTML Report​

The Maester report has been completely redesigned with new views and capabilities.

New Report Features​

Why it matters:

• Share results with stakeholders in their preferred format
• Track remediation progress over time
• Present findings to leadership with professional reports

How to use:

# Generate the enhanced report
Invoke-Maester -OutputFolder ./results

# Open the HTML report and explore the new views
# Click the tabs: Print | Markdown | Excel | Config

🚨 Emergency Access Accounts​

Define your break-glass accounts in the Maester configuration to improve test accuracy.

Why it matters:

• Tests correctly identify your emergency access accounts
• No more false positives on Conditional Access exclusions
• Audit trail for break-glass account usage

How to use:

Edit your maester-config.json:

{
  "GlobalSettings": {
    "EmergencyAccessAccounts": [
      "emergency-admin@contoso.com",
      "break-glass-group-id"
    ]
  }
}

Then run your tests:

Invoke-Maester
# Tests will now recognize your defined emergency access accounts

⚡ Maester App Management​

New cmdlets to simplify setting up Maester for DevOps pipelines.

New Commands​

Why it matters:

• One command to set up your DevOps app registration
• Automatically configures the minimum required permissions
• Supports workload identity federation for GitHub Actions

How to use:

# Create a new Maester app for GitHub Actions
New-MtMaesterApp -Name "Maester Pipeline" -GitHubOrganization "myorg" -GitHubRepository "maester-tests"

# Include mail sending for notifications
New-MtMaesterApp -Name "Maester Pipeline" -SendMail

# Add federated credential to existing app
Add-MtMaesterAppFederatedCredential -GitHubOrganization "myorg" -GitHubRepository "maester-tests"

🔍 Test Inventory Discovery​

A new command to discover and explore available tests.

Why it matters:

• Understand what tests are available before running
• Filter tests by tags or capabilities
• Export inventory for documentation

How to use:

# Get all available tests grouped by tag
$inventory = Get-MtTestInventory

# View tests for a specific tag
$inventory['CIS']

# Export inventory to CSV
Get-MtTestInventory -OutputType CSV -ExportPath ./TestInventory.csv

🔧 Improvements & Fixes​

Performance​

• Optimized Invoke-MtGraphRequest for faster batch operations
• Improved ConvertTo-QueryString with better null handling

CISA Compliance​

• Enhanced CISA test accuracy and reliability
• Individual test IDs for CA What-If analysis

CIS Benchmarks​

• Improved DKIM test with skip logic for onmicrosoft.com domains
• Cleaner test names without level numbers for better readability

Defender for Identity​

• Refactored health issue detection
• Better integration with MDI alerts

🙏 Thank You to Our Contributors​

This release wouldn't be possible without our amazing community:

• @tdcthosc - CISA improvements, CIS refactors, Invoke-Maester enhancements
• @f-bader - Emergency access accounts feature
• @HenrikPiecha - MT.1070, MT.1071, MT.1073 tests
• @marcel-ngn - MT.1068, MT.1069 tests
• @RobbeVandenDaele - XSPM device checks
• @SamErde - Bug fixes and workflow improvements
• @brianveldman - Azure security tests
• @l-gosling - GitLab and Teams integration
• @kij - HTML report improvements
• And many more!

🚀 Get Started​

Update to Maester 2.0 today:

# Update the Maester module
Update-Module Maester -Force

# Update your test files
cd maester-tests
Update-MaesterTests

# Run the tests with the new features
Invoke-Maester

📚 Learn More​

• Maester Documentation
• GitHub Repository
• Join us on Discord

Have feedback or found a bug? Open an issue on GitHub!

Happy testing! 🎉

Code signing and PowerShell​

Regardless if you publish a PowerShell module to the PowerShell gallery or just have a PowerShell script in your home folder, the code in those files, normally is just that, code. But if you have a code signing certificate from a trusted certification authority, you can use this to sign the PowerShell files, which allows anybody else to verify that nobody has tampered with the contents.

This concept is great in theory, but has a few downsides:

• Code Signing certificates are very expensive.
• With the recent changes to code signing certificates, they have to reside inside a HSM, adding operational cost.
• As an open source project you might sign code that is not yours.

The current code signing certificate that Fabian offered at the beginning still has a few months until it's no longer valid, but at the end of this period it won't be extended anymore. Therefore we had to make the decision if we want to sign Maester going forward. There are a few projects out there that offer code signing to open source tools for free, but there are a lot of requirements regarding external code sources that made this road unfeasible for us.

In the end, code signing a PowerShell module adds some value, but the cost outweighs the need, and we decided to stop now.

Starting from version 1.4.0 and any pre-release starting from 1.3.101, the module will no longer be signed.

Why should I care?​

If you use Maester in a CI/CD pipeline with managed workers, nothing will noticeably change. The workers don't persist the module information after running, it and the next run will go through the module installation like always.

But if you have Maester installed on your own machine, PowerShell will throw the following error, calling out that the new version is no longer signed.

Update-Module Maester -AllowPrerelease

Install-Package: The version '1.3.105' of the module 'Maester' being installed is not catalog signed. Ensure that the version '1.3.105' of the module 'Maester' has the catalog file 'Maester.cat' and signed with the same publisher 'CN=Fabian Bader, O=Fabian Bader, L=Hamburg, C=DE' as the previously-installed module 'Maester' with version '1.3.0' under the directory 'C:\Users\Fabian\Documents\PowerShell\Modules\Maester\1.3.0'. If you still want to install or update, use -SkipPublisherCheck parameter.

Sadly, the -SkipPublisherCheck switch is not available for the Update-Module cmdlet.

Solution​

The solution is to install the new version once with:

Install-Module Maester -AllowPrerelease -Force -SkipPublisherCheck

We gladly welcome any feedback or suggestions for improvements. You can also join our community on Discord. Thank you!

A Review of How Tags are Used​

When you run Maester with no tag-related parameters, it automatically includes all available tests except (1) tests that rely on features that are still in preview and (2) tests that can take a very long time in large environments. The goal with this default behavior is to quickly get meaningful results with minimum learning curve.

🏷️ Run All Default Tests​

Invoke-Maester -Path './maester-tests'

Runs all the default tests in the folder ./maester-tests (excludes long running and preview, as noted above) and generates a report of the results in the default ./test-results location.

🏷️ Run Tests with Specific Tags​

You can use the Tag parameter to target tests with specific tags. For example:

Invoke-Maester -Path './maester-tests' -Tag 'CA', 'MFA'

Only run tests with the 'CA' or 'MFA' tags in the ./maester-tests directory.

🏷️ Exclude Tests with Specific Tags​

Invoke-Maester -ExcludeTag 'App', 'Azure'

Run all default tests excluding tests that are tagged with 'App' or 'Azure'. By default, tests that can take a very long time in large environments and tests that rely on preview features are still excluded as well.

What has changed?​

As noted above, Maester's default execution excludes long-running tests and tests in preview status. Two new switch parameters have been introduced so we can begin the removal of the ambiguous tags that targeted these two categories.

As you can imagine, the original naming lead to many people adding the All and Full tags to their test scripts with the goal of being generally included. Now, running Maester with every available test can be accomplished as shown below. Note that you can still combine these parameters with other options:

🏷️ Run Maester with Default Tests, Long-Running Tests, and Preview Tests​

Invoke-Maester -Path './maester-tests' -IncludeLongRunning -IncludePreview

Runs all tests in the path ./maester-tests including preview and long running tests.

🏷️ Run Maester with Default Tests and Long-Running Tests, Excluding 'App' Tests​

Invoke-Maester -Path './maester-tests' -IncludeLongRunning -ExcludeTag 'App'

Runs all tests in the path ./maester-tests including long running tests and excluding tests tagged with 'App'.

Details​

IncludeLongRunning​

These tests may take a long time in tenants that have a large number of user, group, or application objects. In the future, we hope to add the ability to set a dynamic threshold after checking the number of each object type in the tenant before testing. Then, for example, a tenants with less than a hypothetical threshold of 2000 users would run these tests by default, but tenants with more than 2000 users (as an example) would require the IncludeLongRunning switch to include these tests. Tenants with a very large number of users, groups, or applications can take hours to assess or even timeout completely due to the extra processing time required to get the objects and then report on them. Available memory on the system running Maester can also become a limiting factor in these scenarios.

IncludePreview​

Include tests that rely on functionality that is still in preview status. These might be tests that are based on new techniques that are still being validated by the Maester team or tests that are using a beta API.

How Will This Affect Me?​

We have done our best to deprecate the All and Full tags gracefully. They have been removed from all tests, but the Invoke-Maester function has also been updated to handle their use. However, this code may be removed in the future to keep Maester streamlined and easy to maintain. We currently support use of the tags and/or switches with the following logic:

• The -IncludeLongRunning switch is automatically enabled when the Full tag is included in the Tag parameter.
• The -IncludePreview switch is automatically enabled when the All tag is included in the Tag parameter.

In addition, if these deprecated tags are used, you will now see a warning in the output:

Bonus: Get-MtTestInventory​

Several commonly requested features have been related to the ability to get an inventory of the tests and their tags. The new Get-MtTestInventory function delivers exactly that. It enables users of Maester to gain more insights about the tests at their disposal.

The test inventory results are returned as an ordered dictionary (hash table) with the tags as the keys, and a list of the related tests as their associated values.

One way that this can be used is to list all tests associated with a specific tag such as "CIS."

$TestInventory = Get-MtTestInventory -Path ~/Maester-Tests -PassThru
$TestInventory['CIS']

Try those two commands to see the output, and then explore the tests associated with other tags such as 'XSPM.' You can also see the full list of discovered tags by running $TestInventory.Keys after the above command.

Conclusion​

For more information, please refer to the Maester documentation for Invoke-Maester and Get-MtTestInventory.

• Invoke-Maester
• Get-MtTestInventory

As always, Maester is a community project that thrives on your input! We gladly welcome any feedback or suggestions for improvements. You can also join our community on Discord. Thank you!

New version of Maester on Azure Web App 🎉​

What was it before?​

The setup allowed Maester to run on an Azure Web App, enabling you to perform Microsoft Graph security configuration checks on your Microsoft tenant directly from the Azure Web App, secured with Entra ID Authentication through an Azure Bicep deployment. At that time, it only supported Microsoft Graph security configuration tests. Many people asked me to update the deployment to include also the other tests that are part of Maester, because we want to utilize all the available tests that Maester has.

What has changed?​

• 🔥 Support for the latest Maester PowerShell module through the use of PowerShell 7.4 runtimes. 
• 💪🏻 Support for Exchange Online security tests 
• 🎉 Support for Security & Compliance security tests 
• 📱Support for Microsoft Teams security tests 
• 🤙🏻 Support for Azure configuration security tests

📚 Documentation​

Follow the step-by-step guide to start using the Azure Bicep Deployment for Maester on Azure Web App:

• Setup Maester in Azure Web App using Azure Bicep

Contributors 🙏​

We have built this Azure Bicep Deployment: 👇

_{Merill Fernando}

_{Brian Veldman}

What's Next?​

We are incredibly excited about the updated Maester Web App Deployment and have many ideas for new features and improvements. Feel free to share your ideas and contribute as well. 🙌

What is a control?​

The ComplianceForge team provides a nice definition:

"Controls are safeguards or countermeasures implemented to manage risks and protect assets. Cybersecurity controls can be technical, administrative, or physical and are designed to reduce vulnerabilities, prevent threats and ensure confidentiality, integrity and availability of information." (ComplianceForge, 2025)

In the simplest of terms your organization has said, "We care about X". The control documents what you are doing to protect "X".

Keeping in mind too, that your control usually is a reference to a general situation or outcome you are hoping to manage the risk of. Through that reference you will typically aim to have a mapping to a procedure. The procedure should specify what steps are taken to align with a control for a given system or process.

Controls will also typically map to the upstream compliance requirements through policies, standards, or other documentation.

A very simple example of how this fits together:

• Policy - "Employees must protect organization data"
• Control - "Computers should not remain unlocked when not in use for longer than 5 minutes"
• Procedure - "Configure the Windows lock screen timeout setting to 5 minutes of inactivity"

💡 Callout

Above you can see keywords should and must, these have specific implications as to optional or mandatory respectively as well. See RFC 2119 for more detail of one example of defining these terms.

This example is a simple example, but the nuance and complexity becomes challenging to manage at scale, your organization may even have individuals dedicated in a partial or full time capacity to managing this.

For our example we can map our control against a well known control framework or benchmarck, the Center for Internet Security (CIS) Critical Security Controls (CSC) Version 8.1. For CIS CSC safeguard 4.3 they specify a 15 minute maximum inactivity period for general computing devices. There are many different control frameworks out there that reference similar control concepts, and some frameworks may even have contradicting controls.

💡 Callout

Governance terminology (e.g., frameworks, policies, and standards) is used in many contexts with different meanings. For example, the United States National Institute of Standards and Technology (NIST) publishes the Special Publication (SP) 1800 series as guidelines, although these publications are often described as standards. Standards bodies cover many fields: the OpenID Foundation (OIDF) creates secure, interoperable, and privacy-preserving identity standards, while ASTM International provides resources for standards development and use worldwide. This also highlights the distinction between internal and external standards. External standards are typically consensus-driven by an industry working group around common implementation specifications, whereas internal standards define an organization's specific implementation requirements.

But still... Why would you implement that control?​

There are a many reasons your organization may want to implement a control like our example, but there are two general categories:

• Proactive risk mitigation
  • It is well known that cybersecurity has direct risk and impact to business operations. Understanding, identifying, and prioritizing these risks is beneficial for any organization. Some risks may be worth taking mitigating measures, such as implementing controls, proactively and others may not be a high enough priority.
• Regulatory compliance
  • Your organization may have specific regulatory or compliance obligations as part of your business operations as well. A common example of a regulatory obligation is Health Insurance Portability and Accountability Act (HIPAA) for healthcare covered entities and their business associates. Using our example control, 45 CFR 164.312(a)(2)(iii) identifies a specific addresable requirement.

Why do we need to compensate?​

Continuing to use the screen lock out example. You may find yourself in situations where:

• There is no technical capability on a system to enforce a screen lockout to the specific maximum inactivity time or possibly at all.
  • An example may be a proprietary system that does not offer the technical capability.
• There is a business process that does not allow for a screen lockout within the specific maximum inactivity time or possibly at all.
  • An example may be a kiosk or shared workstation.
• There may be tangential services you offer that do not fall within scope of the requirements.
  • An example may be a personal use device provided to clients during waiting periods.

Each of these situations could justify a need for an exception to your policy. These could be examples of compensating controls.

• You may decide to implement a physical safeguard and prevent physical access to a proprietary system that does not allow for a screen lockout.
• You may decide to exclude the shared workstations from policy, but require applications in use on those systems to enforce an inactivity requirement.
• You may decide to exclude all personal use devices from policy and prevent access to organization resources.

How does this apply to Maester?​

The Maester project provides a way for testing that a control's procedures are currently in place. Often times though your organization may have different requirements, exceptions, or preference in the controls you implement. Maester offers testing for multiple control procedures from community guidance (i.e., MT or EIDSCA), Cybersecurity & Infrastructure Security Agency (CISA), CIS, and more. Though there is still some decisions on your part which tests you want to use or if you should use your own.

The Maester project is providing you better visibility into the possible controls you may need to implement, but you still need to decide what is the best for your end user experience, acceptable risk tolerance, and business obligations.

Examples of this topic in the wild​

• https://github.com/maester365/maester/discussions/1068
• https://github.com/maester365/maester/discussions/429
• https://github.com/maester365/maester/discussions/1093
• https://github.com/maester365/maester/issues/686
• https://github.com/maester365/maester/issues/1052
• https://github.com/maester365/maester/issues/364
• https://github.com/maester365/maester/issues/282
• https://github.com/maester365/maester/issues/194
• https://github.com/maester365/maester/discussions/1049

Here are some quick stats for you:

❇️ 55,000+ tenants have used Maester to improve their security posture

🚀 260,000+ downloads of Maester on PowerShell Gallery

💻 2,600+ commits on GitHub

🤝 72+ contributors

✳️ 285 Maester tests (90+ new tests!)

📦 252 releases

There's a lot to cover, so let's dive right in!

We have added a lot of new features and improvements based on your feedback. Thank you for that! 🙏

Here are all the new features and improvements in this release:

🌟 New Tests​

We've added a whole bunch of new tests to check your security configuration, growing from 194 to 286! 🎉 Check out the test list for the full breakdown.

ORCA​

Mike Soule came up with the idea to integrate Cam Murray's excellent Office 365 Recommended Configuration Analyzer (ORCA) with Maester.

We reached out to Cam and he was all for helping Microsoft customers become more secure. With the greenlight, Mike started integrating ORCA and we had amazing support from Thomas Schmidt who really helped improve the quality and polish of the ORCA tests in Maester. Call out to Cameron Moore who pitched in with a huge number of PRs.

You can read more about this in our previous blog post Maester adds ORCA tests

Entra app tests​

We have a number of app related tests that help you identify potential security issues with your Entra applications.

Note: We don't run these new app related tests by default since they can take a long time to run. You will need to explicitly include them using Invoke-Maester -IncludeLongRunning.

This is because it needs to query all applications and service principals in the tenant which can take many hours in large tenants.

The application risk tests are based on the excellent Azure Tiering research by Emilien Socchi. These help identity apps that have a path to Global Admin permissions, which can lead to a full tenant takeover.

Maester - Platform Updates​

Special call out to Thomas Schmidt, Sam Erde, Stephan van Rooij and Cameron Moore for their amazing contributions to this release. They have been instrumental in making Maester more robust, performant and easier to use.

In addition, we have had a lot of contributions from the community, which has helped us improve Maester even further. Thank you to all our contributors! 🙏

🤖 Maester GitHub Action​

We are excited to announce the new Maester GitHub Action! 🎉

This version is a huge update and adds performance improvements as well a number of new features and configuration options.

We moved the Maester GitHub Action to a new repository, which allows us to better manage the action and its dependencies.

However, this means that you will need to update your workflow files to use the new action. See the Usage section in the Maester GitHub Action documentation for more details.

📋 Excel and CSV Export Formats​

We have added new export formats for the Maester report. You can now export the report in Excel and CSV formats, which makes it even more easier to share and analyze the results.

It's as simple as adding an -ExportExcel or -ExportCsv switch when running Invoke-Maester!

🚥 Severity levels​

Each test now includes a severity rating. This will help you prioritize the tests and focus on the most critical issues first.

You can also change the severity levels of the tests to suite your needs.

Check the Severity Levels documentation for all the details including how you can add Severity to your custom tests.

📊 Maester Report Improvements​

You can now search and filter the results list by name, severity, tags and more.

The test details view now support navigating to the next and previous test, making it easier to review the results.

Thank you to all our amazing contributors! 🙏​

There are many, many more new features, improvements and fixes that have gone in by this amazing list of contributors 👇

Here's a sneak peek at the some of the checks from ORCA that will be included in the next Maester release.

What is ORCA?​

Cam Murray created the Office 365 Recommended Configuration Analyzer (ORCA) PowerShell module to help align tenant configuration with Microsoft's recommended configurations. Many of these settings are available in the configuration analyzer today, but ORCA provided these insights earlier and often in a more concise approach. Building these configuration items as tests in Maester provided an awesome way to build on the core ORCA module value and bring even more context into the configuration state of a tenant.

How to build?​

The ORCA module utilizes user defined types with enumerations and classes heavily. This is the best approach for an individual module and helps produce well-typed and structured code bases. It also can be challenging when trying to merge code bases dynamically as those types within the module need to exist outside the module.

Git Submodules have their own issues too so definitely avoid those unless the challenges are worth it.

To handle this, PowerShell has this awesome feature called the abstract syntax tree (AST). This feature allows you to parse PowerShell files and interface with them as structured objects. Using the AST the Maester team was able to build a script to parse the ORCA code base and dynamically build the necessary functions, tests, and report details for incorporating with the Maester module.

Similarly and even more elegantly the EIDSCA team was able to incorporate their module as well.

How to contribute?​

Update-OrcaTests.ps1​

Located in /build/orca/Update-OrcaTests.ps1 is the build mechanism for each test derived from ORCA.

1. The latest ORCA module is pulled from orca.git into the subfolder /orca.
2. Prerequisites are initialized as described above and the following files are created in /powershell/internal/orca:
   • Add-IsPresetValue.ps1
   • Get-ORCACollection.ps1
   • Get-PolicyStateInt.ps1
   • Get-PolicyStates.ps1
   • Get-AnyPolicyState.ps1
3. Each ORCA check located in /build/orca/orca/Checks/ are processed and compiled into Maester tests like so:
   1. A $content variable is prepared and contains the following properties:

      Property	Purpose
      file	Name of the check script
      content	Content of the check script
      name	Name of the check
      pass	Text requirement of passing
      fail	Text for remediation
      func	Name of the test function
      control	Check control number
      area	Check category/area
      description	Check description
      links	Check related links

   2. Each property listed above are populated using regular expressions on the raw value of the ORCA check content.
   3. $testId is derived from $content.func to fit the Maester test id format.

      If it is not possible to derive it using the expected ORCA test function name format (ORCA.n or ORCA.n.n), where the last number is optional and can be any number of digits, it will skip processing this test. A manual fixed id must be added to $mapping = @{} at line ~187

   4. A pester test instruction file is generated and added to /tests/orca/ for each processed test, that instructs Maester to run the below mentioned function and process the result.
   5. A powershell function file is generated and added to /powershell/public/orca/ that contains the logic of initiating and processing the ORCA check result.
   6. A markdown file is generated and added to /powershell/public/orca/ that is associated with the above mentioned PowerShell file in which the description, remediation action and related links are placed.
4. ScriptsToProcess is made available for the Maester module manifest.
5. FunctionsToExport is made available for the Maester module manifest.

When modifying the /build/orca/Update-OrcaTests.ps1 it is important to run it as well in order to build all ORCA test files as described. See How to build?

Test function​

Each test function generated for each ORCA check contains various logic:

1. Skip if not connected to Exchange Online.
2. Set $SCC to true if connected to Security & Compliance, otherwise set to false.
3. If Get-ORCACollection has not been run before and stored in $__MtSession.OrcaCache then execute Get-ORCACollection -SCC:$SCC and store it in the cache.
4. Run the ORCA class New-Object -TypeName <Check> associated with the test upon the ORCA result $obj.Run($Collection) stored in the cache.
5. First, if the ORCA check should be skipped if it SkipInReport is specified in the check output.
6. Second, determine if the ORCA check should be skipped by evaluating if $obj.CheckFailed is true, if $obj.Completed is false or if the check output specifies that this is a Security & Compliance check and we are not connected to Security & Compliance.
7. Determine if the check passed or failed based on $obj.ResultStandard (See ORCA config level for more information).
8. Determine if we need to expand the results of the check $obj.ExpandResults otherwise add details to Maester and return.
9. Expand each nested result in $obj.ExpandResults into a markdown table showing the result of each individual result.
10. Add details to Maester and return.

Markdown file​

Each test function has its associated markdown file that provides Maester with test descriptions. It is comprised of description, remediation action and related links from the ORCA check.

Caveats to be aware of​

ORCA result is only processed once​

Each test will call Get-ORCACollection only if it has not been run and stored in the cache $__MtSession.OrcaCache before.

SkipInReport​

Some ORCA checks might have the property SkipInReport set. This must be handled in each test within a try-catch-finally block due to ORCA returning a Continue statement.

Test name should fit Maester format​

Every ORCA test should fit into the Maester test name format.

Regular expressions​

Regular expressions used to capture the raw content of each ORCA check is carefully crafted and allows us to adapt and overcome differences, such as:

• Always add punctuation to fail recommendation text if not present to stay consistent between tests.
• Dynamically populate name of the test if there are more than one ORCA check (The file name contains _) determined by property uniqueness.
• Replace _ with .
• Capture entire text of ORCA check importance, even if it varies between apostrophe and quotes.
• Remove HTML tags from ORCA check description.

Security & Compliance​

The command Get-ORCACollection requires the parameter of -SCC in order to include Security & Compliance tests in each test. However, we only set this to true if we are connected to Security & Compliance.

⚠️ WARNING: We require each ORCA check to include the property SCC in its object output in order for us to skip it in Maester if we are not connected to Security & Compliance. A pull request has been submitted by Thomas S. Schmidt to add this in the upstream module and is awaiting approval. For now it has been manually implemented in /build/orca/orca/ORCA.psm1 @ line 388 and /build/orca/orca/Checks/check-ORCA242.ps1 @ line 29.

ORCA config level​

Maester base the result on ORCA config level Standard. The property ResultStandard of the ORCA check output will be either Pass or Informational if the test passed.

Results​

With this build script, the Maester module can now dynamically build the necessary files for testing and reporting on all the ORCA controls. Providing users with a single report covering many controls that existed before Maester and which are still valuable.

Acknowledgements​

Huge shoutout to the Maester team for all of their awesome contributions in this substantial addition, including:

• Thomas S. Schmidt @ TDC Erhverv Security Insights
• Cameron Moore
• Cam Murray

Contributors​

• Mike Soule
• Thomas S. Schmidt

Teams using Azure DevOps pipelines can now easily integrate Maester into their CI/CD workflows to run automated security checks and enhance their security monitoring on a daily basis.

Utiziling an Azure web app providing access to the results using Entra id as authentication.

Azure DevOps Web App Flowchart​

Quick Stats​

• 🚀 Automated security tests using Azure DevOps Pipelines updated every 12th hour by default
• 🔥 Up and running within 10 minutes
• 🤝 Viewable Maester reports using Azure Web App
• 🔐 Pipeline with authentication support for Exchange Online, ISSP (using certificate based authentication) and Microsoft Teams

Get Started​

Follow the step-by-step guide to set up Maester in Azure DevOps with required resources:

• Documentation: Set up Maester in Azure DevOps with Web App

Contributor​

• Sebastian Claesson

Teams using BitBucket pipelines can easily integrate Maester into their CI/CD workflows to run automated security checks and enhance their security monitoring.

Maester running on BitBucket​

Why It Matters​

• Run automated Microsoft 365 security tests in BitBucket pipelines
• Quick setup - get started in minutes
• Clear and actionable security test reports

Get Started​

Follow the step-by-step guide to set up Maester in BitBucket:

• Documentation: Set up Maester in BitBucket

Contributor​

• Suryendu Bhattacharyya

Teams using GitLab pipelines can easily integrate Maester into their CI/CD workflows to run automated security checks and enhance their security monitoring.

Maester running on GitLab​

Why It Matters​

• Run automated Microsoft 365 security tests in GitLab pipelines
• Quick setup - get started in minutes
• Clear and actionable security test reports

Get Started​

Follow the step-by-step guide to set up Maester in GitLab:

• Documentation: Set up Maester in GitLab

Contributor​

• Stefan Wey

Maester Terraform Module 🎉​

Quick Stats​

• 🚀 Automated security tests using Azure DevOps Pipelines
• 🔥 Up and running within 5 minutes
• 🤝 Downloadable and viewable Maester reports
• ✳️ Detailed view of each test, including name, duration, and status

DevOps Tests Page​

📚 Documentation​

Follow the step-by-step guide to start using the Terraform Module:

• Azure DevOps with Terraform Module
• Terraform Registry

Contributors 🙏​

We have built this Terraform Module: 👇

_{Merill Fernando}

_{Brian Veldman}

What's Next?​

We are incredibly excited about the Maester Terraform Module and have many ideas for new features and improvements. 🙌

Maester reaches v1! 🎉​

We launched Maester at the PowerShell + DevOps Global Summit in March this year and it has been an amazing journey since then.

Here are some quick stats for you:

• 🚀 100,000+ downloads on PowerShell Gallery
• 🌐 17,000 monthly visitors to maester.dev
• 💻 1,800+ commits on GitHub
• 🤝 48+ contributors
• ✳️ 194 Maester tests
• 📦 155 releases

We have added a lot of new features and improvements based on your feedback. Thank you for that! 🙏

What's new since March v0.1.0​

It’s taken a whole village to bring you Maester v1. 🌟 Here are some of the highlights:

🧪 New Tests​

We've almost doubled the number of tests, growing from 96 to 194! 🎉 Check out the test list for the full breakdown. Special mentions go to:

• Mike – Mike started adding CISA tests to Maester the very next day after Maester was unveiled at the PowerShell conference. 🚀 Since then, he’s been instrumental in contributing code, replying to issues on GitHub, and engaging on Discord. Maester wouldn’t be where it is today without him. Thank you, Mike! 🙌
• Ben – Ben took the initiative to add CIS benchmark tests and is now our #6 highest contributor. Thanks, Ben, for the tremendous value you've brought to Maester! 💪

🤖 Maester GitHub Action​

Fabian built the Maester - GitHub Action, simplifying the setup and running of Maester on GitHub. He completed this just in time for the PowerShell Conference Europe. Thank you, Fabian! 👏

🛡️ Entra ID - Security Config Analyzer Updates​

Thomas has done phenomenal work keeping Maester updated with EIDSCA. His vigilance in monitoring Entra ID and adding new security checks has been invaluable in improving the security posture of countless Entra tenants. 🙏

📊 Pester Test & Report Improvements​

A massive shout-out to Frode Flaten for refactoring the Maester codebase and elevating it to new heights. 🚀 From enhancing performance for PSScriptAnalyzer to improving test reports with filtering and tag support, Frode has made Maester run smoother and more efficiently. Thank you, Frode! 🌟

🛠️ New & Improved Test Folder Installation​

Thanks to Sam Erde for making Maester more robust. From improving the test install/update process to fixing PowerShell mistakes (😉), Sam has been a powerhouse!

🫂 New Teams Tests​

Kudos to Stefan Wey for a whirlwind of contributions! Stefan added new tests for Microsoft Teams meeting policies, fixed Entra Recommendations tests, and ensured PowerShell 5 compatibility. Incredible work! 👏

💬 Teams Alerts​

Thanks to Guido Baijense for adding support to send Teams alerts from Maester using a cmdlet with Adaptive Card templates. 💬

🗨️ Slack Alerts​

Shout-out to Fabrizio Di Carlo for adding Slack alert support to Maester. 💻

☁️ Azure Automation​

Daniel Bradley added Azure Automation support to Maester. 🚀

🏗️ Azure Automation with Bicep​

Brian Veldman elevated Azure Automation by adding Bicep support. Amazing! 🙌

🐳 Azure Container App Job​

Thanks to Mike Soule for enabling Docker and Azure Container App Job support for Maester. ⚙️

🖥️ Azure DevOps - Virtual Machine Scale Set Support​

Ilija Ranogajec added support for running Maester in VMSS hosted agents. Awesome work! 🚀

✍️ New Maester Blog​

We’ve started a new blog to share ideas on tests, security, DevOps, and automation. Don’t forget to subscribe via RSS! 📰

📚 Test Documentation Updates​

Big thanks to the following contributors for improving remediation steps for tests, making them clearer and easier to follow:

• Michael Morten Sonne
• Jan Bakker
• Christian Frohn

Thank you to all our amazing contributors! 🙏​

There are many, many more new features, improvements and fixes that have gone in by this amazing list of contributors 👇

_{Mike Soule}

_Fabian

_Thomas

_{Frode Flaten}

_Ben

_{Sam Erde}

_{Michael Sonne}

_{Christian Frohn}

_{Stefan Wey}

_{Daniel Bradley}

_{Thomas Schmidt}

_{Adam Laycock}

_{Guido Baijense}

_corpca-Admin

_{Ben Street}

_dnsinit

_{Erik Oppedijk}

_{Tom Biscardi}

_{Brian Veldman}

_{Tom Pye}

_{Marco Deleu}

_{Pranav Kothare}

_{PT Mohr}

_{Daniel Wahlgren}

_{Tommi Laukkanen}

_{Wes MacDonald}

_{Nathan McNulty}

_{Joshua Fernando}

_{Milan Schwartz}

_{Irwin Strachan}

_{Fabrizio Di Carlo}

_{Ilija Ranogajec}

_{Jan Bakker}

_{Robin Dadswell}

_{Frederik Leed}

_{Thorsten Sauter}

_{Håkon Kristiansen}

_{Jeroen Burgerhout}

_m-hanisch

_{Matt Cave}

_Lennart

_Jean-Paul

_{Petter Fauske}

_{Gerald Lasch}

_{Thomas Balthazar}

_{Stephan van Rooij}

_mircodemo

What's next?​

We are super excited about the future of Maester and we have a lot of ideas for new features and improvements. We are even more excited to have you come and shape the future of Maester with us! 🙌