How DSALTA integrates with Entra (Office 365) — data collected, setup guide, and automated compliance checks.
Overview
How to connect
Automated checks
Useful links
DSALTA connects to Entra (Office 365) using read-only access to your Microsoft 365 / Entra directory to collect compliance evidence automatically. It signs in with Microsoft SSO and syncs your users and groups from Microsoft Graph. Data feeds into your Data Library modules.
Read-only access. DSALTA never modifies, creates, or deletes resources in your Office 365 / Entra directory.
DSALTA collects this integration’s data when you connect it — you can refresh it at any time with Sync from integrations on the Integrations page. The compliance checks below re-run once a day at 02:00 America/New_York.
DSALTA reads the Entra (Office 365) user roster — names, emails, the Entra account type that fills the role column (Member, Guest or User) and active status, which appears on your Access page.It calls these Entra (Office 365) endpoints:
Permissions the checks require:User.Read.All, Group.Read.All, Directory.Read.All, Policy.Read.All, AuditLog.Read.AllEvery request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Entra (Office 365) environment.
There is no Reconnect button. Open Integrations → Connected, click Manage on the Entra (Office 365) card, and check the Status tab. To restore a broken connection you must Disconnect and connect again — signing in with a Global Administrator or Privileged Role Administrator account — which permanently deletes the data and tests collected from Entra (Office 365). This usually happens when admin consent is revoked or the sign-in session expires.
Data is not syncing
Confirm the connected account is still a Global Administrator (or Privileged Role Administrator) and that admin consent for User.Read.All, Group.Read.All, and Directory.Read.All is still granted. Verify the Tenant ID is correct, then click Sync from integrations on the Integrations page (Connected tab) — it refreshes every connected integration at once.
Enter your Tenant ID, then sign in with Microsoft and approve access as an administrator. DSALTA only reads directory data (users and groups) for compliance. You do not enter a client secret here.Before you begin
Microsoft Entra ID (Azure AD) Global Administrator or Privileged Role Administrator
Permission to grant admin consent for application permissions
DSALTA server must have a valid Microsoft (Entra) app configured — if consent works but connection fails, check backend MICROSOFT_CLIENT_ID / MICROSOFT_CLIENT_SECRET match that app in Azure
You will need:
Field
Where to find it
Example
Tenant ID
Find this in Azure Portal → Microsoft Entra ID → Overview. · Open
0bf1f4c0-0d4c-405f-839b-b391a5ef0221
1
Start in DSALTA
Open Integrations in the DSALTA sidebar, find Entra (Office 365), and click Connect to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.
2
Integrating Office 365 with DSALTA means
DSALTA will read your Microsoft 365 / Entra directory to sync users and groups for compliance monitoring.DSALTA uses read-only permissions and never modifies your directory configuration.
3
Enter your Tenant ID
Enter your Microsoft Entra ID Tenant ID. You can find it in Azure Portal → Microsoft Entra ID → Overview → Tenant ID.Microsoft’s current route: sign in to the Microsoft Entra admin center (entra.microsoft.com) as at least a Global Reader, browse to Entra ID → Overview → Properties, and copy the value in the Tenant ID box. In the Azure portal the same value sits under Microsoft Entra ID → Properties. If you would rather not open a portal, az account tenant list (Azure CLI) or m365 tenant id get return it too.
4
Sign in with Microsoft (admin consent)
After you enter your Tenant ID, click Connect and sign in with a Global Administrator (or Privileged Role Administrator) account. Approve read-only access for the DSALTA app.Directory read permissions requested at sign-in: User.Read.All, Group.Read.All, Directory.Read.All. These cover the user and group sync only.
You must sign in with a Global Administrator or Privileged Role Administrator account.
The consent screen asks only for User.Read.All, Group.Read.All and Directory.Read.All — enough for users and groups, not for the MFA check. “MFA should be enabled for all users” reads Security Defaults (/policies/identitySecurityDefaultsEnforcementPolicy) and Conditional Access (/identity/conditionalAccess/policies), and Microsoft requires Policy.Read.All for both; Directory.Read.All does not cover them. Until an admin grants Policy.Read.All to the DSALTA app (Microsoft Entra admin center → Enterprise applications → DSALTA → Permissions → Grant admin consent), that one check reports Failed with a missing-permission result while users and groups keep syncing normally.
Expect the MFA column on the Access page to read Unknown. It comes from /reports/authenticationMethods/userRegistrationDetails, which Microsoft gates behind AuditLog.Read.All — not part of this consent — so DSALTA logs a warning, skips the report and marks every user Unknown. Microsoft also notes the report “doesn’t work for disabled users”, so disabled accounts stay Unknown even after that permission is granted.
DSALTA validates the credential when you click Connect. On success the integration moves to the Connected tab, and Manage → Status reads Connected and working properly. Checks begin reporting after the first sync.
If the connection is rejected. Failed to connect. Ensure admin consent was granted.The on-screen message is generic — see Connection error messages.
Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.
.png?fit=max&auto=format&n=tsMQJyneJ1xquFUo&q=85&s=4d401cc03b547d99b6f75a6bd170c334)