Grafana SSO with Microsoft Entra ID replaces local Grafana passwords with corporate sign-in
Grafana's built-in Entra ID OAuth provider is available in all editions. It covers sign-in, role mapping and restriction to allowed groups, so a team running self-hosted Grafana can retire local passwords without buying Enterprise. Team sync and SCIM-style provisioning are different: they are available only in Grafana Enterprise and Grafana Cloud, so teams that expect Entra ID groups to create Grafana teams automatically need to plan for that licensing decision before the rollout starts. The supported method is the Entra ID OAuth integration described in the Grafana authentication docs, which the rest of this page follows.
This page walks through the work in the order it fails in practice: registering the application in Entra ID, deciding how app roles or directory groups become Grafana roles and organizations, restricting sign-in to the right users, hardening the Grafana side, and testing sign-in and role assignment before users depend on it. Confirm the exact settings and the claims your tenant emits against the current Grafana documentation and your own Entra ID configuration, since the setting names and claim behavior change between Grafana releases. Before you start, also confirm which Grafana version you run and whether it is supported, because a sign-in change made during an unsupported release is hard to troubleshoot.
The highest-risk decisions are who can sign in, which Entra ID group or app role grants Grafana admin rights, and what happens to existing local accounts. Keep at least one break-glass local administrator until SSO is proven, and record which Entra ID users map to the Grafana Admin and Editor roles. Expect failure points around redirect URIs that do not match exactly, missing email claims, users who are members of groups that are not emitted in the token, and role mappings that silently default to Viewer. Test each path with a dedicated pilot group, including a user who should be denied, before you remove the password login for the wider organization.
What the team needs before starting Grafana SSO with Microsoft Entra ID
Five things must be settled before any Entra ID app registration is created: the Grafana version, the database, the public URL, the admin rights, and the directory model. Each one changes what the OAuth configuration looks like and who has to act on it.
Supported Grafana version
Confirm the running Grafana version is still inside its support window before adding SSO. Grafana supports each minor release for 9 months and the last minor release of a major version for 15 months, so a version that is out of support should be upgraded first. Check the current release list and the upgrade guidance, then plan the SSO change as a separate step from any upgrade so that a login problem is not confused with a version problem.
Production database
Grafana keeps its configuration in SQLite by default, but the installation docs say SQLite does not scale for production. Use MySQL 8.0 or later or PostgreSQL 12 or later, because the OAuth settings, user records and database-backed auth tokens all live there. Plan the database before configuring SSO, since high availability with two or more active-active Grafana servers depends on it.
Public HTTPS redirect URL
Entra ID returns the user to a redirect URI that must match the Grafana root URL exactly, including scheme, host and path. Decide the final public hostname, obtain a certificate that browsers trust, and confirm that the load balancer or proxy forwards the original host. Changing the hostname later means updating the app registration and the Grafana server settings together.
Tenant admin rights
Someone with rights to register an application in the Entra ID tenant must create the app, add redirect URIs, create the client secret or certificate, and define app roles. Confirm who holds that permission before the project starts, and whether a security team must approve new app registrations. Ask Microsoft which tenant licensing tier covers the group and app role features your design relies on.
Directory model
Decide whether users are cloud-only in Microsoft Entra ID or synced from an on-premises Active Directory Domain Services forest using Microsoft Entra Connect. Synced accounts depend on the on-premises domain controllers and the sync service, and Windows Server 2022 mainstream support ended October 14, 2026, so check its lifecycle status against the Microsoft Lifecycle page before relying on that server.
Why Entra ID is usually the identity source for Grafana, not Active Directory directly
Grafana's Entra ID integration is an OAuth connection to the cloud directory, so Grafana talks to Microsoft Entra ID at sign-in and never to your domain controllers. Active Directory Domain Services is an on-premises directory that stores users, computers and groups and replicates them across domain controllers. Most SaaS applications do not reach it directly. Microsoft's comparison says on-premises applications typically authenticate against Active Directory with LDAP, Windows-integrated authentication or header-based authentication, and that SaaS applications need a federation system such as AD FS when they cannot use Entra ID. For a self-hosted Grafana, the practical default is to sync identities with Microsoft Entra Connect and sign users in through Entra ID, which keeps Grafana on the same OAuth path as other cloud-connected tools.
Grafana should not be expected to join a domain. Windows servers and desktops can be domain-joined and managed with Group Policy, but Linux hosts need third-party tools or Kerberos realm configuration to authenticate against Active Directory. Grafana runs as an application on whatever host you choose, so its identity path is set by the protocol it speaks, not by whether the host is joined to a domain. Confirm early which hosts are Windows, which are Linux and who manages each, because that determines whether AD FS, Entra Connect or a separate directory connection is needed for the rest of your estate.
Organizations with an existing AD DS forest should decide between two paths. The first uses synced identities: Entra Connect copies users and groups to Entra ID, and Grafana signs them in through the Entra ID OAuth provider. The second keeps a direct LDAP connection from Grafana to Active Directory, which is configured separately and has its own group mapping and debugging work. Compare how group membership, password policy, account disablement and MFA behave in each path, since those controls decide who can sign in after a leaver event. Microsoft's comparison of Active Directory and Entra ID sets out the differences in authentication methods and directory scope that should inform this choice.
Which Entra ID sign-in features work in open source Grafana and which need Enterprise
The open-source edition supports Entra ID as a built-in OAuth identity provider. The authentication documentation lists Entra ID among the providers available in all editions, so a team can sign users in with their Entra ID accounts, map claims to Grafana roles and restrict sign-in to chosen groups without buying a license. Organization mapping is also part of the documented set for all editions, which matters if one instance serves several business units.
- OAuth sign-in with Entra ID: Users authenticate against your tenant through an app registration, and Grafana receives the identity and claims needed to create the account.
- Role mapping from claims: Claims or app roles in the token can be translated into Organization Viewer, Editor or Admin roles, so access follows the identity provider rather than manual edits in Grafana.
- Allowed group restriction: Sign-in can be limited to specified groups, which keeps accounts outside the intended population from being created.
- Org mapping: Users can be placed into one or more Grafana organizations based on claims, which supports a shared instance with separated dashboards and data sources.
- What open source does not give you: Team sync, SCIM and active sync are not available here, so team membership inside Grafana is managed through role and org mapping or by administrators.
Confirm the exact claim names and attribute paths for your tenant configuration against the current authentication documentation before the build starts.
Grafana Enterprise adds identity features that the open-source edition does not include. The authentication documentation places team sync, SAML, active sync and SCIM provisioning in Grafana Enterprise and Grafana Cloud only. These features change how user lifecycle and team membership are managed, so they often drive the licensing decision for regulated environments that need automated deprovisioning or team membership that mirrors directory groups.
- Team sync: Maps identity provider groups to Grafana teams, so team membership inside Grafana follows directory membership without manual work.
- SAML: Offers SAML single sign-on as an alternative to OAuth, which some organizations require for existing federation agreements.
- Active sync: Keeps user accounts and their roles synchronized with the identity provider while Grafana is running, rather than only at sign-in.
- SCIM provisioning: Lets the identity provider create, update and disable Grafana users automatically, which supports joiner, mover and leaver processes.
- Licensing consequence: Any of these features on the design means an Enterprise license for every self-hosted instance that uses them, and that cost is a recurring commitment to plan for.
Ask Grafana Labs for a written statement of which features apply to your license tier and whether anonymous or service-account users are counted, before you commit the design.
Grafana Cloud is a hosted service run by Grafana Labs, not a self-hosted installation, so it is outside the infrastructure this page assumes. The authentication documentation lists the same Enterprise-only features as available in Grafana Cloud, which means a team that needs team sync or SCIM can get them without operating the instance. The trade-off is that the data sources, network paths and identity boundary are set by the hosted service rather than your own infrastructure.
- Feature parity with Enterprise: Team sync, SAML, active sync and SCIM are documented for Grafana Cloud as well as Enterprise.
- Pricing structure: The pricing page lists a free tier, a Pro tier with a monthly platform fee plus usage, and an Enterprise tier with a minimum annual commitment, so cost depends on tier and consumption.
- Data location: Queries and dashboards run in the hosted service, which changes data residency and network review compared with the self-hosted design.
- Operational ownership: Grafana Labs operates the instance, so upgrades and availability are handled by the vendor rather than your platform team.
- Not a substitute for a self-hosted design: If the requirement is to keep Grafana in your own cloud accounts or data centers, Grafana Cloud does not meet it, even though it offers the feature set.
Confirm current tier contents and license terms with Grafana Labs before comparing options, because feature tables change.
Grafana SSO with Microsoft Entra ID setup in six steps
This sequence takes a self-hosted Grafana instance from an app registration in Microsoft Entra ID to tested sign-in, with roles, group restrictions and org mapping in place. Each step closes with a check you can run before moving on.
Register the Grafana application in Entra ID
An administrator with rights to create app registrations in the Entra ID tenant creates a registration for Grafana, sets the redirect URI to the callback path that the Grafana authentication docs give for the installed version, and uses the exact public Grafana URL, including the protocol and any path prefix. Record the application (client) ID, the tenant ID and a client secret with its expiry date. Confirm the redirect URI matches the root URL in Grafana's configuration, because a mismatch is the most common cause of a failed first sign-in. Done means the registration exists with one redirect URI, and the three values are stored in your secrets manager, not in a shared document.
Define app roles and assign users in Entra ID
In the registration, define app roles that correspond to the Grafana roles you need, such as viewer, editor and admin, and decide whether group membership or app role assignment will drive access. Assign users or groups to the app in Enterprise applications, and turn on assignment required so that only assigned identities can sign in. Include the group or role claim in the token configuration if you use group-based mapping. Done means a test user who is assigned to the application has a token containing the expected role or group value, which you can confirm by signing in to a test app or decoding a token in a controlled environment.
Enable the Entra ID provider in Grafana
A Grafana administrator opens the authentication settings for the installed version, enables the Entra ID OAuth provider, and enters the client ID, client secret and tenant values from the registration. Set the auth URLs and scopes exactly as the Grafana authentication docs for that version describe, and keep the client secret in an environment variable or secrets store rather than the configuration file. Restart Grafana if the version requires it. Done means the login page shows a Microsoft sign-in option, and an assigned test user can complete the redirect and reach Grafana, even if the role is still wrong at this stage.
Configure allowed groups and the role attribute path
Set the allowed groups or allowed domains so that only members of the approved Entra ID group can sign in, and configure the role attribute path to read the role or group claim from the token. Use the key names and claim paths from the docs for your Grafana version, not from older examples. Decide the default role for users who sign in without a matching value, and whether Grafana should deny that case. Done means a user inside the allowed group signs in and lands with the expected role, and a user outside the allowed group is denied at sign-in. Run both tests and record the results.
Map users to organizations for multi-org instances
If the instance serves more than one Grafana organization, configure the organization mapping so that each identity or group lands in the correct organization with the correct role. Keep the mapping list short and review it with the data owners of each organization, because a mapping error can expose dashboards across organizational boundaries. Confirm which features, such as team sync, depend on your edition, since the Grafana authentication docs state that team sync is limited to Grafana Enterprise and Grafana Cloud. Done means a test user from each mapped group appears in the intended organization only, and a user with no mapping cannot see any organization.
Test with non-admin and admin accounts
Sign in with a non-admin test account and confirm that it has the viewer or editor access it should have, cannot open server administration pages, and cannot see dashboards in organizations it is not mapped to. Then sign in with an admin test account and confirm that administration pages and organization settings are available. Also test an account outside the allowed group to confirm denial, and check that sign-out and session expiry behave as your security standards require. Done means each test account has the expected outcome, the results are written down with the Grafana version and the date, and the configuration is saved as code or documented for the next upgrade.
How Entra ID app roles and groups map to Grafana roles and organizations
This table pairs each Entra ID source, such as an app role, security group or token claim, with the Grafana target it controls and the design rule to apply. Read it before you configure the enterprise application, because the choice of claim decides who can sign in, which organization they land in and what role they receive. Team membership is listed separately because it depends on the edition you run.
| Entra ID source | Grafana target | Design rule |
|---|---|---|
| App role assigned to the user | Grafana org role (Viewer, Editor or Admin) through the role attribute path | Use a small, fixed set of app roles that map one-to-one to Grafana roles. Keep the mapping in code or provisioning files so changes go through review. |
| Security group object ID in the groups claim | Organization membership and role through the role mapping expression | Match on group object IDs, not display names, because names can change. Confirm the object IDs in your tenant before writing the mapping. |
| Groups overage claim for users in many groups | Same targets as the groups claim, but the groups list may be missing from the token | Confirm in your tenant whether large group sets trigger an overage claim. Decide early whether to limit group assignment with app roles instead. |
| Allowed group restriction on the application | Sign-in is refused for users outside the permitted group | Restrict sign-in to one or more groups that hold Grafana access. Test a user outside the group to confirm the refusal before go-live. |
| Default role for users with no matching role or group | Role assigned when the mapping finds no match, such as Viewer or no role | Default to Viewer or no role. Assign Editor and Admin only through explicit mappings, and document who approves them. |
| Multi-org mapping by group or claim | Separate Grafana organizations, each with its own role for the user | Create one organization per boundary that needs separate data sources or dashboards. Map each group to exactly one organization to keep access auditable. |
| Server admin (instance-wide administrator) | Grafana server admin flag, separate from organization roles | Grant server admin to a small, named group only. Confirm the claim value in your tenant and review membership on a fixed schedule. |
| Team membership by group (Enterprise only) | Grafana team membership through team sync | Team sync depends on Grafana Enterprise. In open source, manage teams manually or through the API, and document the workaround. |
Security settings to decide before Grafana trusts Entra ID sign-in
Entra ID sign-in moves the front door of Grafana to your identity provider, but Grafana still holds its own admin accounts, cookies and role grants. The cards below cover the settings that decide who can sign in, what they receive and how you recover if the identity provider fails. Confirm each hardening setting against the documentation for the Grafana version you deploy.
Client secret storage and rotation
The Entra ID app registration gives Grafana a client secret or certificate to prove its identity during OAuth. Store the secret in your secrets manager or the environment, never in a file committed to Git, and set an expiry you can track. Confirm with Microsoft and the Grafana authentication docs whether certificate credentials are supported for your version before you choose. Plan the rotation window so a renewal does not lock out every user at once.
Allowed groups and self-signup
Restrict sign-in to the Entra ID groups that should hold a Grafana account, and turn off automatic account creation for anyone who authenticates without an assigned group. Without this, any user in your tenant who can reach the Grafana URL may get an account with a default role. Test with an account outside the allowed groups to confirm that sign-in is refused and that no user record is created.
Secure and SameSite session cookies
The Grafana security hardening docs recommend secure cookies, so session cookies only travel over HTTPS, and SameSite settings that limit cross-site requests. Confirm the exact configuration keys for your version and check that your reverse proxy terminates TLS correctly, because cookies marked secure will not work over plain HTTP. Test the login flow in each browser your users rely on.
Break-glass local admin account
Keep at least one local Grafana admin account with a strong, offline-stored password so you can recover if Entra ID, the app registration or the OAuth settings fail. Restrict its use to a documented break-glass procedure, record each login and review it after every use. Confirm that local login remains enabled in your configuration, since disabling password login is a common cause of a full lockout.
Hiding the Grafana version
The hardening guidance recommends hiding the Grafana version from unauthenticated users, so attackers cannot match your instance against published vulnerabilities before they sign in. Check the version exposure on the login page and in HTTP responses after your proxy is in place. Pair this with requiring authentication for the metrics endpoint, which the same guidance covers.
Server admin grants from claims
A claim mapping that grants the Grafana server admin role gives a user control over the whole instance, including other organizations and plugins. Map Entra ID app roles to organization roles, and grant server admin only by a manual, reviewed assignment. Review the list of server admins against your directory at a set interval, and confirm which claim mapping keys your version uses.
Why Grafana SSO with Microsoft Entra ID logins fail and how to fix them
This table pairs common Grafana sign-in failures with Microsoft Entra ID setups with their likely causes and fixes. Start with the symptom your users report, check the cause column against your app registration and grafana.ini, then apply the fix in a test instance before changing production. Where a fix depends on log output, use the authentication debugging section of the Grafana docs to raise log levels.
| Symptom | Likely cause | Fix |
|---|---|---|
| Redirect error after Microsoft sign-in | The redirect URI registered on the app registration does not exactly match the Grafana root URL and callback path | Register the exact callback URL built from the root_url setting, including scheme, host, port and trailing path, then retest in a private browser window |
| Sign-in fails immediately with an invalid or unauthorized client error | Wrong tenant ID, client ID or client secret, or an expired client secret | Copy the tenant ID, client ID and a current secret from the app registration, confirm the authorization and token endpoints use the same tenant, and replace the secret if it has expired |
| Users sign in but land with the Viewer role | The role attribute path does not match the claim or app role value Entra ID sends, or the user has no app role assigned | Inspect the token claims for a test user, correct the role path or app role value, and assign the app role to the user or group |
| Users see a login denied or not-allowed page | Allowed groups or allowed domains restrict sign-in and the user is not in a permitted group or the group claim is missing | Confirm the group object IDs in the configuration, check that group claims are emitted for the app, and add the user to a permitted group |
| Sign-in fails with a missing email error | Entra ID did not return an email claim, often because the user has no mail attribute or the claim is not included in the token | Set a populated mail or UPN value for the user, configure optional claims for the app, and confirm the email attribute name matches the Grafana setting |
| Users are logged out or repeatedly sent to sign-in across browser requests | Each Grafana node stores sessions locally, or the nodes do not share one database, so requests reach a node without the session | Point all nodes at one MySQL or PostgreSQL database, use database-backed auth tokens, and confirm the load balancer routes consistently with the documented high availability setup |
| Alerts or sessions behave differently across nodes after login succeeds | Shared configuration differs between nodes, such as client secret, redirect settings or database connection values | Compare the configuration files on every node, keep settings in one source of truth, and restart nodes after changes |
| No administrator can sign in after a configuration change | A bad role mapping, wrong tenant or disabled local login removed every admin path | Keep a break-glass local admin account documented before changes, restore the last known good configuration from backup, and test changes on a staging instance first |
What Grafana SSO with Microsoft Entra ID costs and what the work needs from your team
Can our team set up Grafana SSO with Microsoft Entra ID using the docs alone?
Yes, a team with Entra ID administration skills and Grafana operations experience can usually configure the OAuth connection from the Grafana authentication documentation, because Entra ID is one of the providers included in every edition. The harder parts are design decisions: how app roles map to Grafana roles, which groups may sign in, how multiple organizations are mapped, and how the setup is tested and documented for auditors. Teams that have not run identity integrations before often underestimate the testing and rollback planning. Ask yourself whether you have an owner for the Entra ID app registration, someone who can validate role claims with real test accounts, and time to repeat the test after each Grafana upgrade. If any of these are missing, a fixed-scope engagement can cover the gap.
What makes the Grafana Entra ID effort larger or smaller?
The main drivers are the shape of your Microsoft tenant, the number of Grafana organizations, and the quality of your group design. A single tenant with clean app roles and a small number of Grafana organizations is the simplest case. Multiple tenants, guest users, nested groups, or many organizations with different access rules add design and test work. It also matters whether Active Directory is already synced to Entra ID through Microsoft Entra Connect, because group membership then has to be checked at the source. The Enterprise decision is the last driver: team sync and SCIM-based provisioning are Enterprise-only features, and deciding whether to buy them changes what the design covers.
Does open-source Grafana have a license cost for Entra ID sign-in?
Open-source Grafana has no license fee, and the Entra ID OAuth provider is included in all editions according to the Grafana authentication documentation. Grafana Enterprise is a separate commercial option under a non-AGPL license, and the licensing page explains its terms. Enterprise adds features such as SAML, team sync, active sync and SCIM provisioning, which are not available in the open-source edition. Ask your Grafana Labs contact or review the Grafana Labs licensing page to confirm current Enterprise pricing and terms before you decide. Any Enterprise purchase is a recurring cost that should be included in the business case alongside the implementation work.
Will Microsoft Entra ID or Windows Server licensing add cost to this project?
It can, depending on what you already own. Grafana sign-in with Entra ID requires an Entra ID tenant, and the license tier you hold determines which features your users can use. If your identities still live in on-premises Active Directory, you also pay for the Windows Server infrastructure that runs Active Directory Domain Services. As an example of directory licensing, Microsoft's Windows Server 2025 pricing page lists a suggested price of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and notes that prices vary by region. Pay-as-you-go licensing through Azure Arc is listed at 33.58 US dollars per core per month. Confirm Entra ID licensing requirements and your own agreement pricing with Microsoft or your reseller, since these figures are not Grafana costs.
How long does a Grafana Entra ID SSO implementation take?
The duration depends on the agreed scope, and no fixed figure applies to every environment. Work that covers one organization with a single group design usually takes less time than work that covers several organizations, multiple tenants, and an Enterprise decision with team sync. Timelines also depend on how quickly your Entra ID administrators can create the app registration, approve app roles, and give test accounts, because those steps often gate progress. DeployOpen agrees most engagements as fixed scope, so the timeline is set in writing from your requirements before work starts. Ask for the deliverables, the dependencies on your team, and the test sign-off steps to be listed in the quote.
What must our team provide before Grafana Entra ID work starts?
Your team needs to provide a few inputs before design can begin:
- Tenant administrator access, or a named administrator who can create and configure the app registration and app roles in Entra ID.
- A group design that defines which users get which Grafana role and organization, and which groups are allowed to sign in.
- Test accounts in each group, plus a test plan covering sign-in, role mapping, denied access and sign-out.
- Access to the Grafana server, its database and its configuration files, and a change window for rollout.
It also helps to name an owner who approves the design and who will maintain the Entra ID settings after handover. Confirm with your security team how the secret for the app registration will be stored and rotated.
Who is responsible for ongoing Entra ID and Grafana changes after go-live?
Your team owns the Entra ID tenant, its group membership and app role assignments, because those change through normal joiner and mover processes. Grafana configuration and upgrades are also yours to run unless you contract support. Ongoing support, upgrades and continuous testing are available as DeployOpen retainers, which can include re-testing sign-in after Grafana upgrades. Recurring costs therefore fall into three groups: your own staff time for group administration, any Enterprise license, and any retainer you choose. Ask for the handover documentation and the runbook as part of the written scope so the post-go-live owner is clear.
How DeployOpen works on this
DeployOpen plans and implements self-hosted Grafana sign-in with Microsoft Entra ID inside your own infrastructure, starting from a written scope. We confirm which roles, groups and organizations your Grafana instance needs, then build and test the sign-in path before handing it over with documentation your team can run.
How we scope
- Engagements are fixed-scope, with the Entra app registration, role mapping and allowed groups agreed in writing before work starts.
- We confirm which Grafana organizations, roles and Entra ID groups your teams need, and whether any Enterprise-only features are required.
- The written scope states the Grafana version, database backend, hosting model and redirect URLs covered by the work.
How we build
- We register the Grafana application in your Entra ID tenant and configure client credentials and redirect URIs under your control.
- We map Entra app roles or group claims to Grafana roles and organizations, and test each mapping with accounts from every target group.
- We apply hardening settings for cookies, sessions and the Grafana login path, and verify that users are denied when they are outside allowed groups.
How we hand over
- You receive configuration documentation covering the app registration, claim mapping, allowed group settings and the test accounts used.
- We document the steps to add a new team, change a role mapping and rotate the client secret, so your staff can operate the setup.
- The handover records which features are open source and which depend on Grafana Enterprise, such as team sync, so you can make that decision with full information.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so sign-in keeps working through Grafana releases.
- Retainer work can cover re-testing role mappings after Grafana upgrades and Entra ID tenant changes, scoped in writing.
- Ask any partner to confirm in writing who owns the Entra app registration, secret rotation and access reviews after handover.
