Merge pull request #206409 from markwahl-msft/mwahl-gov-gwb1

identity governance: change to application-preparation article to prepare for AD group based apps

Author: PRMerger16

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

@@ -11,7 +11,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.topic: how-to
 ms.subservice: compliance
-ms.date: 04/25/2022
+ms.date: 07/29/2022
 ms.author: mwahl
 ms.reviewer: mwahl
 ms.collection: M365-identity-device-management
@@ -43,7 +43,7 @@ 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 fulfillment could be done through a provisioning protocol such as System for Cross-Domain Identity Management (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 System for Cross-Domain Identity Management (SCIM) or by the application querying Azure AD via Microsoft Graph, or groups that are written to AD DS. 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, 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.
 
@@ -54,8 +54,8 @@ In order to permit a wide variety of applications and IT requirements to be addr
 |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. 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.  For more information, see [Governing an application's existing users](identity-governance-applications-existing-users.md)  to update the application role assignments in Azure AD.|
+|B|If the application uses group claims in addition to application role assignments.| An application may use AD or 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 a non-AD 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.  For more information, see [Governing an application's existing users](identity-governance-applications-existing-users.md)  to update the application role assignments in Azure AD.|
 
 ### Other options
 
@@ -70,15 +70,15 @@ The integration patterns listed above are applicable to third party SaaS applica
 Now that you have identified the integration pattern for the application, check the application as represented in Azure AD is ready for review.
 
 1. In the Azure portal, click **Azure Active Directory**, click **Enterprise Applications**, and check whether your application is on the [list of enterprise applications](../manage-apps/view-applications-portal.md) in your Azure AD tenant.
-1. If the application is not already listed, then check if the application is available the [application gallery](../manage-apps/overview-application-gallery.md) for applications that can be integrated for federated SSO or provisioning. If it is in the gallery, then use the [tutorials](../saas-apps/tutorial-list.md) to configure the application for federation, and if it supports provisioning, also [configure the application](../app-provisioning/configure-automatic-user-provisioning-portal.md) for provisioning.
-1. One the application is in the list of enterprise applications in your tenant, select the application from the list.
+1. If the application is not already listed, then check if the application is available the [application gallery](../manage-apps/overview-application-gallery.md) for applications that can be integrated for federated SSO or provisioning. If it is in the gallery, then use the [tutorials](../saas-apps/tutorial-list.md) to configure the application for federation, and if it supports provisioning, also [configure the application](../app-provisioning/configure-automatic-user-provisioning-portal.md) for provisioning.  If the application uses AD security groups, [add the application for remote access through Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md) and [configure group writeback to AD](../hybrid/how-to-connect-group-writeback-v2.md).
+1. Once the application is in the list of enterprise applications in your tenant, select the application from the list.
 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 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.  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.
+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, or the application uses AD DS groups. 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).
@@ -90,10 +90,10 @@ Now that you have identified the integration pattern for the application, check
 1. If the application supports federated SSO, then change to the **Conditional Access** tab. Inspect the enabled policies for this application. If there are policies that are enabled, block access, have users assigned to the policies, but no other conditions, then those users may be already blocked from being able to get federated SSO to the application.
 
 1. Change to the **Users and groups** tab.  This list contains all the users who are assigned to the application in Azure AD.  If the list is empty, then a review of the application will complete immediately, since there isn't any task for the reviewer to perform.
-1. If your application is integrated with pattern C, then you'll need to confirm that the users in this list are the same as those in the applications' internal data store, prior to starting the review. Azure AD does not automatically import the users or their access rights from an application, but you can [assign users to an application role via PowerShell](../manage-apps/assign-user-or-group-access-portal.md).  See [Governing an application's existing users](identity-governance-applications-existing-users.md) for how to bring in users from different application data stores into Azure AD.
+1. If your application is integrated with pattern C, then you'll need to confirm that the users in this list are the same as those in the applications' internal data store, prior to starting the review. Azure AD does not automatically import the users or their access rights from an application, but you can [assign users to an application role via PowerShell](../manage-apps/assign-user-or-group-access-portal.md).  See [Governing an application's existing users](identity-governance-applications-existing-users.md) for how to bring in users from different application data stores into Azure AD and assign them to an application role.
 1. Check whether all users are assigned to the same application role, such as **User**.  If users are assigned to multiple roles, then if you create an access review of the application, then all assignments to all of the application's roles will be reviewed together.
 
-1. Check the list of directory objects assigned to the roles to confirm that there are no groups assigned to the application roles. It's possible to review this application if there is a group assigned to a role; however, a user who is a member of the group assigned to the role, and whose access was denied, won't be automatically removed from the group.  We recommend first converting the application to have direct user assignments, rather than members of groups, so that a user whose access is denied during the access review can have their application role assignment removed automatically.
+1. Check the list of directory objects assigned to the roles to confirm that there are no groups assigned to the application roles. It's possible to review this application if there is a group assigned to a role; however, a user who is a member of the group assigned to the role, and whose access was denied, won't be automatically removed from the group. If the application does not itself rely upon groups, then we recommend first converting the application to have direct user assignments, rather than members of groups, so that a user whose access is denied during the access review can have their application role assignment removed automatically.  If the application does rely upon groups, and all of the application's groups are assigned to the same application role, then you'll review the group memberships instead of reviewing the application assignments.
 
 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.
 
@@ -137,11 +137,13 @@ 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 you had configured [group writeback](../enterprise-users/groups-write-back-portal.md) for the reviewed groups, then wait until group writeback completes in Azure AD Connect and the changes propagate to all the domain controllers.
+
 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.
 
-1. How long a user who has been denied continued access is able to continue to use a federated application will depend upon the application's own session lifetime, and on the access token lifetime.  To learn more about controlling the lifetime of access tokens, see [configurable token lifetimes](../develop/active-directory-configurable-token-lifetimes.md).
+1. How long a user who has been denied continued access is able to continue to use a federated application will depend upon the application's own session lifetime, and on the access token lifetime. If the applications used Kerberos, since Kerberos caches the group memberships of a user when they sign into a domain, the users may continue to have access until their Kerberos tickets expire.  To learn more about controlling the lifetime of access tokens, see [configurable token lifetimes](../develop/active-directory-configurable-token-lifetimes.md).
 
 ## Next steps