DevOps: Azure Enterprise Application - login via Secret vs. interactive -> Security Issue?

Question

DevOps: Azure Enterprise Application - login via Secret vs. interactive -> Security Issue?

Jens Breidenstein 21

I have a rather (hopefully) theoretical question regarding the secure usage of Service Pricipals in Azure (Enterprise Applications)

Introduction

we currently deploy our DevOps Code via Azure Service Principals.

AppRegistration/Enterprise App is created
Secret is generated
Permission (i.e. Contributor) to the Ressource Group is granted in Azure
Service Connection is made in Devops everything works fine.

Assumption

By default the Service Principal (Enterprise Application) is not restricted to a specific user/group (Assignment Required => "no").

My assumption is now, that every user in the AAD-Tenant is able to login to the Enterprise Application as well.

I i.e. do this by using the "Graph Powershell API"-EnterpriseApp.
I can either use a Secret or use my User Credentials to access the Service Principal and its permissions.

Security issue?

coming back to our DevOps configuration:

The Service Principal has Contributor Permission on the dedicated Resource Group.
Assignment Required (of the Enterprise App) is set to no (default configuration).

if I (as a malicious user) have the Application ID, i could simply logon to the Service Principal and receive the Token.

Question:
With this token and my login to the EnterpriseApp, do i also have the Contributor Permissions of the App and could now manipulate the whole Resource Group?

Since i'm not an Azure Developer - but only an Azure AD Admin - my knowledge regarding this is limited, so i'm not able to test it.
Can someone maybe either provide code or prove that my assumptions are wrong or correct?!

Thanks

Accepted answer

0 additional answers

Your answer

Answer 1

Vasil Michev 119.5K MVP Volunteer Moderator

When you are logging in (obtaining a token) in the context of a user, the effective permissions you get are the cross-section of the permissions granted to the app (service principal) and those granted to the user. So in your scenario, the user still needs to have Contributor permissions on the resource group. And as you mentioned above, if you are too worried about this scenario, you can simply restrict the app/SP to specific users only. Or only enable the client credentials flow to begin with.

Jens Breidenstein 21 Reputation points

2022-12-10T14:50:16.307+00:00
Hi Michev,

Thanks for your fast reply.
I'm actually not convinced.

I know your statement is true for "normal" API Permissions.
But i'm not sure about Azure AD Roles or Azure RBAC role assignments to an Enterprise Application.

Example with Azure AD Roles

what makes me unsure is the following:
I use an AppRegistration to regularly cleanup rogue devices from Azure AD via Powershell.

The AppRegistration has the following permissions:

Directory.AccessAsUser.All
and has the Azure AD Role

Cloud Device Administrator
assigned
see https://learn.microsoft.com/en-us/graph/api/device-delete
I connect to the App with a Client Id & Secret
So in this case it is just the other way arround. Connect-MgGraph -ClientId $clientId -TenantId $tenantId -CertificateThumbprint $cert_thumbprint
Remove-MgDevice -DeviceId $device_id

The Service Principal does not have ANY permissions itself. (AppI & Secret)
It is accessing the API with "AccessAsUser".
As i understand it - this "permission" just enables User Access without any permission.
Only the assignment of the Azure AD Role to the EnterpriseApp makes it possible to delete devices.

Resulting Assumption

So from what i assume from this example:

an assignment of an Azure AD Roles to an Enterprise App is independed(!) from the user

if this is true for Azure AD Roles - it might also be true for Azure RBAC Roles

Is there a way to prove this assumption right or wrong?

BR
Jens
Vasil Michev 119.5K Reputation points MVP Volunteer Moderator

2022-12-10T16:38:41.167+00:00

When you are connecting via Certificate, or client secret, that's using application permissions, not delegate permissions. You can easily confirm it by running Get-MgContext.
Jens Breidenstein 21 Reputation points

2022-12-10T20:58:51.353+00:00
(1/2)
Hi michev,

Thanks again for your fast feedback.

What you write is fully clear - but it doesn't calm my concerns, because you only refer to basic API permissions.

It might seem very pedantic from my side.
But, if I would be correct, this is would have huge security impact.

API permissions vs. role assignments
In addition to delegated and application permissions, you can (and sometimes have to) assign

Azure AD Roles or

Azure RBAC Roles
to an Enterprise Application.

Azure AD: assign the role in AAD Role assignments or via PIM to the APP
Azure RBAC: assign i.e. Contributor to the App (instead of a user) in the usual Azure Role assignments or via PIM

As it seems to me, such role assignments evade the mechanism you described in your first reply.
It seems only be effective in API permissions (delegated or application).

Transfer to the example
In my working example, I assigned the delegated API permissions "Directory.AccessAsUser".
No other application permission (such as Directory.ReadWrite.All) is assigned.
(because this wouldn't work for delete device) see link

Instead i have to assign the Azure AD Role "Cloud Device Administrator" to the Enterprise Application.
So there is no user that has the additional permission, to check against.
The application just "owns" the permission.
Jens Breidenstein 21 Reputation points

2022-12-10T21:02:01.6+00:00
(2/2)

The concern I have is the default configuration ("assignment required" = no), that allows any user to use the Enterprise Application.
And we have quite a lot Enterprise Applications that have this enabled - because it is the default configuration.
And some of those Applications have Role Assignments instead of API permissions. :(

My Assumption:
If i would use any arbitrary user to generate a valid token, this user also would have the permission of the App.
In this case the user would have "Cloud Device Administrator" permission - no matter what permission he/she would have assigned to in the first place.
Because there is no check like in the API permissions.

For the DevOps example:
The user would have contributor permission on the ressources, the Service Principal has access to.
No matter, if it would have it.

It seems to me that the additional check against the user permissions is not implemented to Role Assignments to the Enterprise App.

Practical Check
I would like to check this with an example.
However, i don't have the knowledge to use User Authentication with a custom Service Principal.
This is not implemented in the MG-Graph Module by Microsoft.

The implementation of MG-Graph only implements

Application Authentication via secret/certificate or

User Authentication against the default "Microsoft Graph Powershell" Enterprise App
But it should be possible with User Authentication against any Enterprise App - i expect.

Jens
Vasil Michev 119.5K Reputation points MVP Volunteer Moderator

2022-12-11T16:10:45.197+00:00

Again, that's not how delegate permissions work. Even if the SP itself has been assigned an Azure AD admin role, a token obtained in the context of a given user will not reflect such roles. You can easily verify this by obtaining a token and decoding it. The "scp" claim will contain the API permissions granted, whereas the "wids" claim will contain the roles.
It's worth also comparing the claims between a token obtained in the delegate model and one obtained in the application permissions model (where you will see the "roles" claim instead of "scp"). In particular, you will see that an AAD role assigned to the SP will only be returned in the second scenario.
The claims mentioned above is what applications/resources should be examining in order to make authorization decisions. Now, I cannot guarantee that there isn't a single app that has failed to follow the guidelines, but at least for first-party Microsoft apps, you should be safe.

If you want to test it yourself via the Graph PowerShell module, use the -AccessToken parameter to pass a token obtained in the context of your test app. Or, just test it via direct Graph API query.
Jens Breidenstein 21 Reputation points

2022-12-12T05:24:40.19+00:00
Hi michev,

thanks for your patience.
slowly it's dawning what you mean.

In my words:
If I login as a user, the claims in the token will always contain the information of the user.
So even, if the SP has different and higher permissions, the permission level of the user is still visible.
The token will basically contain:

user permissions (claims)

SP permissions (claims)

If the authorization mechanism of the service is checking all information properly and
ensures that the user permissions is taken care of, everything is fine.

correct?

I still have a understanding issue with "Directoy.AccessAsUser.All" and then assigning the Azure AD Role and in other scenarios it is not done.
But this is all just additional information in the token, which is helping the service to make the correct authorization decision.

correct?

Jens

Share via

DevOps: Azure Enterprise Application - login via Secret vs. interactive -> Security Issue?

0 additional answers

Your answer