I'm referring to the Azure documentation on Application and service principal objects in Azure Active Directory.
I would like to understand the security implications of allowing users to register an application in Azure AD.
I couldn't find any documentation that explained who and who should not have the permission to do so and for what reason.
More specifically the use case is letting the owner of an Azure subscription create an ARM Service Connection in Azure DevOps. This implies registering an app in Azure AD (for this service connection).
So my question is: are there any good reason to deny the owner of an Azure subscription the permission to register applications in Azure AD?
What are the general risks or security considerations?
Only a subscription owner can define IAM for a service principal (service connection), just because you can create them it's useless without the right permissions.
But.....
If you keep on creating principals with the similar names (not following any form of naming conversion) you are very close to making a human error by giving a wrong service principal unwanted access. This can lead to potential security incidents.
Also, as an admin you will have a lot of unused 'junk' service principals in your directory. Cleanup becomes very hard with cowboy developers -demanding for them to be retained.
Related
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
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
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.
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
I'm looking for my VSTS deployment agent service principal to get the Object ID of a managed service principal (created by Data Factory V2).
It needs this for assigning ACL's in data lake store.
However as far as I can tell, it requires Read Permission on Azure AD.
I wish to avoid granting it read permission if possible, to follow the 'least privilege' mantra.
For non-managed service principals, I allow the deployment agent to manage service principals it has created (thus not needing full read access). However I suspect the fact that the service principals are managed by Azure it is unlikely I'll be able to give the deployment agent any ownership over the managed service principal (however I'm working with AD admins to see if there is a way).
I've tried everything I can think of mixing and matching Azure RM data factory v2 powershell modules and Azure AD modules.
Is it possible to get the id without Azure AD read access? Or a novel workaround (I'm considering a constrained Web API wrapper)?
I'd like to create a service principle to allow deployments to one or more of my resources under my subscription.
I have an MSDN subscription allowing me £40 a month on Azure.
The Azure Active Directory is maintained by my company.
I am set as a general user
I've already created a service principle with a key via the portal.
When I try to connect via the SP from Octopus Deploy I get the below message:
Unable to verify Azure Account: The client 'xxxx' with object id
'xxxx' does not have authorization to perform action
'Microsoft.Resources/subscriptions/resourcegroups/read' over scope
'/subscriptions/xxxx'.
As I now understand it, an SP sits at tenant level. So does this mean that I likely don't have any permissions to create an SP with the proper access to do what I need and I'll have to get an Admin to do it?
I'm struggling to understand this authentication method tbh. So any information to help clarify how this all fits together would be very much appreciated.
e.g.
Can I limit an SP to just my MSDN subscription?
Can I even limit it to resource groups / resources?
...
In terms of permissions Service Principal doesnt differ from a regular user. Your service principal doesnt have access to that particular subscription. You need to grant those rights to the service principal. You can use portal\powershell\cli\SDK to do that. Sample link.
I tried to find some information which application permission is necessary for a service principal to create another AAD applications / service principal but didn't find a least privilege setup.
Currently I assign the SP some directory roles like Directory Writers which probably is to much?
Does anybody know which application permission the SP needs to create another SP? Or does the SP needs directory roles?
If your app creates applications and then creates principals for them, then the Application.ReadWrite.OwnedBy application permission on the Azure AD Graph can do that.
It does not allow the app to create service principals for other applications though. That requires quite big app permissions as you noticed.