Configuring Kerberos SSO for the Power BI Gateway - What It Solves and Why It Hurts
There's a specific moment in a lot of Power BI projects where things get political. The reports are built, the data is connecting, and then security or the database team asks the question that stops everyone: "When a report runs against our on-prem SQL Server, whose identity is it running as?"
If the answer is "one shared service account that sees everything", you've got a problem. Because the whole point of your carefully built row-level security, the rules that say a Queensland sales manager only sees Queensland data, can be quietly bypassed if every Power BI query hits the database as the same all-seeing account. The database can't tell users apart, so it can't enforce per-user rules. This is where Kerberos-based single sign-on comes in, and it's one of those features that's genuinely important and genuinely painful in equal measure.
So here's the explainer I give clients when this comes up, which it always does the moment a regulated industry is involved.
What problem Kerberos SSO actually solves
When Power BI in the cloud needs to query an on-prem data source, it goes through the on-premises data gateway. The gateway is the bridge: it sits inside your network, receives the query from the service, and runs it against your SQL Server, SAP HANA, Teradata, or whatever you've got.
The question is what identity that query runs under. By default, you configure stored credentials on the gateway, and every query runs as that one account. Fine for a lot of cases. Not fine when the data source itself enforces security per user.
Kerberos constrained delegation changes this. With it configured, the gateway can impersonate the actual user who opened the report. So when your Queensland sales manager opens a dashboard, the query that hits the on-prem database runs as her, with her Active Directory identity. The database sees her, applies whatever native row-level security or permissions it has for her, and returns only her data. Her colleague in Western Australia opens the same report and gets different rows, because the database enforced it, not Power BI.
That's the payoff. You push security enforcement down to the data source, where a lot of organisations have already invested years building it. You don't have to rebuild all those rules in Power BI. You honour the security model that already exists. For financial services, healthcare, and government clients, this is frequently non-negotiable. We see it constantly in our Power BI consulting engagements, especially anywhere there's a compliance auditor in the building.
How it works, in plain terms
Kerberos is the authentication protocol Active Directory uses. Constrained delegation is the feature that lets one service (the gateway) act on behalf of a user when talking to another service (the database), but only to specific, named services that you've explicitly allowed. The "constrained" part is the security control: the gateway can't go impersonating users to just anything on the network, only to the data sources you've whitelisted.
The flow goes roughly like this. The user authenticates to Power BI with their Azure AD identity. That identity gets mapped to an on-prem Active Directory identity (this mapping step matters, more on it below). The gateway, which is running under a service account you've configured for delegation, requests a Kerberos ticket on behalf of that user for the specific database service. The database receives the connection as the user, not the gateway account, and does its thing.
When it works, it's invisible. Users have no idea any of this is happening. They just see correct data. When it doesn't work, you get authentication errors that are spectacularly unhelpful, and you spend a day reading event logs.
The setup landmines
I'll be straight with you: this is one of the fiddlier things in the Microsoft data stack, and the documentation makes it sound smoother than it is. Here's where I've watched it go wrong.
Service Principal Names (SPNs). Kerberos lives and dies by SPNs being registered correctly. The SPN identifies the service on the network so the right ticket can be issued. Get the SPN wrong, duplicated, or missing, and authentication fails. A duplicate SPN is especially nasty because it can break authentication intermittently and for unrelated services. You'll need someone with the AD rights to register SPNs, and in a lot of Australian enterprises that person sits in a different team behind a change request queue. Plan for that delay.
Delegation configuration. The gateway service account needs to be trusted for constrained delegation to the specific service. This is configured in Active Directory, usually by a domain admin. Again, different team, different queue. You also need to decide between standard constrained delegation and resource-based constrained delegation, and the right choice depends on whether the gateway and the data source live in the same domain. Cross-domain scenarios add real complexity.
The identity mapping problem. Power BI users authenticate with their Azure AD UPN, which is often something like [email protected]. Your on-prem AD might use a different format, or a different domain entirely. If the UPN doesn't cleanly map to an on-prem AD account, delegation fails. You can configure mapping rules on the gateway to bridge this, but you have to know to do it. Hybrid identity setups where the cloud and on-prem usernames don't match are where I've seen teams lose the most time.
Testing as someone else. The configuration always works for the admin who set it up, because their identity is the one being tested. Then a regular user opens the report and it fails, and now you're debugging in production. Test with a real end user's account early, not just your own.
Is it worth the pain?
Honestly, sometimes no. Before you commit to Kerberos SSO, ask whether you actually need it.
If your security requirement is "different people see different rows", you have options. You can implement row-level security inside Power BI itself, using the Power BI model, and run the database queries under a single account. That's far simpler to set up and maintain, and for a lot of organisations it's the right answer. The Power BI RLS engine is mature and it works well.
You only really need Kerberos SSO when the security must be enforced at the source, not in Power BI. That's the case when the database already has rich, complex security rules that you can't or shouldn't replicate in Power BI, or when compliance demands that the data source itself controls access and can audit it under each user's identity, or when you're using DirectQuery against a source whose own security model is the source of truth. If none of those apply, you can probably skip the whole exercise and save yourself the AD wrangling.
When I scope this with clients, the decision usually comes down to a single question: does the auditor need to see, in the database's own logs, that user X queried table Y? If yes, Kerberos SSO. If the requirement is just "users see the right data" and nobody's demanding source-level audit trails, Power BI RLS is the pragmatic choice. We work through this trade-off regularly as part of our broader business intelligence and analytics work, and I'd say more than half the time the simpler path is the correct one.
My honest take
Kerberos SSO is powerful and it's the right tool for genuinely regulated, source-secured scenarios. It's also the kind of thing that turns a two-week Power BI rollout into a six-week one because you're now waiting on the AD team, the network team, and a security review. None of that is a reason not to do it. It's a reason to scope it honestly up front, so leadership isn't surprised when "just connect to the database" turns into a small infrastructure project.
If you're going down this road, get your AD and gateway people in the room early, register the SPNs correctly the first time, and test with a real user before you declare victory. The Microsoft reference on configuring Kerberos-based SSO has the step-by-step, and it's worth reading slowly rather than skimming.
This is bread-and-butter work for us, both the Kerberos setup and the harder question of whether you need it at all. If you want a second opinion before you commit, that's a quick conversation. Our Microsoft consulting team does this most weeks, and we'll tell you honestly if the simpler path will do the job. Reach out here.