Entra ID Tenant Setup

Use this guide to connect your Entra ID tenant to GrantFlow so your users can sign in to the GrantFlow portal and CLI.

GrantFlow is a multi-tenant application. You do not create any app registration in your tenant. You consent to GrantFlow's application once, which adds it to your Enterprise applications, and then you decide who may use it.

Before you start

You need:

• A Global Administrator, Application Administrator or Cloud Application Administrator of your tenant, to create the enterprise applications and grant consent.
• Your tenant ID. In the Entra admin center it is on Overview, or run az account show --query tenantId -o tsv.
• The Azure CLI (az login to your tenant) for step 1. You can also do step 1 by opening the consent link in step 2 twice, see the note there.

GrantFlow's applications

GrantFlow uses two applications. Both are published by GrantFlow, and both appear in your Enterprise applications after consent:

Name	Application (client) ID	What it is
pamplus-api	01906db8-9d41-46b8-b5d4-a00222f22509	The GrantFlow API application. It defines the User and Admin roles. Identifier URI api://01906db8-9d41-46b8-b5d4-a00222f22509, delegated scope user_impersonation
pamplus-webapp	211741db-2aac-4f14-8ef4-fb361e386429	The GrantFlow web app, which the portal and the CLI sign in with. It asks for user_impersonation on the GrantFlow API

These IDs are the same for every customer. The names in the first column are what you search for under Enterprise applications.

No app registrations in your tenant

Do not create your own GrantFlow app registrations or client apps. Earlier versions of this guide asked for that; GrantFlow no longer uses them. If you created them, you can delete them after you complete this guide.

1. Add the GrantFlow API to your tenant

Create the enterprise application for the GrantFlow API first, so the web app's consent in step 2 can find it:

az ad sp create --id 01906db8-9d41-46b8-b5d4-a00222f22509

If the command reports that the service principal already exists, the API is already in your tenant. Continue with step 2.

2. Grant admin consent to the GrantFlow web app

As one of the administrators above, open this link in a browser. Replace <your-tenant-id>:

https://login.microsoftonline.com/<your-tenant-id>/adminconsent?client_id=211741db-2aac-4f14-8ef4-fb361e386429&redirect_uri=https%3A%2F%2Fportal.grantflow.cloud

Review the request and select Accept. You are then sent to the GrantFlow portal.

The consent covers one delegated permission: user_impersonation on the GrantFlow API, so the portal and the CLI can call the GrantFlow API as the signed-in user. GrantFlow asks for no Microsoft Graph or application permissions for sign-in.

Without the Azure CLI

If you skipped step 1, the consent page may report that the GrantFlow API is missing from your tenant. Open the same link with client_id=01906db8-9d41-46b8-b5d4-a00222f22509 instead, accept, and then open the original link above again.

3. Get your tenant onboarded

GrantFlow serves only tenants it has onboarded. Send your tenant ID to your GrantFlow contact.

Until onboarding is complete, signing in shows Organization Not Onboarded. That page has a Copy Tenant ID button, so a user who signs in first can send you the right value.

4. Assign the User and Admin roles

GrantFlow admits only users who hold one of its roles. In the Entra admin center:

1. Open Enterprise applications → pamplus-api → Users and groups.
2. Select Add user/group.
3. Pick the users or groups and the role:
   • User: can sign in, see their eligible roles and request activations.
   • Admin: everything a User can do, plus GrantFlow administration.
4. Select Assign.

Assign the roles on the GrantFlow API application (pamplus-api), not on the web app (pamplus-webapp): GrantFlow reads them from the API's access token.

A user without a role who signs in sees Access denied and is asked to contact an administrator. After you assign a role, the user signs out and back in.

Assignment required

Entra lets every user in your tenant sign in to the GrantFlow API by default, and GrantFlow then refuses those without a role. If you prefer Entra to block them at sign-in, set Properties → Assignment required? to Yes on the pamplus-api enterprise application.

5. Sign in

Open https://portal.grantflow.cloud and sign in with a work account from your tenant. The first sign-in after consent needs no further prompt.

Configure the CLI

The CLI signs in with the device code flow, through the same GrantFlow web app. Users need no extra consent. Set these values in ~/.grantflow/config.yaml:

api_url: "https://api.grantflow.cloud"
tenant_id: "<your-tenant-id>"
client_id: "211741db-2aac-4f14-8ef4-fb361e386429"
scope: "api://01906db8-9d41-46b8-b5d4-a00222f22509/user_impersonation"

Set scope explicitly. Without it, the CLI derives a scope from client_id, which is the wrong application. See CLI configuration for every option.

Conditional Access

Your Conditional Access policies apply to GrantFlow sign-ins like any other application. Target the GrantFlow API application (pamplus-api in the policy's app picker) to cover the portal, the CLI and the MCP server.

GrantFlow can also ask for a stronger sign-in for sensitive actions. See Step-up Authentication.

Connect GrantFlow's MCP server to InfraScout

InfraScout can register GrantFlow's MCP server so its AI chat can answer questions about your tenant and, for administrators, make changes such as granting eligibility, ending activations or rotating managed account passwords. Most changes are previewed before they apply, but some apply at once without a preview, such as creating a role, linking people to a managed account, starting a connector sync and setting up remote sessions. With InfraScout's per-user identity mode, each InfraScout chat user calls GrantFlow as themselves rather than as one shared account. GrantFlow then applies that person's own GrantFlow role, so a chat user with the User role sees only the sign-in identity tool, and its audit log names the real user. See MCP Server for every tool and how changes are confirmed.

In InfraScout, register the server with these values:

• MCP server URL: https://mcp.grantflow.cloud/mcp
• Authentication: OAuth, with On behalf of each user (Entra OBO)
• Downstream scope: https://mcp.grantflow.cloud/user_impersonation

An administrator of your tenant then grants tenant consent once, from InfraScout's server form. InfraScout's Per-User Identity for MCP Servers guide walks through the whole setup.

Tenants that already use GrantFlow

The scope above is served by the GrantFlow API application (application ID 01906db8-9d41-46b8-b5d4-a00222f22509) under its identifier URI https://mcp.grantflow.cloud. That URI was added after many tenants had already started using GrantFlow. Your tenant's enterprise application for the GrantFlow API keeps the identifier URIs it had when it was first created, so in an existing tenant it may not know the new one. When that happens, InfraScout's tenant consent never lands and its Test keeps reporting consent as missing.

Check the enterprise application's names, signed in to your tenant with the Azure CLI:

az ad sp show --id 01906db8-9d41-46b8-b5d4-a00222f22509 --query servicePrincipalNames

If https://mcp.grantflow.cloud is missing, add it. The update replaces the whole list, so send every existing value together with the new one. An Application Administrator or Cloud Application Administrator can run it:

SP_ID=$(az ad sp show --id 01906db8-9d41-46b8-b5d4-a00222f22509 --query id -o tsv)
az rest --method PATCH \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals/$SP_ID" \
  --headers "Content-Type=application/json" \
  --body '{"servicePrincipalNames": ["api://01906db8-9d41-46b8-b5d4-a00222f22509", "01906db8-9d41-46b8-b5d4-a00222f22509", "https://mcp.grantflow.cloud"]}'

Adjust the list if the check showed other values than the two api:// and bare-ID entries, and keep them all. The change only adds a name to your tenant's copy of the application; existing users, assignments and consents are untouched. Afterwards, grant tenant consent in InfraScout again and run Test.

New tenants need nothing extra

A tenant that first starts using GrantFlow now gets an enterprise application with every current identifier URI, so this step only applies to tenants that used GrantFlow before the MCP server was published.

Not covered here: the Entra ID connector

Signing in to GrantFlow and syncing your directory are separate. To let GrantFlow read and manage Entra ID groups and roles, you create a dedicated app registration for the connector. See Create Entra ID Connector.