Merge pull request #221028 from MicrosoftDocs/main

12/09 AM Publish

Author: huypub

articles/active-directory/app-provisioning/on-premises-application-provisioning-architecture.md

@@ -37,6 +37,8 @@ There are three primary components to provisioning users into an on-premises app
 
 You don't need to open inbound connections to the corporate network. The provisioning agents only use outbound connections to the provisioning service, which means there's no need to open firewall ports for incoming connections. You also don't need a perimeter (DMZ) network because all connections are outbound and take place over a secure channel.
 
+The required outbound endpoints for the provisioning agents are detailed [here](../cloud-sync/how-to-prerequisites.md#firewall-and-proxy-requirements).
+
 ## ECMA Connector Host architecture
 The ECMA Connector Host has several areas it uses to achieve on-premises provisioning.  The diagram below is a conceptual drawing that presents these individual areas.  The table below describes the areas in more detail.
 

articles/active-directory/governance/TOC.yml

@@ -69,6 +69,8 @@
       href: entitlement-management-process.md
   - name: Access reviews
     items:
+    - name: Enable multi-stage reviews
+      href: using-multi-stage-reviews.md
     - name: Manage access with reviews
       href: manage-access-review.md
     - name: Manage users excluded from Conditional Access

articles/active-directory/governance/media/using-multi-stage-reviews/multi-stage-reviews.png

@@ -0,0 +1,139 @@
+---
+title: Using multi-stage reviews to meet your attestation and certification needs - Azure AD 
+description: Learn how to use multi-stage reviews to design more efficient reviews in Azure Active Directory. 
+services: active-directory
+author: amsliu
+manager: amycolannino
+editor: florianf
+ms.service: active-directory
+ms.workload: identity
+ms.tgt_pltfrm: na
+ms.topic: how-to
+ms.subservice: compliance
+ms.date: 11/15/2022
+ms.author: amsliu
+ms.reviewer: florianf
+ms.collection: M365-identity-device-management
+---
+ 
+# Using multi-stage reviews to meet your attestation and certification needs in Azure AD 
+
+Azure AD Access Reviews support up to three review stages, in which multiple types of reviewers engage in determining who still needs access to company resources. These reviews could be for membership in groups or teams, access to applications, assignments to privileged roles, or access package assignments. When review administrators configure the review for automatic application of decisions, at the end of the review period, access is revoked for denied users.
+
+## Use cases for multi-stage reviews
+
+Multi-stage access reviews allow you and your organization to enable complex workflows to meet recertification and audit requirements calling for multiple reviewers to attest to access for users in a particular sequence. It also helps you design more efficient reviews for your resource owners and auditors by reducing the number of decisions each reviewer is accountable for. This approach allows for combining otherwise disjoint, separate reviews for the same resource, to be combined in one access review.
+
+:::image type="content" source="media/using-multi-stage-reviews/new-access-reviews.png" alt-text="Screenshot of new access reviews." lightbox="media/using-multi-stage-reviews/new-access-reviews.png":::
+
+Here are some scenarios you may want to consider:
+
+- **Reach consensus across multiple sets of reviewers:** Let two audiences of reviewers independently review access to a resource. You can configure reviews such that both stages of reviewers must agree on *Approved* without seeing each other’s decisions.
+- **Assign alternate reviewers to weigh in on unreviewed decisions:** Let the resource owner attest to access to their resource in stage 1. Then, users for which no decision has been recorded go to a second stage reviewer, such as the user’s manager or an auditing team, who review the undecided requests. 
+- **Reduce burden on later-stage reviewers:** Reviews can be configured such that earlier-stage-denied users won't be reviewed by later stages, allowing for later stage reviewers to see a filtered-down list.     
+
+## Reach consensus across multiple sets of reviewers  
+
+Reaching quorum on the right access for users could be difficult. For resources that many users have access to, or for a diverse group or users that need to be reviewed, it's especially hard for any single reviewer to make the right choices for all reviewees. Reaching consensus by giving three different reviewer groups the opportunity to record decisions and by showing what the earlier reviewer audiences said helps drive consensus on who should have access to the resource. 
+
+An example would be a review that consists of three stages that determines group membership to a group that governs access to a resource. In the review settings, the administrator chooses to not show decisions of earlier stage reviewers. This configuration allows for every review audience, for example the user’s manager, the group owner and a security officer to review access independently. The three stages are lined up with increased importance of reviewer audience weight, with decisions from the last reviewer audience potentially overwriting earlier-stage reviewer’s decisions.
+
+The configuration for this scenario would look like this:
+
+ | Attribute | Configuration |
+ |:--- |:---:|
+ |Multi-stage review|Enabled|
+ |First stage reviewers|Managers of users|
+ |Second stage reviewers|Group owners|
+ |Third stage reviewers|Select user(s) or group(s) – “Contoso auditors group”|
+ |Show previous stage(s) decisions to later stage reviewers|Enabled|
+ |Reviewees going to the next stage|Select all|
+ |If reviewers don’t respond|Remove access|
+
+## Assign alternate reviewers to weigh in on unreviewed decisions 
+
+For scenarios that you need decisions recorded and need to make sure that access is preserved for the right people, multi-stage reviews let you progress a subset of reviewees to the next stage, that potentially needs a second reviewer audience for double-checking or decision making. Customers can use this pattern to ensure that there are fewer unreviewed users or users marked as **Don’t know**, by progressing these reviewees to another stage, and having another group of reviewers take decisions.
+
+An example for this would be review that contains of two stages that determines access to an application. In the review settings, the review administrator chooses to **Show previous stage(s) decisions to later stage reviewers**. For **Reviewees going to the next stage**, the decisions that need confirmation would be added: to ensure all reviewees have a decision, select **reviewees marked as ‘Don’t know’** and **Not reviewed reviewees**, so that later-stage reviewers only see the undecided or unsure reviewees to retain the right access.
+
+ | Attribute | Configuration |
+ |:--- |:---:|
+ |Multi-stage review|Enabled|
+ |First stage reviewers|Select user(s) or group(s) – the owner(s) of the applications|
+ |Second stage reviewers|Managers of users|
+ |Show previous stage(s) decisions to later stage reviewers|Disabled|
+ |Reviewees going to the next stage|Select **Not reviewed reviewees** and **Reviewees marked as ‘Don’t know’**|
+ |If reviewers don’t respond|Approve Access|
+
+## Reduce burden on later stage reviewers 
+
+For reviews that may contain many reviewees, or users to be reviewed and attested, you may require all end users to self-attest before they're reviewed by a resource owner or their manager in a later stage. This model allows for filtering reviewees from stage to stage, progressing reviewees that have self-approved, only. 
+
+Later stage reviewers, such as user’s managers, or the resource owner, only see the reduced list of reviewees – those that approved previously. The number of reviewees per stage decreases stage by stage. Only the users that have been approved through all three stages preserve access.
+
+An example would be a review of a group that grants an IT exception, that an administrator wants to regularly review. As that exception is popular, users are asked to respond first, and only those that responded that they still need the exception, are progressed to the second stage, where their manager decides. Only if the user and the manager approve, IT owners for the exception get to see the list of users who still need and want the exception, look at a reduced list of reviewees.
+
+ | Attribute | Configuration |
+ |:--- |:---:|
+ |Multi-stage review|Enabled|
+ |First stage reviewers|Users review their own access|
+ |Second stage reviewers|Managers of users|
+ |Third stage reviewers|Group owner(s)|
+ |Show previous stage(s) decisions to later stage reviewers|Disabled|
+ |Reviewees going to the next stage|Select **Approved reviewees**|
+ |If reviewers don’t respond|Remove Access|
+
+:::image type="content" source="media/using-multi-stage-reviews/multi-stage-reviews.png" alt-text="Screenshot of multi-stage reviews." lightbox="media/using-multi-stage-reviews/multi-stage-reviews.png":::
+
+## Guest user reviews
+
+Guest user reviews include organizations that use Azure AD B2B for collaboration, users that are invited from another company into their tenant, guest user accounts created for assigning, and resources for tracking and reviewing access. These guest users’ access should be reviewed regularly to check on whether collaboration is still desired in order to facilitate a cleanup of guest user accounts that are no longer needed.
+
+This scenario can be configured with multi-stage reviews similarly to how the reduce reviewee list by filtering works. First, ask guest users to self-review and attest their continued interest and need for collaboration, and only then letting an internal employee approve or deny continued access or collaboration.
+
+For guest user review scenarios, Access Reviews supports an extra configuration option: **Action to apply on denied guest users**, which can result in either:
+
+- Remove user’s membership from the resource
+- Block user from signing-in for 30 days, then remove user from the tenant
+
+Depending on your review needs, guest users that aren’t responding to the review request, or decline further collaboration, can be removed automatically from your tenant.
+
+ | Attribute | Configuration |
+ |:--- |:---:|
+ |Multi-stage review|Enabled|
+ |First stage reviewers|Users review their own access|
+ |Second stage reviewers|Group owner(s)|
+ |Show previous stage(s) decisions to later stage reviewers|Disabled|
+ |Reviewees going to the next stage|Select **Approved reviewees**|
+ |If reviewers don’t respond|Remove Access|
+ |Action to apply on denied guest users|Block user from signing-in for 30 days, then remove user from the tenant|
+
+ > [!NOTE]
+ > The **Action to apply on denied guest users** setting is only visible in the review creation process if the Access Review scope is configured as **Guest users only**.
+
+## Duration of review stages  
+
+Review administrators define the duration of every review stage and therefore, how much time reviewers in their stage have to record their decisions. Each stage can be configured to have its own duration, to cater for availability and expectation of reviewers.
+
+:::image type="content" source="media/using-multi-stage-reviews/using-multi-stage-reviews.png" alt-text="Screenshot of using multi-stage reviews." lightbox="media/using-multi-stage-reviews/using-multi-stage-reviews.png":::
+
+Each review stage will stay open for reviewers to add decisions for the length of the duration. Review administrators can stop a running stage and automatically progress the overall review to the next review stage on the reviewer overview page, by selecting **Stop current stage**.
+
+## Application of results 
+
+Azure AD Access Reviews can apply decisions about access to a resource by removing no longer needed users from the resource. Decisions are always applied at the end of the review period or when a review administrator manually ends the review. Automatic application of results is defined by the review administrator with the **Auto apply results to resource** setting or manually through the **Apply results** button in the review overview page.
+
+Decisions are collected by reviewers for every stage. The setting **Reviewees going to the next stage** defines, which reviewees later stage reviewers will see and asked to record decisions for. Only at the end of the overall review, decisions are applied to the resource.
+
+For all decisions, the last decision recorded for a reviewee is applied at the end of the review. Decisions that were made for Jane in the first stage of the review, can in stage two and stage three be overwritten by later-stage reviewers.
+
+If the **Reviewees going to the next stage** setting is set such that only a subset of reviewees progress to later stages, it may be that decisions made in the first stage are applied at the end of the review. If the review administrator configured a three-stage review, and wants only **Denied** and **Not reviewed** reviewees to progress to the next stages, if Jane was approved in the first stage, she won't progress to the later stages and her **Approve** decision is recorded and at the end of the review, applied.
+
+## Next steps
+- [What are Azure AD access reviews](access-reviews-overview.md)
+- [Create an access review of groups and applications in Azure AD](create-access-review.md)
+
+
+
+
+ 

articles/active-directory/governance/media/using-multi-stage-reviews/new-access-reviews.png

@@ -54,7 +54,7 @@ To assign a user or group account to an enterprise application:
 :::zone pivot="aad-powershell"
 
 1. Open an elevated Windows PowerShell command prompt.
-1. Run `Connect-AzureAD Application.Read.All, Directory.Read.All, Application.ReadWrite.All, Directory.ReadWrite.All` and sign in with a Global Admin user account.
+1. Run `Connect-AzureAD -Scopes "Application.Read.All", "Directory.Read.All", "Application.ReadWrite.All", "Directory.ReadWrite.All"` and sign in with a Global Admin user account.
 1. Use the following script to assign a user and role to an application:
 
     ```powershell
@@ -116,7 +116,7 @@ This example assigns the user Britta Simon to the Microsoft Workplace Analytics
 ## Unassign users, and groups, from an application
 
 1. Open an elevated Windows PowerShell command prompt.
-1. Run `Connect-AzureAD Application.Read.All Directory.Read.All Application.ReadWrite.All Directory.ReadWrite.All` and sign in with a Global Admin user account. Use the following script to remove a user and role from an application.
+1. Run `Connect-AzureAD -Scopes "Application.ReadWrite.All", "Directory.ReadWrite.All", "AppRoleAssignment.ReadWrite.All"` and sign in with a Global Admin user account. Use the following script to remove a user and role from an application.
 
     ```powershell
     # Store the proper parameters
@@ -163,7 +163,7 @@ $assignments | ForEach-Object {
 :::zone pivot="ms-powershell"
 
 1. Open an elevated Windows PowerShell command prompt.
-1. Run `Connect-AzureAD Application.Read.All Directory.Read.All Application.ReadWrite.All Directory.ReadWrite.All` and sign in with a Global Admin user account.
+1. Run `Connect-MgGraph -Scopes "Application.ReadWrite.All", "Directory.ReadWrite.All", "AppRoleAssignment.ReadWrite.All"` and sign in with a Global Admin user account.
 1. Use the following script to assign a user and role to an application:
 
 ```powershell    
@@ -192,7 +192,7 @@ New-MgUserAppRoleAssignment -UserId $userId -BodyParameter $params |
 ## Unassign users, and groups, from an application
 
 1. Open an elevated Windows PowerShell command prompt.
-1. Run `Connect-AzureAD Application.Read.All Directory.Read.All Application.ReadWrite.All Directory.ReadWrite.All` and sign in with a Global Admin user account. Use the following script to remove a user and role from an application.
+1. Run `Connect-MgGraph -Scopes "Application.ReadWrite.All", "Directory.ReadWrite.All", "AppRoleAssignment.ReadWrite.All"` and sign in with a Global Admin user account. Use the following script to remove a user and role from an application.
 ```powershell
 # Get the user and the service principal
 
@@ -231,7 +231,7 @@ $assignments | ForEach-Object {
 
     You'll need to consent to the following permissions: 
 
-    `Application.Read.All`, `Application.ReadWrite.All`, `Directory.Read.All`, `Directory.ReadWrite.All`.
+    `Application.ReadWrite.All`, `Directory.ReadWrite.All`, `AppRoleAssignment.ReadWrite.All`.
 
     To grant an app role assignment, you need three identifiers: