Enterprise identity & Active Directory
Status: planned, not available to enable in the current app. The enterprise identity design covers Entra SSO, OAuth On-Behalf-Of (OBO), customer-side Kerberos constrained delegation and workload identities. The proposed Settings & Monitoring → Identity & Access panel has not been implemented. Existing Google/local login and MCP OAuth do not provide this end-to-end delegation.
Three identity modes
| Mode | Intended use | Whose permissions apply? |
|---|---|---|
| Entra OIDC + OAuth OBO | Interactive access to supported Fabric and Microsoft/custom APIs | The verified user's delegated scopes and downstream resource permissions. |
| AD Kerberos constrained delegation | SQL Server and individually certified Windows legacy systems through a customer connector | The mapped AD user's permissions, constrained to approved services. |
| Managed identity / service principal | Explicitly configured agents and background jobs | The workload principal's own grants, not the user's grants. |
Signing in and authorizing a downstream query are separate operations. An administrator's successful connector test does not prove a user has permission to the data. The design requires failed user delegation to deny access without falling back to a shared service identity.
Prepare for Entra SSO and OBO
These are customer preparation steps, not activation instructions:
- Identify the customer Entra tenant, pilot users/groups and the AgentData tenant/project they should access. Decide invitation/provisioning, guest and role-mapping policies.
- Work with your Entra administrator to prepare the browser and confidential API registrations, approved redirect URIs and an exposed AgentData API scope. The final redirect URLs will depend on the deployed implementation.
- Agree the downstream resources/scopes and grant required consent. Use certificates or an approved secret store for confidential application credentials; do not send secrets in email or paste them into documentation.
- Confirm Conditional Access/MFA and device requirements. The implementation must propagate claims challenges rather than bypass these policies.
- Prepare two users with different data permissions and verify both allowed and denied access during the pilot.
OBO requires a user access token issued for the middle-tier AgentData API. A Google session, locally issued JWT, ID token or app-only token cannot simply be exchanged as that user. Stable Entra identity identifiers will be used for linking; email alone is insufficient. See Microsoft OBO guidance.
Fabric REST, Power BI REST and Fabric SQL are separate integration targets. Identity support, scopes and audience must be certified for each endpoint/driver; one successful connection does not enable them all. See Fabric identity support.
Prepare for Windows AD / Kerberos
- Provide a supported domain-joined Windows host for the future customer-side delegation connector and a customer-managed service account, preferably gMSA where validated.
- Ask the AD administrator to approve the delegation topology and specific target SPNs. Classic KCD or resource-based constrained delegation depends on the domain/forest topology.
- Establish an authoritative mapping between the verified Entra user and the AD account/SID. Cloud-only users without a suitable AD mapping cannot use this path.
- Prepare SQL Server permissions and restricted pilot accounts. Certification must check the effective SQL principal and Kerberos authentication, including concurrent connections and denied access.
An Entra access token is not a Kerberos ticket. Adding Trusted_Connection=yes to the existing shared connector does not implement per-user delegation. The planned Windows connector must validate signed, short-lived execution requests, impersonate the approved user safely, isolate connections and revert the impersonation context. AD administrators configure delegation; an AgentData tenant setting cannot grant it. See Microsoft KCD guidance.
The current document connector's safe local reads are POSIX-only. Planned Windows delegation support is separate from that existing document preview capability.
Prepare service identities for jobs
For Azure hosting, prepare an assigned managed identity and least-privilege resource grants. For other hosting, prepare an explicitly configured service principal with certificate credentials, or an approved federated workload identity where supported. Selecting managed identity on a host without a supported Azure identity environment does not create one. See Managed identities overview.
Each job will declare its execution identity, permitted targets and output audience. Broad workload access must not expose restricted results to every application user. Delegated scheduled execution is outside the initial design scope.
Planned admin activation and monitoring
Once implemented and certified, tenant admins will configure SSO registration/role policy, source-specific OBO or KCD bindings, workload identities and sanitized diagnostics in Identity & Access. Configuration will be tested before activation; SSO enforcement must preserve an audited recovery path. Monitoring will distinguish the initiating user from the effective downstream principal.
Authorization must extend to caches, search indexes, document results, exports and flow outputs. App RBAC and downstream permissions are both required. This remains a design requirement, not a claim of completed security certification.
For current authentication options, see Authentication. For existing tenant administration, see Administration.