Forum Discussion
Power BI Report Server with custom authentication error Power Bi Desktop
Hi fabio78,
You’ve used the correct and reliable approach for integrating Power BI Report Server with Custom Authentication and SSAS. By adding CUSTOMDATA={{USERID}} to the PBIRS connection string and referencing it in an SSAS role, you successfully recreate the user context that PBIRS doesn’t provide in Forms mode. Your setup works as intended: the Custom DLL sets the user identity, PBIRS forwards it via CUSTOMDATA, and SSAS applies Row-Level Security through DAX. This method is supported for per-user filtering when EffectiveUserName isn’t available.
Your architecture is solid: PBIRS operates in Custom Authentication mode, the report sends the custom identity in the connection string, and SSAS handles security in the role. This ensures that all security is managed within the semantic layer, not the report. The results you’re seeing, admins having full access and other users being filtered are expected.
To expand this to groups, modify your DLL to capture user groups and pass a normalized value into CUSTOMDATA, such as a group key or list. Then, add a group-to-business key mapping table in your Tabular model and adjust your role DAX to filter using CUSTOMDATA(). This approach keeps authorization logic in SSAS, maintains your custom identity throughout, and avoids unsupported changes in PBIRS.
Thank you.
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.