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.

Entra App Registrations and Enterprise Applications: The Definitive Guide

Eric woodruff.

For those that must manage application integrations in Entra ID, it’s an inevitable question: What is the difference between an App Registration and an Enterprise Application? Why are there two different management blades? Why do I see some applications in both places?

I’ll admit that this is not the first take at answering this question, and there are already some good answers out there. Microsoft breaks things down here, Apps & service principals in Azure AD – Microsoft Entra | Microsoft Learn , with a decent visual at the end.

Marilee Turscak also has an excellent breakdown here, The Differences Between App Registrations, Enterprise Applications, and Service Principals in Azure AD | Marilee Turscak .

And John Savill has fantastic video published covering this as well, Azure AD App Registrations, Enterprise Apps and Service Principals – YouTube .

As John points out in his video, the understanding of App Registrations and Enterprise Apps can further be enhanced by understanding OpenID Connect and OAuth 2.0 flows. This is especially important for identity professionals and ITPros who may come from a sysadmin background. Modern authentication flows and concepts may feel foreign to folks who built their career on identity platforms such as Active Directory.

For those that find it easiest to learn by doing, if you want to play around with App Registrations, Enterprise Aps and Service Principals, but don’t want to mess with your prod environment, sign-up for an M365 Developer account, to have your own free tenant to work with here, Developer Program | Microsoft 365 Dev Center

We’ll start with some definitions, and then try to walk through various scenarios that you may encounter. If you don’t see your question answered within the definitions, keep reading… we’ll try to hit on all the areas here. If there is something I’ve missed or isn’t clear, reach out to me on LinkedIn or Twitter (@msft_hiker) .

App Registrations

An application registration (app registration) is the definition of the application, as an application object , in Entra ID. It “explains” to Entra ID what the application wants, such as permissions for certain APIs, as well as where and how the application resides, with information such as the Redirect URI.

For a line-of-business (LOB) it would usually be your developers specifying the contents within an application object. Where identity professionals usually get involved:

• The Entra tenant is locked down, and developers do not have permissions to create App Registrations. Someone with permissions in the tenant will create the app registration and assign ownership to the developer, or potentially work with the developer to configure it.
• The organization has procured an application that they need to integrate into Entra ID. The application may be either a SaaS application or a piece of software run in an IaaS or PaaS environment, or on-prem.

An application definition, at its core, is the application manifest. Except for the value of a secret, any configuration you make within the app registration portal will be reflected in the application manifest.

If we look at My Test Application in the Entra portal:

We can then select Manifest from application configuration blade, and see these represented within the manifest:

In this specific example they are represented as their actually Microsoft Graph API resource identifier; the term scope comes from OAuth 2.0. The portal does a lot of work “translating” the manifest into something easier for those less familiar with the underlying terminology to understand.

In OAuth 2.0 scope effectively equates to permissions, and the majority of what many ITPros may be concerned with as far as integrations go would be Microsoft Graph API permissions. Note that several different APIs can be scoped within an application, not just Graph permissions.

For more details on the application manifest, see Understanding the Azure Active Directory app manifest – Microsoft Entra | Microsoft Learn .

⚠️ Editing the application manifest directly without thoroughly understanding of the changes you are making may break your application.

App registrations are considered a globally unique definition of the application across all Entra tenants, even if it’s an application that is only to be used by your tenant.

Entra ID, as a global Identity-as-a-service (IDaaS) platform, has shared backend components, and for the purposes of a multitenant application it’s important to ensure that the application is globally unique from a security and functionality perspective. Since organizations can choose to change a single-tenant application to a multitenant application, the ID needs to remain unique.

Service Principals

Service principals are a security principal that define the allowed permissions for the application in Entra ID and give the application representation within the directory. Users are another type of security principal – we assign permissions and roles to users within Entra ID, as well as other associated resources.

I highlight allowed permissions because while the App registration defines what permissions the app developer needs for the application to function, it’s the service principal that actually defines what is allowed in the tenant. The service principal is also the object that will appear in various Azure “pick lists”, if you are applying something like a Conditional Access policy, or assigning the service principal rights in an Azure subscription.

There are three types of service principals in Entra ID:

• Enterprise applications
• Managed identities

Since legacy service principals are something that organizations shouldn’t be using these days, we really just have two types that we’ll focus on.

Enterprise Applications

Enterprise applications, as a type of service principal, could effectively be thought of as a child if you were diagram a hierarchy. Now if service principals are the parent to enterprise applications, why is the blade in Entra admin center titled Enterprise applications? It’s because that’s primarily what we are concerned with when working within that blade. If you’ve used PowerShell or the Graph API for enumerating and working with enterprise applications, it’s why you use commands like get-azureadserviceprincipal or /servicePrincipals in Graph for accessing these.

If you browse to Enterprise applications, you’ll notice that the view is actually pre-scoped to Application type == Enterprise Applications

We can actually clear the filter, and we’ll end up being able to view not just our enterprise applications, but also our service principals, and Microsoft applications.

Microsoft applications are still service principals in our Entra tenant, but they generally relate to more tightly integrated services. For the purposes of our exploration, we won’t dive into these, but will note that they should primarily be left unaltered.

Every time you see the term enterprise application, just remember it’s a type of service principal.

Gluing the two together

It’s important to come back to the understanding that there is a direct link between an app registration and a service principal.

Single Tenant Application

For a single tenant application, we’ll have the app registration along with the corresponding service principal. If the app registration occurs in the tenant, there will always be a corresponding service principal created.

Multitenant Application

For a multitenant application, we’ll have the app registration along with the corresponding service principal in all tenants that the application has been granted consent to.

Consent Grant

This is probably a good place to bring up that the application consent grant process is what permits the service principal creation with the associated API permissions. This is when you receive a popup such as the following:

At the time of providing the consent grant, a service principal is created in your Entra tenant indicating the permissions that were consented to.

What about Passwords

This is where it gets a bit complex, and existing documentation tends to really pass over what passwords live where and when to use what.

For purposes of this document I’ll use the term password to represent a shared secret. I mention this because while the Entra admin center places these under the term Client secrets , in the application manifest and service principal definition, passwordCredentials is what holds the data on the secret. For simplicity we’ll be looking at shared secrets, but you can, and should whenever possible, use Certificates , also referred to as keyCredentials .

Most documentation would lead you to believe that you create a password in the application object, and then this is referenced by the service principal. However, you also can create and associate a password with the service principal itself.

Service Principal Passwords

We can test creation of a service principal and assign a password directly to it with the following bit of PowerShell:

Reinforcing the relationship between a service principal and an application object (application registration), notice that we must reference an application ID when creating a service principal. This means we always have to create an application object before being able to create a service principal.

This should give us output with a password. If we query Graph for the details of the service principal, we can see the following:

Now, if we look at the app registration for this service principal, note that the passwordCredentials is empty:

And to validate this, we can look at the associated application object in the portal:

Application Object (App registration) Passwords

This time, let’s create another service principal but we’ll set a password in the application object:

Interestingly we see that the service principal has no reference to the password:

However looking at the app registration, we can see the password reference:

If we look at the associated application object, we can see this password:

Since there is no place in the Entra admin center that exposes service principal passwords, there is nothing to compare to there.

So Which Passwords Where?

If we can register a password on either the service principal or application object, how do we decide which to use and where?

In a test, I’ve assigned both the service principal and application object with a password set to an Azure subscription, and you can authenticate using either type of password credential.

Service Principal password:

Application Object password:

Notice the service principal and application object relationship again. While both are a type of service principal shown in the connection, we had to use the client ID as the user ID. The client ID is a value that only exists within the application object.

Most documentation from Microsoft indicates that if you are using service principals for integrations into Azure for things like subscription management, to use service principal passwords. I don’t see any downside to this, with the exception that the secrets cannot be managed within the Azure portal.

From a security boundary perspective, some folks will mention that not showing secrets within the Azure portal helps create a security boundary, however, many tenant-wide RBAC roles in Entra ID that permit secret management, such as adding/replacing/removing secrets, would have that capability on both service principals and application objects.

If you are developing or deploying a multitenant application you will need to use a client secret (password) within an application object (or preferably a certificate). This is because only the credentials in an application can be used across tenants.

This is where an understanding of OAuth 2.0 comes into play. There are several different ways in which OAuth 2.0 flows work, and you can also add OpenID Connect on top of things there as well. Keeping things a bit simplified, we’ll look at two common examples:

• When you attempt to access the application, you will be sent to the Entra ID OAuth 2.0 authorization endpoint.
• If you are not signed in you will be asked to do so.
• If you have not previously consented to the application, you will be prompted to. Alternatively, your organization may have already performed a tenant-wide consent.
• The app registration defines a redirect URI, which you will pass an authorization code you receive from Entra ID back to.
• The application will then take the authorization code and pass it to Entra ID, and in return obtain an access and refresh token.
• The access token can then be used for access to Microsoft Graph API, as an example, in which the permissions you consented to, the application will have access to on your behalf.
• When onboarding an application with application permissions, the application permissions must be granted with admin consent.
• Upon authentication and consent, you will provide a response to the application with your tenant ID.
• The application takes the secret and provides it to Entra ID, along with your tenant ID, to request an access token for the consented permissions.
• Entra ID provides the access token, and the application can then use that for access to the Microsoft Graph API, leveraging the permissions you granted.

It’s important to understand that in the world of Entra ID, there is a common OAuth 2.0 endpoint. While ever tenant has a security boundary, Entra ID itself is a single identity platform, and this is what allows authorization codes and secrets to be leveraged across tenants by the application developer. This is a good thing, as it removes any need for a developer to get into the sticky business of having to manage and coordinate secrets with customers.

If you are using a multitenant application, you can see these results yourself if you look at your Entra Sign-in logs for service principals:

If we look at the sign-in above, and then check our enterprise applications we’ll find the associated service principal ID (object ID):

And if we look at the app registration in the other tenant:

And we can even see that the certificate registered in the app registration was used for authentication, by matching the key ID. Of course, this is only to show that the secret/certificate is used cross-tenant, and we luckily have access to both tenants in our example:

In my example I’m using a certificate, not a password, as the sample code used was out of the box designed to use a certificate (key pair).

Questions and Scenarios

Now that we have some foundation, let’s take a look at some common questions and scenarios.

Will Every App Registration Have a Corresponding Service Principal

Yes. Every app registration will have at least one service principal, which is created in the home tenant that the app registration was created in.

There are some examples of PowerShell code out there that will create a service principal but are missing the WindowsAzureActiveDirectoryIntegratedApp tag, which will prevent them from showing up in enterprise applications (even with the filter removed).

Will Every Enterprise Application/Service Principal have a corresponding app registration?

Yes, but not necessarily in your tenant.

To be more specific, and this is also where we need to understand that enterprise applications are more than just OAuth 2.0/OIDC applications.

If the application is OpenID Connect or OAuth 2.0, as we have seen above, the resource tenant will only have a service principal in the applications home tenant.

However, you may see other times that when you create an enterprise application that an associated app registration will show up in your tenant. In reality any application you add from enterprise applications – SAML, Linked, Password-based, or Entra Application Proxy, are all going to create an associated app registration. Why? Because the service principal was not designed to hold all the information that defines the app (back to our definition of an app registration).

You can add a SAML application into Entra ID, and then go to its corresponding app registration and look at the manifest.

Here is an example of the manifest for the SAML app of Claims X-Ray. Notice that some of the configuration settings for the application, such as the ACS URL, are stored within the manifest.

If you’ve integrated certain SAML applications and wanted to assign groups to custom roles to then emit in the SAML response, you would find yourself in the App registration to further define those.

But take notice that from a permissions perspective, going back to the security principal side of things, it is the enterprise application where you configure who is allowed to access the application.

Why do we need to handle the secret management for our single tenant application?

This is something that your developers are likely used to. Going back to the beginning of this post, while you have to agree to the permissions the application developer needs, the developer is the one who would be likely handling the secrets.

But if you’ve purchased a piece of software that ITPros would be the owners of – third party Exchange Online backup software, Identity Governance and Administration products, security assessment platforms – these are the things you will need to provide the secret to, in order for the applications to obtain the necessary access tokens. But, because of the way that OAuth 2.0 functions, you still need to go through that initial consent process.

What about for certain SaaS applications? Why do they need secrets?

It usually comes down to the type of SaaS application and how the applications multi-tenancy is handled.

Look at Salesforce. While this is a SaaS platform, each instance of Salesforce is left up to the organization that has acquired it to manage who can authenticate to what and how. So, while Salesforce supports OpenID Connect, it’s up to the organization that manages their instance of Salesforce to configure that. In this example for every Entra ID customer out there with Salesforce and OpenID Connect, there are that many essentially “duplicate” app registrations for it in Entra ID. Also – nothing is forcing Salesforce (in this example) to register their application in Entra ID. And it could easily go down a rabbit hole quite quickly – what about needing to register with Okta? Ping? Who and what do they have potentially partner relationships with? You also have to think about things like token customization and the data that you may want to be sent to Salesforce. You need to have control over the app registration to be able to do this with OIDC.

As such, it’s common for large and complex enterprise-oriented SaaS vendors to still require you to manage both ends of the OIDC/OAuth 2.0 configuration.

Why Can I consent in either the enterprise application or app registration?

Because the portal tries to make things magic. It’s simply an ease thing – the function behind the scenes is the same, regardless of where you consent.

Why do some service principals I’ve created with PowerShell not appear in the Enterprise applications view?

When creating a service principal, if the tag WindowsAzureActiveDirectoryIntegratedApp is not included in the definition, the service principal will not show up in Enterprise Applications. Microsoft is not completely clear as to why this tag is optional, as the application will still be available in the Conditional Access and Azure RBAC pick lists. One could presume you would not necessarily concern yourself with service principals created for things like automation products. Still, if you accidently created a service principal without this, you could simply run the following command to update it:

Additional Resources

Authenticating to Entra ID with PowerShell using a service principal, Using a service principal | Microsoft Learn .

OAuth 2.0 client credentials flow on the Microsoft identity platform – Microsoft Entra | Microsoft Learn

Microsoft identity platform and OAuth 2.0 authorization code flow – Microsoft Entra | Microsoft Learn

Some great explanations from Frontegg on OAuth 2.0 grant types, OAuth Grant Types: Explained | Frontegg

Additional explanations from Frontegg on OAuth 2.0 flows, Demystifying OAuth Flows | Frontegg

Okta guide to OpenID Connect and OAuth 2.0, An Illustrated Guide to OAuth and OpenID Connect | Okta Developer

About This Posts Featured Image

The chosen photo is the work of Javier Allegue Barros , used under the  Unsplash license .

Writing about all things identity and identity adjacent in the Microsoft ecosystem of Entra ID and Active Directory.

Recent Articles

Eric Woodruff © 2024. Site by Rare Machine

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
• CEO Update: Building trust in AI is key to a thriving knowledge ecosystem
• How to improve the developer experience in today’s ecommerce world
• Featured on Meta
• Preventing unauthorized automated access to the network
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network...

Hot Network Questions

• Use of "lassen" change intransitive verbs to transitive verbs
• Simulating the Howland Current Pump in Real-World Applications
• How many triangles in the picture?
• How can I block localhost access from other computers on the same local network?
• MuseScore 3 Cresc. Poco a Poco
• How to professionally tell colleagues on business trip their judgemental comments are unwelcome
• Is using online interaction platforms like Wooclap effective in a university math classroom?
• How to synchronize both hands when shredding guitar?
• What are some options for adding a sound equality operator (or avoiding it) in a type system with subtyping?
• Polars - How to run computations on other rows efficiently
• How do I force Wayland on in Linux when using Nvidia proprietary drivers?
• How would I translate a question like "you do realize...?" rather than "do you realize...?" into German?
• Mapping does not work in "Press ENTER or type command to continue" screen only on macOS
• Should a 10/2 cable for a clothes dryer be upgraded to 10/3 during a renovation?
• How to pipe input to an interactive shell in Bash
• How do speakers of gendered languages experience English [non-gendered] nouns?
• Common mode choke DC resistance measurement technique
• Best statistical analysis with (very) limited samples : MLR vs GLM vs GAM vs something else?
• Magic Combination lock
• Three semicircles geometry problem from TikTok
• 怎么理解 troll factories
• How do North Korean troops in Ukraine threaten South Korea?
• How to efficiently select elements with the minimum value from a large list?
• Leaving e-bike out in the rain WITHOUT battery

This browser is no longer supported.

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

REG:User assignment required? FLAG

I have registered an application in Azure AD of type AzureADandPersonalMicrosoftAccount . Now I'm trying to login to my application.

**Note:**User assignment required? flag is Set to YES for this application

Case 1: Login with tenantid in the url https://login.microsoftonline.com/tenantId

Result : The user is able to access the application when the user is assigned to the application under users and groups section.And Unassigned user is not able to login to application (Expected Behavior).

Case 2: Login with common instead of tenantId in the URL https://login.microsoftonline.com/common

• The unassigned user is able to access the application.

Question: When common is placed instead of tenantId in the URL. Why does the unassigned users are able to access the application.

Please Advice

Thanks, Subbu

Microsoft Entra ID A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory. 21,983 questions Sign in to follow Follow

This can happen if you signin using a user from another tenant. User restriction applies to local users only.

-- Please let us know if this answer was helpful to you. If so, please remember to mark it as the answer so that others in the community with similar questions can more easily find a solution.

Case 3: Login with tenantId in the URL https://login.microsoftonline.com/tenantId

When the invited user is trying to login to the application . We observe the message saying

"Need admin approval someapp

someapp needs permission to access resources in your organization that only an admin can grant. Please ask an admin to grant permission to this app before you can use it. Have an admin account? Sign in with that account Return to the application without granting consent"

For case 3 you need to grant admin consent .

We still see the same message even after granting the admin consent

Are you sure the same permissions the app is requesting have been granted already? (Enterprise apps > (app) > Permissions)

Is the application sending prompt=consent in the authorization request? (This will force consent, even if consent has already been granted.)

Here is the complete details. 1 While creating the Azure Application we added two API application permissions to the application( User.Invite.All and AppRoleAssignment.ReadWrite.All 2 Granted the Admin Consent for the above two permissions. 3 Set the User assignment required? to YES. 4 granted the admin permissions -clicking Grant.. 5 Tried to login to the application using the assigned users. 6 Observed the above message How we resolved. We could able to resolve this issues by adding user.read delegate permission and provided the admin consent. Question: Why the Admin consent message ("Need admin approval.............")is not displayed after adding the user.read. Do we really required this delegated permission.

Our Requirement : We just need to have two permissions (User.Invite.All and AppRoleAssignment.ReadWrite.All). and then assigned user should be able to login Do we have any API or powershell command for this to grant the permissions ?

User.Read is required to access the user profile once User assignment required is enabled. Permissions can be granted interactively but not trough an API or powershell. You can use Set-AzureADApplication or similar cmdlets to add permissions (-RequiredResourceAccess param) but you will have to consent them as explained before.

Azure Application registrations, Enterprise Apps, and managed identities

• 04/03/202112/12/2022
• by Martin Ehrnst

This post has been lurking in my drafts for almost two years now, and after a recent discussion with colleagues, it was about time I finish it. Weekly I get questions about Azure AD application registrations and Enterprise Applications. And since you found this post, you are probably looking for a few answers yourself.

Over the years I have done a lot of work that requires playing around with authentication in Azure. Especially the case I had with the secure application model and Microsoft CSP gave me some good insight into this space. In general, I have limited knowledge of Oauth2, etc. And most of my work in this space has been related to integration with Azure Management APIs The purpose of this post is to demystify everything around managed identities (MSI), Azure application registrations, and Enterprise Apps. Although Microsoft has this well documented , the context can be somewhat vague. Especially for new developers and IT Pros integrating with the Azure Control plane.

Azure Application registrations

Microsoft has a very robust identity platform in Azure AD . And by creating an application registration you can use this platform to authorize and authenticate various and multiple clients (Mobile, web apps, etc).

When creating an application registration you establish a trust relationship between the Microsofts identity platform and your custom application, meaning you trust Microsoft, but Microsoft does not trust your application in the same way.

You can create single-tenant, multi-tenant, and Microsoft (liveid) based app registrations or a combination of them. But the application definition is only tied to its home directory.

• Only principals in the “home” tenant can authenticate.
• Allows users and applications in other Azure AD tenants to access your app.
• Here you can allow Microsoft Live ID accounts to access.

Enterprise applications – service principals

App registrations are not very functional on their own. Where App registrations is you custom application definition. Enterprise application is the application identity within your directory (Azure AD). The service principal (enterprise app) can only be assigned access to the directory it exists, and act as an instance of the application.

Relationship between app registrations and enterprise applications.

Enterprise applications (the service principal) have a reference to its Application registration. In most cases, you have one app registration and the service principal (enterprise application) in the same tenant. When the application is accessible by multiple tenants, all tenants will have one enterprise application. However, the application registration itself will be in its “home” tenant

This can be confusing. But if you look in the enterprise application blade you can find applications from other app vendors being used by you or other users in your directory.

In short: Azure application registrations are the global representation of your custom application, and Enterprise Application is the local representation of the same application, bound to your tenant.

See this post on how to create Application registrations using PowerShell .

Conditional Access

Conditional Access is where you use signals to identify if a user can access your application or not. You then use these signals in an “if-this-then-that” format to decide whether the user can access your application.

Conditional access is widely used for accessing cloud resources like the Azure Portal or Office 365. However, you can also use the service for your in-house developed applications as well .

Managed identities

Another player in the mix often causing confusion for developers and administrators is Managed Identities. When released, we used the name Managed Service Identities, in short MSI. But recently Microsoft renamed this service to Managed Identities.

Managed Identities is used to assign an identity (service principal) to an Azure resource. You can use this service principle to access other resources, leveraging the built-in authentication and authorization mechanisms you find in Azure.

Managed identities can access other Azure resources or custom applications.

Previously, when we did not have managed identities, we created an application registration for the resource. Using a secret or certificate to authenticate with Azure. This created a lot of overhead, as it required secret management, key rotation, etc. With managed identities, Azure takes care of this for us.

Managed Identities comes in two configurations. One fully managed and tied to a resource, or as an individual resource.

System-assigned managed identity

System-assigned is where you tie the identity to one specific resource. You configure this during resource deployment or assign an identity after it’s deployed. The service principal created with system-assigned managed identity will follow the resource lifecycle. If you delete the resource, the identity will also be deleted.

User-assigned managed identity

User-assigned managed identities are individual resources. Multiple Azure resources can use one managed identity, or you can use multiple identities for one resource. Microsoft will still rotate keys and secrets. But with user-assigned managed identities you are in control of the service principal lifecycle and general governance.

There are a lot more to go through when talking about authentication. How to obtain Azure access tokens or how you add Azure login to your website is not covered here. However, I hope this post made the Azure application registrations, service principal, and managed identity space a bit more clear.

Share this:

Related articles.

21 COMMENTS

Nice information.

Thanks for sharing your knowledge.

https://rsdigitalservices.com/

Hire Offshore Python Developers with Excellent Skill Whatever you want to build in the tech world, make it secure, innovative, and scalable by choosing the Python language and hiring the most skilled Python developers. Techcospace provides you with a team of talented offshore Python developers for hire. Whatever you want to do—whether build applications from scratch or manage existing ones—our adept team can handle that. Experience perfection and efficiency at their peak while working with experts in the industry at Techcospace.

https://www.techcospace.com

Masalqseen I just like the helpful information you provide in your articles

Family Dollar Good post! We will be linking to this particularly great post on our site. Keep up the great writing

Simply Sseven I truly appreciate your technique of writing a blog. I added it to my bookmark site list and will

BaddieHub Great information shared.. really enjoyed reading this post thank you author for sharing this post .. appreciated

Real Estate very informative articles or reviews at this time.

Ive read several just right stuff here Certainly price bookmarking for revisiting I wonder how a lot effort you place to create this kind of great informative website faselhd

Program iz very informative articles or reviews at this time.

Ny weekly very informative articles or reviews at this time.

I don’t think the title of your article matches the content lol. Just kidding, mainly because I had some doubts after reading the article.

Hi, I got my certification, like 80% of the question were from this dump https://www.pass4surexams.com/microsoft/az-104-dumps.html

[…] sooner than I knew podcast used to be a phrase. For roughly part an hour, Richard and I mentioned Azure software registrations, undertaking apps, and controlled identities. What are they, how are you able to take pleasure in them, and what are their similarities and […]

[…] in 2007- way before I knew podcast was a word. For about half an hour, Richard and I talked about Azure application registrations, enterprise apps, and managed identities. What are they, how can you benefit from them, and what are their similarities and differences? Not […]

[…] is simply as simple as the present DevOps setup. I’m lovely aware of Azure as an id platform, particularly with app registrations and undertaking apps. So the above script used to be achieved briefly. However, It’s not that i am that aware of […]

[…] The reason I had it laying in drafts is that I am unsure of the supportability from Microsoft and the potential security vulnerability it may add to your services. However, keep that in mind and use the feature when needed.If you want to learn more about application registrations, enterprise apps, and managed identities i… […]

[…] just as easy as the current DevOps setup. I am pretty familiar with Azure as an identity platform, especially with app registrations and enterprise apps. So the above script was done quickly. On the other hand, I am not that familiar with GitHub APIs. […]

[…] as the present DevOps setup. I’m lovely conversant in Azure as an identification platform, particularly with app registrations and undertaking apps. So the above script used to be performed briefly. However, I’m really not that conversant in […]

Please clarify where you say “App registrations are not very functional on their own. Where App registrations is you custom application definition.”

Do you have an idea on how to clarify?

[…] AD part, I had mostly everything in place already. Service connections for Azure AD are essentially Azure application registrations, and Azure AD groups are easily created using New-AzADGroup or Microsoft Graph API. However, my […]

Engage by commenting Cancel reply