acrolinx and add link to group-write-back-portal.md

Author: markwahl-msft

articles/active-directory/governance/identity-governance-applications-integrate.md

@@ -75,7 +75,7 @@ Next, if the application implements a provisioning protocol, then you should con
 
      |Application supports| Next steps|
      |----|-----|
-     | Kerberos | Configure Azure AD Connect [group writeback to AD](../hybrid/how-to-connect-group-writeback-v2.md) |
+     | Kerberos | Configure Azure AD Connect [group writeback to AD](../hybrid/how-to-connect-group-writeback-v2.md), create groups in Azure AD and [write those groups to AD](../enterprise-users/groups-write-back-portal.md) |
 
    * Otherwise, if this is an on-premises or IaaS hosted application, and is not integrated with AD, then configure provisioning to that application, either via SCIM or to the underlying database or directory of the application.
 
@@ -96,9 +96,9 @@ If this is a new application your organization hasn't used before, and therefore
 However, if the application already existed in your environment, then it's possible that users may have gotten access in the past through manual or out-of-band processes, and those users should now be reviewed to have confirmation that their access is still needed and appropriate going forward. We recommend performing an access review of the users who already have access to the application, before enabling policies for more users to be able to request access. This review will set a baseline of all users having been reviewed at least once, to ensure that those users are authorized for continued access.
 
 1. Follow the steps in [Preparing for an access review of users' access to an application](access-reviews-application-preparation.md).
-1. If the application was not using Azure AD or AD, bring in any [existing users and create application role assignments](identity-governance-applications-existing-users.md) for them.  If the application was using AD security groups, then you will need to review the membership of those security groups.
+1. If the application was not using Azure AD or AD, bring in any [existing users and create application role assignments](identity-governance-applications-existing-users.md) for them.  If the application was using AD security groups, then you'll need to review the membership of those security groups.
 1. If the application had its own directory or database and wasn't integrated for provisioning, then once the review is complete, you may need to manually update the application's internal database or directory to remove those users who were denied.
-1. If the application was using AD security groups, and those groups were created in AD, then once the review is complete, you will need to manually update the AD groups to remove those users who were denied.
+1. If the application was using AD security groups, and those groups were created in AD, then once the review is complete, you'll need to manually update the AD groups to remove memberships of those users who were denied.  Subsequently, to have denied access rights removed automatically, you can either update the application to use an AD group that was created in Azure AD and [written back to Azure AD](../enterprise-users/groups-write-back-portal.md), or move the membership from the AD group to the Azure AD group, and nest the written back group as the only member of the AD group.
 1. Once the review has been completed and the application access updated, or if no users have access, then continue on to the next steps to deploy conditional access and entitlement management policies for the application.
 
 Now that you have a baseline that ensures existing access has been reviewed, then you can [deploy the organization's policies](identity-governance-applications-deploy.md) for ongoing access and any new access requests.