application assignments azure

The challenge

Preferably, role assignments are automated through privileged release pipelines.  The two PowerShell commands that can be used to automate this – New-AzureADServiceAppRoleAssignment and New-AzureADUserAppRoleAssignment – are not easy to use, as it is not always clear what the exact Ids are that you have to provide.

The solution

That’s why I prefer to automate this based on display names and let a script take care of fetching the required Ids. Lately, I have developed such a script to assign Azure AD application roles to users and applications.  Hereby, I share it with the community.  The script can be found in this gist .

Config file

The script is driven by a simple config file , that contains a JSON array of role assignments:

• description : free text field that describes the role assignment
• client_type : “user” or “application”
• client_principal_name:  the users’ UPN ([email protected]) or the display name of the service principal (enterprise application)
• server_app_registration_name : the display name of the app registration to which you want to grant the client access
• role_name the display name of the application role you want to assign to the configured client

You can use the script like this:

• Download the script and the config file.
• Update the config files to your needs
• Trigger the script via PowerShell

If you are interested, this is how the script looks like:

I hope that this script helps you to accelerate your security automation.

Cheers Toon

UPCOMING TRAININGS

CHECK OUT OUR TRAININGS

Azure Integration Services

Azure migration.

• Azure Governance

Azure Security

Azure foundations, recent posts.

• Azure Service Bus vs Event Grid Pull Delivery
• Trying the new Microsoft Applied Skills
• Finally a correct way to configure RBAC for DevOps agents!
• What do the new API Management v2 tiers mean for you?
• Validate payloads in Azure API Management
• Announcement
• API Management
• Architecture
• Azure App Service
• Azure Data Factory
• Azure DevOps
• Azure Event Grid
• Azure Functions
• Azure Kubernetes Service
• Azure Policy
• Azure Resource Graph
• Azure Resource Manager
• Azure Service Bus
• Azure Stream Analytics
• BizTalk Server
• Container Apps
• Geen categorie
• Home Automation
• Microsoft Learn
• Service Bus

MEET THE YOUR AZURE COACH TEAM

Your Azure Coach is specialized in organizing Azure trainings that are infused with real-life experience. All our coaches are active consultants, who are very passionate and who love to share their Azure expertise with you.

Toon Vanhoutte

Azure integration services & serverless.

Wim Matthyssen

Azure infra, security & governance, azure development and ai/ml, azure identity and security, stéphane eyskens, cloud-native azure architecture, geert baeke, azure kubernetes service & containerization, maik van der gaag, azure infrastructure as code & devops, bart verboven, sammy deprez, azure ai, ml & cognitive services, sander van de velde.

Entra ID Application Key Concepts & Background

Most of the content here is also represented at https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-how-applications-are-added . Because everyone learns information slightly differently, you may find one or the other easier to understand.

Terminology

Microsoft has a few terms which can be a bit confusing if you don’t understand what they mean:

• Entra ID Application : an identity intended to be used by an application with a bit of configuration about how that identity can be used. The fact that Azure is in the name does not designate where the software lives but that the application will only trust sign on tokens issued by Entra ID. The fact that application is in the name does not imply that this is a software platform for development or hosting.
• Application object : This is the single, definitive object with configuration details, and is only present in one Entra ID tenant. Think of it as the template by which many instances of this application might be created from.
• Service Principal object : This is a working instance of the application. This object will contain operational configuration information specific to this instance of the application and is linked to the application object.
• Enterprise application : This is a location in the Azure Portal where you can manage service principals. It is also the only location from which pre-integrated 3rd party SaaS applications in the Entra ID application gallery can be created (the application object does not exist in the UW tenant). The creation of service principals from this location can only be done by UW-IT.
• App registration : This is a location in the Azure Portal, where you can create and manage application objects (in the UW tenant). Anyone with a UW Microsoft account can create an application object, and a service principal is automatically created at the same time.

Entra ID Application Concepts

• There are many meanings of the word “application.” When we talk about an Entra ID Application, we are talking about something very specific. An Entra ID Application is a digital identity and some associated configuration which informs Entra ID about how to treat software which uses that digital identity. The software itself may be running anywhere, on any platform, written in any language. To be more specific, if software needs to request Entra ID logon tokens or consume Entra ID logon tokens, then it must be an Entra ID application. The software might have other digital identities it uses, but that topic isn’t covered here.
• An object of type application. This is the core digital identity with the basic required configuration details, and is only present in the Entra ID application’s home tenant.
• One or more objects of type service principal. This object will be present in each tenant which has an instantiation of the Entra ID application, except the Entra ID application’s home tenant. This object will have the specific role assignments and user consent permissions granted for that tenant. Note: An Entra ID application’s instantiation in a given tenant is the service principal object–but that service principal references the “primary” Entra ID object of type application that lives in one and only one tenant. You can read more about these Entra ID objects here .
• User consent. The end user is presented with a list of permissions the Entra ID application would like, if you agree to grant them. If the user does not consent, then they can not use the application.
• Admin consent. The tenant admin is presented with a list of permissions the Entra ID application would like. Admin consent is required if the required application permissions are broader in scope than what an individual user can grant for themselves. If admin consent is required, then no user can use the application until admin consent. Optionally a tenant admin can provide the user consent decision on behalf of all users. In this case, the end user never sees the user consent dialog.
• An Entra ID application instance will record all consent permissions granted within that tenant related to itself (on the service principal object).
• Application permissions are those which are used solely by the application identity itself. You use these type of permissions for a non-interactive application that is doing work without a human interacting with that application. Application permissions require admin consent because there is no user consent experience by design.
• Delegated permissions are those which require a user to interactively sign into the application. The user consents to the permissions, which authorizes the application to act on behalf of the user with the permissions which that user has consented to. If an admin consents to delegated permissions then users don’t consent.
• Entra ID Applications come in two fundamental flavors–confidential clients and public clients. Confidential clients need to authenticate as themselves, so must have credentials–these are typically web apps or code used to programmatically leverage the API of another Entra ID application. Public clients do not need to authenticate as themselves and typically represent native clients broadly distributed on many devices. So the key differentiator here is whether the application needs to get a logon token for itself–and that is usually dependent on whether it needs to access another Entra ID application. Most Entra ID Apps will be confidential clients. Note: public clients do not have a service principal in each tenant–they are only ever present in the developer’s tenant. If you’d like to explore public clients further, you might review the ‘Native Application to Web API’ section of https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/ .
• If an Entra ID Application needs a credential, then it has two options–a password or a cert. See more here .
• An Entra ID application may define whether it is available to other tenants.
• An Entra ID application must define what permissions to other Entra ID applications it needs. To only authenticate other users, you do not need any permission, but if you need to include name or other basic data in the user experience, then you will likely need User.Read, i.e. the ability to read the profile of an Entra ID user who has logged into your application. You can read more about permission scopes, including the permission scopes that Entra ID itself has available at https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes .
• An Entra ID application may define permission scopes that can be granted to other Entra ID applications. This is optional.
• Each app may define roles which users can be assigned to. This is optional. Each Entra ID application instance will record any role assignments.
• Each Entra ID application instance may require assignment of users or groups to be able to access to the app. This is optional. Note that if assignment is required, a basic role is created even if the application doesn’t define any roles.
• Each app can have owners defined, but they are not represented in the roles property. Application Owners have a broad set of permissions.
• An Entra ID application records the URIs that tokens it requests are issued to. A given Entra ID application may have many valid URIs. You might imagine using the same Entra ID application for a production, pre-production, and development instance of the code behind your Entra ID application, each with their own distinct URI. Or you can create a separate Entra ID application for production, pre-production, and development purposes.

• WHY WORK HERE
• We solve tough problems for organizations big and small. As a trusted partner to international brands, small firms, and colleges/universities, we need top-notch people to do what we do.

• We offer customized cybersecurity solutions in security, identity & access, compliance, and mobility and DaaS to help you stay ahead of an ever-evolving threat landscape.
• GET STARTED WITH OUR AD HEALTH CHECK

• In Sync: Proper Time Configuration in AD
• Identity & Access
• Mobility & DaaS
• Explore our resources for advice on boosting your organization's security.
• Stay up-to-date — read our experts' unique takes on trends in cybersecurity.

• Improving Entra ID B2B User Management with Cross-Tenant Synchronization
• Our experts are always ready to discuss your needs – whatever stage you’re at – and with no obligation.
• AD HEALTH CHECK
• We enhance your AD and improve its security with our holistic health assessment.

How to Effectively Manage Microsoft Intune Application Assignments with PowerShell and the Microsoft Graph API

• May 6, 2021
• Blog , Security

Tony Brzoskowski

In large-scale Microsoft Intune deployments, you’ll typically find both production and development tenants. For effective application testing, you’ll need to assign your applications to test groups of devices or users. Performing this process manually can be time-consuming and repetitive. To simplify the mass addition of a group for application deployment, you can leverage the  Intune PowerShell SDK .  

Connecting to Intune PowerShell  

Download the  Intune PowerShell SDK  and follow the configuration steps in the “Getting started” section of the documentation. As of this writing, high-level steps for configuration are: 

• Install the Microsoft.Graph.Intune module. The module can be installed in a few different ways, but the easiest method is from the PowerShell Gallery via:
• Perform admin consent for the module. After installation, you’ll be prompted to consent to the tools to access your Azure and Intune environments. You’ll need an account with the appropriate roles to approve consent. 
• Run the Connect-MSGraph command. When connecting, you’ll be prompted for Intune administrator credentials. 

Scripting Application Assignments 

Next, you’ll need to retrieve a list of all Intune applications. If Win32 applications are part of your desired pool, you’ll need to connect to the MSGraph beta schema: 

To retrieve all applications: 

Next, define the group you want to apply: 

Once you have all the applications, you need to limit the scope of which applications you’ll be updating. In the lab environment, applications are assigned to groups of collections. 

The following code searches for a known group ID that will be the target modification pool. If you want to deploy to all applications, you can remove the  if  statement from the snippet. 

Similarly, if you need to remove a group from a set of applications, you can find the group that needs to be removed: 

Next, cycle through all the applications and remove that group: 

Note that the new group will retain the same “intent” as the referenced group (e.g., Required). 

Automate More Tasks 

The Microsoft Graph API and the Intune PowerShell SDK can be daunting to navigate. The number of tasks you can complete with the Graph API is growing almost daily. Managing application assignments with the Graph API is just one example. The Graph API is also a foundation for automating more tasks with Intune and Microsoft 365.  

Need help with your Intune deployment or using the Microsoft Graph API?  Contact  the experts at Ravenswood Technology today! 

[RELEVANT BLOG CONTENT]

Highly Available, Secure, and Convenient: Leveraging Azure Blob Storage for your PKI Needs, Part 1

For as long as public key infrastructure (PKI) has existed, it has relied on certificate revocation lists (CRLs) and authority information access (AIA). CRLs are

Three Reasons to Use Azure Automation to Run Your Scripts 

Azure Automation is a cloud-based service that can help you run scripts; configure, update, and manage operating systems; and manage your IT asset inventory. This

An Introduction to Protected Actions in Conditional Access

The Microsoft Azure portal includes a subset of permissions called protected actions, which can be used to manage Conditional Access (CA) policies and cross-tenant access

Windows 365 Boot and Switch: Building a Solid Foundation

In the ever-evolving landscape of digital workspace solutions, Windows 365 emerges as a cloud-based PC deployment solution tailored for organizations seeking enhanced security and centralized

6 Tips to Harden Your Windows LAPS Deployment

In a previous blog post, we covered how to migrate to Windows Local Administrator Password Solution (LAPS). With Windows LAPS deployments gaining traction, it’s important

Use Privileged Access Workstations to Increase Security

All organizations use privileged accounts to manage their environments. In many cases, administration is performed from productivity workstations, which are vulnerable to a substantial number

Active Directory: The End of the Road? Not Quite Yet!

Microsoft announced several enhancements to Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS) that are included in the preview

Migrating to Windows LAPS

Windows Local Administrator Password Solution (LAPS), now integrated into the OS, is the replacement for Microsoft LAPS, which was a separate installation. Windows LAPS is

Leave a Comment Cancel Reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Ravenswood Technology Group is based in Chicago, IL but with customers around the world. We help companies, universities, and other organizations with less than 100 employees to over 500,000 build secure, hybrid infrastructure that enable their users to work from anywhere. 

[What we do]

• Identity & Access

[Recent Blog Posts]

How to Sync Time in Active Directory

[Expertise]

• Active Directory Health Check
• Azure Government & Office 365 Government – GCC High
• Microsoft Entra ID
• Microsoft Sentinel

[Get in Touch]

© Ravenswood Technology Group, LLC

A Cloud Guy

Azure, M365, AWS and IT in general

Azure AD – Assign Groups and Users to an application

Azure AD allows granting access to resources by providing access rights to a single user or to an entire Azure AD group. Using groups let the application or the resource owner to assign a set of permissions to all the members of a group. Management rights can be granted to other roles, like example., Helpdesk administrators to add or remove members from the group.

When a group is assigned to an application, only users in the group will have access. Also, if the application exposes role, roles can also be assigned to groups or users.

When I was working on integrating Salesforce with Azure AD for SSO, I needed to assign groups to the roles that Salesforce exposed and I figured I’d document the process I went though here.

Table of Contents

Bulk create Azure AD groups

This section describes how to create multiple groups in Azure AD. This is not needed if your organization already has groups created.

Use below script to create multiple Azure AD groups that are listed in a csv file,

csv file input,

PowerShell output,

Assign Groups and Users to an app using PowerShell

Assigning groups or users can be done from the Azure AD admin portal by clicking on the Users and groups tab in the application which you are granting access to.

My plan here is to create Azure AD groups that corresponds to the name of the role that Salesforce exposes and then add users to those groups which provides them with appropriate access to the application.

Determine the roles available for the application

To determine the roles that the application exposes, use the cmdlet below.

Assign Groups to Roles in Application

Use below script to assign the application’s roles to groups. If you notice the csv file, I’m using the groups created in the previous step to the roles. This way, it is easier to manage. The New-AzureADGroupAppRoleAssignment cmdlet can be used to achieve this.

This below is how the application looks like in the Azure AD admin portal after running the above script,

Assign Users to Roles in Application

Use below script to assign the application’s roles to users. This can be achieved using the New-AzureADUserAppRoleAssignment cmdlet. Use the below script,

Get all role assignments to an application using PowerShell

Get-AzureADServiceAppRoleAssignment cmdlet can be used to determine all role assignments to an application,

Remove All Groups and Users assigned to an application

To remove all assigned groups and users from an application, Remove-AzureADServiceAppRoleAssignment cmdlet can be used,

It should go without saying that removing all permissions will disable user’s access to the application. Don’t try this as a first step in a production environment, unless you are absolutely sure of it.

Thank you for stopping by.✌

1 thought on “Azure AD – Assign Groups and Users to an application”

• Pingback: Implement Azure AD SSO integration with Salesforce – A Cloud Guy

Leave a Comment Cancel reply

Save my name, email, and website in this browser for the next time I comment.

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Azure Managed Applications overview

• 6 contributors

Azure Managed Applications enable you to offer cloud solutions that are easy for customers to deploy and operate. As a publisher, you implement the infrastructure and can provide ongoing support. To make a managed application available to all customers, publish it in Azure Marketplace. To make it available to only users in your organization, publish it to an internal service catalog.

A managed application is similar to a solution template in Azure Marketplace, with one key difference. In a managed application, the resources are deployed to a managed resource group that's managed by the application's publisher or by the customer. The managed resource group is present in the customer's subscription, but an identity in the publisher's tenant can be given access to the managed resource group. As the publisher, if you manage the application, you specify the cost for ongoing support of the solution.

The documentation for Azure Custom Providers used to be included with Managed Applications. That documentation was moved to Azure Custom Providers .

Publisher and customer permissions

For the managed resource group, the publisher's management access and the customer's deny assignment are optional. There are different permission scenarios available based on publisher and customer needs for a managed application.

• Publisher managed : Publisher has management access to resources in the managed resource group in the customer's Azure tenant. Customer access to the managed resource group is restricted by a deny assignment. Publisher managed is the default managed application permission scenario.
• Publisher and customer access : Publisher and customer have full access to the managed resource group. The deny assignment is removed.
• Locked mode : Publisher doesn't have any access to the customers deployed managed application or managed resource group. Customer access is restricted by deny assignment.
• Customer managed : Customer has full management access to the managed resource group and the publisher's access is removed. There's no deny assignment. Publisher develops the application and publishes on Azure Marketplace but doesn't manage the application. Publisher licenses the application for billing through Azure Marketplace.

Advantages of using permission scenarios:

• For security reasons, publishers don't want persistent management access to the managed resource group, customer's tenant, or data in managed resource group.
• Publishers want to remove the deny assignment so that customers manage the application. Publisher doesn't need to manage the deny assignment to enable or disable actions for the customer. For example, an action like rebooting a virtual machine in the managed application.
• Provide customers with full control to manage the application so that publishers don't have to be a service provider to manage the application.

Advantages of managed applications

Managed applications reduce barriers to customers using your solutions. They don't need expertise in cloud infrastructure to use your solution. Depending on the permissions configured by the publisher, customers might have limited access to the critical resources and don't need to worry about making a mistake when managing it.

Managed applications enable you to establish an ongoing relationship with your customers. You define terms for managing the application and all charges are handled through Azure billing.

Although customers deploy managed applications in their subscriptions, they don't have to maintain, update, or service them. But there are permissions that allow the customer to have full access to resources in the managed resource group. You can make sure that all customers are using approved versions. Customers don't have to develop application-specific domain knowledge to manage these applications. Customers automatically acquire application updates without the need to worry about troubleshooting and diagnosing issues with the applications.

For IT teams, managed applications enable you to offer preapproved solutions to users in the organization. You know these solutions are compliant with organizational standards.

Managed applications support managed identities for Azure resources .

Types of managed applications

You can publish your managed application either internally in the service catalog or externally in Azure Marketplace.

Service catalog

The service catalog is an internal catalog of approved solutions for users in an organization. You use the catalog to meet organizational standards and offer solutions for the organization. Employees use the service catalog to find applications that are recommended and approved by their IT departments. They can access the managed applications that other people in their organization share with them.

For information about publishing a managed application to a service catalog, see Quickstart: Create and publish a managed application definition .

Azure Marketplace

Vendors who want to bill for their services can make a managed application available through Azure Marketplace. After the vendor publishes an application, it's available to users outside their organization. With this approach, a managed service provider (MSP), independent software vendor (ISV), or system integrator (SI) can offer their solutions to all Azure customers.

For information about publishing a managed application to Azure Marketplace, see Create an Azure application offer .

Resource groups for managed applications

Typically, the resources for a managed application are in two resource groups. The customer manages one resource group, and the publisher manages the other resource group. When the managed application is defined, the publisher specifies the levels of access. The publisher can request either a permanent role assignment, or just-in-time access for an assignment that's constrained to a time period. Publishers can also configure the managed application so that there's no publisher access.

Restricting access for data operations is currently not supported for all data providers in Azure.

The following image shows the relationship between the customer's Azure subscription and the publisher's Azure subscription, which is the default publisher managed permission. The managed application and managed resource group are in the customer's subscription. The publisher has management access to the managed resource group to maintain the managed application's resources. The publisher places a read-only lock (deny assignment) on the managed resource group that limits the customer's access to manage resources. The publisher's identities that have access to the managed resource group are exempt from the lock.

The management access as shown in the image can be changed. The customer can be given full access to the managed resource group. And, the publisher access to the managed resource group can be removed.

Application resource group

This resource group holds the managed application instance. This resource group may only contain one resource. The resource type of the managed application is Microsoft.Solutions/applications .

The customer has full access to the resource group and uses it to manage the lifecycle of the managed application.

Managed resource group

This resource group holds all the resources that are required by the managed application. For example, an application's virtual machines, storage accounts, and virtual networks. The customer might have limited access to this resource group because unless permission options are changed, the customer doesn't manage the individual resources for the managed application. The publisher's access to this resource group corresponds to the role specified in the managed application definition. For example, the publisher might request the Owner or Contributor role for this resource group. The access is either permanent or limited to a specific time. The publisher can choose to not have access to the managed resource group.

When the managed application is published to the marketplace , the publisher can grant customers the ability to perform specific actions on resources in the managed resource group or be given full access. For example, the publisher can specify that customers can restart virtual machines. All other actions beyond read actions are still denied. Changes to resources in a managed resource group by a customer with granted actions are subject to the Azure Policy assignments within the customer's tenant scoped to include the managed resource group.

When the customer deletes the managed application, the managed resource group is also deleted.

Resource provider

Managed applications use the Microsoft.Solutions resource provider with ARM template JSON. For more information, see the resource types and API versions.

• Microsoft.Solutions/applicationDefinitions
• Microsoft.Solutions/applications
• Microsoft.Solutions/jitRequests

Azure Policy

You can apply an Azure Policy to audit your managed application. You apply policy definitions to make sure deployed instances of your managed application fulfill data and security requirements. If your application interacts with sensitive data, make sure you've evaluated how that should be protected. For example, if your application interacts with data from Microsoft 365, apply a policy definition to make sure data encryption is enabled.

In this article, you learned about benefits of using managed applications. Go to the next article to create a managed application definition.

Quickstart: Create and publish an Azure managed application definition

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources