Azure AD App Registration User Role Propagation Times

Question

I have added an app registration with custom user roles through the manifest

I have successfully protected an API endpoint by way of the [authorize] atribute and roles.

I have now changed the names of the roles in AD but when I try to access the API endpoint I can see in the access token that the roles have not changed.

How long does it take for roles to change for a user?
Do I need to do something else other than just change the names of the roles? Force a cache refresh somewhere?
Am I missing something?

I am using a private browser to eliminate any stale cookie noise

Answer 1

Hi,
I'm wow
Welcome to our new Microsoft Q&A Platform.

There are several settings you can configure.You can choose from two assignment duration options for each assignment type (eligible or active) when you configure settings for a role. These options become the default maximum duration when a member is assigned to the role in Privileged Identity Management.

If it's frustrating for you to find the role you need out of a list of many roles, Azure AD can show you subsets of the roles based on role categories. Check out our new Type filter for Azure AD Roles and administrators to show you only the roles in the selected type.

Assign or remove administrator roles
To learn how to assign administrative roles to a user in Azure Active Directory, see View and assign administrator roles in Azure Active Directory.

Rendering, or consumption, of embedded content, fails or times out
Make sure the embed token did not expire. Make sure you're checking the embed token expiration and refreshing it. For more information, see Refresh token using JavaScript SDK.

Rmb Few thing Important for Administrator role permissions

This exception means that you can still consent to permissions for other apps (e.g. third party apps or apps that you have registered), but not to permissions on Azure AD itself. You can still request these permissions as part of the app registration, but granting (i.e. consenting to) these permissions requires an Azure AD admin. This means that a malicious user cannot easily elevate their permissions, for example by creating and consenting to an app that can write to the entire directory and through that app's permissions elevate themselves to become a global admin.

This is a sensitive role. The keyset administrator role should be carefully audited and assigned with care during pre-production and production.

Users with this role can change credentials for people who may have access to sensitive or private information or critical configuration inside and outside of Azure Active Directory. Changing the credentials of a user may mean the ability to assume that user's identity and permissions. For example:

• Application Registration and Enterprise Application owners, who can manage credentials of apps they own. Those apps may have privileged permissions in Azure AD and elsewhere not granted to Authentication Administrators. Through this path an Authentication Administrator may be able to assume the identity of an application owner and then further assume the identity of a privileged application by updating the credentials for the application.
  -Azure subscription owners, who may have access to sensitive or private information or critical configuration in Azure.
  -Security Group and Office 365 Group owners, who can manage group membership. Those groups may grant access to sensitive or private information or critical configuration in Azure AD and elsewhere.
  -Administrators in other services outside of Azure AD like Exchange Online, Office Security and Compliance Center, and human resources systems.
  -Non-administrators like executives, legal counsel, and human resources employees who may have access to sensitive or private information.

The B2 IEF Policy Administrator is a highly sensitive role which should be assigned on a very limited basis for tenants in production. Activities by these users should be closely audited, especially for tenants in production.

Users with this role can change passwords for people who may have access to sensitive or private information or critical configuration inside and outside of Azure Active Directory. Changing the password of a user may mean the ability to assume that user's identity and permissions. For example:

-Application Registration and Enterprise Application owners, who can manage credentials of apps they own. Those apps may have privileged permissions in Azure AD and elsewhere not granted to Helpdesk Administrators. Through this path a Helpdesk Administrator may be able to assume the identity of an application owner and then further assume the identity of a privileged application by updating the credentials for the application.
-Azure subscription owners, who might have access to sensitive or private information or critical configuration in Azure.
-Security Group and Office 365 Group owners, who can manage group membership. Those groups may grant access to sensitive or private information or critical configuration in Azure AD and elsewhere.
-Administrators in other services outside of Azure AD like Exchange Online, Office Security and Compliance Center, and human resources systems.
-Non-administrators like executives, legal counsel, and human resources employees who may have access to sensitive or private information.

This role grants the ability to manage assignments for all Azure AD roles including the Global Administrator role. This role does not include any other privileged abilities in Azure AD like creating or updating users. However, users assigned to this role can grant themselves or others additional privilege by assigning additional roles.

Users with this role can change passwords for people who may have access to sensitive or private information or critical configuration inside and outside of Azure Active Directory. Changing the password of a user may mean the ability to assume that user's identity and permissions. For example:

-Application Registration and Enterprise Application owners, who can manage credentials of apps they own. Those apps may have privileged permissions in Azure AD and elsewhere not granted to User Administrators. Through this path a User Administrator may be able to assume the identity of an application owner and then further assume the identity of a privileged application by updating the credentials for the application.
-Azure subscription owners, who may have access to sensitive or private information or critical configuration in Azure.
-Security Group and Office 365 Group owners, who can manage group membership. Those groups may grant access to sensitive or private information or critical configuration in Azure AD and elsewhere.
-Administrators in other services outside of Azure AD like Exchange Online, Office Security and Compliance Center, and human resources systems.
-Non-administrators like executives, legal counsel, and human resources employees who may have access to sensitive or private information.

Hope that got help you
Good Day

Answer 2

Dun be discouraged！！！I can't help u but I'm Sure got someone can ！！！

别气馁，路还长，兄弟，加油！!👏 🤜🤛