Merging changes synced from https://github.com/MicrosoftDocs/azure-docs-pr (branch live)

Author: Banani-Rath

articles/active-directory-b2c/TOC.yml

@@ -31,6 +31,7 @@
     href: tutorial-create-user-flows.md
   - name: 4 - Manage your tenant
     href: tenant-management.md
+    displayName: break glass account, emergence account
   - name: 5 - Clean up and delete tenant
     href: tutorial-delete-tenant.md
 - name: Samples

articles/active-directory-b2c/conditional-access-user-flow.md

@@ -5,7 +5,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: overview
-ms.date: 03/03/2022
+ms.date: 04/10/2022
 ms.custom: project-no-code
 ms.author: kengaderdus
 author: kengaderdus
@@ -120,7 +120,7 @@ To add a Conditional Access policy:
 
     | Include  |License   |   Notes|
     |---|---|---|
-    |**All users**    | P1, P2  | If you choose to include **All Users**, this policy will affect all of your users. To be sure not to lock yourself out, exclude your administrative account by choosing **Exclude**, selecting **Directory roles**, and then selecting **Global Administrator** in the list. You can also select **Users and Groups** and then select your account in the **Select excluded users** list.  |
+    |**All users**    | P1, P2  | This policy will affect all of your users. To be sure not to lock yourself out, exclude your administrative account by choosing **Exclude**, selecting **Directory roles**, and then selecting **Global Administrator** in the list. You can also select **Users and Groups** and then select your account in the **Select excluded users** list.  |
 
 1. Select **Cloud apps or actions**, and then **Select apps**. Browse for your [relying party application](tutorial-register-applications.md).
 1. Select **Conditions**, and then select from the following conditions. For example, select **Sign-in risk** and **High**, **Medium**, and **Low** risk levels.
@@ -130,7 +130,7 @@ To add a Conditional Access policy:
     | **User risk**  | P2  |User risk represents the probability that a given identity or account is compromised.   |
     | **Sign-in risk**   | P2  |Sign-in risk represents the probability that a given authentication request isn't authorized by the identity owner.   |
     | **Device platforms**  |Not supported   |Characterized by the operating system that runs on a device. For more information, see [Device platforms](../active-directory/conditional-access/concept-conditional-access-conditions.md#device-platforms).   |
-    | **Locations**  |P1,P2   |Named locations may include the public IPv4 network information, country or region, or unknown areas that don't map to specific countries or regions. For more information, see [Locations](../active-directory/conditional-access/concept-conditional-access-conditions.md#locations).   |
+    | **Locations**  |P1, P2   |Named locations may include the public IPv4 network information, country or region, or unknown areas that don't map to specific countries or regions. For more information, see [Locations](../active-directory/conditional-access/concept-conditional-access-conditions.md#locations).   |
 
 3. Under **Access controls**, select **Grant**. Then select whether to block or grant access:
 
@@ -441,4 +441,4 @@ To review the result of a Conditional Access event:
 
 ## Next steps
 
-[Customize the user interface in an Azure AD B2C user flow](customize-ui-with-html.md)
+[Customize the user interface in an Azure AD B2C user flow](customize-ui-with-html.md)

articles/active-directory-b2c/tenant-management.md

@@ -1,23 +1,23 @@
 ---
 title: Manage your Azure Active Directory B2C
 titleSuffix: Azure Active Directory B2C
-description: Learn how to manage your Azure Active Directory B2C tenant. Learn which Azure AD features are supported in Azure AD B2C, how to use administrator roles to manage resources, and how to add work accounts and guest users to your Azure AD B2C tenant.
+description: Learn how to manage your Azure Active Directory B2C tenant. Learn which Azure AD features are supported in Azure AD B2C, how to use administrator roles to manage resources, and how to add work accounts and guest users to your Azure AD B2C tenant, and how to manage emergency access accounts in Azure AD B2C.
 services: active-directory-b2c
 author: kengaderdus
 manager: CelesteDG
 
 ms.service: active-directory
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 10/25/2021
+ms.date: 04/20/2022
 ms.custom: project-no-code
 ms.author: kengaderdus
 ms.subservice: B2C
 ---
 
 # Manage your Azure Active Directory B2C tenant
 
-In Azure Active Directory B2C (Azure AD B2C), a tenant represents your directory of consumer users. Each Azure AD B2C tenant is distinct and separate from any other Azure AD B2C tenant. An Azure AD B2C tenant is different than an Azure Active Directory tenant, which you may already have. In this article, you learn how to manage your Azure AD B2C tenant.
+In Azure Active Directory B2C (Azure AD B2C), a tenant represents your directory of consumer users. Each Azure AD B2C tenant is distinct and separate from any other Azure AD B2C tenant. An Azure AD B2C tenant is different than an Azure Active Directory (Azure AD) tenant, which you may already have. In this article, you learn how to manage your Azure AD B2C tenant.
 
 ## Prerequisites
 - If you haven't already created your own [Azure AD B2C Tenant](tutorial-create-tenant.md), create one now. You can use an existing Azure AD B2C tenant.
@@ -49,7 +49,70 @@ To create a new administrative account, follow these steps:
 1. Copy the autogenerated password provided in the **Password** box. You'll need to give this password to the user to sign in for the first time.
 1. Select **Create**.
 
-The user is created and added to your Azure AD B2C tenant. It's preferable to have at least one work account native to your Azure AD B2C tenant assigned the Global Administrator role. This account can be considered a *break-glass account*.
+The user is created and added to your Azure AD B2C tenant. It's preferable to have at least one work account native to your Azure AD B2C tenant assigned the Global Administrator role. This account can be considered a *break-glass account* or *[emergency access accounts](#manage-emergency-access-accounts-in-azure-ad-b2c)*.
+
+## Manage emergency access accounts in Azure AD B2C
+
+It's important that you prevent being accidentally locked out of your Azure Active Directory B2C (Azure AD B2C) organization because you can't sign in or activate another user's account as an administrator. You can mitigate the impact of accidental lack of administrative access by creating two or more *emergency access accounts* in your organization.
+
+When configuring these accounts, the following requirements need to be met:
+
+- The emergency access accounts shouldn't be associated with any individual user in the organization. Make sure that your accounts aren't connected with any employee-supplied mobile phones, hardware tokens that travel with individual employees, or other employee-specific credentials. This precaution covers instances where an individual employee is unreachable when the credential is needed. It's important to ensure that any registered devices are kept in a known, secure location that has multiple means of communicating with Azure AD B2C. 
+
+- Use strong authentication for your emergency access accounts and make sure it doesn’t use the same authentication methods as your other administrative accounts. For example, if your normal administrator account uses the Microsoft Authenticator app for strong authentication, use a FIDO2 security key for your emergency accounts.
+
+- The device or credential must not expire or be in scope of automated cleanup due to lack of use.
+
+
+### Create emergency access account
+
+Create two or more emergency access accounts. These accounts should be cloud-only accounts that use the *.onmicrosoft.com domain and that aren't federated or synchronized from an on-premises environment.
+
+Use the following steps to create an emergency access account:
+
+1. Sign in to the [Azure portal](https://portal.azure.com) as an existing Global Administrator. If you use your Azure AD account, make sure you're using the directory that contains your Azure AD B2C tenant:
+
+    1. Select the **Directories + subscriptions** icon in the portal toolbar.
+    
+    1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.
+    
+1. Under **Azure services**, select **Azure AD B2C**. Or in the Azure portal, search for and select **Azure AD B2C**.
+
+1. In the left menu, under **Manage**, select **Users**. 
+
+1. Select **+ New user**.
+
+1. Select **Create user**.
+
+1. Under **Identity**:
+
+    1. For **User name**, enter a unique user name such as *emergency account*. 
+    
+    1. For **Name**, enter a name such as *Emergency Account*
+    
+1. Under **Password**, enter your unique password. 
+    
+1. Under **Groups and roles** 
+ 
+    1. Select **User**.
+
+    1. In the pane that shows up, search for and select **Global administrator**, and then select **Select** button. 
+
+1. Under **Settings**, select the appropriate **Usage location**.
+
+1. Select **Create**.
+
+1. [Store account credentials safely](../active-directory/roles/security-emergency-access.md#store-account-credentials-safely).
+
+1. [Monitor sign in and audit logs](../active-directory/roles/security-emergency-access.md#monitor-sign-in-and-audit-logs).
+
+1. [Validate accounts regularly](../active-directory/roles/security-emergency-access.md#validate-accounts-regularly).
+
+Once you create your emergency accounts, you need to do the following: 
+
+- Make sure you [exclude at least one account from phone-based multi-factor authentication](../active-directory/roles/security-emergency-access.md#exclude-at-least-one-account-from-phone-based-multi-factor-authentication)
+
+- If you use [Conditional Access](conditional-access-user-flow.md), at least one emergency access account needs to be excluded from all Conditional Access policies.
 
 ## Invite an administrator (guest account)
 
@@ -74,7 +137,7 @@ To invite a user, follow these steps:
 
 1. Select **Create**.
 
-An invitation email is sent to the user. The user needs to accept the invitation to be able to sign in.
+An invitation email is sent to the user. The user needs to accept the invitation to be able to sign in. 
 
 ### Resend the invitation email
 
@@ -135,11 +198,11 @@ The user is deleted and no longer appears on the **Users - All users** page. The
 
 ## Protect administrative accounts
 
-It's recommended that you protect all administrator accounts with multifactor authentication (MFA) for more security. MFA is an identity verification process during sign-in that prompts the user for a more form of identification, such as a verification code on their mobile device or a request in their Microsoft Authenticator app.
+It's recommended that you protect all administrator accounts with multifactor authentication (MFA) for more security. MFA is an identity verification process during sign in that prompts the user for a more form of identification, such as a verification code on their mobile device or a request in their Microsoft Authenticator app.
 
-![Authentication methods in use at the sign-in screenshot](./media/tenant-management/sing-in-with-multi-factor-authentication.png)
+![Authentication methods in use at the sign in screenshot](./media/tenant-management/sing-in-with-multi-factor-authentication.png)
 
-You can enable [Azure AD security defaults](../active-directory/fundamentals/concept-fundamentals-security-defaults.md) to force all administrative accounts to use MFA.
+If you're not using [Conditional Access](conditional-access-user-flow.md), you can enable [Azure AD security defaults](../active-directory/fundamentals/concept-fundamentals-security-defaults.md) to force all administrative accounts to use MFA.
 
 ## Get your tenant name
 

articles/active-directory/privileged-identity-management/groups-features.md

@@ -12,7 +12,7 @@ ms.subservice: pim
 ms.topic: overview
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 10/07/2021
+ms.date: 04/18/2022
 ms.author: curtand
 ms.custom: pim 
 ms.collection: M365-identity-device-management
@@ -25,19 +25,19 @@ ms.collection: M365-identity-device-management
 
 In Privileged Identity Management (PIM), you can now assign eligibility for membership or ownership of privileged access groups. Starting with this preview, you can assign Azure Active Directory (Azure AD) built-in roles to cloud groups and use PIM to manage group member and owner eligibility and activation. For more information about role-assignable groups in Azure AD, see [Use Azure AD groups to manage role assignments](../roles/groups-concept.md).
 
->[!Important]
-> To assign a privileged access group to a role for administrative access to Exchange, Security & Compliance Center, or SharePoint, use the Azure AD portal **Roles and Administrators** experience and not in the Privileged Access Groups experience to make the user or group eligible for activation into the group.
+> [!Important]
+> To provide a group of users with just-in-time access to roles with permissions in SharePoint, Exchange, or Security & Compliance Center, be sure to make permanent assignments of users to the group, and then assign the group to a role as eligible for activation. If instead you  assign a role permanently to a group and and assign users to be eligible to group membership, it might take significant time to have all permissions of the role activated and ready to use.
 
 > [!NOTE]
 > For privileged access groups that are used to elevate into Azure AD roles, we recommend that you require an approval process for eligible member assignments. Assignments that can be activated without approval might create a security risk from administrators who have a lower level of permissions. For example, the Helpdesk Administrator has permissions to reset an eligible user's password.
 
 ## Require different policies for each role assignable group
 
-Some organizations use tools like Azure AD business-to-business (B2B) collaboration to invite their partners as guests to their Azure AD organization. Instead of a single just-in-time policy for all assignments to a privileged role, you can create two different privileged access groups with their own policies. You can enforce less strict requirements for your trusted employees, and stricter requirements like approval workflow for your partners when they request activation into their assigned group.
+Some organizations use tools like Azure AD business-to-business (B2B) collaboration to invite their partners as guests to their Azure AD organization. Instead of a single just-in-time policy for all assignments to a privileged role, you can create two different privileged access groups with their own policies. You can enforce less strict requirements for your trusted employees, and stricter requirements like approval workflow for your partners when they request activation into their assigned role.
 
 ## Activate multiple role assignments in a single request
 
-With the privileged access groups preview, you can give workload-specific administrators quick access to multiple roles with a single just-in-time request. For example, your Tier 0 Office Admins might need just-in-time access to the Exchange Admin, Office Apps Admin, Teams Admin, and Search Admin roles to thoroughly investigate incidents daily. Before today it would require four consecutive requests, which are a process that takes some time. Instead, you can create a role assignable group called “Tier 0 Office Admins”, assign it to each of the four roles previously mentioned (or any Azure AD built-in roles) and enable it for Privileged Access in the group’s Activity section. Once enabled for privileged access, you can configure the just-in-time settings for members of the group and assign your admins and owners as eligible. When the admins elevate into the group, they’ll become members of all four Azure AD roles.
+With the privileged access groups preview, you can give workload-specific administrators quick access to multiple roles with a single just-in-time request. For example, your Tier 0 Office Admins might need just-in-time access to the Exchange Admin, Office Apps Admin, Teams Admin, and Search Admin roles to thoroughly investigate incidents daily. You can create a role-assignable group called “Tier 0 Office Admins”, and make it eligible for assignment to the four roles previously mentioned (or any Azure AD built-in roles) and enable it for Privileged Access in the group’s Activity section. Once enabled for privileged access, you can assign your admins and owners to the group. When the admins elevate the group into the roles, your staff will have permissions from all four Azure AD roles.
 
 ## Extend and renew group assignments
 

articles/active-directory/privileged-identity-management/pim-apis.md

@@ -10,33 +10,30 @@ ms.service: active-directory
 ms.workload: identity
 ms.subservice: pim
 ms.topic: how-to
-ms.date: 10/07/2021
+ms.date: 04/18/2022
 ms.author: curtand
 ms.reviewer: shaunliu
 ms.custom: pim 
 ms.collection: M365-identity-device-management
 ---
 # Understand the Privileged Identity Management APIs
 
-You can perform Privileged Identity Management (PIM) tasks using the Microsoft Graph APIs for Azure Active Directory (Azure AD) roles and the Azure Resource Manager API for Azure resource roles (sometimes called Azure RBAC roles). This article describes important concepts for using the APIs for Privileged Identity Management.
+You can perform Privileged Identity Management (PIM) tasks using the Microsoft Graph APIs for Azure Active Directory (Azure AD) roles and the Azure Resource Manager API for Azure roles. This article describes important concepts for using the APIs for Privileged Identity Management.
 
 For requests and other details about PIM APIs, check out:
 
 - [PIM for Azure AD roles API reference](/graph/api/resources/unifiedroleeligibilityschedulerequest?view=graph-rest-beta&preserve-view=true)
 - [PIM for Azure resource roles API reference](/rest/api/authorization/roleeligibilityschedulerequests)
 
-> [!IMPORTANT]
-> PIM APIs [!INCLUDE [PREVIEW BOILERPLATE](../../../includes/active-directory-develop-preview.md)]
-
 ## PIM API history
 
 There have been several iterations of the PIM API over the past few years. You'll find some overlaps in functionality, but they don't represent a linear progression of versions.
 
-### Iteration 1 – only supports Azure AD roles, deprecating
+### Iteration 1 – Deprecated
 
-Under the /beta/privilegedRoles endpoint, Microsoft had a classic version of the PIM API which is no longer supported in most tenants. We are in the process of deprecating remaining access to this API on 05/31.
+Under the /beta/privilegedRoles endpoint, Microsoft had a classic version of the PIM API which only supported Azure AD roles and is no longer supported. Access to this API was deprecated in June 2021.
 
-### Iteration 2 – supports Azure AD roles and Azure resource roles
+### Iteration 2 – Supports Azure AD roles and Azure resource roles
 
 Under the /beta/privilegedAccess endpoint, Microsoft supported both /aadRoles and /azureResources. This endpoint is still available in your tenant but Microsoft recommends against starting any new development with this API. This beta API will never be released to general availability and will be eventually deprecated.