Scheduled and On Demand Refresh still work with a user that no longer has access to the source AAS

[powerbibibibi]

Hi All,
We have PowerBI reports that have a live connection to Azure Analysis Services.
I have read that visuals are cached unless something such as filters are changed, so that PowerBI doesn't need to keep querying the tabular model.
This all seems fine.
I am testing taking over the dataset for certain test copies of AAS live connection reports so that should the user who published change their password or their MFA token changes, the scheduled refresh will continue.
I wanted to test that 100% removing a user that had published from the source AAS model (e.g. like that person no longer had access) to see what happens to the report loading and the scheduled and on demand refreshes - I expected all to fail.
So I removed my own user, and in PowerBI, I could no longer load my test reports that used this AAS datasource, the visuals all failed.
I was expecting that and that made sense.
However, if I went into the dataset of that report in apps.powerbi.com and then hit refresh (so an on demand refresh) or scheduled a refresh, both still worked even though I was still the owner of those two datasets.
So I can't understand how the refresh is actually accessing the AAS datasource for the On Demand Refresh and Scheduled Refresh when I have purposefully removed myself from that model.
So visuals fail when try to load as myself = completely what I expected
However, scheduled and on demand refreshes still work whilst I am the dataset owner despite me no longer having access to the AAS data souce = confused...com 🙂
How does PowerBI know if my source AAS data model has changed if I no longer have access to it?
There are no errors reported at all with the refreshes.
These test datasets\reports are not using a shared dataset.
AAS can't be caching my credentials as opening the report fails right after I remove them for testing, its jsut the refreshes that seem to be able to continue.
I think I must be misunderstanding something here!
If anyone can help I would be grateful.
Many Thanks!

[powerbibibibi · Accepted solution]

I figured this one out - as known already, the refresh query is only concerned if the model underneath has changed, data or schema, by looking at last schema \ last data update times on the cube. The network setting on the AAS server "Allow access from the Power BI Service" is the one setting that allows PowerBI to query the model to run this basic have you changed query - it is not done as the publishing user\data owner of the dataset. Phew that messed me up for some time!

[powerbibibibi]

Update on this one. I span up our test AAS cube and used that for my source in my PowerBI test report.

I used DAX Studio to watch the incoming connections to this test AAS cube, which were isolated to the ones that I was sending to it. Everytime I hit refresh it will run :

select [LAST_SCHEMA_UPDATE],[LAST_DATA_UPDATE] from $system.mdschema_cubes where ([CATALOG_NAME]=@p1)

As User NT AUTHORITY\SYSTEM

Approx 24 hours before that, I had removed the test account that is also the dataset owner of my test PBI report, from this AAS cube and deleted all of the roles - so it had zero access (which I can confirm by trying to open the report). 

However, I can still hit refresh on the dataset  (when logged into apps.powerbi as that test account)

I originally published the test PowerBI report with that test account also.

In Azure AD I revoked all sessions and refreh tokens for my test account.

Somehow this dataset is still able to query the underlying AAS model and I have yet to work out/prove if it is definitely an unexpired token as nothing seems to be expiring...

[powerbibibibi]

https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/users-revoke-access#access-... this is suggesting one hour for a specific resource (so AAD in this case) so I will try leaving it for longer than that 🙂

[GilbertQ]

Hi @powerbibibibi 

My understanding is for the user credentials these settings are cached using a token with an expiry. I am not certain of the expiry but it does last for quite some time. And that would explain as to why the refresh is still working to me!

[powerbibibibi]

Thanks for helping me. Yes I think that could be it. So refresh is using a previously obtained token and not yet expiring, whereas loading a report is different, and means visuals are trying to authenticate at that moment and can't any longer obtain a token (since I revoked access after). That would make sense. I guess I can try testing just by leaving the scheduled refresh running and seeing if the token evenutally expires. I will find out from our Azure AD colleague how long to expect in our environment. I think we can trigger a revoke with another test user.