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.
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.
I am creating an API client for Azure Compute. I want the ability to start/stop/restart my Azure virtual machines.
In the past when I've created apps using the Graph API, I created a new app registration and then gave the app permissions for the actions I wanted under 'Microsoft Graph API' permissions list.
However, I cannot find Azure Compute listed in the available Microsoft APIs. I'm confused as to what I need to do in order to get API permissions for Azure compute as opposed to some of the other APIs.
I've spent the morning searching for tutorials or example implementations to look through, but combinations of Azure/Compute/API/permissions/etc... don't seem to ever come up with the results that I'm looking for.
Has anyone done something like this? Is it possible to use application permissions for Azure compute or is it entirely separate? Will it require a service account instead?
However, I cannot find Azure Compute listed in the available Microsoft
APIs. I'm confused as to what I need to do in order to get API
permissions for Azure compute as opposed to some of the other APIs.
The API you're looking for is Azure Service Management.
Once you add this delegated permission, you will be able to perform operations on your Virtual Machines provided your Service Principal is assigned an appropriate role (Virtual Machine Contributor, for example) in an Azure Subscription.
You can assign the App an RBAC role as though it were a user that you were giving permission to restart VMs. For example, you could go to the resource group that contains the VM, then go to Access Control (IAM) -> Add Role Assignment -> Add the app registration to the Contributor role.
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.
In my azure account I have 2 directories, lets call them directory A and B.
With some recent changes I need to switch a app service from a subscription in directory A to a subscription that is on directory B.
Is this possible to achieve, and if it is how?
EDIT 1
As directory I mean the directory that you can see in the image below:
EDIT 2
Since It seems that I have mislead people I will try to explain what i want to achieve with images.
I want to move the App Service from the App Service Plan in the directory A as you can see in here:
to the App Service Plan in the directory B that you can see in here:
It looks like you want to move resources between subscriptions. It is possible to do this but there are a few restictions and rules around what you can do.
You can definitely move an App Service between subscriptions. However, in your case, as the subscriptions in question exist in different AD tenants, you will need to change the tenant of one of the subscriptions. You can only do this if you are a Service Administrator and signed in using a Microsoft i.e non organizational account.
Check this reference document from Microsoft, it explains in detail how the transfer process works.
I think we might need some additional information, since it seems that the terms we're using are sometimes equivocal. Microsoft Azure subscriptions are not associated to Azure Active Directories, but to an Service Account. You can add how many Azure ADs you want to an Azure subscription, but the Azure subscription itself will be managed by the service account (which is not necessarily member of a certain Azure AD).
Further, only the service administrator can manage Azure resources, like VMs, App Services and so on. Azure AD admins can only manage identity aspects that define identity life cycles within that specific Azure AD. The service admin could add a co-admin a user from the default Azure AD and that user would then also be able to manage Azure resources, like App Services and so on.
So the Azure App Service is tied to a Azure subscription that is managed by a service account, not by the Azure AD. Please check the official documentation on this topic. Also please clarify exactly what you would like to do.
Ive created a website in Azure and I want to allow users to login and use the app, but im slightly confused by azure active directory access. I want users to only have acces to the web app, not to the portal. Users will be from within my organisation and from outside it so its vitally important that access is locked down, If a user somehow ends up at the azure portal they must not be able to access it. If I set users up in our active directory, wont they be able to login to the azure portal too ? I want to take advantage of authentication as a service and hand over authentication and multi factor authentication to azure but everytjhing Ive read so far seems to suggest If i use azure active directory, users will be able to acess the Azure portal too, is this correct or am i misinterpreting the information ? Are there any step by step guides available for these sorts of scenarios ?
If i use azure active directory, users will be able to acess the Azure
portal too, is this correct or am i misinterpreting the information ?
No, your users will not have access to Azure Portal (rather Azure Subscription as Azure Portal is an application using which a user manages one or more Azure Subscriptions) unless you grant them permission to access it. In order for your users to have access to Azure Portal, you would need to grant them permissions explicitly to do so. In the new portal, you do it by assigning roles (e.g. Owner, Contributor, Reader etc.) and in the old portal you do it by making them co-administrators.
Unless you do this, when they login into Azure Portal all they will see is a message stating no Azure Subscriptions were found.