application assignment azure ad

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.

• Looking back at INTEGRATE 2024
• 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?
• 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.

Assign Users to Azure AD Application with PowerShell

Azure AD Enterprise Applications are a great way to connect third-party applications to your Azure Active Directory. Depending on your Azure AD plan you can assign either single users to an application or complete groups.

With Azure AD Plan 1 you can only assign users, not groups. So keeping your list with users up-to-date is a hideous task. Every time you add a new user to your Office 365 tenant you will need to add the user to the Azure AD application as well.

For example, if you want to integrate Jira Cloud with Azure AD. If you have Jira Cloud Access (Atlassian Cloud Access), you can connect it with your Azure Active Directory so that new users are automatically added to Jira.

Add users to Azure AD Application with PowerShell

To automatically assign new users to enterprise applications, we need to know the existing users and all the licensed users in our tenant.

Getting licensed users is easier with Msol services, but I want to run this script in an Azure Runbook. Authenticating Azure AD is a lot easier (and more convenient) than Msol services.

Tip If you want to know more about getting started with Azure Runbooks or Authentication in Runbooks, then make sure you read this article .

We are going to need the object id of the Azure AD Enterprise Application, the service principal to be exact. To get this, we can simply filter the AzureADServicePrincipal on the name of the application.

With the servicePrincial we can get all the users that has been assigned a role to the application:

We only want to add Office 365 users that have a license. If we don’t filter it, we will also get guest accounts for example.

The next step is to compare both lists that we have to get all the new users that we need to add:

So we now have a list of new users that are not assigned to the application. We can simply process this list and assign them a new role to the Azure AD Enterprise application:

I always try to use a try-catch block and output the results to a custom object. This way we can easily see what the script has done.

Wrapping Up

I have used this script in an Azure Runbook. You can find the complete script here at my Github that you can use in a runbook. Authentication is based on the Run As account of the Azure Automation account. You can find more info about that here .

If you have any questions, just drop a comment below.

You may also like the following articles

How to Get the Computer Name with PowerShell

The Best PowerShell Cheat Sheet

PowerShell Operators [Complete Guide]

21 thoughts on “assign users to azure ad application with powershell”.

It would be great if you could help me translate this script to the new Microsoft Graph Powershell.

Please check out this script https://github.com/ruudmens/LazyAdmin/blob/master/MsGraph/Add-UserToAzureApplication.ps1

Due to the deprecation of Azure RunAs Accounts, I have been attempting to update this RunBook for use with a Managed Identity. However, keeps throwing an error about not loading ‘IEFrame.dll’. Am I going about this the wrong way? What should I change? Thanks for your help!

Have you read this article ?

Rudy, I have a situation where I don’t want to add all the users to the application. These are service accounts and admin accounts, indistinguishable from other users but by ObjectId. I’ve now sort of solved it with an array of those ObjectId and an extra compare. Can it be solved more ellegant?

I do it pretty much the same way. An exclusion list (Array) and an extra comparison. The only other way to solve it would be to create an extra group in your AD with only actual users, and then get the users with Get-AzureADGroupMember

I know this is an older post. What do I need to change to run this on a local server instead of Azure Runbooks?

Only the authentication part. So remove

# Get the service principal connection details $spConnection = Get-AutomationConnection -Name AzureRunAsConnection

# Connect AzureAD # Check if Azure is installed and connect if ((Get-Module -ListAvailable -Name AzureAd) -ne $null) { Connect-AzureAD -TenantId $spConnection.TenantId -ApplicationId $spConnection.ApplicationID -CertificateThumbprint $spConnection.CertificateThumbprint | Out-null }else{ Write-Error "Please install AzureAd." }

And just log in manually to azure ad

Thank you for your insight into this! This simple script will save our client thousands in Azure licensing costs.

I used a runbook just like you recommended and it works great.

What part would I have to change to assign new users to a Microsoft Team automatically in the same way?

You will need to use the Add-TeamUser cmdlet for this.

Would this be simple enough to switch to a list of group names in a CSV?

If Get-AzureADServiceAppRoleAssignment also returns the group PrincipalId’s then you should be able to compare that against a CSV list with Import-CSV . Maybe combine it with Get-AzureADGroup to get the group object id.

Thanks for this guide. This is really helpful. But I’m just wondering how can we assign from .csv file?

Replace the $licensedUsers with :

# Or use CSV File $csvUsers = Import-Csv -Path C:\temp\azuread.csv

$users = @() $csvUsers | ForEach { $name = $_.name $users += Get-AzureADUser -Filter "DisplayName eq '$name'" | select ObjectId }

And then compare: # Compare lists $newUsers = $users | Where-Object { $_.ObjectId -notin $existingUsers }

Here is another scenario I am wondering about. What are the possibilities currently for automating the provisioning of an Azure AD account FROM a Jira ticket? (eg., HR creates a request for new employee onboarding and a new user must be created in Azure AD).

Well, you could create a Power Automate flow , that is triggered by the Jira trigger “When a new issue is created”. And then create an Azure Automation job that runs a PowerShell script.

Maybe a good idea to built in a approval request, so you can check the request before the user is created

Thank you very much!

can you help me to assign only Users with E3 Licenses to one of the Azure Enterprise Applications? With this command I can get my Users with E3 Licencse: Get-MsolUser | Where-Object {($_.licenses).AccountSkuId -match “ENTERPRISEPACK”}

You can simply replace this line with: $licensedUsers = Get-AzureADUser -all $true | Where-Object {$_.AssignedLicenses} | Select displayname,objectid # Replace with Get-MsolUser | Where-Object {($_.licenses).AccountSkuId -match “ENTERPRISEPACK”} | Select displayname,objectid

exactly what I looked for. So with a Azure AD Plan 1 only there is no other way than Powershell to automate user assignment e.g. via Azure AD configuration?

Thanks Mario

Yes, that is correct.

Leave a Comment Cancel reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

So, about that AdBlocker... Will you consider disabling it?

Yes, ads can be annoying. But they allow me to keep writing content like this. You can also support me by Buying Me a Coffee ☕ or visit the shop to get some Tech-Inspired merchandise | Read more about disabling AdBlockers

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.✌

Leave a Comment Cancel reply

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

Software Engineering

• ASP.NET Core
• Elasticsearch
• Entity Framework

Implement app roles authorization with Azure AD and ASP.NET Core

This post shows how to implement Azure AD App roles and applied to users or groups in Azure AD. The roles are used in an ASP.NET Core Razor page application as well as a ASP.NET Core API. The roles from the access token and the id token are used to authorize the identity which is authenticated.

Code: App roles

Create an Azure App registration for Web APP

In this example, a web application will implement authentication and will use a second ASP.NET Core application which implements the user API. Two Azure AD App registrations are created for this, one for each application.

The ASP.NET Core Razor page application is a client which can be authenticated, as well as the identity using the application. It has a trusted back end which can keep a secret. The Azure AD App registration uses a standard web application with a client secret. You could also use a certificate instead of a secret to authenticate the client.

App roles are added to the App registration for the UI client. These roles are used in the UI application which are returned in a user data profile request or in the id token, depending how your client implemented the OIDC standard.

Three roles were added to the Azure AD App registration using the App roles | preview blade.

The roles could also be added directly in the manifest json file.

The API permissions are setup to include the scope created in the API Azure AD App registration. The standard OIDC scopes are added to the registration. All scopes are delegated scopes.

Create an Azure App registration for Web API

The App registration used for the API implements NO authentication flows. This App registration exposes an API and defines roles for the API project authorization. An access_as_user scope is added to the Azure App registration which is a delegated scope type.

Three roles were added to the Azure AD App registration for the API. These roles are for the API and will be added to the access token if the identity has been assigned the roles in the enterprise application of the Azure AD directory. The roles could also be added directly in the manifest.

Apply roles in Azure AD enterprise applications

The new roles which were defined in the Azure AD App registration can now be used. This is setup in the Enterprise application blade of the Azure AD directory. In the Enterprise application list, select the App registration for the API. New users or groups can be added here, and the roles can then be assigned.

In the Add user/group a user or a group can be selected (! Groups can only be selected if you have the correct license) and the roles which were created in the Azure AD App registration can be applied.

If creating applications for tenants with lots of users, groups would be used.

Implement ASP.NET Core API

The API is implemented in ASP.NET Core . The startup class is used to setup the authorization of the access tokens. The Microsoft.Identity.Web Nuget package is used for this. This application configuration will match the configuration of the Azure AD App registration setup for the API. The AddMicrosoftIdentityWebApiAuthentication method is used for this.

ASP.NET Core adds namespaces per default to the claims which are extracted from the access token. We do not want this and so disable the default claim mapping. The roles and the name can should also be mapped, as the default setting does not match what Azure AD returns in the token.

Authorization is added for the API using the AddAuthorization method or it can be added global as a filter. The roles claims are mapped to policies which can then be enforced throughout the application. You could also do this directly using the roles property in the authorize attribute, but I prefer to use policies and separate the authorization. Only policies are used in the application.

A ValidateAccessTokenPolicy policy is implemented to do validation on the access token. The scp claim is validated for an access_as_user value as this is a user API for delegated access and not an application token. The azp claim is used to validate the client calling the API. The API is made specifically for the UI application and so we can validate that only access tokens created for the UI application can use this API. The azp claim is only sent in version 2 Azure App registrations. You must set this in the manifest.

The azpacr claim is also validated. Only authenticated clients can use this API. Any application which gets an access token for this API must use a secret as the value of “1” is controlled. This ensures that public clients cannot create access tokens for this API. If this was a value of “2”, only clients which used certificates to authenticate can acquire access tokens for this API.

It is good to validate the intended user, if possible.

Authorization can also be added globally as a filter in the AddControllers. This would be applied to this middleware.

The policies can then be applied in the API application as required. The access token used to access the API must fulfil all policies used on the API endpoint. If any single policy fails, the a 403 forbidden is returned.

Implement ASP.NET Core Razor Page APP

The ASP.NET Core Razor Page application uses an OIDC interactive flow to authenticate using Azure AD as the identity provider. Both the client application and the identity are authenticated. Microsoft.Identity.Web is used to implement the client code which uses Open ID connect. The AddMicrosoftIdentityWebAppAuthentication method is used in the Startup class in the ConfigureServices method. The downstream APIs are enabled as well as in memory cache. In memory cache is a bit of a problem with testing, as you need to delete the cookies in the browser manually after every test run. You can fix this by using a persistent cache. A filter is added so that an authenticated user is required.

The app.settings.json file contains the configurations for the Azure AD authentication of the application which uses the Microsoft.Identity.Web client. The ClientId from the Web APP App registration and the TenantId for the directory are added here. The ClientSecret also needs to be defined. This should be added to the user secrets in development or added to an Azure Key Vault if deploying to Azure. The ApiWithRoles configuration added the API scope and the URL for the API.

The GetDataFromApi method calls the APIs. The UI application can call any one of the APIs, user, student or admin, each which required a different role. The policies were applied to these APIs. If an error is returned, the exception is handled and returned as a list to demonstrate. The ITokenAcquisition interface is used to get the access token from cache or from the Azure AD identity provider and the access token is added to the Authorization header of the HTTP request as a Bearer token.

To demonstrate the application, the user has been assigned the user “web-api-with-roles-user” and the “web-api-with-roles-admin” roles but not the “web-api-with-roles-student” for the API access. The “web-app-with-roles-user” was assigned for the UI application.

After a successful authentication, the claims from Azure AD are added to the HttpContext.User. A single roles claim (“web-app-with-roles-user”) is added for the UI application. This is as we expected.

If the API is called, the access token can be extracted from the debugger and pasted to jwt.ms or jwt.io . The access token contains two roles, “web-api-with-roles-user”, “web-api-with-roles-admin” as was configured in the enterprise application for this user. The access token also has the scp claim with the access_as_user . The azp claim and the azpacr claims have the expected values. A secret was using to signin to the client UI application which we allow.

A breakpoint was added to Visual Studio in the API project and the claims from the access token can be inspected. We expect the same values like in the access token and without the ASP.NET Core extras.

The ASP.NET Core UI application displays the results of the three API calls. The user and the admin APIs return data and the student API returns a forbidden result. This is what was configured. Now if the user is assigned new roles, after a logout, login, the new claims will be included in the tokens.

This approach works well if you do not have many roles, groups or claims, or if you do not need to change the authorization without re-authentication. The size of the access_token is important, this should not become large. If you require lots of claims for the authorization rules, the claims should not be included in the access token and Microsoft Graph API could be used to access these, or you could implement your own policy management.

https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/app-roles

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-enterprise-app-role-management

https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master/5-WebApp-AuthZ/5-1-Roles

https://docs.microsoft.com/en-us/azure/active-directory/develop/microsoft-identity-web

https://github.com/AzureAD/microsoft-identity-web

https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens

https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens

Restricting access to an Azure AD protected API using Azure AD Groups

https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies

Share this:

10 comments.

[…] Implement app roles authorization with Azure AD and ASP.NET Core – Damien Bowden […]

Thank you for the agreat post,

When WebAppWithRoles calls WebApiWithRoles returns an forbidden as result . Can you place explain how you configured web apps claims as azp, azpacr, roles”: [ “web-api-with-roles-user”, “web-api-with-roles-admin” ], and scp to the access token

Unable to run the application end-to-end…. Would appreciate some tips..

Sorry for the slow reply, just saw this now. The Azure App registrations need to be added from your tenants Azure App registration as well as the secrets

Nice tutorial.

Did you map users/groups in the SPA Enterprise App AND in the Api Enterprise App?

or did you only do it in the Api Enterpise App?

thanks, yes

It sounds like a problem from a maintenance point of view. Lets say you add the correct roles to the SPA for a user, but forgets one role on the API.

Then the user will be presented with some functionality, but when he tries to use it, he will get a 403 from the API.

I also asked this question in the msal library: https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/4389

But not sure what the best strategy is to tackle this problem

I normally do this with security groups. The groups roles and APP are setup once at the start. The I restrict access to the Enterprise APP. Then you only need to assign or remove users from the security groups. But this is not black and white. You need too think about lifespan of the roles, where these belong and so on. No authz is ever the same. I would need to analyze this in more detail for your setup. Greetings Damien

[…] También revisa esto Implementar la autorización de roles de aplicaciones con Azure AD y ASP.NET Core | Ingeniería de S… […]

Can you kindly suggest changes to above required for App Role (application)

Leave a comment Cancel reply

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

blogs 1 web, general

• Andrew Lock
• Anthony Giretti
• ASP.NET Core blog
• Benjamin Abt (de)
• Bryan Hogan
• Claudio Bernasconi
• code-maze.com
• Davide Bellone
• dotnetcore tutorials
• dotnetthoughts
• Fabian Gosebrink
• Filip WOJCIESZYN
• Gérald Barré
• Gunnar Peipman's
• haacked.com
• Isaac Abraham
• Isaac Levin
• Jürgen Gutsch
• Jeremy Likness
• João Antunes
• josef.codes
• joseph guadagno
• Jussi Roine
• khalid abuhakmeh
• Laurent Kempé
• mikesdotnetting
• Morning brew
• Niels Swimburger
• Ramani Sandeep
• Rockford Lhotka
• Scott Hanselman
• Shawn Wildermuth
• Steve Gordon
• thomas claudius huber
• Tobias Zimmergren

blogs 2 security

• Ackermann Yuriy
• Azure security podcast
• Bárbara Vieira
• Daniel Fett
• Daniel Miessler
• Dominick Baier
• Elie Bursztein
• futurae.com
• James Kettle
• John Patrick Dandison
• Justin Richer
• Kévin Chalet
• Kevin Dockx
• Matthijs Hoekstra
• Michal Špaček
• Microsoft Secure
• Mike Jones self-issued
• Nat Sakimura
• Philippe De Ryck
• research.kudelskisecurity
• Robert Broeckelmann
• Rory Braybrook
• Scott Brady
• Scott Helme
• securityguill
• sirdarckcat
• Stephen Haunts
• Steve Syfuhs
• Takahiko Kawasaki
• Tanya Janca
• Torsten Lodderstedt

blogs 3 Azure

• Alexandre Verkinderen
• Anthony Chu
• Azure DevOps
• Boris Wilhelms
• cloud-architekt.net
• cloudbrothers
• daniel chronlund
• Daniel Krzyczkowski
• Dominique St-Amand
• Eduard Keilholz
• francois leon
• Gareth Emslie
• Jan de Vries
• jeffrey appel
• Joonas Westlin
• Mahindra Morar
• Marius Solbakken
• Martin Lingstuyl
• Mickaël Derriey
• o365blog Dr Nestori Syynimaa
• olivier vaillancourt
• René Bremer
• Rick van den Bosch
• Sahil Malik
• Stephan van Rooij
• Stephane Eyskens
• Stian A. Strysse
• thomas maurer
• Thomas Naunheim
• Toon Vanhoutte

blogs 4 SSI DID

• hyperledger
• hyperledger aries-framework-dotnet
• identity.foundation
• identity.foundation blog
• idunion.org
• Kaliya-Identity Woman
• Kim Hamilton Duffy
• Kyle Den Hartog
• Markus Sabadello
• mattr.global
• Microsoft DID
• newsletter.identosphere.net
• Phillip J. Windley
• ssi-orbit-podcast
• Tomislav Markovski
• Andreas Helland
• Damien Guard
• Dan Wahlin's
• Data Farm Julie Lerman
• Dave Paquette
• Development With A Dot
• Elton Stoneman
• exceptionnotfound.net
• jeff handley
• Jeffrey T. Fritz
• Juan Carlos Sanchez's
• Maarten Balliauw
• Manfred Steyer (de)
• Manuel Meyer
• Mete Atamel
• Minko Gechev
• Nate Barbettini
• Nicholas Blumhardt
• Pawel Kadluczka
• Rui Figueiredo
• Stefan Prodan
• Stephen Cleary
• Alexander Beletsky
• Anders Janmyr
• Anže Vodovnik
• chsakell's Blog
• Florian Hopf
• fredrik normén
• Galdin Raphael
• Gernot Starke (de)
• Imran Baloch
• Jalpesh Vadgama DotNetJalps
• Jeffrey Palermo
• Jimmy Nilsson
• job tips for geeks
• Johnny Graber (de)
• Jon Galloway
• Kevin Jones
• Laurent Bugnion
• Linda Lawton
• Mick Taulty
• Muhammad Rehan Saeed
• PPEDV blog (de)
• Rashim's Blog
• Scott Addie
• scottgu .NET
• Shayne Boyer
• steven sanderson
• Taiseer Joudeh
• Thomas Ardal
• Thomas Levesque
• Tugberk Ugurlu
• .NET (Core, 5+ ) SDK
• Angular CLI
• bootstrap 4
• gitextensions
• IDP Azure AD
• IDP DuendeSoftware
• IDP keycloak
• IDP node-oidc-provider
• IDP OpenIddict
• lets encrypt
• protobuf-net
• randommer.io
• Search elasticsearch
• Search Solr
• Test achecker.ca
• Test DotTrace Profiler
• Test FakeItEasy
• Test Fiddler
• Test mkjwk.org JSON Web Key
• Test Ndepend
• Test Sysinternals Suite
• Test wireshark
• Test xunit.net
• Test zaproxy
• Visual Studio
• Visual Studio Code
• .NET Group Basel
• .NET Group Bern (de)
• .NET Group Luzern (de)
• .NET Group Zürich
• .NET User Group Geneva
• Angular Switzerland
• blackhat.com
• Brice's Entity Links
• Christian Mosers
• Code Project
• devcurry Suprotim Agarwal
• developer.chrome
• Fabrice Bellard
• fido alliance
• jeremy skinner
• Martin Fowler
• one unicorn
• OPC Foundation
• rob tiffany
• Simple Talk Red Gate
• thinktecture
• Thoughtworks Radar
• tutorialzine
• Web Fundamentals
• Entries feed
• Comments feed
• WordPress.com
• August 2024
• February 2024
• January 2024
• December 2023
• November 2023
• October 2023
• September 2023
• August 2023
• February 2023
• January 2023
• December 2022
• November 2022
• October 2022
• September 2022
• August 2022
• February 2022
• January 2022
• December 2021
• November 2021
• October 2021
• September 2021
• August 2021
• February 2021
• January 2021
• December 2020
• November 2020
• October 2020
• September 2020
• August 2020
• February 2020
• January 2020
• December 2019
• November 2019
• October 2019
• September 2019
• August 2019
• February 2019
• January 2019
• December 2018
• November 2018
• October 2018
• September 2018
• August 2018
• February 2018
• January 2018
• December 2017
• November 2017
• October 2017
• September 2017
• August 2017
• February 2017
• January 2017
• December 2016
• November 2016
• October 2016
• September 2016
• August 2016
• February 2016
• January 2016
• December 2015
• November 2015
• October 2015
• September 2015
• August 2015
• February 2015
• January 2015
• December 2014
• November 2014
• October 2014
• September 2014
• August 2014
• February 2014
• January 2014
• December 2013
• November 2013
• October 2013
• September 2013
• August 2013
• February 2013
• January 2013

• Already have a WordPress.com account? Log in now.
• Subscribe Subscribed
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar

AdamFowlerIT.com

Azure active directory – assigning groups to applications in powershell.

Azure Active Directory Applications have been around for a while, but it’s I’ve found it hard to find good information  on them beyond the biggest benefit of Marketplace Apps .

Along with my Azure AD B2B journey (still in preview at time of writing), the option of pushing out something like a SharePoint Online site as an app is one of the jigsaw pieces required to make the whole B2B process work – as a version of the apps  page is displayed as the default link to anyone who accepts an Azure AD B2B invite and logs in for the first time.

I’m trying to gloss over details here, as there’s a lot of steps with different parts of the Microsoft world to get a process automated end to end for inviting external users to a SharePoint Online site – but the last step of assigning a user or group to an application  has no documentation I could find, that showed how to achieve this via PowerShell.

All I want to do here, is create an Application in Azure AD, then assign a group to it. Members of the group will then see the application on MyApps .

Two different modules are required – Azure Active Directory V2 PowerShell module  and Azure Resource Manager .

What we can do with these two modules is first create the application with the New-AzureRMADApplication  command:

Easy, now you have an application that will point to the URL entered in Azure Active Directory. Assigning a group to it is a bit trickier…

First, a few values need to be obtained:

This is getting the two objects as variables – the Application itself, and the group that you want to add onto it.

Then a new Service Principal needs to be created based on the Application, as this is required when adding the group onto the application:

Another variable is needed, which is the new Service Principal we just created:

Finally, we can assign the group to the application:

You can check that this has applied by the Azure Active Directory porta l too, by going to your Active Directory section, choosing ‘Applications’ and finding your app, then go into ‘users and groups’ and find the group. You should see a ‘yes’ in the assigned field.

If there’s any interest in documenting the entire SharePoint Online and Azure AD B2B invite process and script, let me know. It’s a great way of sharing data with clients via a portal.

Update 15th June 2017

Microsoft made a change with the IdentifierURI field, which is also called AppID if you view it in the Azure portal. Previously, it could be any unique URL, it just has to be unique amongst your apps (as to why it has to be a URL at all, I couldn’t get an answer on). Now, it can be anything as long as it’s not sharepoint.com or dynamics.com as they’ve reserved those for other reasons. My example above, and what I’d been using in production was variants of sharepoint.com – as the unique URI might as well be the actual URL of the site. If you use a URL that’s not allowed anymore, you’ll get the error:

New-AzureRMADApplication : Operation returned an invalid status code ‘BadRequest’

Share this:

Other blog posts, one thought on “ azure active directory – assigning groups to applications in powershell ”.

Running into kind of the same issues you noticed here. For what I see the fact that you need to create an App with a unique URL in order to get the AppId is kind of inconvenient, because if you have several Site Collections on your SharePoint.com tenant; it’ll force the registration of as many apps as Site Collections you have.. Am I missing something?, or is that your experience as well?

Good write up though.

Leave a Reply Cancel reply

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

Create and Configure Azure AD Application using PowerShell

In this article, we will explain how to create a new Azure AD application, configure API permissions, create an Enterprise Application (Service Principal) for the new app, and provide user and admin consent to the app using the PowerShell script. We will also demonstrate how to acquire an app access token by using the newly created application and access Microsoft Graph API resources.

If you are new to using Azure AD applications, then we would recommend reading this post to know more about how to register Azure AD application and how to configure permissions and provide consent to the app from the Azure AD portal.

Before you start, install the Azure AD V2 PowerShell module and run the following command to connect the module.

• Create a new Azure AD Application

Configure required API Permissions in Azure AD Application

Create client secret or application password.

• Create new Service Principal or Enterprise Application
• Grant consent (user and admin) to Enterprise Application
• Get access token on behalf of the app
• Get access token on behalf of a user

Use the access token to call Microsoft Graph

Create a new azure ad application using powershell.

We can use the New-AzureADApplication cmdlet to create a new Azure Active Directory application. Run the following command to create a new app.

You can view the newly created app in the  App registrations  blade, under All applications in the Azure portal. Run the following commands to add the current user as Owner of the new app, hence you will also see the app under Owned applications.

Also Read: Create a new Azure AD Application (App registrations) from Azure AD portal

In Azure AD Portal, we can select the required app in App registrations and assign the required permissions under the section Manage -> API permissions. First, we need to select the required resource API (Ex: Microsoft Graph) and choose the required permissions (Ex: User.Read.All , Reports.Read.All ). The permission can either be Application permissions or Delegated permissions. Here, we are going to execute the same steps with the PowerShell script.

Also Read: Configure API Permissions in Azure AD Application from Azure AD portal

Run the following commands to configure the required Application and Delegated permissions in the newly created Azure AD application.

Note : The above script updates the permissions in the existing Azure AD application. You can also use the same script to set permissions while creating a new application.

When you request a token from a client application, a secret key is required to prove the application identity. The client secret key can also be referred to as the application password. You can create multiple keys and specify the validity period for your key. The below command creates a client secret key that will expire in two years. You can also specify a StartDate if you do not want the key activated immediately.

Also Read: Create client secret key from Azure AD Portal

Create new Service Principal or Enterprise Application for Azure AD Application

Once we created an Azure AD application, a service principal object ( Enterprise application ) is required for the application to access resources that are secured by Azure AD tenant. The security principal defines the access policy and permissions for the application in the Azure AD tenant. This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.

Run the following commands to create a new service principal for the Azure AD application.

When you register a new application from the App registrations  blade in the Azure portal, a service principal object for the application will be automatically created in your tenant and it will be available under  Enterprise applications  blade in the portal. If you created the app as a multi-tenant app and want to use it in different tenants such as a customer tenant, the service principal object will be created in the customer tenant when the customer provides permission to access resources in their tenant (upon registration or user consent or admin consent). They can also use PowerShell, Azure CLI, and other tools to create this security principal.

The service principal object is the local representation or application instance of a global Azure AD application in a single tenant or directory. The service principal can also be called as Enterprise Application or Managed Application in the local directory. You can refer to this post to know more about service principal: Azure AD Application and Service principal object .

Grant consent (user and admin) to Service Principal/Enterprise Application

As we already explained, the service principal (aka Enterprise application) of the application will control the resource access for the application in the Azure AD tenant. To acquire an access token for the configured permissions, the required consent (admin or user consent) should already have been provided for the required permissions in the service principal object.

Here, we are explaining how to grant consent for Application and Delegated permissions using the PowerShell script. We can also provide admin consent through the Azure AD portal or with admin consent URL, you can refer to this post for more details: Grant tenant-wide admin consent to an application .

$requiredResourcesAccess  – In the below scripts we have used the object $requiredResourcesAccess , you can refer to the above section Configure required API Permissions to form this object. If the Azure AD application available in your Tenant, then you can get the configured permissions by running the following commands.

$servicePrincipal –  In the below scripts we have used the object $servicePrincipal to get the Object Id of the service principal (Enterprise application). You can run the following commands to get the service principal object of your Azure AD application by providing the application’s AppId (Application client id).

Grant Admin consent for Application permissions

Run the following commands to grant admin consent for the application permissions that are configured in the app.

Grant User or Admin consent for Delegated permissions

We are going to use Microsoft Graph API to grant consent for the delegated permissions, so we need to get an access token with the required permissions to create or update a delegated permission grant (oAuth2PermissionGrant). 

$accessToken  – Run the following commands to retrieve access token by using the AzureAD Powershell app which provides a token with the required privilege.

Run the following commands to grant consent for all the users or required users. By default, the script gives consent for all the users (admin consent), you can set the value for  $GrantConsnetForAllUsers  as  $false  and provide the required user id to give consent only for the required user (user consent).

Get access token on behalf of the app – Application permissions

Once you have successfully created and configured an Azure AD application, run the following commands to get a resource access token with configured Application permissions.

Get access token on behalf of a user – Delegated permissions

For Delegated permissions token, we would recommend you to use a sign-in library such as MSAL (or ADAL) and prompt the user to log-in. For unattended sign-in access (without login-prompt window), we can use OAuth 2.0 Resource Owner Password Credentials flow.

Also Read: Get Access Token by Delegated permissions using MSAL.PS Library in PowerShell

Run the following commands to get an access token on behalf of a user by sending the required username and plain password.

The below command calls the users endpoint in the Microsoft Graph API resource and retrieves Azure AD user details.

Share this:

Related posts.

• How to Install and Connect Azure AD PowerShell
• Difference between App Registration and Enterprise Application in Azure AD
• Get List of Registered Azure AD Applications using PowerShell
• Get Azure AD Users with their Registered Devices using Powershell
• Manage Office 365 Groups using Azure AD Powershell module

9 thoughts on “Create and Configure Azure AD Application using PowerShell”

Hello Morgan,

Thank you very much for the code, this is exactly what I was looking for!

I keep running into an issue where when trying to grant consent I get the following error when PowerShell attempts to Invoke the oauth2PermissionGrants API

{“error”:{“code”:”Request_BadRequest”,”message”:”Specified clientId was not found.”}}

I’m quite positive the clientId is correct and it does indeed exist within my Tenant. Any thoughts on what could be the issue? This is a real head-scratcher for me.

Thanks, Matthew

Ensure that the $servicePrincipal is not a null object and run the below command to return the Object Id of the Enterprise Application (Service Principal object of your Azure AD app).

$servicePrincipal.ObjectId

If $servicePrincipal is a null object, then run the below command to get the Enterprise App (Azure AD Service Principal) object.

#Provide Application (client) ID of your App Registration (Azure AD Application) $appId="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" #$appId=$aadApplication.AppId #Get Enterpise application (Service Principal object) for your Azure AD app $servicePrincipal = Get-AzureADServicePrincipal -All $true | Where-Object {$_.AppId -eq $appId}

Actually here we are using the Object ID of the Enterprise Application (Service Principal object of your Azure AD app) as ClientID. So, go to Azure AD portal > Azure Active Directory > Enterprise applications > Open (Double-click) the required app, now cross-check the Object ID value with the value returned in the below command.

Ah, I see now. The difference is I am using “New-AzureADApplication” instead of “New-AzureADServicePrincipal”, which creates the App Registration, but doesn’t make it available yet under “Enterprise Applications”. Would you say that a simple fix is just to use “New-AzureADServicePrincipal” instead, or perhaps can you suggest a way to adapt the above with “New-AzureADApplication”?

My purpose here is to create some (2) App Registrations for a Web App with a middle-tier Web API, and then automatically have them granted Admin Consent during the onboarding (PowerShell deployment) process.

Very much appreciated!

Got it all figured out, thanks so much for your help. Wonderful post!

Hellow Morgan,

I have a question about the accessToken and is why we need to login again to get the accesstoken in this part of the code?

$platformParameters = New-Object “Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters” -ArgumentList “Always” $authResult = $authContext.AcquireTokenAsync($resourceURI, $ClientID, $RedirectUri, $platformParameters) $accessToken = $authResult.Result.AccessToken

is not better get the accesstoken when we login using the command Connect-AzureAD?

Also, you know if its possible to add the platform Mobile and Desktop application for the Reply URLs that the application needs?

thanks for your time and for the code it has been very useful!

Sorry, I don’t have any idea to get access token from the Connect-AzureAD context. Can you guide me if you know any method to get the token from existing Azure AD context?

Hello, Thanks for the post

I am getting error : New-AzureADServiceAppRoleAssignment : Error occurred while executing NewServicePrincipalAppRoleAssignment Code: Request_BadRequest Message: Permission being assigned already exists on the object

Can you help me in this.

Leave a Comment Cancel reply

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

Assigning groups to Azure AD roles and Privileged access groups, a first look!

On August 13th 2020, Alex Simons (Microsoft Identity PM) announced that assigning groups to Azure AD roles in now in public preview . This feature is one of the most requested features to be found in the Azure AD feedback forum .

I have been following this feature request for a while now, and up until recently Microsoft stated that implementing Azure AD role assignment for Azure AD groups wasn’t the issue, the issue was more related to who is able to manage those groups. For example, if enabled how can we circumvent that someone with the “User Administrator” role (capable of adding users to groups) is capable of adding someone to the group used to assign Global Administrator rights. When implemented incorrectly, this new “feature” could then introduce a new security risk in your environment.

Assigning groups to Azure AD roles requires an Azure AD Premium P1 license at minimum, for the Privileged Identity Functionality an Azure AD Premium P2 license is needed.

Disclaimer:  This post reflects the status of assigning groups to Azure AD roles as of August 20, 2020. Functionality may change, even right after this post has been published.

So, let’s walk through on what was announced and see..

So, up until now when you wanted to assign a user an Azure AD role, you had to include the user account directly in the role. Verifying which account has what privileges is therefore hard, especially if you don’t have Azure AD Privileged Identity Management (PIM) licensed.

For a more in depth overview of what Azure AD Privileged Identity Management (PIM) is, please see another blogpost I wrote on this subject here: Lessons learned while implementing Azure AD Privileged Identity Management (PIM)

Changed behaviour while adding members to Azure AD Roles

On the topic of PIM, I also noticed some changed functionality when adding users when you have PIM enabled in your environment. If you don’t have PIM enabled you can assign a user to a role, but if you have PIM enabled there is another experience where when you want to assign an Azure AD role you are actually redirected to the Privileged Identity Management blade, where you can directly create an Eligible (must be activated) or Active (always active) assignment.

Adding users to Azure AD roles via Group membership

In order to add users to Azure AD roles via Group membership you first have to create a new group, so it’s not possible to repurpose an existing group for this.

New groups have the option to set the “Azure AD roles can be assigned to the group (Preview)” option which can be set to either “No” or “Yes”. When you switch this setting to ‘Yes’ the group’s eligibility for role assignment is permanent. Besides that you can only have a membership type of Assigned, so using Dynamic Groups is not supported, and within the wizard you can only add users as member and not groups (group nesting). Interestingly, you can assign multiple Azure AD roles to the group.

If you want to create the Group with the “Azure AD roles can be assigned to the group (Preview)” option enabled you will get an extra confirmation screen:

The option “Azure AD roles can be assigned to the group (Preview)” is only visible if you are member of either the Global Administrator or Privileged Role Administrator role.

Privileged access groups

Once a group with the option to enable Azure AD role assignments is created and you have PIM enabled, a new option becomes available called “Privileged access (Preview)”.

Enabling this option gives us the following options:

Define Eligible or Active assignments to the group

On the group you can assign members or owners using the capabilities provided by PIM. So for example, while adding our user as a member of the group permanently earlier in this article, I now have the option to make the membership Eligible. Also notice that this assignment type is time bound, with a maximum of 1 year.

It’s also interesting to notice that if you want to update an Active Assignment you will not be allowed to Permanently assign an Active role by default. And that assigning an Active role has a maximum allowed assignment duration of 6 months. Once the group is enabled for Privileged Access and you want to add a member, then you don’t have the option “Permanently assigned” available. Also notice that providing a justification is mandatory.

The default options described above are configurable though, trough the settings, so you are able to configure these depending on your requirements.

Activating your Azure AD role while using Privileged access groups

It’s interesting to see that once a user is set to Eligible for the privileged access group, that the Azure AD role doesn’t show up under Eligible Assignments when the user browses to My Roles in PIM. In order to active the Azure AD role in this scenario, the user must go to Privileged access groups (Preview) and active the role from there.

Once the role is activated via the group, it will show up under Active assignments, and what’s interesting to see is that at this time it’s still displayed as being permanent. But I expect that to be fixed while the functionality is still in preview.

Within the PIM settings of the group you can also specify that any Activation request for the group must be approved. This works similar to approval in PIM as we already know it. You define that approval is mandatory and specify who can approve. This can either be a user or a group.

If the user now requests to activate the privileged access group, he will receive the message that the request is pending for approval

The approver doesn’t see the request under Privileged Identity Management | Approve requests but has to go to Privileged Identity Management | Privileged access groups (Preview) and select the group, from there the Approve Requests functionality is providing the ability to approve the request.

I hope this walkthrough gave you an idea on the new possibilities as announced in the public preview. And there is much more to cover actually when it comes to PIM, like more in depth information about auditing and access reviews.

Microsoft has addressed its own concerns by only allowing Global Administrators and Privileged Role Administrators to create the groups enabled for Azure AD role assignment. And having this functionality combined with Privileged Identity Management (PIM) makes the solution even better. Another reason to buy an Azure AD Premium P2 license for your administrative accounts at least.

A winning feature is that by using Privileged access with Azure AD Groups is that you can enable multiple Azure AD roles at once, this could save you creation of a custom role in some cases when using PIM.

While there are still some little fixes which must be applied, for now this looks like a welcome addition for any Azure AD tenant using Premium functionality.

Assigning groups to Azure AD roles is now in public preview!

Use cloud groups to manage role assignments in Azure Active Directory (preview)

Management capabilities for privileged access Azure AD groups (preview)

2 thoughts on “ Assigning groups to Azure AD roles and Privileged access groups, a first look! ”

• Pingback: Active Directory Identity Governance – Privileged Identity Management - JanBakker.tech

make the Security Admin Role a member Privilege Role Admin in Privilege Identity Management in Azure AD is this possible??

Leave a Reply Cancel reply

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

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

Privacy Overview

This browser is no longer supported.

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

Assign apps to groups with Microsoft Intune

• 21 contributors

After you've added an app to Microsoft Intune, you can assign the app to users and devices. It's important to note that you can deploy an app to a device whether or not the device is managed by Intune.

The Available for enrolled devices deployment intent is supported for user groups and device groups when targeting Android Enterprise fully managed devices (COBO) and Android Enterprise corporate-owned personally-enabled (COPE) devices.

Options when assigning managed apps

The following table lists the various options when assigning apps to users and devices:

Currently, you can assign iOS/iPadOS and Android apps (line-of-business and store-purchased apps) to devices that aren't enrolled with Intune.

To receive app updates on devices that aren't enrolled with Intune, device users must go to their organization's Company Portal and manually install app updates.

For almost all app types and platforms, Available assignments are only valid when assigning to user groups, not device groups. Win32 apps can be assigned to either user or device groups.

If managed Google Play pre-production track apps are assigned as required on Android Enterprise personally-owned work profile devices, they will not install on the device. To work around this, create two identical user groups and assign the pre-production track as "available" to one and "required" to the other. The result will be that the pre-production track successfully deploys to the device.

Assign an app

Sign in to the Microsoft Intune admin center .

Select Apps > All apps .

In the Apps pane, select the app you want to assign.

In the Manage section of the menu, select Properties .

Scroll down to Properties and select Assignments .

Select Add Group to open the Add group pane that is related to the app.

For the specific app, select an assignment type :

Available for enrolled devices : Assign the app to groups of users who can install the app from the Company Portal app or website.

Available with or without enrollment : Assign this app to groups of users whose devices aren't enrolled with Intune. Users must be assigned an Intune license, see Intune Licenses .

Required : The app is installed on devices in the selected groups. Some platforms may have additional prompts for the end user to acknowledge before app installation begins.

Uninstall : The app is uninstalled from devices in the selected groups if Intune has previously installed the application onto the device via an "Available for enrolled devices" or "Required" assignment using the same deployment.

For iOS/iPadOS apps only :

• To configure what happens to managed apps when devices are no longer managed, you can select the intended setting under Uninstall on device removal . For more information, see App uninstall setting for iOS/iPadOS managed apps .
• If you have created an iOS/iPadOS VPN profile that contains per-app VPN settings, you can select the VPN profile under VPN . When the app is run, the VPN connection is opened. For more information, see VPN settings for iOS/iPadOS devices .
• To configure whether a required iOS/iPadOS app is installed as a removable app by end users, you can select the setting under Install as removable .
• To configure a way to prevent the iCloud backup of the managed iOS/iPadOS app, you can click on one of the following settings after adding a group assignment - VPN, or Uninstall on device removal, or Install as removable. Then, configure the setting called Prevent iCloud app backup. For more information, see Prevent iCloud app backup setting for iOS/iPadOS and macOS apps .

For macOS apps only :

• To configure a way to prevent the iCloud backup of the managed macOS app, you can click on one of the following settings after adding a group assignment - VPN, or Uninstall on device removal, or Install as removable. Then, configure the setting called Prevent iCloud app backup. For more information, see Prevent iCloud app backup setting for iOS/iPadOS and macOS apps .

For Android apps only :

• If you deploy an Android app as Available with or without enrollment , reporting status will only be available on enrolled devices.

For Available for enrolled devices :

• The app is only displayed as available if the user logged into the Company Portal is the primary user who enrolled the device and the app is applicable to the device.

To select the groups of users that are affected by this app assignment, select Included Groups .

After you have selected one or more groups to include, select Select .

In the Assign pane, select OK to complete the included groups selection.

If you want to exclude any groups of users from being affected by this app assignment, select Exclude Groups .

If you have chosen to exclude any groups, in Select groups , select Select .

In the Add group pane, select OK .

In the app Assignments pane, select Save .

The app is now assigned to the groups that you selected. For more information about including and excluding app assignments, see Include and exclude app assignments .

Intune supports assigning apps to nested groups too. For example, if you assigned an app to the "Engineering Global" group and have "Engineering APAC", "Engineering EMEA" and "Engineering US" nested as child groups, the members of those child groups will also be targeted with the assignment.

Prevent iCloud app backup setting for iOS/iPadOS and macOS apps

Admins have the option to no longer backup managed App Store apps and line-of-business (LOB) apps on iOS/iPadOS and managed App Store apps on macOS devices, for both user and device licensed VPP/non-VPP apps. macOS LOB apps won’t support this setting. This functionality includes both new and existing App Store/LOB apps sent with and without VPP that are being added to Intune and targeted to users and devices. Preventing the backup of the specified managed apps ensure that these apps can be properly deployed via Intune when the device is enrolled and restored from backup. If you configure the new setting for new/existing apps in your tenant, managed apps can and will be reinstalled for devices, but Intune will no longer allow them to be backed up.

While we don't expect managed apps on devices to backup data to iCloud, note that data saved locally for managed apps may not be available after a backup and restore.

For existing devices, when Prevent iCloud app backup is set to Yes for an app/apps, the new behavior is automatically updated for all required App Store/LOB apps (with or without VPP). Required apps previously installed on devices are automatically reconfigured for all devices once the setting value is saved to Yes . Available apps require the user to redownload the available app from the Company Portal app or the Company Portal website . Additionally, depending on the app’s configurations and licensing, a sync between Intune and the device may be needed.

How conflicts between app intents are resolved

A single group is prevented from being targeted for multiple app assignment intents, however if a user or a device is a member of multiple groups that are each assigned with different intents it will result in a conflict. Creating assignment conflicts for applications isn't recommended. The information in the following table can help you understand the resulting intent when a conflict occurs:

For managed iOS store apps only, when you add these apps to Microsoft Intune and assign them as Required , the apps are automatically created with both Required and Available intents. iOS Store apps (not iOS/iPadOS VPP apps) that are targeted with required intent will be enforced on the device at the time of the device check-in and will also show in the Company Portal app. When conflicts occur in Uninstall on device removal setting, the app is not removed from the device when the device is no longer managed.

Apps deployed as Required to corporate-owned work profile and corporate-owned fully managed devices cannot be uninstalled manually by the user.

Managed Google Play app deployment to unmanaged devices

For unenrolled Android devices, you can use managed Google Play to deploy store apps and line-of-business (LOB) apps to users. Once deployed, you can use Mobile Application Management (MAM) to manage the applications. Managed Google Play apps targeted as Available with or without enrollment will appear in the Play Store app on the end user's device, and not in the Company Portal app. End user will browse and install apps deployed in this manner from the Play app. Because the apps are being installed from managed Google Play, the end user won't need to alter their device settings to allow app installation from unknown sources, which means the devices will be more secure. If the app developer publishes a new version of an app to Play that was installed on a user's device, the app will be automatically updated by Play.

Steps to assign a Managed Google Play app to unmanaged devices:

Connect your Intune tenant to managed Google Play. If you have already done this in order to manage Android Enterprise personally owned, dedicated, fully managed, or corporate-owned work profile devices, you don't need to do it again.

Add apps from managed Google Play to your Intune admin center.

Target managed Google Play apps as Available with or without enrollment to the desired user group. Required and Uninstall app targeting aren't supported for nonenrolled devices.

Assign an App Protection Policy to the user group.

User logs in any protected app.

The next time the end user opens the Company Portal app and completes the log in process, they'll see a message indicating in the Apps section that there are apps available for them. The user can select this notification to navigate to the Play Store.

You can configure device enrollment setting options to be Available, no prompts or Unavailable . This setting will prevent user from unintentionally enrolling their device or receiving notifications to enroll their device after they logged in to the Company Portal.

The end user can expand the context menu within the Play Store app and switch between their personal Google account (where they see their personal apps), and their work account (where they'll see store and LOB apps targeted to them). End users install the apps by tapping Install in the Play Store app.

When an APP selective wipe is issued in the Intune admin center, the work account will be automatically removed from the Play Store app and the end user will from that point no longer see work apps in the Play Store app catalog. When the work account is removed from a device, apps installed from the Play Store will remain installed on the device and won't uninstall.

App uninstall setting for iOS managed apps

For iOS/iPadOS devices, you can choose what happens to managed apps on unenrolling the device from Intune or removing the management profile using Uninstall on device removal setting. This setting only applies to apps after the device is enrolled and apps are installed as managed. The setting can't be configured for web apps or web links. Only data protected by Mobile Application Management (MAM) is removed after retirement by an App Selective Wipe.

Default values for the setting are prepopulated for new assignments as follows:

"Available" assignment types: If you're updating this setting for "available for enrolled devices" or "available with or without enrollment" groups, users who already have the managed app won't get the updated setting until they sync the device with Intune and re-install the app.

Pre-existing assignments: The App uninstall setting was introduced in May 2019. Assignments that existed prior to this date are unmodified and all managed apps will be removed on device removal from management. If your assignment was created before May 2019, you may need to explicitly set the App uninstall setting, as the default settings above may not apply.

To learn more about monitoring app assignments, see How to monitor apps .

Was this page helpful?

Additional resources

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Azure AD application - User assignment required option enabled, newly added user can't login

We have an application setup to use Azure AD. The 'User Assignment Required' option is enabled because we wanted to restrict access to a specific set of AD users. It's working fine for existing users.

However, we recently added a new user from the Enterprise Applications section for that app, and he is not able to log in. He gets the 'Need admin approval' message. When we disable the 'User Assignment Required' option, it works fine for him as well.

Please advise.

• azure-activedirectory

When you enable the 'User Assignment Required' option you have to give Admin Consent for that Applications permissions. When enabling this option normal users can not give consent on their own anymore, they only can give consent when that option is off. But you probably want that option on so you can control who can access the Application so you need an Admin (Global admin, Cloud Application admin or Application Admin) to give the consent for that App.

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged azure azure-activedirectory ..

• The Overflow Blog
• Where does Postgres fit in a world of GenAI and vector databases?
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• What would be non-slang equivalent of "copium"?
• What prevents a browser from saving and tracking passwords entered to a site?
• Historical U.S. political party "realignments"?
• Searching for an illustrated children's book with anthropomorphic animals, a sled, and a train
• Two way ANOVA or two way repeat measurement ANOVA
• Why is {_Integer..} matching {_Rule..}?
• Using "no" at the end of a statement instead of "isn't it"?
• Can a 2-sphere be squashed flat?
• A very interesting food chain
• Encode a VarInt
• Can probabilistic predictions be obtained from gradient boosting models CatBoost and XGBoost?
• Is this a mistake or am I misunderstanding how to calculate a capacitor's impedance with ESR and ESL?
• Is it possible to have a planet that's gaslike in some areas and rocky in others?
• Why does Jesus give an action of Yahweh as an example of evil?
• Too many \setmathfont leads to "Too many symbol fonts declared" error
• about flag changes in 16-bit calculations on the MC6800
• Should I report a review I suspect to be AI-generated?
• How can these humans cross the ocean(s) at the first possible chance?
• If inflation/cost of living is such a complex difficult problem, then why has the price of drugs been absoultly perfectly stable my whole life?
• Command-line script that strips out all comments in given source files
• Why does a halfing's racial trait lucky specify you must use the next roll?
• My visit is for two weeks but my host bought insurance for two months is it okay
• Why does flow separation cause an increase in pressure drag?
• How much of a discount do you get when buying cards on sale?

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

client_credentials authentication with Azure ID: Application is not assigned to a role

I'm trying to use Azure AD for a App-to-App authentication (grant_type: client_credentials) for calling a Rest API.

To avoid implementation issue I firstly tried with Postman with the following configuration, and got the error " Application {clientID} is not assigned to a role for the application {clientID}":

On Azure the App Registration seems to be properly configured, with a custom scope in "API permissions" and the same scope listen in "Expose an API".

What should I have to add in order to be able to call that API? Please note that the same API works properly using IdentityServer4 with client_credentials grand type.

Thanks in advance

• azure-active-directory

3 Answers 3

The answer from Rukmini is not entirely correct. In the answer provided, a Delegated permissions is assigned as API permission, and the token request is with a client_credentials flow. For client_credentials flow authentication, an Application permissions is required, not Delegated.

The issue can be fixed by keeping the "Assignment Required" on YES for security reasons (you may want to decide who, user/group or service principal, can access your application), and creating an Application permission on your App Registration.

Specifically:

• Create an App Role for the app registration with users/groups and Applications (if you need to have both Delegated and Application permissions, otherwise Application is sufficient")
• Create an API in "Expose an API" (if you need Delegated permissions for your users) with another Value
• Edit the manifest to have matching values between the ID of the app role and the scope, and between the scope name and App Role value (only if you want to have both the Delegated and the Application permissions with the same value)
• In API Permissions, Add a permission for your application using Application permissions and grant admin consent

That way, you can keep the Assignment required on YES and use both client_credential and other flows. For other flows, you need to add also the Delegated permissions.

• @matteogll let me know if there is anything that requires more clarification; I know it's a bit hurried but wanted to make sure that you have information in line with your requirements –  Marco Lodini Commented Jun 7, 2023 at 8:46

I created an Azure AD Application and Exposed an API like below:

And added the API permissions:

Now, when I generated the access token, I got the error like below:

The error " AADSTS501051: Application 'ClientID'(ruktestapp) is not assigned to a role for the application 'api://ClientID'(ruktestapp) " usually occurs if the user assignment is turned on for the Service Principal.

To resolve the error, Go to Enterprise Applications -> Select your application -> Go to properties -> Assignment required to NO and Save

Now, I generated access token successfully after few seconds applying the changes like below:

• 1 Thanks, switching "Assignment required" to NO solve my issue –  matteogll Commented May 16, 2023 at 7:49
• Set "Assignment required"=NO has security concerns? In my case that app is not public –  matteogll Commented Jun 6, 2023 at 12:22

Thanks Marco, your solution works as expected. I don't need to manually edit the manifest so basically there are the 2 main configuration to do:

In this way you are able to get an access token for that App.

TIP: In my .Net Core API I've to add this flag to the "Azure AD" configuration: "AllowWebApiToBeAuthorizedByACL": true

See: How to authenticate protect a backend web api for server to server communication using Azure Ad client_credentials

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged azure azure-active-directory postman identity or ask your own question .

• The Overflow Blog
• Where does Postgres fit in a world of GenAI and vector databases?
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites
• What does a new user need in a homepage experience on Stack Overflow?
• Feedback requested: How do you use tag hover descriptions for curating and do...
• Staging Ground Reviewer Motivation

Hot Network Questions

• Has the US said why electing judges is bad in Mexico but good in the US?
• Two way ANOVA or two way repeat measurement ANOVA
• How do eradicated diseases make a comeback?
• Upper bound for combinatorial sum
• What prevents a browser from saving and tracking passwords entered to a site?
• Are carbon fiber parts riveted, screwed or bolted?
• What explanations can be offered for the extreme see-sawing in Montana's senate race polling?
• The answer is not wrong
• Encode a VarInt
• Distinctive form of "לאהוב ל-" instead of "לאהוב את"
• Reusing own code at work without losing licence
• Why was this lighting fixture smoking? What do I do about it?
• Too many \setmathfont leads to "Too many symbol fonts declared" error
• If inflation/cost of living is such a complex difficult problem, then why has the price of drugs been absoultly perfectly stable my whole life?
• Why does flow separation cause an increase in pressure drag?
• Product of rings are Morita equivalent implies the rings are Morita equivalent.
• Where to donate foreign-language academic books?
• Why is {_Integer..} matching {_Rule..}?
• Has a tire ever exploded inside the Wheel Well?
• Cramer's Rule when the determinant of coefficient matrix is zero?
• "TSA regulations state that travellers are allowed one personal item and one carry on"?
• How can these humans cross the ocean(s) at the first possible chance?
• What is the difference between a "Complaint for Civil Protection Order" and a "Motion for Civil Protection Order"?
• Do the amplitude and frequency of gravitational waves emitted by binary stars change as the stars get closer together?

Automatic Application(Azure Active Directory) Assignment

We have to assigned the application (AZ Directory). Here we have two types of accounts normal and admin account . So, we have to atuo assign the application based on UPN application attribute.

How i can perform these activity looking your assistance here

Do i need to create new rule, workflow and provisioning policy for that? it will trigger once identity update is trigger?.

Thanks, Shubham

Hi @GutteStolt ,

Could you provide more information about what you need?

Regards, Arun

We have to automatically assign the application Azure Active Directory to the user based on the application attribute called UPN for that I am looking assistant here

you can manage it with a BS and IT role.

With this, when an identity meets the conditions of BS role, SP assign the roles and send a request to create an account if it dont have.

It’s purely depends on your application how it behaves and how you want. There are two ways I can tell.

• Use roles in which add assignment rule as @enistri_devo suggested. So that users whoever is matching the criteria then those will get the account. Make sure create account provisioning policy should be there. The problem with this is in rare cases I see, if there is any license issue for the user means if they are not logged in for more than certain days then account should be disable. Then that case it is the problem. SailPoint again tries to add because of the assignment rule we have even after disable also.
• To overcome the above one, create account while joiner is processing for the user based on your condition.

Related Topics