Power BI Report Server, Reverse Proxies & Kerberos: Making It All Work Together

Power BI Report Server, Reverse Proxies & Kerberos: Making It All Work Together

If you’ve ever tried to expose your Power BI Report Server to the internet, you’ve probably run into a few headaches—especially when it comes to authentication. Let’s walk through the typical setup, the challenges, and how modern identity platforms like Okta can help bridge the gap between legacy and modern authentication.

The Reverse Proxy Setup

When you want to make internal services like Power BI Report Server accessible from the internet, the go-to approach is a reverse proxy. Think of it as a gatekeeper: all external traffic hits the proxy first, which then forwards requests to the appropriate internal server.

Popular tools for this include Apache and Nginx. The reverse proxy becomes your central security checkpoint, exposing just one public IP while shielding your internal infrastructure.

Authentication: The Kerberos Conundrum

Power BI Report Server supports only Windows Authentication. Ideally, you’d use Kerberos, which allows users to authenticate once and then access multiple systems without re-entering credentials—a concept known as Single Sign-On (SSO).

Kerberos is a network authentication protocol that uses tickets to allow nodes to prove their identity securely. It’s great if it works but hickups are rather challenging to debug especially in a Windows environment. Call yourself lucky if you have a seasoned Kerberos expert on your team.

The Problem with Reverse Proxies

Here’s the catch: when you put Power BI Report Server behind a reverse proxy, Kerberos doesn’t work out of the box. Most reverse proxies only support Basic Authentication when forwarding requests.

This means:

  • The user logs in via Basic Auth at the proxy.
  • The proxy authenticates the user to the Power BI Report Server.
  • But… that authentication stops there.

If your Power BI reports pull data from other servers, the Report Server can’t impersonate the user via Kerberos. It only knows the proxy’s credentials—or a single service account. That’s a big problem if your data sources are secured per user.

Why This Matters

If you rely on row-level security or user-specific data access, this setup can lead to data leaks. Anyone who can access the PBIX file (or the report) might see more than they should, especially if the report server uses a shared account to fetch data.

Enter Okta (and Friends)

Modern identity providers like Okta or Microsoft Entra ID use SAML or OAuth for authentication. These protocols are great for web apps and offer features like:

  • Self-service password reset
  • Multi-factor authentication (MFA)
  • A slick dashboard with app tiles (Power BI Report Server can be one of them)

But here’s the rub: SAML/OAuth ≠ Kerberos. They’re different beasts. So how do you make them play nice?

Translating Protocols: Okta Access Gateway

This is where Okta Access Gateway (OAG) comes in. It acts as a translator between modern web authentication (OAuth/SAML) and legacy protocols like Kerberos.

Think of it as a smart reverse proxy that:

  • Authenticates users via Okta (SAML/OAuth)
  • Then impersonates them using Kerberos to access internal apps like Power BI Report Server

Pretty slick, right?

Resources to Get You Started

Real-World Example: 3C Experian

At Experian we used Okta as our central identity provider. It offered:

  • A unified login experience
  • MFA support
  • A user-friendly app dashboard (Power BI Report Server was just a tile away)

By integrating Okta Access Gateway, we were able to securely expose Power BI Report Server to the web without sacrificing Kerberos-based access to backend data sources.

What’s Next?

In a follow-up post, I’ll walk you through how to configure Okta Access Gateway specifically for Power BI Report Server, including the gotchas and best practices we learned along the way.

Stay tuned!

Disclaimer

This article was created based on my personal notes with support from Microsoft Copilot. While Copilot assisted in structuring and refining the content, all technical details have been carefully reviewed and developed by me.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.