Revert back to SSO from oAuth2 on Paginated Report Data Source connected to Azure Analysis Services

[Anonymous]

Hi!

I found out, too late of course, that if you change Data source authentication method to oAuth2 for Paginated Reports Data Source and the Data Source is type AAS, then you can't go back to SSO.

The data sources default to using single sign-on (SSO), where applicable. For Azure Analysis Services, you can change the authentication type to OAuth2. However, once the authentication type for a given data source is changed to OAuth2, it can't revert back to use SSO. In addition, this change applies to all the reports that use that data source across all workspaces for a given tenant. Row-level security in paginated reports won't work unless users choose SSO for authentication type.

Supported data sources for Power BI paginated reports - Power BI | Microsoft Docs

So when I remove the report from workspace and re-deploy it, it still uses the oAuth2. Also it doesn't help if I change workspace as the setting is Tenant wide. So is my only options really to deploy AAS model to a new server? Seems unbelieveble that this kind of tenant level decision is possible and it can't be reverted. We have lost RLS functionality from Paginated Reports because of this.

[v-lili6-msft]

hi  @Anonymous 

Try to open inprivate window to try it again.

If it doesn't work ,from the document, it seems that it can't revert back to use SSO any more.

Regards,

Lin

[gwhinkel]

Had the same issue starting on Friday December 18th, so created a support ticket.

It was revealed during the call with MS tech that any report you create that connects to the same server, same model, same workspace, will share the first connection published to that workspace. And if you change the credentials (for any of those reports in the workspace) to Oauth2, all of your reports will now fail.

He suggested 3 ways to fix the issue:

1. Delete all reports in the workspace that use the same connection, then re-publish. (He did mention though that this "sometimes" does not work.)

2. Re-name, re-deploy the AAS model (and connect your reports to the newly named model, and re-publish). This will create a new data source in the PBI service. (Apparently these are named using <AAS instance name> + <Model Name>)

3. Deploy to a different workspace. (which will create a new connection as well)

I didn't try #1 or #3, but #2 was the easiest for me, and worked as advertised.

It's a necessity to be able to change back to SSO (blank) from Oauth2.

In addition, we should be able to see / edit the (shared) connections in the PBI Service, in the lineage view.

[Anonymous]

Hi!

I had a ticket created to support also and I didn't get these options. Only a reference to documentation stating the problem. We ended up testing possible options ourselves and found out 2 that seemed to resolve it through a workaround.

1. Rename AAS model or move it to new server. Like mentioned by @gwhinkel the connection string id is stored as servername + database name. Change either one and get a new connection id. We ended up using this but with a "friendly name" option that AAS supports. That ment that other reports didn't need to be reconfigured to use new connection string and we can generate new connection strings when we need.

2. Using a new Power BI account to publish Paginated report. Connection Id seems to be unique for every user. If a new user, that has never touched the authentication method for that connection string in any workspace ever, publishes the report, then it gets SSO as authentication method (And a new connection id).

[jochenj]

hi @Anonymous  created a support ticket but up to now no suggestion for a "way back" to SSO 😞 

You wrote "We ended up using this but with a "friendly name" option that AAS supports."
->Could you explain that? How to configure that "friendly name"? Can't find anything in azure portal blade for AAS and wonder how it is done.  THanks for Insight!

EDIT:
You did "Alias server names" like here described? Azure Analysis Services alias server names | Microsoft Docs 

[Anonymous]

Hi @jochenj !

That's correct. The other method (Azure storage) is documented here.

Static website hosting in Azure Storage | Microsoft Docs