On-Premise Gateway data source account seems to require Local Admin on the Server to refresh

[Recce]

I have an on-premise data gateway connecting to an on-premise SSAS 2019. I've been able to get it to work, but only by adding the account used to connect to the SSAS (ie. the credentials setup in the data source on the gateway) to the Local Administrators group on the SSAS server. I'd prefer it if this wasn't necessary and I had a setup with more mininal permissions.

The setup is as follows:

• The SSAS Service is running under a domain user account.
• The gateway is clustered and running as the NT Service account. 
• The account (GatewayReader) used in the data source on the gateway is an Admin for SSAS service. I have also added the account into the Windows Authorization Access (WAA) group in the Active Directory.

When attempting to refresh a PowerBI dataset configured to connect to the SSAS through the on-premise data gateway, I get following error:

the AnalysisServices: XML for Analysis parser: The 'ST@Ranger.com' value of the 'EffectiveUserName' XML for Analysis property is not valid.

When I add the GatewayReader account into the Local Administrators group of the SSAS server, then it works. What permissions / privilages should I give the GatewayReader account so that it no longer has to be a Local Admin?

Thanks in advance

[Recce · Accepted solution]

Misunderstanding on my part. The acccount the SSAS service is running under needs to belong to Windows Authorization Access group in Active Directory, not the GatewayReader in my example above.

Strangely this group assignment isn't required when the client is on the internal network / domain, but is required in the cross domain scenario of having the client being the PowerBI cloud service connecting to the on-premise gateway. There's proably something else at play here that I don't understand. 

[lbendlin]

That's exactly our problem too. Nobody can tell me if the Discover permission can be given to a non-admin role. Do you have any advice on that?

[Recce]

Speaking from a position of ignorance (I'm woefully lack experience in the SSAS and PowerBI space), I don't see the SSAS Admin role as big a problem / security risk as I thought it was going to be because of the EffectiveUserName property. 

We currently has a SSAS multi-dimensional model and have setup a data source on the on-premise gateway for it. Any report author who attempts to refresh their data set using the gateway will find that the refresh is completed using the Admin creds impersonating the owner of the data set, via the EffectiveUserName property. They will not be able to populate the data set with any data / measure that the owner of the data set does not have permissions for. 

I would prefer to not the give the account SSAS Admin role, but I don't see a way around that. As the account is performing impersonation (within the scope of SSAS), the account is always going to be privileged within SSAS. Until Microsoft provides an actual SSO credential type connection for SSAS, as they have done for SQL Server, I don't see a viable alternative. 

But it should be possible for the gateway to leverage EffectiveUserName property without us having to grant Local Admin on the server. 

[lbendlin]

The account needs Read and Discover privileges.

[Recce]

The account is an Administrator for the SSAS service and so will have Discover and Read permissions through that. The permissions that I'm hoping to "trim" is the account being a Local Administrator of the actual server. A member of the Windows Local Administrators group