Reports Reader Admin Role irrelevant?

[Stefan Fried]

hi folks

I've found out that the delegated permissions (azure AD app) do not work as documented or the O365 Admin role "Reports Reader"  is irrelevant at least in case of "Usage reports".

I've created a Native Azure AD Application where I've set delegated permissions for "Read all usage reports" within MS graph

According to the documentation provided here the effective permissions of an application should be 
"the least privileged intersection of the delegated permissions the app has been granted (via consent) and the privileges of the currently signed-in user" 

I thought that the user (which should use this application in order to access usage reports) needs to have at least the Reports Reader Role...but in fact this is not necessary :(

My Testcase:

I send a token request for graph api for a user without any special privileges (normal user without any admin roles!)

You see in the screenshot below that this user got the Scope Reports.Read.All !

So in my opinion this means, that EVERY user can access all the usage Reports. And in fact an ordinary user can pull the reports :)

Questions:

- is this intended ?  I don't think so :)

- if yes, whats the reason for having Admin Role ?

- or do i misunderstood here something ?

thank you

stefan

[#2]

Not all Office 365 admin roles have relation to the Graph, in fact many of them don't care at all about it. Of course I cannot speak on behalf of the devs and of course I haven't even seen the code, but unless we are talking about some of the default roles (GA, User admin, etc) I wouldn't expect the Graph permission scopes to rely on the user role. So in this case, think of them as two different controls for the same functionality.

It's also not true that every user can access the reports, as that's a permission scope that requires Admin consent. Unless you as the admin have granted consent to all users, they will not be able to obtain such token.

That's my understanding at least.

[#3]

Thanks Vasil,

but now i have the following questions:

you said:
"Unless you as the admin have granted consent to all users, they will not be able to obtain such token"

Within Delegated Permissions (Azure AD App Settings) you can not assign it to individual users. It is always granted to all users but restricted based on the following (cited from MS documentation)

"the least privileged intersection of the delegated permissions the app has been granted (via consent) and the privileges of the currently signed-in user" 

So the first question is, If above statement (least privileged intersection) is not true, how can i restrict a normal user then  ?

the second question is in regards to the "Reports Reader Role":

MS says , that users with the Reports Reader Role can access the Reports via Admin Center and any reports exposed through the reporting APIs.

So why does this Role exists then ?

thanks

[#4]

Stefan, I'm in no way an expert of Graph or even a programmer for that matter, I was just trying to explain things the way I see them. Obviously I'm not very good at that :)

My point was that you should use the built-in AAD role if you want to grant certain person access to the reports functionality. They way I understand it, "Reports Reader" is a role "described" in one of the underlying/built-in "applications" in Office 365/Azure AD. And "assigning" the role in the portal basically grants the relevant assignment of the underlying app to the user.

On the other hand when you are creating a custom application, you are in charge of describing the permissions, and are (or should be) aware that some permissions require Admin consent, which as you correctly mentioned applies to the entire directory. Thus once you add (and consent to) application that has the Reports.Read.All scope, every user in the organization will be able to get a token/access any resource the app grants permissions to.

To control who gets access to the functionality exposed by said app, *you* should describe/create roles/scopes for that application. Which is one of the things you can control on the Assignments page in the portal (https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/app-roles). By default a single "Default Access" role is created for each application, meaning that everyone will have the exact same access (unrestricted access to all the resources the application has been granted consent to).

Do correct me if any of the above is wrong, I'm also trying to make sense of this whole thing :)

[#5]

thank you vasil

your input make absolutely sense and it gave me also the hint in regards to App-Roles.

I was NOT aware of AppRoles at all because in the UI there was no indication that you can assign Roles to apps (i would have expected at least a button instead of manually modifying the manifest ).

And assigning users to a role via PowerShell only (without the chance of doing it via UI) is also a bit strange :)

but anyway....that's the way

However there is one single fact:

that the citied MS statement ....

""the least privileged intersection of the delegated permissions the app has been granted (via consent) and the privileges of the currently signed-in user" 

..is absolutely WRONG !

lesson learned....i will NOT ask Microsoft for further details

thanks again for your help..i owe you a beer :)

cheers

stef