[Azure AD roles] two updates

Author: curtand

articles/active-directory/users-groups-roles/directory-assign-admin-roles.md

@@ -47,31 +47,37 @@ The following administrator roles are available:
 Users in this role can create and manage all aspects of enterprise applications, application registrations, and application proxy settings. Note that users assigned to this role are not added as owners when creating new application registrations or enterprise applications.
 
 Application Administrators can manage application credentials that allows them to impersonate the application. So, users assigned to  this role can manage application credentials of only those applications that are either not assigned to any Azure AD roles or those assigned to following admin roles only:
+
 * Application Administrator
 * Application Developer
 * Cloud Application Administrator
 * Directory Readers
 
-If an application is assigned to any other role that are not mentioned above, then Application Administrator cannot manage credentials of that application. 
- 
+If an application is assigned to any other role that are not mentioned above, then Application Administrator cannot manage credentials of that application.
+
 This role also grants the ability to _consent_ to delegated permissions and application permissions, with the exception of permissions on the Microsoft Graph API.
 
 > [!IMPORTANT]
-> 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 exception means that you can still consent to permissions for _other_ apps (for example, non-Microsoft 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_ (that is, 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.
 
 ### [Application Developer](#application-developer-permissions)
 
 Users in this role can create application registrations when the "Users can register applications" setting is set to No. This role also grants permission to consent on one's own behalf when the "Users can consent to apps accessing company data on their behalf" setting is set to No. Users assigned to this role are added as owners when creating new application registrations or enterprise applications.
 
 ### [Authentication Administrator](#authentication-administrator-permissions)
 
-The Authentication administrator role is currently in public preview. Users with this role can set or reset non-password credentials and can update passwords for all users. Authentication Administrators can require users to re-register against existing non-password credential (for example, MFA or FIDO) and revoke **remember MFA on the device**, which prompts for MFA on the next sign-in of users who are non-administrators or assigned the following roles only:
+The Authentication administrator role is currently in public preview. Users with this role can set or reset non-password credentials for some users and can update passwords for all users. Authentication administrators can:
 
-* Authentication Administrator
-* Directory Readers
-* Guest Inviter
-* Message Center Reader
-* Reports Reader
+* Require users to re-register against existing non-password credentials (for example, MFA or FIDO)
+* Revoke **remember MFA on the device**, which prompts for MFA on the next sign-in of users who are non-administrators or assigned the following roles only:
+
+  * Authentication Administrator
+  * Directory Readers
+  * Guest Inviter
+  * Message Center Reader
+  * Reports Reader
+
+The [Privileged authentication administrator](#privileged-authentication-administrator) role has permission can force re-registration and MFA for all users.
 
 > [!IMPORTANT]
 > 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:
@@ -123,6 +129,7 @@ Makes purchases, manages subscriptions, manages support tickets, and monitors se
 Users in this role have the same permissions as the Application Administrator role, excluding the ability to manage application proxy. This role grants the ability to create and manage all aspects of enterprise applications and application registrations. This role also grants the ability to consent to delegated permissions, and application permissions excluding the Microsoft Graph API. Users assigned to this role are not added as owners when creating new application registrations or enterprise applications.
 
 Cloud Application Administrators can manage application credentials that allows them to impersonate the application. So, users assigned to  this role can manage application credentials of only those applications that are either not assigned to any Azure AD roles or those assigned to following admin roles only:
+
 * Application Developer
 * Cloud Application Administrator
 * Directory Readers
@@ -345,7 +352,7 @@ Users with this role can register printers and manage printer status in the Micr
 
 ### [Privileged Authentication Administrator](#privileged-authentication-administrator-permissions)
 
-Users with this role can set or reset non-password credentials for all users, including global administrators, and can update passwords for all users. Privileged Authentication Administrators can force users to re-register against existing non-password credential (e.g. MFA, FIDO) and revoke 'remember MFA on the device', prompting for MFA on the next login of all users.
+Users with this role can set or reset non-password credentials for all users, including global administrators, and can update passwords for all users. Privileged Authentication Administrators can force users to re-register against existing non-password credential (such as MFA or FIDO) and revoke 'remember MFA on the device', prompting for MFA on the next sign-in of all users. The [Authentication administrator](#authentication-administrator) role can force re-registration and MFA for users and readers.
 
 ### [Privileged Role Administrator](#privileged-role-administrator-permissions)
 

articles/active-directory/users-groups-roles/roles-custom-overview.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.workload: identity
 ms.subservice: users-groups-roles
 ms.topic: article
-ms.date: 11/08/2019
+ms.date: 04/21/2020
 ms.author: curtand
 ms.reviewer: vincesm
 ms.custom: it-pro
@@ -32,6 +32,22 @@ Once you’ve created your role definition, you can assign it to a user by creat
 
 Azure AD built-in and custom roles operate on concepts similar to [Azure role-based access control](../../role-based-access-control/overview.md). The [difference between these two role-based access control systems](../../role-based-access-control/rbac-and-directory-admin-roles.md) is that Azure RBAC controls access to Azure resources such as virtual machines or storage using Azure Resource Management, and Azure AD custom roles control access to Azure AD resources using Graph API. Both systems leverage the concept of role definitions and role assignments.
 
+### How Azure AD determines if a user has access to a resource
+
+The following are the high-level steps that Azure AD uses to determine if you have access to a management resource. Use this information to troubleshoot access issues.
+
+1. A user (or service principal) acquires a token to the Microsoft Graph or Azure AD Graph endpoint.
+
+1. The user makes an API call to Azure Active Directory (Azure AD) via Microsoft Graph or Azure AD Graph using the issued token.
+
+1. Depending on the circumstance, Azure AD takes one of the following actions:
+
+    - Evaluates the user’s role memberships based on the [wids claim](https://docs.microsoft.com/azure/active-directory/develop/access-tokens) in the user’s access token.
+    - Retrieves all the role assignments that apply for the user, either directly or via group membership, to the resource on which the action is being taken.
+
+1. Azure AD determines if the action in the API call is included in the roles the user has for this resource.
+1. If the user doesn't have a role with the action at the requested scope, access is not granted. Otherwise access is granted.
+
 ### Role assignments
 
 A role assignment is the object that attaches a role definition to a user at a particular scope to grant Azure AD resource access. Access is granted by creating a role assignment, and access is revoked by removing a role assignment. At its core, a role assignment consists of three elements: