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.

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

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
• Upcoming research at Stack Overflow
• The reverse mullett model of software engineering
• Featured on Meta
• Testing a new version of Stack Overflow Jobs

Hot Network Questions

• Do I have to sign a new offer letter after working almost three months?
• Synonym for "turn around" in the given context?
• Is it possible to establish a shared secret over an untrusted unidirectional channel?
• DB: Can I still use the return journey if I miss the outbound train?
• How to merge only the necessary vertexes?
• What are the logistics behind getting everyone on and off a sandworm?
• Do thoughts work as an info-dump?
• About countif but ignore empty cells with formulas in it
• Romans 9:5 Is this a scriptural evidence for Pauline Trinitarian Christology
• What is Unity's definition of time?
• Extracting a subsequence Cesàro converging to the limsup of the Cesàro sums
• Why does Ripley buy six train tickets?
• If Crew Dragon can dock autonomously, why is there a crew aboard when they change from docking port to another?
• Rear cable length
• Book series set after a nuclear war - sickly hacker genius and an Amazonian goth battle-priestess/nun
• Can the word "christen" be used in an entirely non-religious context to describe the naming of something like a building?
• What are these things in the wall of the spare room?
• Is there a site where I can check on what Congressperson voted for which bill?
• What adhesive properties does chewing gum have under conditions found in space?
• Are there non-antisymmetric solutions to the electronic Hamiltonian?
• Given MAC address, how to tell if interface is wifi
• Sentence with a subordinate clause with a passive infinitival clause complement
• Increasing sequences and Wieferich primes
• Why some USA launches are visible in Europe

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

Troubleshooting consent in Azure AD

This is a general guide for troubleshooting consent in Azure AD . It will help resolve majority of the consent related scenarios (Not all of them). In general, the application is trying to sign-in or get an access token for a resource which has not been consented by the user or admin. In general, you want to make sure all of the permissions needed by the application have been consented to.

This article only applies to OpenID Connect and OAuth2 based authentications. SAML based applications which may throw the same type of errors however may have a different solution. Generally, the issue will be inside the SAMLRequest. Either the configuration on the third-party SAML Service Provider or Azure AD does not match.

You get one of the following similar messages…

• Need admin approval
• AADSTS65001: The user or administrator has not consented to use the application with ID ‘{App-Id}’ named ‘{Name-of-App}’. Send an interactive authorization request for this user and resource.
• AADSTS650056: Misconfigured application. This could be due to one of the following: The client has not listed any permissions for ‘AAD Graph’ in the requested permissions in the client’s application registration. Or, The admin has not consented in the tenant. Or, Check the application identifier in the request to ensure it matches the configured client application identifier. Please contact your admin to fix the configuration or consent on behalf of the tenant.
• AADSTS90094: An administrator of <tenantDisplayName> has set a policy that prevents you from granting <name of app> the permissions it is requesting. Contact an administrator of <tenantDisplayName>, who can grant permissions to this app on your behalf. 
• AADSTS90008: The user or administrator has not consented to use the application with ID ‘162841d6-3c61-4676-a2c1-5a9c1e68ccf3’. This happened because application is misconfigured: it must require access to Windows Azure Active Directory by specifying at least ‘Sign in and read user profile’ permission

As you can see from the list above, there are lots of variations of how we basically say, an admin needs to consent to the application.

There are a lot of different reasons for getting a message about admin approval or admin consent is required, or one of the other various messages.

Here are some of the high-level scenarios of what to look for…

• User.Read permission is missing.
• User consent is disabled.
• User Assignment required is enabled.
• Service principal does not exist in tenant for client app.
• Service principal does not exist in tenant for resource.
• Hitting the consent url (prompt=admin_consent & prompt=consent).
• Scopes requested in sign-in request that have not been consented to yet.
• The scope/permission requires Admin consent.
• User Consent Blocked For Risky Apps

Simply adding permissions to an application registration is NOT consenting to the permissions. This is probably the most common mistake. So, what do we mean when we say “consented” to permissions?

Understand Application registrations vs Enterprise applications

In Azure AD, we have an application model that consists of “Application” objects also called “Application registrations” and “ServicePrincipal” objects also called “Enterprise applications” and how their relationship works together based on the required permissions set up on the Application object.

To learn more about that relationship, review the following article…

https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

Assigning permissions to the ServicePrincipal object is what defines when we say “consented” to.

Understand Delegated permissions vs Application permissions

There are two types of permissions: Delegated and Application permissions.

To learn more about permissions in Azure AD, review the following articles…

• https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent
• Understanding the difference between application and delegated permissions from OAuth2 Authentication Flows perspective

You need to make sure you apply the correct permission configuration in the Application registration and consent to that permission.

Understand the Azure Active Directory Consent Framework model

There is a reason why we are asking for consent. In most cases, the sign-in request or based on the application configuration, something has not been consented to yet that requires consent. Understand our consent framework…

• https://docs.microsoft.com/en-us/azure/active-directory/develop/consent-framework-links
• https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-admin-consent
• https://docs.microsoft.com/en-us/azure/active-directory/develop/application-consent-experience

Make sure the Application has the permission to allow a user to sign in. (I.e. User.Read permission)

First and foremost before we go into any troubleshooting, lets make sure your app allows users to sign in.

If you own the Application registration, a t minimum, any application where you expect a user to sign in, you should at least have the Microsoft Graph “User.Read” or “Openid” Delegated permission added to the Application registrations API Permissions and the permission has been consented to…

Troubleshooting

I suppose that’s enough of concepts and theory. Let’s start with the troubleshooting.

Step 1: Get the sign-in request sent to Azure AD.

Based on the parameters being passed to Azure AD, we can start figuring out why the consent screen is being prompted and why it is failing.

First, we need to understand the request sent to Azure AD.

A sign-in request looks something like this…

Azure AD V1 OAuth2 endpoint: https://{Aad-Instance}/{Tenant-Id}/oauth2/authorize?client_id={App-Id}&response_type=code&redirect_uri={redirect-uri}&resource={App-URI-Id}&scope={Scope}&prompt={Prompt}

Azure AD V2 OAuth2 endpoint: https://{Aad-Instance}/{Tenant-Id}/oauth2/v2.0/authorize?client_id={App-Id}&response_type=code&redirect_uri={redirect-uri}& scope={Scope}&prompt={Prompt}

If you’re not sure how to get this or see this sign-in request…

• If you’re using a browser, look at the address bar
• If you’re not using a browser or still can’t see the address bar in the browser, then a HTTP capture tool like Fiddler will be required.

If you just want to skip finding the root cause and go straight to resolving the issue, go to Step: Perform admin consent .

Here is a quick table for you to use and track the information obtained from the sign-in request.

For example, your table might look like this…

The information obtained from this sign-in request will be used throughout the troubleshooting steps. I will reference them like this…

{App-Id} from the table above.

Step 2: Do you allow users to consent?

First check if User consent is allowed in your organization…

• Sign in to the Azure portal @ https://portal.azure.com
• Go to Azure Active Directory
• Go to Enterprise applications
• Go to User settings
• If “ Yes ” is selected, then users can consent to permissions which do not require Admin consent. Move on to the next step.
• If “ No ” is selected, Users will always get the “Need admin approval” message. An admin must perform admin consent. Go to Step: Perform admin consent
• Step 3 will cover the App-Id in more detail.
• Step 4 will cover the permissions in more detail.

Step 3: Verify the application being used.

Verify if the application exists in the tenant.

• Ensure you switch to the correct tenant based on the {Tenant-Id} from the table above.
• Go to Enterprise applications .
• Switch Application Type to All Applications and search for the {App-Id} from the table above.
• If the application is not found, this would be the cause of you getting the consent messages. Go ahead and skip to Step: Perform admin consent .

If the application is found, go to the next step.

Step 4: User assignment required

While in the Enterprise application , go to Properties and review the User assignment required setting.

If user assignment is required, an admin must consent to this application. Go to Step: Perform admin consent .

If user assignment is not required, go to next step.

There is always confusion that when you consent to an application for all users in the organization that this will allow all users to access the application. This is not true; we will still follow the user assignment rules. Only those users assigned to the application can access it.

Otherwise, if you really do not want to perform admin consent, then the only other option would be to turn off user assignment required , have the user consent when they access the application, and turn user assignment required back on.

Step 5: Verify the permissions.

Let’s next verify that the scopes (or also called permissions) in the sign-in request are listed in the permissions section of the Enterprise App…

• If the application is found from the step above (Step 3), go ahead and select that application.
• Go to permissions…
• Compare what is listed on the permissions page and what is listed as {Scope} from the table above in the sign-in request. The permissions listed on this page are the permissions that have been consented. Note : Pay extra attention to the permission type. Keep in mind that Delegated permissions are for when users sign in and Application permissions are for when the service principal is used to authenticate via the client credential flow. Note : OpenID Connect scopes are generally not listed in the Enterprise application. Don’t worry if the following are not listed…
• Openid: Sign users in
• Email: View users’ email address
• Profile: View users’ basic profile
• Offline_access: Maintain access to data you have given it access to

Note : if {Scope} from table above is blank or contains less than what is listed on the permissions page, go ahead to the next step.

If there are other scopes in {Scope} from the table above that are not on the permissions page, then go to Step: Perform admin consent . These missing permissions still need to be consented.

Step 6: Verify the resource exists in your tenant.

Easiest way to do this is generate a request that looks like this…

https:// {Aad-Instance} / {Tenant-Id} /oauth2/authorize?response_type=code&client_id= {App-Id} &resource= {App-Uri-id}

You might get one of 4 behaviors…

• You will be allowed to sign-in (This is the behavior you want to see) Your good to go to next step. In most cases, if you see the “code” parameter in the address bar, this means authentication piece was successful.
• AADSTS650052: The app needs access to a service (\”https://api.contosocloud.williamfiddes.onmicrosoft.com\”) that your organization \”mycloude5.onmicrosoft.com\” has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service subscriptions.   This means the resource does not exist in your organization. To resolve this, use the following consent URL… https://login.microsoftonline.com/ {Tenant-Id} /oauth2/authorize?response_type=code&client_id= {App-Uri-id} &prompt=admin_consent

• AADSTS500011: The resource principal named ‘ {App-Uri-Id} ‘ was not found in the tenant named ‘ {Tenant-Id} ‘. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.This means either the {App-Uri-Id} specified is not valid at all or is only available as a single tenant application. Otherwise meaning this resource can not be accessed by external organizations or does not exist. You will need to work with the application owner. You will need to verify that {App-Uri-Id} and {Tenant-Id} is correct. If the {App-Uri-Id} is owned by a different {Tenant-Id} then the app registration for {App-Uri-Id} must be set up as a multi-tenant application. Otherwise the {Tenant-Id} must be the same tenant as where the app registration for {App-Uri-Id} is located.

Step 7: Verify if the prompt parameter is being passed.

Sometimes, the way in which your signing into the application is always passing the prompt parameter of consent or admin_consent . Once the application has been consented to, make sure the prompt parameter is not specified. Otherwise, your users might always get the consent error.

You sign-in request might look something like this…

https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All&prompt=consent

So simply remove the prompt parameter and now it should look something like this…

https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All

Step: Perform admin consent.

• Have the admin (user with the Global/Company administrator role or a Application Administrator role) access the application normally.
• When the consent screen appears, review the request permissions. Note : If an admin is not sure what the permissions allow, then the admin must work with the application vendor to understand the permissions and what they are used for. Microsoft support may not know what these permissions do or why the permissions are needed.

Step: Force Admin Consent

If the admin does not get the consent screen,

Remember step 1? Grab that sign-in address and add &prompt=consent

So, for example, the sign-in request the admin should use will look something like this…

https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile&tresource=https://graph.microsoft.com&prompt=consent

If the permissions needed are not in the application registration, then the V2 endpoint can be used… (V2 endpoint requires each permission scope to be passed in the scope parameter)

https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All&prompt=consent

Permission scopes used by the application must be provided by the application owner.

• Consent for Application permissions will always require admin consent from a Global/Company administrator. Application permissions must be added within the application registration on the applications owning tenant.
• Application admins can also consent to Delegate permissions which require admin consent.
• When using the adminconsent URL, the permissions must already be configured with the application registration. Otherwise meaning, the application owner must have their application correctly configured with Azure AD. adminconsent URL looks something like this… https://login.microsoftonline.com/ {Tenat-Id} /adminconsent?client_id= {App-Id}

For more information about troubleshooting consent issues…

You can use the Azure AD Audit logs to get more details…

• Sign in to the Azure Portal @ https://portal.azure.com (Use a account that has permission to read Audit logs. Like a Global Admin or Security Reader).
• Go to Azure Active Directory .
• Go to Audit logs .
• Category: ApplicationManagement
• Status: Failure
• Activity: Consent to application
• Find and select the app that’s failing to consent.
• Observe the STATUS REASON . This might give you more details. For certain scenarios like “Microsoft.Online.Security.UserConsentBlockedForRiskyAppsException” will require you to perform a Admin consent even though you may allow users to consent and the permission normally does not require an admin to consent.

For more information, see the following…

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-sign-in-unexpected-user-consent-error#requesting-not-authorized-permissions-error

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-sign-in-unexpected-user-consent-prompt

One Thought to “Troubleshooting consent in Azure AD”

[…] AADSTS650056, AADSTS90094, AADSTS90008 – see Azure AD Dev support team blog for the possible […]

Leave a Comment Cancel reply

Recent posts.

• ‘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
• How to bundle consent
• May 2024  (2)
• 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

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 service app registration automatically allowed for clients without approval

I have an Azure Web App Service that will be used in a service-to-service environment. I want that this service to use the Azure AD app registration for authentication. This service will due to it's implementation only use client credentials grant type for the authentication process.

I expect that since my client app registration doesn't have any API permissions configured against my service app registration that the authentication should fail, but it doesn't; it returns a valid access token with my service app registration Application ID URI as audience that can be used to access my Azure App Service.

So, why does this happen? I expect that an app registration isn't available until there is an approved API permission configured for my client registration, but this isn't the case.

This is what I have done:

I have created an app registration the following way to make this work:

• Made a app registration manually in Azure AD with
• Supported account types set to Accounts in this organizational directory only
• Added an Application ID URI
• Added a client secret (used by the Azure App Service configuration)
• Created an App role (since this is a requirement to be able to use client credentials grant type as far as I have understood)

This app registration is then connected to the Web App service using the Authentication / Authorization configuration on the App Service using advanced configuration (not that this is relevant for this issue).

I also created a another app registration that identifies my client service. This service has not been configured to access the service app registration. I then use this client service credentials to authenticate against my Azure AD using client credentials grant type with the service Application ID URI as scope.

I know that I can limit the access in my code by checking the role, but that's not the issue here, I am wondering why it returns a valid access token at all with my service Application ID URI as audience.

NOTE: I have found that if I go to enterprise applications and set User assignment required? to Yes, it will return 400, but is there any way to have this as default for all new app registrations, to ease the app registration?

• azure-app-services

You must log in to answer this question.

Browse other questions tagged entra-id azure-app-services ..

• The Overflow Blog
• Upcoming research at Stack Overflow
• The reverse mullett model of software engineering
• Featured on Meta
• Testing a new version of Stack Overflow Jobs

Hot Network Questions

• How can they move large amounts of money from the USA to a Swiss bank without getting caught?
• Exercise about Order statistics from uniform distribution
• Is air less dense than chimney exhaust?
• Are the 0BSD and MIT-0 licenses public domain declarations?
• Given MAC address, how to tell if interface is wifi
• Do I have to sign a new offer letter after working almost three months?
• Why doesn't Japanese pineapple hurt my mouth, unlike what I eat in the US?
• How is the channel ability word actually implemented in the rules?
• Pipe union fitting leaks slowly. How to seal?
• Alright to leave or use electric bicycle in rain
• What adhesive properties does chewing gum have under conditions found in space?
• About countif but ignore empty cells with formulas in it
• What are the tool proficiencies for the Urban Bounty Hunter background?
• "for what it's worth — used to say that one/someone is not sure whether something one/someone is about to say will be helpful or valued"
• Can the word "christen" be used in an entirely non-religious context to describe the naming of something like a building?
• What are the logistics behind getting everyone on and off a sandworm?
• How to only print odd characters of a string in terminal?
• Wind needed to deflect a bullet
• When and how did the definition of continuity in terms of function's oscillation come into picture?
• Do thoughts work as an info-dump?
• How do you validate the credibility of arXiv cited papers in IEEE conferences?
• Short story about shoes that may have talked to other pairs of shoes and were possibly trying to find their owner or way home
• What is Unity's definition of time?
• Extraterrestrial organisms similar to humans and design

Restricting which managed identities can access an Azure application

When you attach a service account to a VM instance on Google Cloud, an application running on the VM can obtain an access token for the attached service account by querying the metadata server. It can then use this access token to access Google Cloud resources (assuming the service account has been granted access).

Applications can also obtain an ID token for the attached service account. Google Cloud doesn’t really specify what to use this ID Token for, but one common use case is to use it for authenticating service-to-service communication .

On Azure, managed identities serve a similar purpose as attached service accounts on Google Cloud. By attaching a managed identity to a compute resource such as a VM, you enable an application that runs on the VM to obtain access tokens. It can then use these tokens to access Azure resources.

An interesting difference between managed identities and attached service accounts is that managed identities don’t support ID Tokens. To use managed identities for service-to-service communication, you have to use an access token, and a common way to do this is to:

• Register a new application in Azure AD that represents the target resource or service
• Let the calling service use managed identities to obtain an access token for the Azure AD application
• Use the access token to authenticate communication

Using access tokens for authenticating service-to-service communication is actually more in line with how OAuth 2 is supposed to be used than using ID Tokens for this purpose. So I actually like Azure’s approach here. But having to manage an application in Azure AD also creates a new challenge – how do we control access to the application? How can we ensure that only certain managed identities can obtain access tokens for the application?

Let’s find out.

Creating a new application

To get started, we need to register a new application in Azure AD . We’re not planning to use 3-legged OAuth with this application, so it’s not necessary to specify a redirect URI.

As every object in Azure AD, applications have an Object ID . But more commonly, applications are referred to by their Application ID (AppID). This identifier also serves as the OAuth Client ID :

There is another identifier for applications, which is the Application ID URI . If set, Azure AD uses this URI as audience ( aud ) in access tokens. An Application ID URI is also necessary if we want to use managed identities to obtain access tokens for the application. So let’s add an Application ID URI to our app:

• Open the Expose an API blade of the app registration,
• Next to Application ID URI , click Set
• It doesn’t really matter which URL we use here, so let’s keep the default which in my case is api://00dea43a-04ed-4460-975f-8fe739af9a06 .

To make things a bit more interesting, let’s further customize the app to include a few custom claims in the access tokens:

• Open the Token configuration blade
• Select Add optional claim .
• Select Access and check idtyp and tenant_region_scope .

As to be expected, our new application shows up in the output of Get-AzureADApplication :

Somewhat more interestingly, the portal also created a service principal for us, as indicated in the output of Get-AzureADServicePrincipal :

Notice how the 2 objects are linked by a common AppID.

If we view the details of the service principal, we notice that AppRoleAssignmentRequired is false – we’ll get to that later:

Testing the application

To check if the application works, and whether the token includes the claims that we expect, let’s do a quick test without managed identities first:

• Open the Certificates & secrets blade
• Select New client secret .
• Enter a description and select an expiry date.
• Select Add .

Let’s fire up a PowerShell prompt and request an access token:

Connect to Azure AD:

Populate a few variables:

In my case, this looks like:

Now we can request an access token for the application by passing the Application ID URI in the resource parameter:

This returns:

If we decode the JWT, the body looks like this:

We can see that:

• aud and appid both contain the AppID of our application
• oid and sub both contain the Object ID of the application’s service principal
• idtyp is app, indicating that the token was issued for an application
• tenant_region_scope , our second custom claim, contains the region code
• ver is 1.0 , so we’re getting the old token format by default. We can change that by updating the application manifest if we want, but it doesn’t really matter here.

This worked as expected, but the endpoint we used is actually deprecated. The new endpoint doesn’t support a resource parameter anymore – instead, it expects us to specify a scope . Because we haven’t created any custom scopes, we can use <App ID URI>/.default as scope:

Now that we know the application works as expected, we can delete the secret and move on to managed identities.

Obtaining tokens using a managed identity

To test managed identities, let’s create a new Azure VM that uses a system-assigned managed identity . Once the VM is up and running, we can a new service principal in the output of Get-AzureADServicePrincipal :

Each managed identity (system-managed or user-managed) also comes with a new App ID. Interestingly, these applications don’t show up in Get-AzureADApplication however.

On the VM, we can now request a token from the Azure Instance Metadata Service (IMDS) by using the “old” method of passing the Application ID URI in the resource parameter:

This token looks very similar to the one we saw before, but this time the oid and sub both contain the Object ID of the managed identity’s service principal (as shown in Get-AzureADServicePrincipal above).

Restricting access

Notice that we didn’t have to do anything to allow our managed identity to obtain access tokens for the application – it just worked. That’s because AppRoleAssignmentRequired is set to false by default, meaning anybody (in the tenant) can access the application.

To restrict access to the application, we first have to toggle the AppRoleAssignmentRequired flag. We can do that in the portal by opening the enterprise application’s Properties blade and setting User assignment required to Yes :

Notice that it can take a long time (i.e., hours) before this change takes effect on our running VM – but if we wait long enough, we can notice that requesting tokens now fails:

Instead of allowing access by default, we’re denying access by default now. But how can we re-grant access to our managed identity? For that, we need to create an app role :

• Open the App roles blade of the app registration.
• Display name : AppUsers
• Allowed member types: Applications
• Value: App.Use
• Description: Allow usage of app
• Select Apply

To list the app roles defined by an application in PowerShell, we can use Get-AzureADApplication again:

Now we grant the App.Use role to the managed identity:

If we look at the Users and groups blade of the enterprise application, we can now see that centos-1 (that’s the VM’s managed identity) shows up as having access to the application:

Now let’s return to the VM and run the previous PowerShell command again:

Thanks to the app role assignment, we’re getting a token again:

By granting or revoking the App.Use role to individual service principals or managed identities, we can now control which managed identities can obtain tokens for the application.

Related posts

• Exporting RSA public keys in .NET and .NET Framework
• Importing RSA public keys in downlevel .NET and .NET Framework versions
• Best practices for using workload identity federation
• Encoding public keys in PEM format
• What's inside a PEM file
• Share this article:

The Daily Iowan

Demystifying the Process of LEI Registration: A Step-by-Step Guide

The Legal Entity Identifier (LEI) is a unique global identifier assigned to legal entities participating in financial transactions. Whether you are a corporation, partnership, trust, or fund manager, obtaining an LEI is essential for complying with regulatory requirements and enhancing transparency in financial markets. This article will provide the step-by-step process of the LEI Register , simplifying what can seem like a complex procedure.

Understanding the Importance of LEI Registration

Before delving into the registration process, it’s crucial to understand why obtaining an LEI is necessary. LEIs are used to identify legal entities engaged in financial transactions worldwide uniquely. They are vital in improving transparency, risk management, and regulatory oversight in the global financial system. Many regulatory bodies and financial institutions require entities to have an LEI to participate in certain transactions.

Step 1: Determine the Need for an LEI

The first step in the LEI registration process is determining whether your organization requires an LEI. Evaluate whether you engage in financial transactions necessitating an LEI, such as trading securities or derivatives. Check with regulatory authorities or counterparties to confirm specific requirements for LEI use in your jurisdiction or industry.

Step 2: Choose an Authorized Register

To obtain an LEI, you must select an authorized LEI for registration. These are organizations accredited by the Global Legal Entity Identifier Foundation (GLEIF) to issue and maintain LEIs. Research reputable LEI Registers that offer registration services and comply with regulatory standards. Ensure the chosen service is recognized and trusted within the financial industry.

Step 3: Gather the Required Information

Before initiating the registration process, gather all necessary information about your legal entity. This typically includes legal name, registered address, corporate structure, ownership information, and primary business activities. Having this information readily available will streamline the registration process and minimize delays.

Step 4: Submit Registration Application

Once you have chosen the right service and gathered the required information, proceed to submit your registration application. The application form will prompt you to enter detailed information about your legal entity. Provide accurate and up-to-date information to ensure the registration process proceeds smoothly.

Step 5: Verification and Validation

After submitting your application, they will verify the information provided. This may involve validating corporate documents, verifying ownership details, and confirming the legal entity’s existence with relevant authorities. Be prepared to respond to any inquiries or requests for additional documentation during this stage.

Step 6: Receive LEI Assignment

Upon successful verification and validation, they will assign a unique LEI to your legal entity. This LEI will be used to identify your organization in financial transactions and reporting. Once assigned, the LEI should be renewed annually to maintain its validity and compliance with regulatory requirements.

Step 7: Use and Maintain Your LEI

With your LEI assigned, you can use it to report obligations, regulatory filings, and transactions requiring LEI identification. Ensure that your LEI information remains accurate and up-to-date by promptly updating any changes to your legal entity’s details, such as address, ownership structure, or business activities.

Obtaining an LEI through an accredited service is straightforward. It involves determining the need for an LEI, choosing a reputable LEI Register, gathering the required information, submitting an application, undergoing verification and validation, receiving an LEI assignment, and using and maintaining the LEI. By following this guide, you can confidently navigate the LEI registration process and ensure compliance with regulatory requirements.

• Newsletters
• Print Subscription
• Reprints and Permissions
• Publishing Guidelines
• Editorial Policy
• Job Descriptions
• Scholarship Opportunities
• Advertising Info / Rate Card
• Today’s Classified Ads
• The Daily Iowan archives (1868-present)

This browser is no longer supported.

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

Configure Azure AD Graph permissions for an app registration

• 7 contributors

Azure Active Directory (Azure AD) Graph is deprecated and is in its retirement path . We recommend that you follow the App migration planning checklist to help you migrate your apps to Microsoft Graph .

Your app might still temporarily require Azure AD Graph permissions to access resources. You can follow one of four methods described in this article to configure Azure AD Graph permissions for your app registration:

Use the Microsoft Entra admin center to find the APIs your organization uses

Update the application manifest on the microsoft entra admin center, use the microsoft graph applications api.

Any app using Azure AD Graph will still stop functioning after the API is retired. For more information, see Migrate Azure AD Graph apps to Microsoft Graph .

Prerequisites

The steps in this article require two sets of privileges:

• Privileges to add permissions to an app registration
• Privileges to grant those permissions to the app registration.

A user with the Global Administrator role can do both, while a user with the Application Administrator or Cloud Application Administrator role can only add the permissions. To help you enforce separation of duties and least privilege access, separate the tasks of adding permissions and granting permissions to different users. For more information about the actions supported by these roles, see Microsoft Entra built-in roles .

In addition, you need the following resources and privileges:

• Sign in to an API client such as Graph Explorer to run the HTTP requests.
• The app used to make these changes must be granted the Application.ReadWrite.All permission.

The Microsoft Graph application object includes a requiredResourceAccess property that is a collection of objects with information about the resource API and permissions. Use this property to configure Azure AD Graph permissions as described in the following steps.

Step 1: Identify the permission IDs for the Azure AD Graph permissions your app requires

Identify the Azure AD Graph permissions your app requires, their permission IDs, and whether they're app roles (application permissions) or oauth2PermissionScopes (delegated permissions). For more information, see Azure AD Graph permissions reference .

Azure AD Graph is identified as a servicePrincipal object with 00000002-0000-0000-c000-000000000000 as its globally unique appId and Windows Azure Active Directory as its displayName and appDisplayName . Run the following request to retrieve the service principal object for Azure AD Graph in your tenant.

Read the SDK documentation for details on how to add the SDK to your project and create an authProvider instance.

In the response object, details for Azure AD Graph application permissions are listed in the appRoles object while details for delegated permissions are listed in the oauth2PermissionScopes object.

Note: The response object shown here might be shortened for readability.

From the preceding truncated output, 311a71cc-e848-46a1-bdf8-97ff7156d8e6 is the permission ID for the User.Read delegated permission while 3afa6a7d-9b1a-42eb-948e-1650a849e176 is the permission ID for the Application.Read.All application permission in Azure AD Graph.

Step 2: Add Azure AD Graph permissions to your app

The following example calls the Update application API to add the Azure AD Graph User.Read and Application.Read.All delegated and application permissions to an app registration identified by object ID 581088ba-83c5-4975-b8af-11d2d7a76e98 .

To update the requiredResourceAccess property, you must pass in both existing and new permissions. Passing in only new permissions overwrites and removes the existing permissions.

Step 3: Verify the Azure AD Graph permissions were added to your app

Verify that your app registration has the Azure AD Graph API permissions you added in Step 2 by:

Calling the Microsoft Graph GET /application/{id} endpoint and reading the requiredResourceAccess property as follows:

Checking the App registrations page in the Microsoft Entra admin center.

Step 4: Grant admin consent

Though you added Azure AD Graph permissions, you haven't granted these permissions to the app. Many permissions require admin consent before they can be used to access organizational data. Sign in to the Microsoft Entra admin center as a global administrator and grant admin consent for the permissions to the app registration.

Grant API permissions without using the consent prompt

When using Microsoft Graph and any related SDKs, you can grant permissions to an app registration without the need to use the Microsoft Entra admin center and selecting the Grant admin consent for [Company] button on the API permissions page. For more information, see Grant or revoke API permissions programmatically .

Sign in to the Microsoft Entra admin center .

Expand Identity > Applications > select App registrations .

In the App registrations window, under the All applications tab, select the app that you want to add Azure AD Graph permissions to.

From the left pane of the window, under the Manage menu group, select API permissions . In the Configured permissions window, select Add a permission .

In the Request API permissions window, switch to the APIs my organization uses tab and search for Windows Azure Active Directory or 00000002-0000-0000-c000-000000000000 . Select from the filtered result set to reveal the Azure Active Directory Graph permissions window.

Select the Delegated permissions or Application permissions tab to choose from the list of delegated and application permissions respectively. Select Add permissions to add the permission to your app registration.

After adding the permissions you need, back in the Configured permissions window, select Grant admin consent to grant the Azure AD Graph permissions to your app registration.

Expand the Identity menu > Applications > select App registrations .

In the left pane of the window, under the Manage menu group, select Manifest to open up an editor that allows you to directly edit the attributes of the app registration object.

Carefully edit the requiredResourceAccess property in the app's manifest to add the following details:

A. You can edit the app manifest on the Microsoft Entra admin center or select Download to edit the manifest locally, and then use Upload to reapply it to your application.

B. To learn more about how to configure the requiredResourceAccess property, see requiredResourceAccess resource type .

C. Refer to the Azure AD Graph permissions reference for details of Azure AD Graph permission names, IDs, and types.

5.1. If the app isn't assigned any Azure AD Graph permissions, add the resourceAppId property and assign the value 00000002-0000-0000-c000-000000000000 representing Azure AD Graph.

5.2. Add the resourceAccess property and configure the permissions.

The following JSON snippet shows a requiredResourceAccess property with Azure AD Graph as the resource, and assigned the User.Read and Application.Read.All oauth2PermissionScope (delegated permission) and appRole (application permission) respectively.

Save your changes.

Back under the Manage menu group, select API permissions and in the Configured permissions for your app registration, select Grant admin consent to grant the Azure AD Graph permissions to your app registration.

Related content

• application object
• Grant permissions programmatically without interactive consent
• Azure AD Graph permissions reference

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