Connection Testing with Credentials As the user viewing the report errors. Connection either timed o

[dorje]

Hi,

We spun up a new SSAS server and tried to migrate databases from currently existung SSAS server. Made the required change in security , aded SPN and delegation.

When testing PowerBI report connection pointing to the new SSAS server, if choosing use following credential and enter an account that has read access the SSAD DB the connection test is successful. But if i Check "As User Viewing the report" it errors out.

In the Current SSAS both the option works. 

Im not sure whats missing? does anyone has similar experience, am i missing someting.

[d_gosbell]

---

@dorje wrote:

When testing PowerBI report connection pointing to the new SSAS server, if choosing use following credential and enter an account that has read access the SSAD DB the connection test is successful. But if i Check "As User Viewing the report" it errors out.

---

This implies that your Kerberos configuration is not working. When you choose the Use Following Credentials option PBIRS can fall back to using NTLM auth if Kerberos fails as the credentials only have to do a single "hop" PBIRS -> SSAS. Bbut when you choose "As User Viewing the Report" the credentials have to do a double "hop" Client -> PBIRS -> SSAS and so a working Kerberos configuration is required. If you run a SQL Profiler trace against SSAS while testing the connection and listen for the "Existing Session" or "Session Initialize" events you will see the user being passed through as Anonymous if Kerberos is not configured correctly while doing "As the User Viewing the report". 

The first thing I would try would be rebooting the SSAS server to force it to re-authenticate against the domain. If that does not help you'll need to double/triple check your SPNs and constrained delegation settings compairing the old and new servers to find what is different. You can also check the SSAS server logs when it starts up as i believe it logs the SPNs it detects when it starts up.

[dorje]

Thanks for your input it was really valuable. 

I also should have mentioned that we are testing on GMSA on the SSAS server. 

I was able to put the trace on both the SSAS server and perform the connection testing. The one with GMSA and which is having issue is showing the failing test connection as ANONYMOUS LOGIN , which is poiting to the double hop issue.

Currently the issue seems to be the SPN and Delegation as per the Kerberose Manager. The Kerberose manager shows the SPN status as Misplaced with Error Sign  and the Delegation status shows "NONE" but Server team is saying that the the SPN staus is good and that maybe issue with Kerberose manager or GMSA. Service Account Delegation also they looks good on their end. 

I doubt this but i need to find more info on this. Why whould it say "misplaced"  with error if its actually working.

No relief in sight, just have to do some more testing. 

Currently my options are to push a new test report server and plug it with GMSA and perform testing.

Any perspective is highly appriciated.

[d_gosbell]

---

@dorje wrote:

I was able to put the trace on both the SSAS server and perform the connection testing. The one with GMSA and which is having issue is showing the failing test connection as ANONYMOUS LOGIN , which is poiting to the double hop issue.

So this definitely means that your Kerberos authentication is not configured correctly. There is a chain of configurations required to get Kerberos working and every part has to be setup correctly or it just won't work. PBIRS has to be setup to ask the client browser to authenticate using Kerberos and it has to have the correct SPN and constrained delegation configuration in order to pass the credentials on to SSAS which also needs the appropriate SPNs configured.

You can double check the SPN and delegation settings that your AD admins have setup using this Powershell script: https://gist.github.com/dgosbell/166c0f63da9bae80ad25 (you don't need to run this from a server, you can run it from your workstation as it is just querying active directory). You would run this script twice, once for the account running Report Server and once for the account that SSAS is running as.

Once you have the output from the script compare the SPN and delegation settings to those documented here: https://docs.microsoft.com/en-us/power-bi/report-server/configure-kerberos-powerbi-reports

I would suggest stepping through the article above very carefully and double/triple check everything.

Make sure you have updated the AuthenticationTypes settings in rsreportserver.config to use RSWindowsNegotiate

---

@dorje wrote:

Server team is saying that the the SPN staus is good and that maybe issue with Kerberose manager or GMSA. Service Account Delegation also they looks good on their end. 

SPNs are just special text strings stored against an AD account. There is not really any such thing as "SPN status" if there is a typo or incorrect SPN format entered you will not get an error when creating the SPN, but the authentication will not work. It's the same with constrained delegation, if it's setup for Kerberos only or pointing to an incorrectly formatted SPN it will be accepted, but nothing will work.