Microsoft connector (auto-managed mode)

When to use auto-managed mode

• You want the simplest setup for the customer — no manual app registration in their Azure portal.
• You want the connector to survive Global Admin password resets, role changes, and account churn.
• You want one consent prompt that covers ingestion, detection, response actions, AND posture (no separate Office 365 step, no separate posture-app step).
• You are comfortable with the platform creating a dedicated app registration named "ITDR Connector — <your tenant>" that stays in the customer Enterprise Apps list.

What happens during setup

1. Global Admin clicks "Continue with Microsoft sign-in (auto-managed)" on /connectors.
2. Microsoft shows a consent prompt for Application.ReadWrite.All and AppRoleAssignment.ReadWrite.All on the platform multi-tenant app. These are needed once, to create the new app.
3. After the GA consents, the platform creates a new app registration in the customer Entra tenant.
4. Platform creates the matching service principal, generates a 365-day client secret, and patches requiredResourceAccess with the consolidated permission set.
5. Platform admin-consents every application permission on the new app by writing appRoleAssignments.
6. Platform stores the new app client_id + client_secret, marks the connector ACTIVE in app-only mode, and discards the GA delegated token.
7. From then on the connector authenticates as the new app via client_credentials. The GA session is no longer involved.

Permissions granted on the new app

The platform grants this full consolidated set of 30 application permissions on the new per-tenant app, so a single credential covers identity ingestion, detection telemetry, incident response actions (including application revocation and Intune device actions), Defender for Identity posture checks, Exchange Online posture, and Teams posture. This list is generated from the same registry the provisioning code uses, so it cannot drift from what you consent to. For each permission's purpose, its read/write classification and the two that warrant a plain-language explanation, see What the connector asks for.

What the customer will see in their tenant

• A new app named "ITDR Connector — <your platform tenant>" appears in the customer Entra portal under App registrations and Enterprise applications.
• All the application permissions above appear under the new app API permissions tab, status Granted.
• The platform multi-tenant app continues to appear separately in the customer Enterprise applications list as the consent vehicle, but it has no application permissions of its own on the customer tenant.
• Because the app registration lives in the customer tenant, the customer can revoke ITDR unilaterally at any time — delete the app, disable its service principal, or remove its credentials in the Entra portal — with no action needed from us and nothing we can do to prevent it.
• Every call the connector makes is attributed to that service principal in the customer's own Entra audit log, so the customer can see exactly what ITDR did and when.
• The credential ITDR holds is unique to this customer. A compromise of one customer's connector secret does not grant access to any other customer's tenant.

Rollback behavior on failure

• If any Graph call during provisioning fails (network blip, missing role, tenant disallows app creation), the platform calls Graph DELETE on the half-created app so no debris remains in the customer tenant.
• If cleanup itself fails, the orphan app id is logged and the failure is surfaced in the connector sync_error column.
• Rollback never re-raises a different error than the original failure — the customer sees the underlying reason.

Validation

• Connector status should be ACTIVE and sync_status authorized_app_only_auto_provisioned.
• Permissions granted column should list every application permission from the consolidated set.
• Conditional Access posture, Secure Score, and detections pages should all return data.
• No "Re-authorization required" banner should appear under any conditions, including after the original GA admin is disabled or removed.

Troubleshooting

• If the OAuth flow returns connectors?error=auto_provision_failed, the platform attempted rollback. Check backend logs for the exact Graph error. Common causes: GA role does not include Application.ReadWrite.All consent rights, or the customer tenant has Conditional Access policies excluding the platform multi-tenant app.
• If sync_status is duplicate_tenant, an existing connector for this Microsoft tenant already exists. Either remove the old connector first, or re-use it via Reauthorize.
• The new app secret is valid for 365 days. A daily rotation job mints a replacement when the secret is within 30 days of expiry, using the app's own Application.ReadWrite.OwnedBy permission — no Global Admin session is needed after the initial setup. The superseded secret is left to expire on its own rather than deleted, so rotation can never revoke the credential still in use.