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 on the new per-tenant app, so a single credential covers identity ingestion, detection telemetry, incident response actions (including application revocation), Defender for Identity posture checks, Exchange Online posture, and Teams posture.

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.

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. The rotation worker (Phase 2) will renew it automatically before expiry once that ships.