March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early bird discount ends December 31.
Register NowBe one of the first to start using Fabric Databases. View on-demand sessions with database experts and the Microsoft product team to learn just how easy it is to get started. Watch now
Hi!
I just got this working after consulting this article:
So I have a tabular cube on one machine and report server on a different machine. I have set up SPNs and granted Kerberos delegation as described in the article above.
When I tried a testreport it still couldnt connect (We couldnt connect...) to the cube but once I changed the settings for the data source on the report from "As the user viewing the report" to "Using the following credentials" and checking the "Log in using these credentials, but then try to impersonate the user viewing the report" it worked.
Why do I need to change this setting to make it work? Is it some permissions that is missing?
For mor context, my user has all privilages to the cube and the report server. Prior to changing the setting on the data source, when I view the report as my own user I dont get any error. But when I view the report as a user that only is assigned a role in the cube I get the error.
Can anybody share any light on this?
Solved! Go to Solution.
On the delegation settings on the service account running the PBI RS we have Use Kerberos only. I have asked the domain admin to change it to Use any authentication protocol. Hope that helps.
This might be your issue. In my experience any slight variation from the instructions and it just does not work and it gives no meaningful error.
I don't *think* having all 3 methods listed in the rsreportserver.config file will be an issue since NTLM is last and Negotiate should attempt Kerberos first and then fall back to NTLM if that fails.
@Anonymous wrote:
So I have a tabular cube on one machine and report server on a different machine. I have set up SPNs and granted Kerberos delegation as described in the article above.
When I tried a testreport it still couldnt connect (We couldnt connect...) to the cube but once I changed the settings for the data source on the report from "As the user viewing the report" to "Using the following credentials" and checking the "Log in using these credentials, but then try to impersonate the user viewing the report" it worked.
Why do I need to change this setting to make it work? Is it some permissions that is missing?
So configuring the connection in that way will effectively bypass Kerberos so this most likely means that something is not quite right in your Kerberos configuration.
One way to double check this is to run a profiler trace against SSAS listening for the Existing Session, Initialize Session, Error and Begin Query events at a minimum. If Kerberos is NOT configured correctly you will see sessions from Anonymous users trying to connect to your cube. Unfortunately Kerberos needs everything to be configured 100% correctly or it just fails so you need to triple check the SPNs an constrained delegation settings in the MSFT docs.
If you do see user names in the profiler trace it means that Kerberos is working but something is wrong with your roles in SSAS and you should double check that you have granted read permisions.
Thanks for your tips!
There are two settings that are different in my environment compared to the one that GuyinaCube has that I know of is:
* On the delegation settings on the service account running the PBI RS we have Use Kerberos only. I have asked the domain admin to change it to Use any authentication protocol. Hope that helps.
* In rsreportserver.config I have (by default) all three methods listen in this order:
<RSWindowsNegotiate />
<RSWindowsKerberos />
<RSWindowsNTLM />
I have run the profiler and just as you suspected my test user who gets the error shows up as anonymous in the SSAS trace when I set the report on Report Server as "As the user viewing the report". If I run Power BI Desktop as this user and connects to the cube it works fine though.
Did this give you any clues?
On the delegation settings on the service account running the PBI RS we have Use Kerberos only. I have asked the domain admin to change it to Use any authentication protocol. Hope that helps.
This might be your issue. In my experience any slight variation from the instructions and it just does not work and it gives no meaningful error.
I don't *think* having all 3 methods listed in the rsreportserver.config file will be an issue since NTLM is last and Negotiate should attempt Kerberos first and then fall back to NTLM if that fails.
After swithcing to "Use any authentication protocol" the test user can see the contents of the report without setting the "Using the following credentials" on the data source of the report.
Thanks!
Are you using different domain service account for PBI RS and SSAS? Your account works as you are admin to both server?
YEs, I have one service account for the SSAS och one for PBI RS. My account is admin on both servers.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!
Your insights matter. That’s why we created a quick survey to learn about your experience finding answers to technical questions.
Arun Ulag shares exciting details about the Microsoft Fabric Conference 2025, which will be held in Las Vegas, NV.
User | Count |
---|---|
2 | |
2 | |
2 | |
1 | |
1 |
User | Count |
---|---|
5 | |
4 | |
3 | |
3 | |
3 |