
## Set up Microsoft Entra ID

URL: https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-power-bi/how-tos/set-up-microsoft-entra-id-for-power-bi

> Create the app registration, client secret, and security group in Microsoft Entra ID that Atlan uses to connect to Power BI, including the zero-API-permissions rule.

Performed by your **Azure / Entra ID admin** · about 15 minutes. Three objects: an app registration, a client secret, and a security group.

## Step 1 · Create app registration

1. Azure portal → **Microsoft Entra ID** → **App registrations** → **New registration**.
2. Name it something findable, for example `Atlan-PowerBI-Connector`. Leave redirect URI empty.
3. From the **Overview** page, copy the **Application (client) ID** and **Directory (tenant) ID**. These two values are a pair, they must come from the same page.

:::caution The ID pair must match
Error `Application with identifier '…' was not found in the directory` means the client ID and tenant ID in Atlan don't belong together, usually a tenant ID assumed from "where the team uses Power BI" instead of copied from the app registration's Overview page. Always copy both from the same screen.
:::

## Step 2 · Create client secret

1. In the app registration: **Certificates & secrets** → **New client secret**.
2. Pick the longest expiry your policy permits, and **record the expiry date** somewhere your team can see it.
3. Copy the **Value** column immediately, it's shown only once.

:::caution Value, not Secret ID
The secrets table shows two columns. Atlan needs the **Value** (the long random string). Pasting the **Secret ID** (a UUID) produces `AADSTS7000215: Invalid client secret provided`. Expired secrets are the single most common cause of a previously-working connection suddenly failing, see [Connectivity errors](https://docs.atlan.com/llms/connectors/microsoft-power-bi/microsoft-power-bi-connectivity-errors/llms.txt).
:::

## Step 3 · Create security group

1. Microsoft Entra ID → **Groups** → **New group**, type **Security**, for example `sg-atlan-powerbi`.
2. Under **Members**, add the app registration's service principal. Search for the app's *name*, it appears as the Enterprise Application object.
3. Add it as a **direct member**. Don't rely on nested groups, Power BI tenant settings may not resolve nested membership.

## Step 4 · Add zero API permissions (yes, zero)

This is the step that surprises everyone. The app registration needs **no Power BI API permissions at all**, the default Microsoft Graph `User.Read` is fine to leave in place, and nothing needs to be added.

:::caution Adding Power BI permissions breaks the connector
Counter-intuitively, granting the app registration Power BI Service API permissions (for example `Tenant.Read.All` with admin consent) causes Microsoft to **reject the service principal's token for admin APIs**, the exact APIs Atlan needs. A setup that fails preflight with 401 despite every tenant setting being correct is often this. Authorization comes entirely from the tenant settings + security group on the next page, never from API permission grants.
:::

## Checklist before moving on

- Client ID and Tenant ID copied from the same app registration Overview page
- Secret **Value** saved; expiry date recorded with a rotation reminder
- Security group exists; service principal (Enterprise Application) is a *direct* member
- API permissions list shows only the default Graph `User.Read`, nothing Power BI

---
