user assignment required app registration

Mickaël Derriey's blog

© 2024 Mickaël Derriey

Powered by Jekyll and GitHub Pages Theme based on Hyde by @mdo with modifications by @todthomson

The consequences of enabling the 'user assignment required' option in AAD apps

Introduction.

Applications in Azure Active Directory have an option labelled “user assignment required”. In this blog post, we’ll talk about how this affects an application.

💡 Quick heads-up — all the examples in this blog post are based on a web application using AAD as its identity provider through the OpenID Connect protocol.

By default, applications created in Azure Active Directory have the “user assignment required” option turned off, which means that all the users in the directory can access the application, both members and guests.

While this might sound like a sensible default, we find ourselves at Readify with a growing number of guests in the directory as we collaborate with people from other companies. Some of our applications contain data that should be available to Readify employees only, so we decided to make use of the “user assignment required” option.

To access this option, in the Azure portal, go to “Azure Active Directory > Enterprise applications > your application > Properties” and the option will be displayed there.

Some of the behaviour changes were expected, but others were not! Let’s go through them.

1. People not assigned to the application can’t use it

Well, duh, isn’t that what the option is supposed to do?!

You’re absolutely right! If someone that hasn’t been explicitly assigned to the application tries to access it, then AAD will reject the authorisation request with a message similar to the following:

AADSTS50105: The signed in user ‘Microsoft.AzureAD.Telemetry.Diagnostics.PII’ is not assigned to a role for the application ‘<application-id>’ (<application-name>)

The message is straightforward and the behaviour expected.

There are several ways to assign someone to the application. I typically use the Azure portal, navigate to “Azure Active Directory > Enterprise applications > my application > Users and groups” and add them there.

2. Nested groups are not supported

This is the first surpise we had. It’s our bad, because it’s well documented on that documentation page in the “Important” note: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-saasapps

In other words, if you assign a group to an application, only the direct members of that group will gain access to the application. So instead of using our top-level “all employees” type of group, we had to assign several lower-level groups which only had people inside of them.

3. All permissions need to be consented to by an AAD administrator

Applications in Azure Active Directory can request two types of permissions:

• the permissions which are scoped to the end user, like “Access your calendar”, “Read your user profile”, “Modify your contacts” — these permissions are shown to the user the first time they access an application, and they can consent to the application performing those actions on behalf of them;
• another type of permissions usually have a broader impact, outside of the user’s scope, like “Read all users’ profiles” or “Read and write all groups” — those permissions need to be consented to by an AAD administrator on behalf of all the users of the application.

When the access to the application is restricted via the “user assignment required”, an Azure Active Directory administrator needs to consent to all the permissions requested by the application, no matter whether users can normally provide consent for them.

As an example, I created an application with only one permission called “Sign in and read user profile”. After enabling the “user assignment required” option, I tried to log in through my web application and got prompted with a page similar to the screenshot below:

While I don’t fully understand that behaviour, it is alluded to in the tooltip associated with the “user assignment required” option, shortened for brevity and emphasis mine.

This option only functions with the following application types: […] or applications built directly on the Azure AD application platform that use OAuth 2.0 / OpenID Connect Authentication after a user or admin has consented to that application .

The solution is to have an AAD admin grant consent to the permissions for the whole directory. In the Azure portal, go to “Azure Active Directory > Enterprise application > your application > Permissions” and click the “Grant admin consent” button.

4. Other applications not assigned to the application can’t get an access token

It’s not uncommon to see integration between applications. As an example, an application “A” could run a background job every night and call the API of application “B” to get some data.

Before we enabled the “user assignment required” option in application “B”, it was possible for application “A” to request an access token to AAD, allowing it to call the API of application “B”. This is done using the client_credentials OAuth2 flow, where application “A” authenticates itself against AAD with either a client secret (it’s like a password, but an app can have different secrets) or a certificate.

However, after requiring users to be assigned to the application “A”, the token request returns the following error:

AADSTS501051: Application ‘<application-b-id>’ (<application-b-name>) is not assigned to a role for the application ‘<application-a-id>’ (<application-a-name>).

While it’s similar to the first error we talked about in this post, the resolution is different, as the Azure portal doesn’t let us assign applications to another application in the “User and groups” page.

I found the solution in this Stack Overflow answer which advises to take the following steps:

• create a role in application “A” that can be assigned to applications;
• have application “B” request this permission; and
• get an AAD admin to grant consent for the permissions requested by application “B”.

Let’s go through these steps one by one.

4.1 Create a role that can be assigned to applications

If you want to get some background information on AAD app roles, I highly suggest reading the following pages on docs.microsoft.com : Application roles and Add app roles in your application and receive them in the token .

To create a role aimed at applications, we’ll use the “Manifest” page and replace the appRoles property with the following:

4.2 Request that permission in application “B”

Wait, we were talking about creating a role and now we request a permission?

I agree, sorry about the confusion, but the following will hopefully make sense. There’s a change in the terminology we use because assigning that role to application “B” is actually done the other way around, by requesting that role from the settings of application “B”.

To do so, we navigate in the Azure portal to “Azure Active Directory > App registrations > application “B” > Required permissions” and then click on the “Add” button. In the new “Add API Access”, we look for application “A”, select it, then pick the “Access application A” application permissions we created in the previous step:

💡 Another heads-up — at the time of writing, the Azure portal has a new App registrations experience in preview. The steps mentioned above are for the GA App registrations blade, but the experience is pretty similar in the preview one. If you want to try it out, follow “App registrations (preview) > application “B” > API permissions > Add a permission > APIs my organization uses > application “A” > Application permissions”, then finally pick the “Access application A” one.

4.3 Grant consent for application “B” to access application “A”

Because there’s no user involved, application permissions automatically require admin consent. Follow the steps taken previously, but this time for application “B”. After doing so, the token request from application “B” to access application “A” will work as expected.

When we first used that “user assignment required” option, I was only expecting unassigned users to be bounced by AAD when trying to log in. Little did I know we would encounter all those “bumps” along the way 🤣.

This was a great learning opportunity, and hopefully it’ll be useful to others.

Related Posts

Ensure node.js opentelemetry instrumentations are compatible with installed packages 08 apr 2024, a new and easy way to use aad authentication with azure sql 23 jul 2021, how to lock down your csp when using swashbuckle 14 dec 2020.

Software and Consulting

Assigning all users to an Azure AD Enterprise app registration

Stumbled across a glaring problem with Azure this morning, Azure security groups don’t support nesting!

From this article in the azure docs they quote:

Group-based assignment is supported only for security groups. Nested group memberships are not supported for group-based assignment to applications at this time. https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-saasapps

The Azure feedback channel linked below states that they are currently looking at the issue, it’s obviously an issue for a lot of users.

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/15718164-add-support-for-nested-groups-in-azure-ad-app-acc

We have a complex role based user permission model burnt into our Active Directory that heavily relies on security group nesting. To add all users into an Application Registration for access at the single group level would require adding around 50 groups… which is totally unmanageable.

The workaround I’ve gone with for the time being is to set the “User assignment required?” option in the “Properties” blade on the enterprise side of the app registration to no, which allows all logged in users to have access to the service.

No very granular but will temporarily grant an “Everyone” equivalent to the app registration for global access.

Lets hope they get it fixed up soon.

Leave a Reply 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.

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

• Featured on Meta
• Bringing clarity to status tag usage on meta sites
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Announcing a change to the data-dump process

Hot Network Questions

• Inner tube with sealent inside (unopened), have expiry date?
• What is the purpose of toroidal magnetic field in tokamak fusion device?
• Did the United States have consent from Texas to cede a piece of land that was part of Texas?
• Is "Alice loves candies" actually necessary for "Alice loves all sweet foods"?
• What if something goes wrong during the seven minutes of terror?
• How to fix a bottom bracket shell that has been cut from outside?
• Is there a way to say "wink wink" or "nudge nudge" in German?
• 1 amen for 2 berachot?
• Implications of the statement: "Note that it is very difficult to remove Rosetta 2 once it is installed"
• General Formula For Hadamard Gate on Superposition State
• Is the oil level here too high that it needs to be drained or can I leave it?
• Is there a law against biohacking your pet?
• set of words w such that M halts on w is decidable
• Stabilizing an offset wood bunk bed
• What is the translation of point man in French?
• What to do if sample size obtained is much larger than indicated in the power analysis?
• Physical basis of "forced harmonics" on a violin
• What is the good errorformat or compiler plugin for pyright?
• chess game: loading images for the rooks
• Fourth order BVP partial differential equation
• How to allow just one user to use SSH?
• Solve an integral analytically
• UART pin acting as power pin
• Fitting the 9th piece into the pizza box

Azure Active Directory Developer Support Team

How AuthN do we talk? Thoughts and musings by the Microsoft AAD Developer Support team

• Most Comments
• Terms and Privacy

Control access to your apps in Azure AD

We get this kind of question all the time. It comes in many variations and forms like…

“I only want to consent for some users to access the app.”

“I only want my service account to access this app”

Before we get started…

First and foremost, only consenting for allowed users is not the solution. This is not the purpose for consent. Consent is to inform a user or admin what the application is accessing and to give the user or admin an option to accept or deny the requested permissions. Administrators should not be using this to determine who has access to an application. Once the permissions are consented, then we will only allow the app to access the requested permissions and no more.

For more information about the Azure AD Consent Framework…

https://docs.microsoft.com/en-us/azure/active-directory/develop/consent-framework

Let’s get started…

If you want to control access to an application, then you should be enabling the requirement of user assignment on the Enterprise application then assign the user, group, or service principal to the application.

First: Perform admin consent

Make sure an administrator has performed an Admin consent on the required permissions. This is a requirement in order to restrict user access. Otherwise, you will see various consent related messages or you need admin approval.

For troubleshooting consent issues, see the following article…

Troubleshooting consent in Azure AD

Second: Enable User assignment required …

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/assign-user-or-group-access-portal#configure-an-application-to-require-user-assignment

Third: Assign users, groups, service principals

Once user assignment is required, now assign the user, groups, or service principal to the application…

If it’s a Web Application…

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/assign-user-or-group-access-portal#assign-users-or-groups-to-an-app-via-the-azure-portal

If it’s a Public Client…

If the application is enabled as a Public Client type so that you can use Windows Authentication, Resource Owner Password Credential flow, or Device Code flow, then this is a bit trickier…

• Then perform the step above under “If it’s a Web Application” to assign users, groups, or service principals to the application.
• Then re-enable the Public Client configuration.

Optionally, you can also use Azure AD PowerShell… (Especially if you do not own the application to disable Public client type.)

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/assign-user-or-group-access-portal#assign-users-or-groups-to-an-app-via-powershell

When user assignment is required…

Once user assignment is required, then only those users will be able to access the application. Users who do not have access will get the following similar error message…

AADSTS50105: The signed in user ‘{EmailHidden}’ is not assigned to a role for the application ‘{app-id}'({app-display-name}).

Other Tips…

You can also do this for other resources such as an API. Just follow the steps above applying them to the resource’s Enterprise app. Be careful and don’t do this for Microsoft first-party apps as you might break apps like Outlook, Power BI, SharePoint, ect…

2 Thoughts to “Control access to your apps in Azure AD”

Hi,   I would like to customize the default error page which is displayed when a user is not assigned to the application. How do I do this? I’m using ASP core 3.1 and identity web 0.1.4 preview   Thanks   Jono

The scenario in this post is about controlling access to the application from Azure AD Identity Provider service and its error page or message is not customizable at this point. If you are looking to have more control over the application redirection, this approach may not be correct for you.

Leave a Comment Cancel reply

Recent posts.

• Authorization_RequestDenied error when using Microsoft Graph API to add user(s) to a group
• ‘Update your browser’ message when using apps that leverage ADAL/MSAL
• How to find the underlying MS Graph URL from a Microsoft Graph PowerShell commandlet
• Tutorial: How to call a protected web API with an application permission token in Azure AD B2C
• Troubleshooting CORS to Azure AD/Entra ID
• May 2024  (3)
• March 2024  (1)
• August 2023  (1)
• July 2023  (1)
• May 2023  (1)
• March 2023  (3)
• February 2023  (2)
• November 2022  (2)
• October 2022  (3)
• September 2022  (1)
• August 2022  (5)
• July 2022  (2)
• June 2022  (3)
• May 2022  (5)
• April 2022  (4)
• March 2022  (3)
• February 2022  (1)
• January 2022  (1)
• December 2021  (1)
• November 2021  (1)
• August 2021  (2)
• July 2021  (3)
• June 2021  (3)
• April 2021  (3)
• March 2021  (1)
• February 2021  (2)
• January 2021  (3)
• October 2020  (2)
• September 2020  (2)
• August 2020  (3)
• July 2020  (2)
• June 2020  (4)
• May 2020  (2)
• April 2020  (6)
• March 2020  (1)
• January 2020  (3)
• December 2019  (7)
• November 2019  (7)
• October 2019  (1)
• August 2019  (6)
• July 2019  (5)
• June 2019  (1)
• May 2019  (3)
• April 2019  (2)
• March 2019  (3)
• January 2019  (4)
• December 2018  (1)
• November 2018  (4)
• October 2018  (2)
• September 2018  (2)
• August 2018  (2)
• June 2018  (2)
• May 2018  (8)
• April 2018  (6)
• February 2018  (2)
• App Registration
• asp.net core
• authentication
• Authentication Flows
• Authorization
• Azure AD Graph
• Azure Identity Client
• Client Credentials
• Enterprise application
• Eventual Consistency
• Microsoft Graph
• Microsoft Graph Client
• Microsoft Graph Explorer
• Microsoft Graph PowerShell Module
• Microsoft Identity Web
• National Cloud
• Permissions
• spring boot
• Subscription
• Token Claims
• Token Validation
• Uncategorized

Maik van der Gaag

I am Microsoft Azure MVP , Speaker and Father .

• Schiedam, The Netherlands
• Custom Social Profile Link

“Exposing Azure App Registrations as Secure APIs: A Guide to Authentication with ‘User Assignments Required’ Turned On”

3 minute read

Azure App Registrations are a powerful tool for managing resource access and integrating applications with Microsoft's cloud services. While these registrations are typically used to grant applications access to other Azure resources, they can also be exposed as APIs, allowing external applications to interact with the registered application's resources securely.

In this blog post, we'll explore exposing an Azure App Registration as an API, including the necessary configuration to authenticate towards the application when the application is configured with 'User Assignments Required' turned on. This short guide tells you how to configure this.

This guide talks about two different Application Registrations.

• The application you are authenticating to. (This is the application registered on, for example, an Azure App Service)
• The application you are authenticating with. (This is the application you will use to retrieve data from, for example, an API)

Step 1: Expose an API

Ensure the application you are authenticating to (1) has an Application ID Url configured within the App Registration blade of the application.

If this is not configured, make sure to add it.

Step 2: Create an App Role

An 'App Role' needs to be defined to authenticate your application. For this, go to the 'App Role' blade for the App Registration you are authenticating to (1).

If an App Role does not exist, create a new one and fill in the required properties. Make sure also to select Applications in the allowed "member types" and enable it. Adding these roles makes sure that the roles are added to the token of the application.

Step 3: Add application API Permission

On the 'API Permission' blade of the application you are authenticating with (2), the required permissions for the application need to be configured. In the blade, click 'Add permission.'

Then go to the tab "APIs" my organization uses and search for your App Registration. You should be able to see the name within the list.

Click on the application. On the next screen, you should be able to see the roles that you can choose. Select the permissions that are required and click on "Add Permissions."

Step 4: Admin Consent

These types of app roles require an 'Admin Consent.' After adding the permission, you will be returned to the API permissions blade. In this blade, click on 'Grant admin consent for.'

You May Also Enjoy

Getting started with deployment stacks.

7 minute read

Since June this year, a new functionality in public preview called deployment stacks. Deployment stacks are Azure resources that enable you to manage a group...

Verified commits in GitHub

5 minute read

Git commits can be signed by using a GPG key. With this GPG key, you can prove that a specific commit comes from you. Doing this will also add a ‘Verified’ b...

Creating a Logic App API Connection that uses the Managed Identity using Bicep

2 minute read

Logic Apps in Azure provides a platform for building workflows that integrate with various services and APIs. When creating Logic Apps, you must often connec...

Centrally manage your App Configurations

10 minute read

The application landscape in Azure has grown significantly in recent years, with a wide range of tools and services available to help businesses build, deplo...

• Dynamics 365 + SharePoint Document Management Suite
• CB Dynamics 365 to SharePoint Permissions Replicator
• SharePoint Structure Creator
• CB Dynamics 365 Seamless Attachment Extractor
• Dynamics 365 Database Sync Solution
• Dynamics 365 Customer Engagement Sync
• Connect to Dynamics 365 Finance and Operations
• Connect to Dynamics 365 Business Central
• CB Exchange Server Sync
• CB Exchange Server Sync for GCC High
• CB Super Secure Exchange Server
• Exchange/Outlook Data Filter
• CB Global Address List Sync
• CB Exchange Server Sync for Gmail and Google Workspace
• Digital Transformation – Industrial IoT
• CB Digital Factory
• CB SharePoint Exchange Sync
• CB Blockchain Seal for SharePoint
• Salesforce Document Management & Integration
• Document Extractor built for the Salesforce platform™
• CB Salesforce Exchange Sync
• Database Salesforce Sync
• CB Blockchain Seal for Salesforce®
• CB Document Metadata Reporting for Salesforce®
• CB Blockchain Seal for Salesforce ®
• CB Blockchain Seal
• CB Digital Port of Trust
• CB Blockchain Seal Verifier
• Connect Bridge
• Connect Bridge for Power Automate
• CB Linked Server for Enterprise Applications
• CB Mobile App Integration Toolkit
• Connect Bridge for Software Vendors
• Connect Bridge Connector SDK
• Connect to Microsoft Teams
• Connect to Dracoon
• Out-of-the-box Products
• Software Integration Platform
• In the Media
• Press Release
• Global Code of Conduct
• Sustainability Statement
• Tech Support

How to Create an Azure AD App Registration – Step-By-Step Tutorial

Ana Neto December 4, 2023 Technical Leave a Comment

Are you navigating the world of Modern Authentication in your company? Let's dive into how Azure Active Directory (AAD) app registration can be your ticket for seamless authentication and authorization.

Azure AD App Registration: 'Entra' a New Era

Ah, the world of Azure AD App Registration - a realm where some dare not go in… But wait, there's a plot twist! Enter Microsoft Entra ID , the new protagonist on stage, with changes to the Azure AD App Registration narrative. Microsoft says it is the next evolution of identity and access management solutions for the cloud. If you want to delve in to see what's new, Microsoft has available free training . If you just want to enter the realm to register your app… follow me!

Azure AD App Registration: Two step-by-step scenarios

Depending on the software, the procedure might be a bit different. In this tutorial, we will cover the two options we use at Connecting Software:

• Client Credentials Grant (via certificate)
• Authorization Code Grant (via client secret)

Please note that if you are reading this article because you are starting with a Connecting Software product, you should follow these instructions only if you are deploying the software on-premises. For SaaS, you can use the app we’ll provide you and you’ll only need the directory id, or you can create your own app.

In any case, let’s get started!

Client Credentials Grant

We’ll first go through the Client Credentials Grant (CCG) procedure, sometimes referred to as implicit grant. Here are the steps you’ll need to follow:

CCG1 - Open the Azure portal , log in, and select the Microsoft Entra ID

Alternatively, you can come in through the Microsoft Entra admin center and select Microsoft Entra ID (Azure AD) .

CCG2 - Select App registrations .

If you came in through the Microsoft Entra Admin Center, you’ll find the App registrations under Applications .

CCG3 - Select New registration .

CCG4 - Type your application’s name, choose the account types and click Register. Please note that the Redirect URI is optional, but necessary in most of the scenarios.

CCG5 - Copy your Application (client) ID and Directory (tenant) ID as you will need to enter these in the software you are setting up Modern Authentication in.

CCG6 - You will need to get the certificate from the software you are doing Modern Authentication for. As an example, if it is Document Extractor on-premises you can go to the configuration page, download the certificate from the Public Key Certificate field. In other cases, you will find it in the Certificate field.

CCG7 - You will now upload this certificate in Azure. Click Certificates and secrets , then Certificates , and finally, Upload certificate .

CCG8 - Upload the certificate which you downloaded earlier and click Add .

Once uploaded, you should see the certificate in the list, with its Thumbprint , Start date and an indication of when it Expires

CCG9 - Click API permissions and then click on Add a permission

CCG10 - Select SharePoint and choose Application permissions

CCG11 - The permissions you will need to check will depend on the software you are creating the app for and also on your specific use case for it.

This will differ from product to product but, for example, for Document Extractor you would normally check the “Sites.ReadWrite.All” permission, but if you would like to sync changes from SharePoint to Salesforce then you would check the “Sites.Manage.All” permission instead.

CCG12 - As a final step you should grant admin consent. You’ll find the Grant admin consent for … button next to the Add a permission button that you used in the previous step. If the Grant admin consent for … is disabled, check which user are you logged in with.

Authorization Code Grant

For this other type of grant, the first steps are identical and then the procedure takes a different path: ACG1 - Identical to CCG1 ACG2 - Identical to CCG2 ACG3 - Identical to CCG3 ACG4 - Besides typing your application’s name and choosing the account types, you’ll need to select a platform - select Web - and then enter the redirect URI. For example, for CB Dynamics 365 to SharePoint Permissions Replicator, it should be https://permissions-replicator-saas.connecting-software.com/consent-callback. Once that is done, click on Register . ACG5 -  In the Certificates & secrets section, go to Client secrets and click New client secret . Copy the generated secret so you can use it in the next steps.

ACG6 - Identical to CCG9 ACG7 - Identical to CCG10 ACG8 - Identical to CCG11 ACG9 - Identical to CCG12

In this article, we’ve walked you through the two options we use for Azure AD App Registration at Connecting Software: Client Credentials Grant (via certificate) and Authorization Code Grant (via client secret).

About the Author

By  Ana Neto , technical advisor at Connecting Software.

“I have been a software engineer since 1997, with a more recent love for writing and public speaking. Do you have any questions or comments about this article? I would love to have your feedback, leave a comment below! "

Leave a Reply

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

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use .

I agree to these terms (required).

This website uses cookies. We use cookies to analyze our traffic, enhance our website’s functionality and performance and provide a better experience for our users More info about Privacy policy

Get the Reddit app

Join us in discord here: https://aka.ms/azurediscord.

[Azure AD] Enterprise Applications User Assignment Required

What is the whole point of the "User Assignment Required" option in AAD Enterprise Applications' properties? Every app that I have configured to use SSO has required an account to be created in the actual application before a user can sign into it, so this just seems like an extra pointless step (I have been configuring as YES anyway, but I'm just now wondering why).

Is there some scenario that I am missing where this extra step would be mandatory/required?

EDIT: Or is there some extra risk mitigation that this function provides that I am not thinking of?

By continuing, you agree to our User Agreement and acknowledge that you understand the Privacy Policy .

Enter the 6-digit code from your authenticator app

You’ve set up two-factor authentication for this account.

Enter a 6-digit backup code

Create your username and password.

Reddit is anonymous, so your username is what you’ll go by here. Choose wisely—because once you get a name, you can’t change it.

Reset your password

Enter your email address or username and we’ll send you a link to reset your password

Check your inbox

An email with a link to reset your password was sent to the email address associated with your account

Choose a Reddit account to continue

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

With Azure AD 'User Assignment Required' turned on, how to handle unauthorized users in same tenant

I have an app registration for which users can log into a SPA app using the MSAL library . This works fine until a user already is logged in with an account in the same tenant as the app, but not authorised by being assigned to a role. They are redirected to an azure login error page stating:

AADSTS50105: The signed in user '{user name}' is not assigned to a role for the application '{uid}'({App reg name}).

I can't see any way to prevent this. How can I catch this failure in my apps MSAL library and allow the user to sign in with a different account?

You can also find my issue posted to an MSAL github issue here:

https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/3949

• azure-active-directory
• azure-ad-msal

• similar threads : thread1 >(Changing the ‘User assignment required’ to No, grant admin consent and then set user assignment to yes.) , AADSTS50105 , thread3 –  kavyaS Commented Aug 24, 2021 at 10:21
• thanks. Turning off 'user assignment required' i believe should not be the fix as i want to exclude users in the same tenant from gaining access and also enforce adding users via the user groups –  Ian Commented Aug 24, 2021 at 15:46

Know someone who can answer? Share a link to this question via email , Twitter , or Facebook .

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 .

Browse other questions tagged azure-active-directory azure-ad-msal or ask your own question .

• 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
• Feedback requested: How do you use tag hover descriptions for curating and do...

Hot Network Questions

• What is the number ways to count tuples whose sum is zero?
• What is the origin and meaning of the phrase “wear the brown helmet”?
• Is it possible to use wi-fi on phone while tethered to MacBook Pro?
• how to label a tikz path, where the node label extends outward perpendicular to the path at a point
• Unreachable statement when upgrading APEX class version
• In compound nouns is there a way to distinguish which is the subject or the object?
• Ways to paint a backbone on a tree
• How would a culture living in an extremely vertical environment deal with dead bodies?
• How do you "stealth" a relativistic superweapon?
• Simple JSON parser in lisp
• Harmonic, partial, overtone. Which is which?
• What to do if sample size obtained is much larger than indicated in the power analysis?
• Finite loop runs infinitely
• Genus 0 curves on surfaces and the abc conjecture
• How to fix a bottom bracket shell that has been cut from outside?
• How can I cover all my skin (face+neck+body) while swimming outside (sea or outdoor pool) to avoid UV radiations?
• Who became an oligarch after the collapse of the USSR
• conflict of \counterwithin and cleveref package when sectioncounter is reset
• Short story or novella where a man's wife dies and is brought back to life. The process is called rekindling. Rekindled people are very different
• Kyoto is a famous tourist destination/area/site/spot in Japan
• How to allow just one user to use SSH?
• Why do these finite group Dedekind matrices seem to have integer spectrum when specialized to the order of group elements?
• What is the good errorformat or compiler plugin for pyright?
• ambobus? (a morphologically peculiar adjective with a peculiar syntax here)

This browser is no longer supported.

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

Application registration permissions for custom roles in Microsoft Entra ID

• 10 contributors

This article contains the currently available app registration permissions for custom role definitions in Microsoft Entra ID.

License requirements

Using this feature requires Microsoft Entra ID P1 licenses. To find the right license for your requirements, see Compare generally available features of Microsoft Entra ID .

Permissions for managing single-tenant applications

When choosing the permissions for your custom role, you have the option to grant access to manage only single-tenant applications. single-tenant applications are available only to users in the Microsoft Entra organization where the application is registered. single-tenant applications are defined as having Supported account types set to "Accounts in this organizational directory only." In the Graph API, single-tenant applications have the signInAudience property set to "AzureADMyOrg."

To grant access to manage only single-tenant applications, use the permissions below with the subtype applications.myOrganization . For example, microsoft.directory/applications.myOrganization/basic/update.

See the custom roles overview for an explanation of what the general terms subtype, permission, and property set mean. The following information is specific to application registrations.

Create and delete

There are two permissions available for granting the ability to create application registrations, each with different behavior:

microsoft.directory/applications/createAsOwner

Assigning this permission results in the creator being added as the first owner of the created app registration, and the created app registration will count against the creator's 250 created objects quota.

microsoft.directory/applications/create

Assigning this permission results in the creator not being added as the first owner of the created app registration, and the created app registration will not count against the creator's 250 created objects quota. Use this permission carefully, because there is nothing preventing the assignee from creating app registrations until the directory-level quota is hit.

If both permissions are assigned, the /create permission will take precedence. Though the /createAsOwner permission does not automatically add the creator as the first owner, owners can be specified during the creation of the app registration when using Graph APIs or PowerShell cmdlets.

Create permissions grant access to the New registration command.

There are two permissions available for granting the ability to delete app registrations:

microsoft.directory/applications/delete

Grants the ability to delete app registrations regardless of subtype; that is, both single-tenant and multi-tenant applications.

microsoft.directory/applications.myOrganization/delete

Grants the ability to delete app registrations restricted to those that are accessible only to accounts in your organization or single-tenant applications (myOrganization subtype).

When assigning a role that contains create permissions, the role assignment must be made at the directory scope. A create permission assigned at a resource scope does not grant the ability to create app registrations.

All member users in the organization can read app registration information by default. However, guest users and application service principals can't. If you plan to assign a role to a guest user or application, you must include the appropriate read permissions.

microsoft.directory/applications/allProperties/read

Ability to read all properties of single-tenant and multi-tenant applications outside of properties that cannot be read in any situation like credentials.

microsoft.directory/applications.myOrganization/allProperties/read

Grants the same permissions as microsoft.directory/applications/allProperties/read, but only for single-tenant applications.

microsoft.directory/applications/owners/read

Grants the ability to read owners property on single-tenant and multi-tenant applications. Grants access to all fields on the application registration owners page:

microsoft.directory/applications/standard/read

Grants access to read standard application registration properties. This includes properties across application registration pages.

microsoft.directory/applications.myOrganization/standard/read

Grants the same permissions as microsoft.directory/applications/standard/read, but for only single-tenant applications.

microsoft.directory/applications/allProperties/update

Ability to update all properties on single-tenant and multi-tenant applications.

microsoft.directory/applications.myOrganization/allProperties/update

Grants the same permissions as microsoft.directory/applications/allProperties/update, but only for single-tenant applications.

microsoft.directory/applications/audience/update

Ability to update the supported account type (signInAudience) property on single-tenant and multi-tenant applications.

microsoft.directory/applications.myOrganization/audience/update

Grants the same permissions as microsoft.directory/applications/audience/update, but only for single-tenant applications.

microsoft.directory/applications/authentication/update

Ability to update the reply URL, sign-out URL, implicit flow, and publisher domain properties on single-tenant and multi-tenant applications. Grants access to all fields on the application registration authentication page except supported account types:

microsoft.directory/applications.myOrganization/authentication/update

Grants the same permissions as microsoft.directory/applications/authentication/update, but only for single-tenant applications.

microsoft.directory/applications/basic/update

Ability to update the name, logo, homepage URL, terms of service URL, and privacy statement URL properties on single-tenant and multi-tenant applications. Grants access to all fields on the application registration branding page:

microsoft.directory/applications.myOrganization/basic/update

Grants the same permissions as microsoft.directory/applications/basic/update, but only for single-tenant applications.

microsoft.directory/applications/credentials/update

Ability to update the certificates and client secrets properties on single-tenant and multi-tenant applications. Grants access to all fields on the application registration certificates & secrets page:

microsoft.directory/applications.myOrganization/credentials/update

Grants the same permissions as microsoft.directory/applications/credentials/update, but only for single-tenant applications.

microsoft.directory/applications/owners/update

Ability to update the owner property on single-tenant and multi-tenant. Grants access to all fields on the application registration owners page:

microsoft.directory/applications.myOrganization/owners/update

Grants the same permissions as microsoft.directory/applications/owners/update, but only for single-tenant applications.

microsoft.directory/applications/permissions/update

Ability to update the delegated permissions, application permissions, authorized client applications, required permissions, and grant consent properties on single-tenant and multi-tenant applications. Does not grant the ability to perform consent. Grants access to all fields on the application registration API permissions and Expose an API pages:

microsoft.directory/applications.myOrganization/permissions/update

Grants the same permissions as microsoft.directory/applications/permissions/update, but only for single-tenant applications.

• Create and assign a custom role in Microsoft Entra ID
• List role assignments

Was this page helpful?

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