> This page is for version 0.8.0. > For other versions, use one of these documentation indexes: > - Latest (default): https://docs.nvidia.com/nemo-helix/latest/llms.txt > - 0.8.0: https://docs.nvidia.com/nemo-helix/v0.8.0/llms.txt > - 0.7.1: https://docs.nvidia.com/nemo-helix/v0.7.1/llms.txt > - 0.7.0: https://docs.nvidia.com/nemo-helix/v0.7.0/llms.txt > - 0.6.0: https://docs.nvidia.com/nemo-helix/v0.6.0/llms.txt > - 0.5.1: https://docs.nvidia.com/nemo-helix/v0.5.1/llms.txt > - 0.5.0: https://docs.nvidia.com/nemo-helix/v0.5.0/llms.txt > - 0.4.0: https://docs.nvidia.com/nemo-helix/v0.4.0/llms.txt > - 0.3.0: https://docs.nvidia.com/nemo-helix/v0.3.0/llms.txt > - 0.2.0: https://docs.nvidia.com/nemo-helix/v0.2.0/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.nvidia.com/nemo-helix/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/nemo-helix/_mcp/server. # Azure AD (Entra ID) Setup Complete walkthrough for connecting NeMo Helix to Azure AD (Entra ID), from app registration to first successful login. **Prerequisites**: Access to Azure Portal with permission to create app registrations. Familiarity with [OIDC Setup](/documentation/access-control/authentication/oidc-setup). ## App Registration 1. In Azure Portal, go to **Azure Active Directory** > **App registrations** > **New registration**. 2. Name the application, for example "NeMo Helix". 3. Set **Supported account types** to your tenant configuration. 4. No redirect URI is needed for device flow, but setting one is good practice if Studio or another browser client uses the same app. 5. Note the **Application (client) ID** and **Directory (tenant) ID**. ## Enable Device Flow 1. Go to **Authentication** in the app registration. 2. Under **Advanced settings**, set **Allow public client flows** to **Yes**. 3. Save. ## Expose API Scopes This section is needed when OIDC login tokens should carry NeMo Helix API scopes. If you skip API scopes, NeMo Helix still enforces role bindings. 1. Go to **Expose an API**. 2. Set the **Application ID URI**, usually `api://`. 3. Add scopes: * `platform:read` - read access to NeMo Helix platform resources * `platform:write` - write access to NeMo Helix platform resources 4. Go to **API permissions** > **Add a permission** > **My APIs** > select your app > add the scopes. 5. Click **Grant admin consent** for the scopes, if your tenant requires it. Use short scope names in NeMo Helix configuration. Azure may require the fully qualified request form, such as `api:///platform:read`; set `scope_prefix` so the CLI can send that form while users and docs keep referring to `platform:read`. ## Configure Group Claims This section is needed when Azure group or entitlement values should match NeMo Helix workspace members or role bindings. 1. Go to **Token configuration** > **Add groups claim**. 2. Select **Security groups** or the group types your organization uses. 3. For the bearer token NeMo Helix validates, select the group value format you plan to bind in NeMo Helix. Azure OAuth scopes in `scope` or `scp` are not group principals and they do not grant workspace access. Use NeMo Helix role bindings for workspace authorization. If Azure returns NeMo Helix API scopes such as `platform:read` in `scp`, NeMo Helix uses those scopes to narrow API access for that token. ## Configuration Notes NeMo Helix uses Azure AD as an OIDC identity provider. The Azure token must be a signed JWT that NeMo Helix can validate, and its claims must contain the identity values you want to authorize: * `issuer`: the tenant issuer for the token version your application uses. * `client_id`: the Azure application client ID used by CLI and Studio login. * `audience`: the expected token `aud` claim, if you want audience validation. For Azure AD v2.0 access tokens, this is often the application client ID GUID; verify the token's actual `aud` claim. * `email_claim`: often `upn` for Azure AD access tokens. * `subject_claim`: often `oid` for Azure AD access tokens. * `groups_claim`: `groups` when Azure emits group IDs in the token. ## NeMo Helix Configuration ```yaml auth: enabled: true admin_email: "platform-admin@company.com" oidc: enabled: true issuer: "https://login.microsoftonline.com//v2.0" client_id: "" audience: "" # Azure AD v1 tokens may have a different issuer. additional_issuers: - "https://sts.windows.net//" email_claim: "upn" subject_claim: "oid" groups_claim: "groups" # Required when Azure expects API scopes in resource-qualified form. scope_prefix: "api:///" default_scopes: "platform:read platform:write openid profile email offline_access" ``` ## Verification ```bash nemo auth login # Browser opens to the Azure AD login page # Sign in and consent to the requested permissions nemo auth status # Expected: Logged in as user@company.com, scopes: platform:read platform:write ``` ## Common Errors | Error | Cause | Fix | | ----------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | AADSTS70011 | Scope not configured or no admin consent | Add the API scopes under **Expose an API**, add them under **API permissions**, and grant consent if required | | AADSTS50011 | Reply URL mismatch | Not typically needed for device flow; check **Authentication** settings if you also use browser redirects | | Audience mismatch | `audience` doesn't match token's `aud` claim | Set `audience` to the Azure token audience, or leave it unset if your deployment does not require audience validation | | Empty email claim | Azure AD didn't populate `email` | Use `email_claim: "upn"` instead | ## Related * [OIDC Setup](/documentation/access-control/authentication/oidc-setup) — Generic OIDC configuration. * [OIDC Setup — Claim mapping](/documentation/access-control/authentication/oidc-setup#claim-mapping) — JWT claims vs config defaults. * [Auth Configuration](/documentation/access-control/deployment) — Full config reference.