Power BI Report Server with custom authentication error Power Bi Desktop

Hi fabio78,

This can be accomplished by placing a reverse proxy in front of Power BI Report Server, allowing the proxy to manage different authentication methods depending on the URL path. While Power BI Report Server cannot mix authentication modes, a proxy can handle this by running PBIRS with Windows Integrated Authentication internally and exposing a single public endpoint. The proxy then determines the authentication method for each request.

For example, when users access the portal via a browser, requests like /reports or /Pages/* are intercepted and challenged with your custom or forms-based authentication. Once authenticated, the proxy forwards these requests to PBIRS. For Power BI Desktop, which uses endpoints like /api/v2.0/ServiceState or /ReportServer/*, the proxy skips forms authentication and passes the request using Windows Integrated Authentication. Since PBIRS only supports Windows authentication for these REST endpoints, it responds appropriately and Power BI Desktop functions correctly.

This setup lets you maintain your custom authentication for end users while ensuring Power BI Desktop remains compatible. You can use IIS with Application Request Routing and URL Rewrite, NGINX, or a cloud gateway like Azure Application Gateway to implement this. The main concept is to use path-based routing and authentication at the proxy: custom authentication for portal paths and Windows authentication passthrough for REST and ReportServer paths. This method avoids altering PBIRS internals and follows supported product behavior.

Thank you.

Hi fabio78,

Power BI Report Server does not natively support accepting external identities from a reverse proxy and treating them as the logged-in user. PBIRS only recognizes Windows Integrated Authentication or its own Custom/Forms authentication extension. If authentication is handled entirely by a reverse proxy, PBIRS cannot use headers or tokens (like X-Authenticated-User) to identify users for permissions, RLS, SSAS EffectiveUserName, or User!UserID in reports. In this scenario, PBIRS will see all requests as coming from a single Windows service account or as anonymous, resulting in the loss of the actual end-user identity. Therefore, a reverse proxy setup is limited: either PBIRS runs in Windows mode with the proxy forwarding all requests as one account, or it uses Custom/Forms authentication, which allows user recognition but prevents publishing from Power BI Desktop due to product limitations. There is no supported hybrid model combining Forms authentication for the portal and Windows authentication for REST endpoints while still maintaining user identity. Given these limitations, your current method, using Custom Authentication in PBIRS, building reports in Power BI Desktop, and uploading PBIX files through the portal, is the recommended and supported approach. User-based filtering should be handled within reports or SSAS using your custom identity (such as User!UserID and a mapping layer), instead of trying to map identities at the server level.

Thank you.

Hi, thanks for the reply. I'll tell you what I did in the meantime. Reading around, I found a topic that suggested valuing customdata() and setting it in the SSAS connection string. That's what I did. In my case, I modified the connection string in PBIRS:
Data Source=localhost;Initial Catalog=TabularOrariOdooPowerUser;Cube=Modello;CUSTOMDATA={{USERID}}

Now, in the Power BI Desktop report, I've created a measure to verify whether the user "custom = CUSTOMDATA()" is actually captured. Running the report in PBIRS actually displays the user I'm logging in with, but I can't set this string as a filter in SSAS and, consequently, in the PBIRS report.

If I understand correctly, in your post, you suggested creating a mapping table that links custom usernames to the key and defines row-level security using a filter. To do this, I would need to create a hidden parameter that can't be modified and pass the user to it. I can try, thank you again for your support and I will definitely ask for your help again!!!
Thanks.

Hi,

You didn’t miss a config setting — this is a product limitation.

When Power BI Desktop saves/publishes to Power BI Report Server, it does a backend call to the Report Server REST API (for example GET /api/v2.0/ServiceState). That call only supports Integrated Windows authentication. With a Custom/Forms auth setup, the REST call returns 401, which is exactly what you’re seeing in the RSPortal logs.

So:

• ✅ Portal login (Logon.aspx) works

• ✅ Report Builder works (because it can prompt / handle credentials differently)

• ❌ Power BI Desktop publishing fails with “Unexpected error occurred” because Desktop can’t complete the REST authentication flow when the server is using custom forms auth (cookie-based).

What you can do

1. Use Windows Integrated authentication for PBIRS (supported path). If you must keep custom auth, you’ll likely need to revert/enable Windows auth for the report server endpoint used by Desktop.

2. Workaround: Save the PBIX locally, then upload it through the PBIRS web portal after logging in (if your portal allows uploading PBIX). This bypasses Desktop’s “Save to Report Server” authentication path.

3. Ensure you’re using Power BI Desktop (optimized for Report Server) that matches your PBIRS version, but note this won’t solve the custom-auth limitation — it’s just a compatibility requirement.

Bottom line

Power BI Desktop cannot publish to PBIRS using Custom/Forms authentication. The 401 on /api/v2.0/ServiceState confirms that Desktop is blocked by the authentication mode.

Thanks for the reply, I now understand that PowerBI Desktop isn't compatible with custom authentication, although it seems absurd that changing the authentication mode is allowed and then some products aren't compatible.
In any case, following your instructions, I wanted to understand one thing:
1. Use Integrated Windows Authentication for PBIRS (supported path). If you need to keep custom authentication, you'll probably need to reinstate/enable Windows Authentication for the report server endpoint used by Desktop.
If I understand correctly, can I keep custom authentication and then define endpoints that Desktop uses with Windows Authentication? Can I manage this from web.config? Do you have any examples?

In the meantime, I've tried to manage everything with my custom DLL, intercepting the call headers, and thus I've managed to handle both custom authentication and calls from the desktop. However, for now, I can't optimally filter the desktop (all are allowed). I still have some work to do, but again, if your point 1 is feasible as I interpreted it, I think I'll go that route.

Thanks again for the reply!!

Hi fabio78,

Thank you mohit_sakhare for your reply.

Your understanding is basically correct, but Power BI Report Server doesn't support this natively. PBIRS only allows one authentication model at a time. When Custom/Forms authentication is enabled, it applies to the entire server, including the REST API endpoints that Power BI Desktop uses. Power BI Desktop doesn't go through Logon.aspx; instead, it calls endpoints like /api/v2.0/ServiceState, which only support Windows Integrated Authentication. So, with Forms/Custom authentication enabled, these endpoints return a 401 error. There's no supported way to set PBIRS to use Forms authentication for the portal and Windows authentication for /api or /ReportServer just by changing configuration files, as the product expects a single authentication mode for all endpoints. To achieve a split, you would need an external solution like IIS, a reverse proxy, or an application gateway to route different paths and enforce different authentication methods. Your custom DLL works because it bypasses the built-in security, but this means you have to manage authorization yourself. Officially, the supported options are to use Windows Integrated Authentication for everything, or use Custom/Forms authentication and accept that Power BI Desktop can't publish directly, reports would need to be uploaded through the portal.

Thank you.

Hi, I'm sorry, how can I use a reverse proxy for custom authentication and still use Power BI Desktop? My problem is that you basically have to use custom authentication. I'm not very experienced. Thanks.

Hi fabio78,

Since we haven't heard back from you yet, I'd like to confirm if you've successfully resolved this issue or if you need further help?

If you still have any questions or need more support, please feel free to let us know. 

We are more than happy to continue to help you.

Hi, sorry for not updating you. I did some testing. So I tried to figure out how to use the reverse proxy, but I don't think it can help me, or maybe I didn't understand how it works exactly. My problem is that authentication must be custom, but once authenticated, the web portal (Power BI Report Server) must identify itself with the authenticated user. If I move the authentication to the reverse proxy, how does Power BI Report Server retrieve the user? So in the meantime, I tried again and settled on the solution of configuring Power BI Report Server with custom authentication, creating the report with Power BI Desktop, and then manually uploading it to the portal. Now, this raises another dilemma for me: recovering the custom user and using it to filter the data with SSAS, but that's another problem. Thanks for the support!!!

Fabio

Hi, I've done various tests and so far I've managed to create a DLL and configure the logon page in Power BI Report Server. Now I can log in with a user. I also retrieve the user's group from a database and then configure reports or folders in PBIRS with users or groups to see if it works. Now the problem is how to pass the user or group I logged in with as a variable to the report or SSAS cube. I'm having a lot of trouble... I can't get it to work. I have a user-based filter that needs to be managed within reports or SSAS using the custom identity (e.g., User!UserID and a mapping layer).