Understanding the Azure Service Principal - azure

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.

Related

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

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.

Trying to scale Azure SQL DB using MSI for identity not autharised to perform action

I am creating my first app function using powershell in the Azure portal, It's just to scale a SQLDB on I have tried to use this tutorial as a guide.
MSI example
I turned on MSI for the function and configured resources groups Giving the contributor role to the resource
When I run the function within the portal, I get the message doesn't have authorization to perform action. from this tutorial I believe this is all I had to do ? I have waited over a day to see if it's a timing issue, from the example I Have followed and this MS document managed identies for app service
I don't believe I need to add any secret key for this to work?
Function Error message
Setting the function MSI identity to on
Seeting the access control in
The service principal you are using doesn't have rights within that tenant.
Tenants have subscriptions and service principals belong to tenants. Azure resource manager also exposes role based authorization for a given principal, which would give it rights on Azure resources. It appears the service principal doesn't have rights to read from that subscription.
Go to portal and find your subscription, click on Access Control (IAM) and then click on Add role assignment with correspond service principal which you use to acquire token.
After you have given successful permission, refresh and try again.

Security Implications of Azure AD App Registration

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.

How to grant subscription access to an azure registered application?

I am trying to set up octopus to deploy resources to azure.
Under azure active directory I've added a new app registration, and have generated a key and hooked up octopus with the correct Application ID, Tenant ID and key
The organisation has multiple azure subscriptions corresponding to the environments, so I've noticed if I use the Subscription ID of my "Visual Studio Professional MSDN" subscription it works and creates the resources, however if I try to use any of the other organisation Subscription IDs I get the following error:
Login-AzureRmAccount : The provided account c0b2.......76a6 does not
have access to subscription ID "f06.......2aa3". Please try logging in
with different credentials or a different subscription ID.
I have looked through all the settings of the Application Registration and granted it every "Windows Azure Active Directory" permission available, but still no luck.
How do I go about granting permissions to this Application Registration so that it can access the relevant subscriptions?
You need to give the app a role on the subscription/resource group/resource you want it to be able to access.
So for example, you can go to the Access Control (IAM) tab of the subscription, and give the app the Contributor role, which allows the app to read and modify anything in the subscription.
You can also give a more limited role if desired.
Roles can also be applied at a lower scope, like a resource group.
More info in the docs: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal

Application Authorization for Registering App and Creating Groups - Azure AD

I have a Java application running on premise in order to manage Azure app registrations and groups. For that purpose I registered an app and its service principle in Azure. I am using one of the samples under (https://github.com/Azure-Samples/aad-java-manage-users-groups-and-roles/). I am having trouble about giving right permissions to my app so that it can register other apps, create groups, assign them to groups and do client secret operations. I am receiving 403 unauthorized response. What are least possible Azure AD permissions for these operations? Which steps and options should I take/follow to implement that requirements in portal?
Thanks
UPDATE 1
Giving owner right is a big move. So that's not the answer I was looking for. That's why I am not marking it as a solution for my question but that would definitely work if you are willing to do that. Code also works.
Part of my question was least possible permissions. After experimenting I found that in app permissions:
Windows Azure Active Directory->Read Write Directory Data
Windows Azure Active Directory->Read Write All Applications
Microsoft Graph->Read Write Directory Data
Microsoft Graph->Read Write All Domains
Microsoft Graph->Read Write All Groups
solved the problem. Active Directory ones allowed me to create app and create group, graph ones allowed me to add app to group. Instead of Graph, adding app as User Access Admin also let me the app to group.
UPDATE 2
I am trying to repeat same process with another app. This time although I gave same permissions as I did in Update 1 this time adding new app to group fails with 403. Any idea how this really works? I am really confused...
You need create a service principal and give it Owner role to your subscription. You could check the code, the new created user is gived CONTRIBUTOR to your subscription. So, your sp need Owner role.
// Assign role to AD user, it needs `Owner` role.
RoleAssignment roleAssignment1 = authenticated.roleAssignments()
.define(raName1)
.forUser(user)
.withBuiltInRole(BuiltInRole.READER)
.withSubscriptionScope("3b4d41fa-e91d-4bc7-bc11-13d221b3b77d")
.create();
System.out.println("Created Role Assignment:");
You could do it on Azure Portal.
<your subscription>--><Access Control>--><Add>.
More information about this please refer to this official document.
Update:
I test in my lab, you don't need give your sp Graph permission, you only need give your sp your subscription Owner role. This is my test result.

Resources