Connect-Maester Advanced
Overview
There are two main methods of authenticating sessions for use with Maester:
- Within the Maester module
- Within the respective modules for the tests
Within the Maester module
Recommended for interactive use
The Maester module includes Connect-Maester
to provide coverage for common scenarios. The parameter set options afford a user of the module the ability to test with common interactive methods. The Microsoft Graph API is the default authentication service, and more specifically the Microsoft Graph PowerShell SDK. Coverage for tests shipping with Maester have at least one option available in general.
The objective of the Maester module is not to replace or consolidate the authentication options across the many possible testing sources.
Within the respective modules for the tests
Recommended for automation use
The Maester module provides a framework for creating, executing, and reporting on configuration state using tests. Each test can rely on one or more sources to perform validation. Each source a test validates may be available without authentication (e.g., Domain Name System) or may require authentication to a sepcific environment (e.g., Microsoft Graph API).
The recommendation for authenticating to modules necessary to support tests for the most extensibility is to authentcate within those source modules and running Invoke-Maester
with the -SkipGraphConnect
property.
As an example, connecting to the Microsoft Graph PowerShell SDK module as a managed identity and then running Maester.
Running
Connect-Maester
is not required to useInvoke-Maester
.
Connect-MgGraph -Identity -NoWelcome
Invoke-Maester -SkipGraphConnect -NonInteractive
The following diagram provides a general overview of command dependency relationships. You can extend Maester with your own tests that leverage other modules as may be beneficial. There is no dependency for your own tests to rely on the Connect-Maester
capabilities.
You can write tests that expand Maester to validate the configuration state of infrastructure in the cloud, on-premises, and entirely unrelated to Microsoft products.
For use with the Maester tests the following provides an overview of creating the necessary service principal.
Create an Entra Application
- Open Entra admin center > Identity > Applications > App registrations
- Tip: enappreg.cmd.ms is a shortcut to the App registrations page.
- Select New registration
- Enter a name for the application (e.g.
Maester DevOps Account
) - Select Register
Grant permissions to Microsoft Graph
- Open the application you created in the previous step
- Select API permissions > Add a permission
- Select Microsoft Graph > Application permissions
- Search for each of the permissions and check the box next to each permission:
- Directory.Read.All
- DirectoryRecommendations.Read.All
- IdentityRiskEvent.Read.All
- Policy.Read.All
- Policy.Read.ConditionalAccess
- PrivilegedAccess.Read.AzureAD
- Reports.Read.All
- RoleEligibilitySchedule.Read.Directory
- RoleManagement.Read.All
- SharePointTenantSettings.Read.All
- UserAuthenticationMethod.Read.All
- Optionally, search for each of the permissions if you want to allow privileged permissions:
- RoleEligibilitySchedule.ReadWrite.Directory
- Required for eligible role assignments (Reference)
- RoleEligibilitySchedule.ReadWrite.Directory
- Select Add permissions
- Select Grant admin consent for [your organization]
- Select Yes to confirm
(Optional) Grant permissions to Exchange Online
The Exchange Online Role Based Access Control (RBAC) implementation utilizes service specific roles that apply to an application and the below configuration allows the authorization chain to the App Registration you created in the previous steps.
The Exchange Online permissions are necessary to support tests that validate Exchange Online configurations, such as the CISA tests.
- Open the application you created in the previous step
- Select API permissions > Add a permission
- Select APIs that my organization uses > search for Office 365 Exchange Online > Application permissions
- Search for
Exchange.ManageAsApp
- Select Add permissions
- Select Grant admin consent for [your organization]
- Select Yes to confirm
- Connect to the Exchange Online Management tools and use the following to set the appropriate permissions:
New-ServicePrincipal -AppId <Application ID> -ObjectId <Object ID> -DisplayName <Name>
New-ManagementRoleAssignment -Role "View-Only Configuration" -App <DisplayName from previous command>
(Optional) Grant permissions to Azure
The Azure Role Based Access Control (RBAC) implementation utilizes Uniform Resource Names (URN) with a "/" separator for heirarchical scoping. There exists resources within the root (e.g., "/") scope that Microsoft retains strict control over by limiting supported interactions. As a Global Administrator you can elevate access to become authorized for these limited interactions.
The Azure RBAC permissions are necessary to support tests that validate Azure configurations, such as the CISA tests.
The following PowerShell script will enable you, with a Global Administrator role assignment, to:
- Identify the Service Principal Object ID that will be authorized as a Reader and the Subscription ID to authorize for
- Install the necessary Az module and prompt for connection
- Elevate your account access to the root scope
- Create a role assignment for Reader access over the Subscription and objects within
- Create a role assignment for Reader access over the Entra ID (i.e., aadiam provider)
- Identify the role assignment authorizing your account access to the root scope
- Delete the root scope role assignment for your account
$servicePrincipal = "<Object ID of the Entra App>"
$subscription = "<Subscription ID>"
Install-Module Az.Accounts -Force
Install-Module Az.Resources -Force
Connect-AzAccount
#Elevate to root scope access
$elevateAccess = Invoke-AzRestMethod -Path "/providers/Microsoft.Authorization/elevateAccess?api-version=2015-07-01" -Method POST
New-AzRoleAssignment -ObjectId $servicePrincipal -Scope "/subscriptions/$subscription" -RoleDefinitionName "Reader" -ObjectType "ServicePrincipal"
New-AzRoleAssignment -ObjectId $servicePrincipal -Scope "/providers/Microsoft.aadiam" -RoleDefinitionName "Reader" -ObjectType "ServicePrincipal"
#Remove root scope access
$assignment = Get-AzRoleAssignment -RoleDefinitionId 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9|?{$_.Scope -eq "/" -and $_.SignInName -eq (Get-AzContext).Account.Id}
$deleteAssignment = Invoke-AzRestMethod -Path "$($assignment.RoleAssignmentId)?api-version=2018-07-01" -Method DELETE
Authenticating Across Tenants
You may have a need to use Maester with multiple tenanats. The Maester tests enable you to accomplish this, but it is best to authenticate within the respective modules for the tests you wish to run.
Microsoft Graph PowerShell SDK Module
The Microsoft Graph PowerShell SDK Module provides many options for authenticating. Below is an example of using a X.509 Certificate private key file, $cert
, to authenticate to $tenantId
as the $applicationId
service principal.
#$applicationId = "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
#tenantId = "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
#$b64 = Get-Content .\path\to\cert.pfx -Raw
#$b64 = Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $applicationDisplayName -AsPlainText
#$bytes = [Convert]::FromBase64String($b64)
#$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($bytes)
Connect-MgGraph -AppId $applicationId -Certificate $cert -TenantId $tenantId -NoWelcome
Microsoft Azure Accounts PowerShell Module
The Microsoft Azure Accounts PowerShell Module provides many options for authenticating. Below is an example of using a X.509 Certificate private key file to authenticate to $tenantId
as the $applicationId
service principal.
#$applicationId = "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
#tenantId = "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
Connect-AzAccount -ServicePrincipal -ApplicationId $applicationId -TenantId $tenantId -CertificatePath /cert.pfx
Microsoft Exchange Online and Security & Compliance PowerShell Modules
The Microsoft Exchange Online and Security & Compliance PowerShell Modules provide many options for authenticating. Below is an example of using a X.509 Certificate private key file, $cert
, to authenticate to $tenantId
as the $applicationId
service principal.
These modules don't reference the tenant ID GUID for authentication, they instead use the tenant's Microsoft Online Email Routing Address (MOERA).
#$applicationId = "xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx"
#$b64 = Get-Content .\path\to\cert.pfx -Raw
#$b64 = Get-AzKeyVaultSecret -VaultName $keyVaultName -Name $applicationDisplayName -AsPlainText
#$bytes = [Convert]::FromBase64String($b64)
#$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($bytes)
#$domains = Invoke-MgGraphRequest -Uri https://graph.microsoft.com/v1.0/domains
#$moera = ($domains.value|?{$_.isInitial}).id
Connect-ExchangeOnline -Certificate $cert -AppID $applicationId -Organization $moera -ShowBanner:$false
Connect-IPPSSession -Certificate $cert -AppID $applicationId -Organization $moera -ShowBanner:$false