Microsoft 365 Authentication in Prowler

Prowler for Microsoft 365 supports multiple authentication types across Prowler Cloud and Prowler CLI.

Navigation

• Common Setup
• Prowler Cloud Authentication
• Prowler CLI Authentication
• Supported PowerShell Versions
• Required PowerShell Modules

Common Setup

Authentication Methods Overview

Prowler Cloud uses app-only authentication. Prowler CLI supports the same app-only options and two delegated flows.

Prowler Cloud:

• Application Certificate Authentication (Recommended)
• Application Client Secret Authentication

Prowler CLI:

• Application Certificate Authentication (Recommended)
• Application Client Secret Authentication
• Azure CLI Authentication
• Interactive Browser Authentication

Required Permissions

To run the full Prowler provider, including PowerShell checks, two types of permission scopes must be set in Microsoft Entra ID.

Application Permissions for App-Only Authentication

When using service principal authentication, add these Application Permissions:

Microsoft Graph API Permissions:

• AuditLog.Read.All: Required for Entra service.
• Directory.Read.All: Required for all services.
• Policy.Read.All: Required for all services.
• SharePointTenantSettings.Read.All: Required for SharePoint service.

External API Permissions:

• Exchange.ManageAsApp from external API Office 365 Exchange Online: Required for Exchange PowerShell module app authentication. The Global Reader role must also be assigned to the app.
• application_access from external API Skype and Teams Tenant Admin API: Required for Teams PowerShell module app authentication.

Directory.Read.All can be replaced with Domain.Read.All for more restrictive permissions, but Entra checks related to DirectoryRoles and GetUsers will not run. If using this option, you must also add the Organization.Read.All permission to the application registration for authentication.

These permissions enable application-based authentication methods (client secret and certificate). Using certificate-based authentication is the recommended way to run the full M365 provider, including PowerShell checks.

Browser Authentication Permissions

When using browser authentication, permissions are delegated to the user, so the user must have the appropriate permissions rather than the application.

Browser and Azure CLI authentication methods limit scanning capabilities to checks that operate through Microsoft Graph API. Checks requiring PowerShell modules will not execute, as they need application-level permissions that cannot be delegated through browser authentication.

Step-by-Step Permission Assignment

Create Application Registration

1. Access Microsoft Entra ID.

   

2. Navigate to “Applications” > “App registrations”.

   

3. Click ”+ New registration”, complete the form, and click “Register”.

   

4. Go to “Certificates & secrets” > “Client secrets” > ”+ New client secret”.

   

5. Fill in the required fields and click “Add”, then copy the generated value (this will be AZURE_CLIENT_SECRET).

   

Grant Microsoft Graph API Permissions

1. Open API permissions for the Prowler application registration.

   

2. Click ”+ Add a permission” > “Microsoft Graph” > “Application permissions”.

   

3. Search and select the required permissions:

   • AuditLog.Read.All: Required for Entra service
   • Directory.Read.All: Required for all services
   • Policy.Read.All: Required for all services
   • SharePointTenantSettings.Read.All: Required for SharePoint service
   

4. Click “Add permissions”, then click “Grant admin consent for <your-tenant-name>”.

Grant PowerShell Module Permissions

1. Add Exchange API:

   • Search and select “Office 365 Exchange Online” API in APIs my organization uses.
   
   • Select “Exchange.ManageAsApp” permission and click “Add permissions”.
   
   • Assign Global Reader role to the app: Go to Roles and administrators > click here for directory level assignment.
   
   • Search for Global Reader and assign it to the application.
   

2. Add Teams API:

   • Search and select “Skype and Teams Tenant Admin API” in APIs my organization uses.
   
   • Select “application_access” permission and click “Add permissions”.
   

3. Click “Grant admin consent for <your-tenant-name>” to grant admin consent.

   

Final permissions should look like this:

Use the same application registration for both Prowler Cloud and Prowler CLI while switching authentication methods as needed.

Application Certificate Authentication (Recommended)

Available for both Prowler Cloud and Prowler CLI

Authentication flag for CLI: --certificate-auth

Certificate-based authentication replaces the client secret with an X.509 certificate that signs Microsoft Entra ID tokens for the Prowler application registration.

This is the recommended approach for production environments because it avoids long-lived secrets, supports the full provider (including PowerShell checks), and simplifies unattended automation. Microsoft also recommends certificate credentials for app-only access, see Manage certificates for applications.

Generate the Certificate

The service principal needs a certificate that contains the private key locally (for Prowler) and the public key uploaded to Microsoft Entra ID. The following commands show a secure baseline workflow on macOS or Linux using OpenSSL:

# 1. Create a private key (keep this file private; do not upload it to the portal)
openssl genrsa -out prowlerm365.key 2048

# 2. Create a self-signed certificate valid for two years
openssl req -x509 -new -nodes -key prowlerm365.key -sha256 -days 730 -out prowlerm365.cer -subj "/CN=ProwlerM365Cert"

# 3. Package the key and certificate into a passwordless PFX bundle for Prowler
openssl pkcs12 -export \
  -out prowlerm365.pfx \
  -inkey prowlerm365.key \
  -in prowlerm365.cer \
  -passout pass:

Guard prowlerm365.key and prowlerm365.pfx. Only upload the .cer file to the Entra ID portal. Rotate or revoke the certificate before it expires or if there is any suspicion of exposure.

If an internal certificate authority is preferred, replace step 2 with a CSR workflow and import the signed certificate instead.

Upload the Certificate to Microsoft Entra ID

1. Open Microsoft Entra ID > App registrations > the Prowler application.
2. Go to Certificates & secrets > Certificates.
3. Select Upload certificate and choose prowlerm365.cer.
4. Confirm the certificate appears with the expected expiration date.

After the certificate is in place, encode the PFX file so it can be stored in an environment variable (macOS/Linux example):

base64 -i prowlerm365.pfx -o prowlerm365.pfx.b64
cat prowlerm365.pfx.b64 | tr -d '\n'

Copy the resulting single-line Base64 string (or the contents of prowlerm365.pfx.b64) for the next step.

Provide the Certificate to Prowler

• Prowler Cloud: Paste the Base64-encoded PFX in the certificate_content field when configuring the Microsoft 365 provider in Prowler Cloud.
• Prowler CLI: Export credential variables or pass the local file path when running Prowler.

export AZURE_CLIENT_ID="00000000-0000-0000-0000-000000000000"
export AZURE_TENANT_ID="11111111-1111-1111-1111-111111111111"
export M365_CERTIFICATE_CONTENT="$(base64 < prowlerm365.pfx | tr -d '\n')"

Store the PFX securely and reference it when running the CLI:

python3 prowler-cli.py m365 --certificate-auth --certificate-path /secure/path/prowlerm365.pfx

The CLI still needs AZURE_CLIENT_ID and AZURE_TENANT_ID in the environment when --certificate-path is used.

Do not mix certificate authentication with a client secret. Provide either a certificate or a secret to the application registration and Prowler configuration.

Application Client Secret Authentication

Available for both Prowler Cloud and Prowler CLI

Authentication flag for CLI: --sp-env-auth

Authenticate using a Microsoft Entra application registration with a client secret by configuring the following environment variables:

export AZURE_CLIENT_ID="XXXXXXXXX"
export AZURE_CLIENT_SECRET="XXXXXXXXX"
export AZURE_TENANT_ID="XXXXXXXXX"

If these variables are not set or exported, execution using --sp-env-auth will fail. This workflow is helpful for initial validation or temporary access. Plan to transition to certificate-based authentication to remove long-lived secrets and keep full provider coverage in unattended environments.

To scan every M365 check, ensure the required permissions are added to the application registration. Refer to the PowerShell Module Permissions section for more information.

If the external API permissions described above are not added, only checks that work through Microsoft Graph will be executed. This means that the full provider will not be executed.

Prowler Cloud Authentication

Use the shared permissions and credentials above, then complete the Microsoft 365 provider form in Prowler Cloud. The platform persists the encrypted credentials and supplies them during scans.

Application Certificate Authentication (Recommended)

1. Select Application Certificate Authentication.
2. Enter the tenant ID and application (client) ID.
3. Paste the Base64-encoded certificate content.

This method keeps all Microsoft 365 checks available, including PowerShell-based checks.

Application Client Secret Authentication

1. Select Application Client Secret Authentication.
2. Enter the tenant ID and application (client) ID.
3. Enter the client secret.

Prowler CLI Authentication

Certificate Authentication

Authentication flag for CLI: --certificate-auth

After credentials are exported, launch the Microsoft 365 provider with certificate authentication:

python3 prowler-cli.py m365 --certificate-auth --init-modules --log-level ERROR

Prowler prints the certificate thumbprint during execution so the correct credential can be verified.

Client Secret Authentication

Authentication flag for CLI: --sp-env-auth

After exporting the secret-based variables, run:

python3 prowler-cli.py m365 --sp-env-auth --init-modules --log-level ERROR

Azure CLI Authentication

Authentication flag for CLI: --az-cli-auth

Azure CLI authentication relies on the identity that is already signed in with the Azure CLI. Before running Prowler, make sure you have an active CLI session in the target tenant:

az login --tenant <TENANT_ID>
# Optional: enforce the tenant when several are available
az account set --tenant <TENANT_ID>

If reusing the same service principal that powers certificate-based authentication, authenticate it through Azure CLI instead of exporting environment variables. Azure CLI expects the certificate in PEM format; convert the PFX produced earlier and sign in:

openssl pkcs12 -in prowlerm365.pfx -out prowlerm365.pem -nodes
az login --service-principal \
  --username <AZURE_CLIENT_ID> \
  --password /secure/path/prowlerm365.pem \
  --tenant <AZURE_TENANT_ID>

After the CLI session is authenticated, launch Prowler with the Azure CLI flag:

python3 prowler-cli.py m365 --az-cli-auth

The Azure CLI identity must hold the same Microsoft Graph and external API permissions required for the full provider. Signing in with a user account limits the scan to delegated Microsoft Graph endpoints and skips PowerShell-based checks. Use a service principal with the necessary application permissions to keep complete coverage.

Interactive Browser Authentication

Authentication flag for CLI: --browser-auth

Authenticate against Azure using the default browser to start the scan. The --tenant-id flag is also required.

These credentials only enable checks that rely on Microsoft Graph. The entire provider cannot be run with this method. To perform a full M365 security scan, use the recommended authentication method.

Since this is a delegated permission authentication method, necessary permissions should be assigned to the user rather than the application.

Supported PowerShell Versions

PowerShell is required to run certain M365 checks.

Supported versions:

• PowerShell 7.4 or higher (7.5 is recommended)

Why Is PowerShell 7.4+ Required?

• PowerShell 5.1 (default on some Windows systems) does not support required cmdlets.
• Older cross-platform PowerShell versions are unsupported, leading to potential errors.

Installing PowerShell is only necessary if you install Prowler via pip or other sources. SDK and API containers include PowerShell by default.

Installing PowerShell

Installing PowerShell is different depending on your OS:

Windows

Windows: PowerShell must be updated to version 7.4+ for Prowler to function properly. Otherwise, some checks will not show findings and the provider may not function properly. This version of PowerShell is supported on Windows 10, Windows 11, Windows Server 2016 and higher versions.

winget install --id Microsoft.PowerShell --source winget

Required PowerShell Modules

Prowler relies on several PowerShell cmdlets to retrieve necessary data. These cmdlets come from different modules that must be installed.

Automatic Installation

The required modules are automatically installed when running Prowler with the --init-modules flag.

Example command:

python3 prowler-cli.py m365 --verbose --log-level ERROR --sp-env-auth --init-modules

If the modules are already installed, running this command will not cause issues—it will simply verify that the necessary modules are available.

Prowler installs the modules using -Scope CurrentUser. If you encounter any issues with services not working after the automatic installation, try installing the modules manually using -Scope AllUsers (administrator permissions are required for this). The command needed to install a module manually is:

Install-Module -Name "ModuleName" -Scope AllUsers -Force

Modules Version

• MSAL.PS: Required for Exchange module via application authentication.
• ExchangeOnlineManagement (Minimum version: 3.6.0) Required for checks across Exchange, Defender, and Purview.
• MicrosoftTeams (Minimum version: 6.6.0) Required for all Teams checks.