Grafana Entra SSO
You set up grafana entra sso by linking a registered cloud app to your dashboard server. This link lets your team log in with work accounts and maps groups to roles. Most teams start by giving broad edit or admin rights to whole engineering groups. When roles are too broad, users can edit data sources and run raw database queries. How grafana entra sso works in practice Setting up grafana entra sso starts inside your Microsoft directory. First, you create an app record for your dashboard serv
Microsoft Entra ID (Azure AD) + Grafana Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up grafana entra sso by linking a registered cloud app to your dashboard server. This link lets your team log in with work accounts and maps groups to roles. Most teams start by giving broad edit or admin rights to whole engineering groups. When roles are too broad, users can edit data sources and run raw database queries.
How grafana entra sso works in practice
Setting up grafana entra sso starts inside your Microsoft directory. First, you create an app record for your dashboard server. You set a return web address so the login page knows where to send users back. Next, you create a client key and copy the main directory ID values.
You then place these identity values into your dashboard server settings. When a user clicks log in, the dashboard sends them to Microsoft. Microsoft checks their identity and MFA rules before sending back a signed token. The dashboard reads that token and starts a user session.
To manage access at scale, teams map directory groups to dashboard roles. The token carries group IDs or app role names for that specific user. The dashboard checks those claims and assigns viewer, editor, or admin permissions on each login. If a user changes teams in the directory, their dashboard role updates on their next login.
How group mapping controls dashboard permissions
Group mapping keeps you from managing local accounts on the dashboard server. You can assign most staff to the viewer role so they only read charts. You can map on-call engineers to the editor role so they build new boards. You can restrict the admin role to a small platform group.
Strict role rules prevent viewers from saving changes to shared team boards. Still, the built-in roles are coarse and apply across whole folders or spaces. Many teams give editor rights to developers so they can test new chart queries. Once a user has editor access, they can often use the explore page freely.
The dashboard uses a shared service account to read from each connected database. Even if users log in with their own work identity, the database sees one shared user. Your database audit log will show the dashboard service account, not the person who ran the query.
Microsoft Entra ID (Azure AD) + Grafana Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What single sign-on solves and what it leaves open
Linking your directory solves account cleanup when someone leaves the company. Disabling a user in your main directory blocks their dashboard login right away. It also enforces your company password and multi-factor rules in one central place. Auditors can check directory groups to see who holds access to the dashboard app.
Still, single sign-on only checks who logs into the front door. It does not inspect the actual queries that run after the session starts. A user with explore access can run heavy queries against connected production data sources. Those queries can return raw customer emails, phone numbers, card numbers, or national IDs.
Single sign-on also cannot pause a risky query for peer review before it runs. Also, developers still need direct database access outside the dashboard for repair tasks. Securing the dashboard login does not protect direct database sessions from local developer tools.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do users always get the viewer role after logging in?
This happens when the identity token lacks the group claim or the role rule does not match. Check that your directory app sends group or role claims in the token. Also check that your role mapping string matches the exact group ID or role name.
How do we stop users without a group from logging in?
You can turn on strict role mapping in your dashboard auth settings. When strict mode is active, users who do not match any mapped group cannot log in. You can also require user assignment on the enterprise app inside your Microsoft directory.
Does directory sign-on pass user identities down to the database?
For most data sources, the dashboard connects using one shared database account stored in its settings. The database sees queries coming from that shared service account rather than the individual person. You need deeper query logging to tie specific database reads back to a single user.