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

Question

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 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 App, 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

Answer 1

Yes, the SPN can manage the resources within the resource group if it has Contributor - it is no different than a normal (human) identity. Consider if the SPN actually needs Contributor or if you can limit it with another role or even make a custom role. Furthermore, monitor the sign-ins using the Azure AD sign-in logs:

• https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-all-sign-ins

You can also use CanNotDelete resource lock, which means that the service principal cannot delete resource as it is only Contributor:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json

You might want to look into the Conditional Access to strengthen your environment:

• https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identities-overview
• https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/workload-identity
• https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-create-azure-ad-roles-and-resource-roles-review

Take a look here:

• https://infosecwriteups.com/a-lab-for-practicing-azure-service-principal-abuse-bd000e6c48eb
• https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/disable-user-sign-in-portal
• https://learn.microsoft.com/en-us/powershell/module/az.accounts/connect-azaccount?view=azps-9.3.0#example-3-connect-to-azure-using-a-service-principal-account

Answer 2

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

No. They would need the client secret or the rights to generate a new one. Which requires that they are owners of the App Registration. In the App Registration on the Owners tab it says:

The users listed here can view and edit this application registration. Additionally, any user (may not be listed here) with administrative privileges to manage any application (e.g., Global Administrator, Cloud App Administrator etc.) can view and edit the application registrations.