Merge pull request #221647 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/active-directory/fundamentals/active-directory-users-reset-password-azure-portal.md

@@ -23,7 +23,9 @@ ms.collection: M365-identity-device-management
 As an administrator, you can reset a user's password if the password is forgotten, if the user gets locked out of a device, or if the user never received a password.
 
 >[!Note]
->Unless your Azure AD tenant is the home directory for a user, you won't be able reset their password. This means that if your user is signing in to your organization using an account from another organization, a Microsoft account, or a Google account, you won't be able to reset their password.<br><br>If your user has a source of authority as Windows Server Active Directory, you'll only be able to reset the password if you've turned on password writeback.<br><br>If your user has a source of authority as External Azure AD, you won't be able to reset the password. Only the user, or an administrator in External Azure AD, can reset the password.
+>Unless your Azure AD tenant is the home directory for a user, you won't be able reset their password. This means that if your user is signing in to your organization using an account from another organization, a Microsoft account, or a Google account, you won't be able to reset their password.
+>
+>If your user has a source of authority as Windows Server Active Directory, you'll only be able to reset the password if you've turned on password writeback and the user domain is managed. Changing the user password from Azure Active Directory for federated domains is not supported. In this case, you should change the user password in the on-premises Active Directory.<br><br>If your user has a source of authority as External Azure AD, you won't be able to reset the password. Only the user, or an administrator in External Azure AD, can reset the password.
 
 >[!Note]
 >If you're not an administrator and are instead looking for instructions about how to reset your own work or school password, see [Reset your work or school password](https://support.microsoft.com/account-billing/reset-your-work-or-school-password-using-security-info-23dde81f-08bb-4776-ba72-e6b72b9dda9e).
@@ -64,4 +66,4 @@ After you've reset your user's password, you can perform the following basic pro
 
 - [Create a basic group and add members](active-directory-groups-create-azure-portal.md)
 
-Or you can perform more complex user scenarios, such as assigning delegates, using policies, and sharing user accounts. For more information about other available actions, see [Azure Active Directory user management documentation](../enterprise-users/index.yml).
+Or you can perform more complex user scenarios, such as assigning delegates, using policies, and sharing user accounts. For more information about other available actions, see [Azure Active Directory user management documentation](../enterprise-users/index.yml).

articles/active-directory/governance/using-multi-stage-reviews.md

@@ -24,17 +24,17 @@ Azure AD Access Reviews support up to three review stages, in which multiple typ
 
 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":::
+:::image type="content" source="media/using-multi-stage-reviews/new-access-reviews.png" alt-text="Screenshot of admin experience to configure multi-stage 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.     
+- **Assign alternate reviewers to weigh in on unreviewed decisions:** Let the resource owner attest to access to their resource first. 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. Use this scenario to filter down on users to review, stage by stage.     
 
 ## 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. 
+Reaching quorum on the right access for users can be difficult. For resources that many users have access to, or for a diverse group of 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 up to 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.
 
@@ -52,7 +52,7 @@ The configuration for this scenario would look like this:
 
 ## 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.
+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. 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.
 
@@ -87,19 +87,22 @@ An example would be a review of a group that grants an IT exception, that an adm
 
 ## 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.
+Guest user reviews help organizations that use Azure AD B2B for collaboration. These guest users’ access should be reviewed regularly to check on whether these guest users have the right access still, and that collaboration is still desired, so revoking access or a cleanup of guest user accounts that are no longer needed is possible.
 
-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.
+This scenario can be configured with multi-stage reviews similar to how the "Reduce burden on later stage reviewers" scenario works. First, ask guest users to self-review and attest their continued interest and need for collaboration, including the requirement to provide a business justification. Only self-approved guests are progressed to a later stage, where an internal employee or sponsor 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:
+For guest user reviews, also consider leveraging the **Inactive users (on tenant level) only** setting. This will scope the review to inactive external users that have not signed in to the resource tenant in the number of specified days.
+
+In scenarios for guest users, 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.
+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. This results in a blocked B2B guest user account for 30 days, following an account deletion.
 
  | Attribute | Configuration |
  |:--- |:---:|
+ |Inactive users (on tenant level) only|180 days|
  |Multi-stage review|Enabled|
  |First stage reviewers|Users review their own access|
  |Second stage reviewers|Group owner(s)|
@@ -121,7 +124,7 @@ Each review stage will stay open for reviewers to add decisions for the length o
 
 ## 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.
+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.
 
@@ -136,4 +139,4 @@ If the **Reviewees going to the next stage** setting is set such that only a sub
 
 
 
- 
+ 

articles/active-directory/manage-apps/migrate-application-authentication-to-azure-active-directory.md

@@ -265,7 +265,7 @@ The already modernized apps are the most likely to be moved to Azure AD. These a
 
 In addition to the choices in the [Azure AD app gallery,](https://azuremarketplace.microsoft.com/marketplace/apps/category/azure-active-directory-apps) these could be apps that already exist in your organization or any third-party apps from a vendor who is not a part of the Azure AD gallery ([non-gallery applications)](./add-application-portal.md).
 
-Legacy apps that you choose to modernize
+### Legacy apps that you choose to modernize
 
 For legacy apps that you want to modernize, moving to Azure AD for core authentication and authorization unlocks all the power and data-richness that the [Microsoft Graph](https://developer.microsoft.com/graph/gallery/?filterBy=Samples,SDKs) and [Intelligent Security Graph](https://www.microsoft.com/security/operations/intelligence?rtc=1) have to offer.
 

articles/azure-monitor/essentials/prometheus-remote-write-managed-identity.md

@@ -105,14 +105,14 @@ This step isn't required if you're using an AKS identity since it will already h
               httpGet:
                 path: /health
                 port: rw-port
-                initialDelaySeconds: 10
-                timeoutSeconds: 10
+              initialDelaySeconds: 10
+              timeoutSeconds: 10
             readinessProbe:
               httpGet:
                 path: /ready
                 port: rw-port
-                initialDelaySeconds: 10
-                timeoutSeconds: 10
+              initialDelaySeconds: 10
+              timeoutSeconds: 10
             env:
               - name: INGESTION_URL
                 value: <INGESTION_URL>
@@ -150,7 +150,7 @@ This step isn't required if you're using an AKS identity since it will already h
     az aks get-credentials -g <aks-rg-name> -n <aks-cluster-name> 
  
     # use helm to update your remote write config 
-    helm upgrade -f <YAML-FILENAME>.yml prometheus prometheus-community/kube-prometheus-stack -namespace <namespace where Prometheus pod resides> 
+    helm upgrade -f <YAML-FILENAME>.yml prometheus prometheus-community/kube-prometheus-stack --namespace <namespace where Prometheus pod resides> 
     ```
 
 ## Verification and troubleshooting

articles/container-apps/azure-arc-enable-cluster.md

@@ -118,7 +118,7 @@ The following steps help you get started understanding the service, but for prod
     # [bash](#tab/bash)
 
     ```azurecli
-    az group create --group $AKS_CLUSTER_GROUP_NAME --location $LOCATION
+    az group create --name $AKS_CLUSTER_GROUP_NAME --location $LOCATION
     az aks create \
        --resource-group $AKS_CLUSTER_GROUP_NAME \
        --name $AKS_NAME \ 
@@ -129,7 +129,7 @@ The following steps help you get started understanding the service, but for prod
     # [PowerShell](#tab/azure-powershell)
     
     ```azurepowershell
-    az group create --group $AKS_CLUSTER_GROUP_NAME --location $LOCATION
+    az group create --name $AKS_CLUSTER_GROUP_NAME --location $LOCATION
     az aks create `
        --resource-group $AKS_CLUSTER_GROUP_NAME `
        --name $AKS_NAME `
@@ -152,13 +152,13 @@ The following steps help you get started understanding the service, but for prod
     # [bash](#tab/bash)
 
     ```azurecli
-        az group create --group $GROUP_NAME --location $LOCATION
+        az group create --name $GROUP_NAME --location $LOCATION
     ```
 
     # [PowerShell](#tab/azure-powershell)
 
     ```azurepowershell
-    az group create --group $GROUP_NAME --location $LOCATION
+    az group create --name $GROUP_NAME --location $LOCATION
     ```
 
     ---