Skip to main content

Connect Microsoft 365

Argus scans a Microsoft 365 tenant read-only through an app registered in your Microsoft Entra ID (formerly Azure AD). Nothing is installed in the tenant, and Argus only ever reads.

Both connection methods are app-only: Argus authenticates as the app itself. No user account, mailbox or password is involved, and no user signs in.

Before you start​

  • Permission to register an application in Microsoft Entra ID and grant it admin consent, such as a Global Administrator or an Application Administrator.
  • An available account slot: Free connects one account, Pro connects an unlimited number. See Billing & plans.
  • For the recommended certificate method, a machine with OpenSSL to create the certificate.

Provider-side setup​

Yes, connecting Microsoft 365 requires an app registration in Entra ID. Registering the app creates the enterprise application (the service principal) that Argus authenticates as.

  1. In the Microsoft Entra admin center, open App registrations and register a new application. This creates the enterprise application in your tenant.
  2. Grant the app the read-only Microsoft Graph application permissions the posture checks require (see Required permissions), then grant admin consent for the tenant. Argus never writes, so no write permission is needed.
  3. Add a credential to the app:
    • Recommended: a certificate. Create it as described in Create the certificate, then under Certificates & secrets, Certificates, upload the public certificate file (.cer). The private key never goes to Microsoft.
    • Alternatively: a client secret, used by the client-secret method below.
  4. From the app's Overview, copy the Application (client) ID and the Directory (tenant) ID.

Create the certificate​

Argus authenticates with a certificate whose public half is uploaded to Entra ID and whose private key stays with Argus, stored server-side. Entra ID only uses the public key to verify the signature on each token request, so a self-signed certificate is fine and is the usual choice. A certificate issued by your internal CA works exactly the same way; nothing checks the issuer.

Argus takes the certificate as a Base64-encoded, passwordless PFX bundle (PKCS #12, holding the certificate and its private key), not as a PEM file. On macOS or Linux:

# 1. Create a private key. Keep this file private; it is never uploaded.
openssl genrsa -out argus-m365.key 2048

# 2. Create a self-signed certificate, valid for two years.
openssl req -x509 -new -nodes -key argus-m365.key -sha256 -days 730 \
  -out argus-m365.cer -subj "/CN=Argus Microsoft 365 scanner"

# 3. Bundle the key and the certificate into a passwordless PFX.
openssl pkcs12 -export -out argus-m365.pfx \
  -inkey argus-m365.key -in argus-m365.cer -passout pass:

# 4. Base64-encode the PFX. This is the value you paste into Argus.
base64 -i argus-m365.pfx | tr -d '\n'      # macOS
base64 -w0 argus-m365.pfx                  # Linux

Upload only argus-m365.cer to Entra ID (step 3 of the setup above). Paste the Base64 output into Argus. Line breaks in the pasted value are fine; Argus removes them.

If you prefer a CA-issued certificate, replace step 2 with a certificate signing request to your CA and bundle the signed certificate in step 3. The PFX must not have a password.

:::warning Guard the key and the PFX Anyone holding argus-m365.key or argus-m365.pfx can read your tenant as the app. Delete local copies once the account is connected, and rotate the certificate before it expires or if you suspect exposure. To rotate, upload the new .cer to Entra ID and use Update credentials on the account card. :::

Required permissions​

For full coverage of the Microsoft 365 checks, grant the app these read-only Microsoft Graph application permissions, then click Grant admin consent for the tenant:

PermissionUsed by
Directory.Read.AllEvery check
Policy.Read.AllEvery check
AuditLog.Read.AllEntra ID checks (MFA registration and usage)
SharePointTenantSettings.Read.AllSharePoint checks
SecurityIdentitiesHealth.Read.AllDefender for Identity health check
SecurityIdentitiesSensors.Read.AllDefender for Identity health check
ThreatHunting.Read.AllDefender XDR checks, and the Entra ID check on app registrations with unused privileged permissions
DeviceManagementServiceConfig.Read.AllIntune checks, and the Entra ID check requiring a compliant device
DeviceManagementConfiguration.Read.AllIntune checks, and the Entra ID check requiring a compliant device
DeviceManagementManagedDevices.Read.AllIntune checks, and the Entra ID check requiring a compliant device

The Exchange Online, Defender for Office 365, Purview and Teams checks read their settings through Microsoft's admin APIs rather than Graph. To cover them, additionally grant:

  • Exchange.ManageAsApp (Office 365 Exchange Online API, under APIs my organization uses), and assign the app the Global Reader directory role under Roles and administrators. Covers Exchange Online, Defender for Office 365 and Purview.
  • application_access (Skype and Teams Tenant Admin API). Covers Teams.

Then click Grant admin consent again so the new permissions take effect.

Scoping to Entra ID only​

You do not have to grant everything. A check whose data the app cannot read produces no finding: it is absent from the results rather than reported as failing, and the compliance requirements it maps to stay uncovered. Grant what matches the services you want Argus to assess.

To monitor identities and Entra ID configuration only, the minimum is:

  • Directory.Read.All
  • Policy.Read.All
  • AuditLog.Read.All

That covers users, groups, roles, service principals, app registrations, conditional access, authentication methods, MFA registration and the identity protection policies. Two Entra ID checks reach into other services and only evaluate with their permissions granted: the check requiring a compliant device (needs the three DeviceManagement*.Read.All permissions) and the check on app registrations with unused privileged permissions (needs ThreatHunting.Read.All).

:::note Do not narrow Directory.Read.All for identity monitoring Directory.Read.All can be replaced with Domain.Read.All plus Organization.Read.All for a tighter scope, but the Entra ID checks that read directory roles and users then stop running. For identity monitoring, keep Directory.Read.All. :::

:::note Hybrid tenants: two checks need a manual review Two Entra checks read the on-premises directory synchronization settings (Seamless SSO disabled, and object takeover blocked through soft and hard matching). Microsoft Graph only exposes those settings to a signed-in Global Administrator, never to an application, so OnPremDirectorySynchronization.Read.All does not appear under Application permissions and cannot be granted to the app. On a tenant with on-premises sync enabled, Argus reports both checks as Manual; on a cloud-only tenant they pass as not applicable. No other check is affected. :::

Connect in Argus​

Go to Accounts and click Connect account. Pick Microsoft 365, then the recommended Certificate method. Enter:

FieldValue
Tenant domainyour tenant's domain, e.g. contoso.onmicrosoft.com
Client IDthe Application (client) ID from step 4
Tenant IDthe Directory (tenant) ID from step 4
Certificate (Base64 PFX)the Base64 output of step 4 in Create the certificate

The form rejects a PEM block or anything that is not Base64 before it is sent.

Client secret​

A second method, Client secret, takes the Client ID, Tenant ID and a client secret from the app's Certificates & secrets. It is app-only too: the secret belongs to the app registration, not to any user. Prefer the certificate method; a client secret expires and has to be rotated in Argus with Update credentials on the account card.

Connection test​

Finish the wizard. Argus stores the credential server-side and runs an asynchronous connection test before the first scan. The account card reports Connected, Checking…, Failed, or Check failed. On a failure, re-check the values above, confirm admin consent was granted, and use Test connection on the account card to retry. Check failed means the check could not run at all rather than that the tenant rejected the credential; retry it, and contact support if it fails again.

Official Microsoft documentation​