acrolinx feedback

Author: markwahl-msft

articles/active-directory/governance/access-reviews-application-preparation.md

@@ -43,17 +43,17 @@ Also, while not required for reviewing access to an application, we recommend al
 In order for Azure AD access reviews to be used for an application, then the application must first be integrated with Azure AD. An application being integrated with Azure AD means one of two requirements must be met:
 
 * The application relies upon Azure AD for federated SSO, and Azure AD controls authentication token issuance. If Azure AD is the only identity provider for the application, then only users who are assigned to one of the application's roles in Azure AD are able to sign into the application. Those users that are denied by a review lose their application role assignment and can no longer get a new token to sign in to the application.
-* The application relies upon user or group lists that are provided to the application by Azure AD. This could be done through a provisioning protocol such as SCIM or by the application querying Azure AD via Microsoft Graph. Those users that are denied by a review lose their application role assignment or group membership, and when those changes are made available to the application, then the denied users will no longer have access.
+* The application relies upon user or group lists that are provided to the application by Azure AD. This fulfillment could be done through a provisioning protocol such as SCIM or by the application querying Azure AD via Microsoft Graph. Those users that are denied by a review lose their application role assignment or group membership, and when those changes are made available to the application, then the denied users will no longer have access.
 
-If neither of those criteria are met for an application, then access reviews can still be used, however some users might not be in scope, because they're not in your Azure AD directory or are not assigned to the app in Azure AD.  Also, the changes won't be able to be automatically sent to the application. The organization must have a process to send the results of a completed review to the application if the application doesn't rely upon Azure AD.
+If neither of those criteria are met for an application, as the application doesn't rely upon Azure AD, then access reviews can still be used, however there may be some limitations. Users that aren't in your Azure AD or are not assigned to the application roles in Azure AD, won't be included in the review.  Also, the changes to remove denied won't be able to be automatically sent to the application if there is no provisioning protocol that the application supports. The organization must instead have a process to send the results of a completed review to the application.
 
-In order to permit a wide variety of applications and IT requirements to be addressed with Azure AD, there are many patterns for how an application can be integrated with Azure AD.  The following flowchart illustrates how to select from three integration patterns, A-C, that are appropriate for applications being used with identity governance.  Knowing what pattern is being used for a particular application helps you to configure the appropriate resources in Azure AD to be ready the access review.
+In order to permit a wide variety of applications and IT requirements to be addressed with Azure AD, there are multiple patterns for how an application can be integrated with Azure AD.  The following flowchart illustrates how to select from three integration patterns, A-C, that are appropriate for applications for use with identity governance.  Knowing what pattern is being used for a particular application helps you to configure the appropriate resources in Azure AD to be ready the access review.
 
    ![Flowchart for application integration patterns](./media/access-reviews-application-preparation/app-integration-patterns-flowchart.png)
 
 |Pattern|Application integration pattern|Steps to prepare for an access review|
 |:---|---|--|
-|A| The application supports federated SSO, Azure AD is the only identity provider, and the application doesn't rely upon group or role claims. | In this pattern, you'll configure that the application requires individual application role assignments, and that users are assigned to the application.  Then to perform the review, you'll create a single access review for the application, of the users assigned to this application role. When the review completes, if a user was denied, then they will be removed from the application role, and Azure AD will no longer issue federation tokens for that user to be able to sign into that application.|
+|A| The application supports federated SSO, Azure AD is the only identity provider, and the application doesn't rely upon group or role claims. | In this pattern, you'll configure that the application requires individual application role assignments, and that users are assigned to the application.  Then to perform the review, you'll create a single access review for the application, of the users assigned to this application role. When the review completes, if a user was denied, then they will be removed from the application role. Azure AD will then no longer issue that user with federation tokens and the user will be unable to sign into that application.|
 |B|If the application uses group claims in addition to application role assignments.| An application may use Azure AD group membership, distinct from application roles to express finer-grained access.  Here, you can choose based on your business requirements either to have the users who have application role assignments reviewed, or to review the users who have group memberships.  If the groups do not provide comprehensive access coverage, in particular if users may have access to the application even if they aren't a member of those groups, then we recommend reviewing the application role assignments, as in pattern A above.|
 |C| If the application doesn't rely solely on Azure AD for federated SSO, but does support provisioning, via SCIM, or via updates to a SQL table of users or an LDAP directory. |  In this pattern, you'll configure Azure AD to provision the users with application role assignments to the application's database or directory, update the application role assignments in Azure AD with a list of the users who currently have access, and then create a single access review of the application role assignments.|
 
@@ -75,9 +75,9 @@ Now that you have identified the integration pattern for the application, check
 1. Change to the **Properties** tab.  Verify that the **User assignment required?** option is set to **Yes**. If it's set to **No**, all users in your directory, including external identities, can access the application, and you can't review access to the application.
    ![Screenshot that shows planning app assignments.](./media/deploy-access-review/6-plan-applications-assignment-required.png)
 
-1. Change to the **Roles and administrators** tab. This displays the administrative roles, that give rights to control the representation of the application in Azure AD, not the access rights in the application.  For each administrative role that has permissions to allow changing the application integration or assignments, and has an assignment to that administrative role, ensure that only authorized users are in that role.
+1. Change to the **Roles and administrators** tab. This tab displays the administrative roles, that give rights to control the representation of the application in Azure AD, not the access rights in the application.  For each administrative role that has permissions to allow changing the application integration or assignments, and has an assignment to that administrative role, ensure that only authorized users are in that role.
 
-1. Change to the **Provisioning** tab.  If automatic provisioning isn't configured, then Azure AD won't have a way to notify the application when a user's access is removed if denied during the review.  This might not be necessary if the application is federated and solely relies upon Azure AD as its identity provider. However, if your application integration is pattern C, and the application doesn't support federated SSO with Azure AD as its only identity provider, then you'll need to configure provisioning from Azure AD to the application. Provisioning is necessary so that Azure AD can automatically remove the reviewed users from the application when a review completes, and this can be done through a change sent from Azure AD to the application through SCIM, LDAP or SQL.
+1. Change to the **Provisioning** tab.  If automatic provisioning isn't configured, then Azure AD won't have a way to notify the application when a user's access is removed if denied during the review.  Provisioning might not be necessary for some integration patterns, if the application is federated and solely relies upon Azure AD as its identity provider. However, if your application integration is pattern C, and the application doesn't support federated SSO with Azure AD as its only identity provider, then you'll need to configure provisioning from Azure AD to the application. Provisioning will be necessary so that Azure AD can automatically remove the reviewed users from the application when a review completes, and this removal step can be done through a change sent from Azure AD to the application through SCIM, LDAP or SQL.
 
    * If this is a gallery application that supports provisioning, [configure the application for provisioning](../app-provisioning/configure-automatic-user-provisioning-portal.md).
    * If the application is a cloud application and supports SCIM, configure [user provisioning with SCIM](../app-provisioning/use-scim-to-provision-users-and-groups.md).
@@ -97,8 +97,8 @@ Now that you have identified the integration pattern for the application, check
 Next, if the application integration also requires one or more groups to be reviewed, as described in pattern B, then check each group is ready for review.
 
 1. In the Azure portal experience for Azure AD, click **Groups**, and then select the group from the list.
-1. On the **Overview** tab, verify that the **Membership type** is **Assigned**, and the **Source** is **Cloud**.  If the application uses a dynamic group, or a group synchronized from on-premises, then those group memberships cannot be changed in Azure AD.  We recommend converting the application to groups created in Azure AD with assigned memberships, then copy the member users to that new group.
-1. Change to the **Roles and administrators** tab. This displays the administrative roles, that give rights to control the representation of the group in Azure AD, not the access rights in the application.  For each administrative role that allows changing group membership and has users in that administrative role, ensure that only authorized users are in that role.
+1. On the **Overview** tab, verify that the **Membership type** is **Assigned**, and the **Source** is **Cloud**.  If the application uses a dynamic group, or a group synchronized from on-premises, then those group memberships can't be changed in Azure AD.  We recommend converting the application to groups created in Azure AD with assigned memberships, then copy the member users to that new group.
+1. Change to the **Roles and administrators** tab. This tab displays the administrative roles, that give rights to control the representation of the group in Azure AD, not the access rights in the application.  For each administrative role that allows changing group membership and has users in that administrative role, ensure that only authorized users are in that role.
 1. Change to the **Members** tab.  Verify that the members of the group are users, and that there are no non-user members or nested groups. If there are no members of a group when the review starts, the review of that group will complete immediately.
 1. Change to the **Owners** tab. Make sure that no authorized users are shown as owners. If you'll be asking the group owners to perform the access review of a group, then confirm that the group has one or more owners.
 
@@ -136,7 +136,7 @@ Once the reviews have started, you can monitor their progress, and update the ap
 
 1. If you had previously configured provisioning of users to the application, then when the results are applied, Azure AD will begin deprovisioning denied users from the application. You can [monitor the process of deprovisioning users](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md). If provisioning indicates an error with the application, you can [download the provisioning log](../reports-monitoring/concept-provisioning-logs.md) to investigate if there was a problem with the application.
 
-1. If provisioning was not possible for your application, then you may need to separately copy the list of denied users to the application. For example, in access reviews for a Windows Server AD-managed group, use this [PowerShell sample script](https://github.com/microsoft/access-reviews-samples/tree/master/AzureADAccessReviewsOnPremises). The script outlines the required Microsoft Graph calls and exports the Windows Server AD PowerShell cmdlets to carry out the changes.
+1. If provisioning wasn't configured for your application, then you may need to separately copy the list of denied users to the application. For example, in access reviews for a Windows Server AD-managed group, use this [PowerShell sample script](https://github.com/microsoft/access-reviews-samples/tree/master/AzureADAccessReviewsOnPremises). The script outlines the required Microsoft Graph calls and exports the Windows Server AD PowerShell cmdlets to carry out the changes.
 
 1. If you wish, you can also download a [review history report](access-reviews-downloadable-review-history.md) of completed reviews.