Merge pull request #231765 from OWinfreyATL/owinfreyATL-PIM-SecurityUpdates

PIM MFA updates

Author: v-regandowner

.openpublishing.redirection.active-directory.json

@@ -7274,6 +7274,11 @@
     {
       "source_path_from_root": "/articles/active-directory/active-directory-privileged-identity-management-how-to-require-mfa.md",
       "redirect_url": "/azure/active-directory/privileged-identity-management/pim-how-to-require-mfa",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/active-directory/privileged-identity-management/pim-how-to-require-mfa.md",
+      "redirect_url": "/azure/active-directory/authentication/howto-mfa-getstarted",
       "redirect_document_id": true
     },
     {

articles/active-directory/privileged-identity-management/TOC.yml

@@ -14,8 +14,6 @@
     href: pim-roles.md
   - name: Secure privileged access in Azure AD
     href: ../roles/security-planning.md?toc=%2fazure%2factive-directory%2fprivileged-identity-management%2ftoc.json
-  - name: MFA and PIM
-    href: pim-how-to-require-mfa.md
 
   - name: Overview dashboards
     href: pim-resource-roles-overview-dashboards.md

articles/active-directory/privileged-identity-management/groups-role-settings.md

@@ -18,7 +18,7 @@ ms.collection: M365-identity-device-management
 
 # Configure PIM for Groups settings (preview)
 
-In Privileged Identity Management (PIM) for groups in Azure Active Directory (Azure AD), part of Microsoft Entra, role settings define membership or ownership assignment properties: MFA and approval requirements for activation, assignment maximum duration, notification settings, etc. Use the following steps to configure role settings and setup the approval workflow to specify who can approve or deny requests to elevate privilege.
+In Privileged Identity Management (PIM) for groups in Azure Active Directory (Azure AD), part of Microsoft Entra, role settings define membership or ownership assignment properties: MFA and approval requirements for activation, assignment maximum duration, notification settings, etc. Use the following steps to configure role settings and set up the approval workflow to specify who can approve or deny requests to elevate privilege.
 
 You need to have Global Administrator, Privileged Role Administrator, or group Owner permissions to manage settings for membership or ownership assignments of the group. Role settings are defined per role per group: all assignments for the same role (member or owner) for the same group follow same role settings. Role settings of one group are independent from role settings of another group. Role settings for one role (member) are independent from role settings for another role (owner).
 
@@ -55,11 +55,12 @@ Use the **Activation maximum duration** slider to set the maximum time, in hours
 
 ### On activation, require multi-factor authentication
 
-You can require users who are eligible for a role to prove who they are using Azure AD Multi-Factor Authentication before they can activate. Multi-factor authentication ensures that the user is who they say they are with reasonable certainty. Enforcing this option protects critical resources in situations when the user account might have been compromised.
+You can require users who are eligible for a role to prove who they are using Azure AD Multi-Factor Authentication before they can activate. Multi-factor authentication helps safeguard access to data and applications, providing another layer of security by using a second form of authentication. 
 
-User may not be prompted for multi-factor authentication if they authenticated with strong credential or provided multi-factor authentication earlier in this session.
-
-For more information, see [Multifactor authentication and Privileged Identity Management](pim-how-to-require-mfa.md).
+> [!NOTE]
+> User may not be prompted for multi-factor authentication if they authenticated with strong credentials, or provided multi-factor authentication earlier in this session. If your goal is to ensure that users have to provide authentication during activation, you can use [On activation, require Azure AD Conditional Access authentication context](pim-how-to-change-default-settings.md#on-activation-require-azure-ad-conditional-access-authentication-context-public-preview) together with [Authentication Strengths](../authentication/concept-authentication-strengths.md) to require users to authenticate during activation using methods different from the one they used to sign-in to the machine. For example, if users sign-in to the machine using Windows Hello for Business, you can use “On activation, require Azure AD Conditional Access authentication context” and Authentication Strengths to require users to do Passwordless sign-in with Microsoft Authenticator when they activate the role. After the user provides Passwordless sign-in with Microsoft Authenticator once in this example, they'll be able to do their next activation in this session without additional authentication because Passwordless sign-in with Microsoft Authenticator will already be part of their token. 
+> 
+> It's recommended to enable Azure AD Multi-Factor Authentication for all users. For more information, see [Plan an Azure Active Directory Multi-Factor Authentication deployment](../authentication/howto-mfa-getstarted.md).
 
 ### On activation, require Azure AD Conditional Access authentication context (Public Preview)
 
@@ -68,11 +69,23 @@ You can require users who are eligible for a role to satisfy Conditional Access
 To enforce this requirement, you need to:
 
 1.	Create Conditional Access authentication context.
+
 1.	Configure Conditional Access policy that would enforce requirements for this authentication context.
+    > [!NOTE]
+    > The scope of the Conditional Access policy should include all or eligible users for group membership/ownership. Do not create a Conditional Access policy scoped to authentication context and group at the same time because during activation a user does not have group membership yet, and the Conditional Access policy would not apply.
 1.	Configure authentication context in PIM settings for the role.
 
 :::image type="content" source="media/pim-for-groups/pim-group-21.png" alt-text="Screenshot of the Edit role settings Member page." lightbox="media/pim-for-groups/pim-group-21.png":::
 
+> [!NOTE]
+> If PIM settings have “**On activation, require Azure AD Conditional Access authentication context**” configured, Conditional Access policies define what conditions user needs to meet in order to satisfy the access requirements. This means that security principals with permissions to manage Conditional Access policies such as Conditional Access Administrators or Security Administrators may change requirements, remove them, or block eligible users from activating their group membership/ownership. Security principals that can manage Conditional Access policies should be considered highly privileged and protected accordingly.
+
+> [!NOTE]
+> We recommend creating and enabling Conditional Access policy for the authentication context before the authentication context is configured in PIM settings. As a backup protection mechanism, if there are no Conditional Access policies in the tenant that target authentication context configured in PIM settings, during group membership/ownership activation, Azure AD Multi-Factor Authentication is required as the [On activation, require multi-factor authentication](groups-role-settings.md#on-activation-require-multi-factor-authentication) setting would be set. This backup protection mechanism is designed to solely protect from a scenario when PIM settings were updated before the Conditional Access policy is created, due to a configuration mistake. This backup protection mechanism will not be triggered if the Conditional Access policy is turned off, in report-only mode, or has eligible users excluded from the policy. 
+
+> [!NOTE]
+> **“On activation, require Azure AD Conditional Access authentication context”** setting defines authentication context, requirements for which users will need to satisfy when they activate group membership/ownership. After group membership/ownership is activated, this does not prevent users from using another browsing session, device, location, etc. to use group membership/ownership. For example, user may use Intune compliant device to activate group membership/ownership, then after the role is activated, sign-in to the same user account from another device that is not Intune compliant, and use previously activated group ownership/membership from there. To protect from this situation, you may scope Conditional Access policies enforcing certain requirements to eligible users directly. For example, you can require users eligible to certain group membership/ownership to always use Intune compliant devices.
+
 To learn more about Conditional Access authentication context, see [Conditional Access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context).
 
 ### Require justification on activation
@@ -81,11 +94,11 @@ You can require that users enter a business justification when they activate the
 
 ### Require ticket information on activation
 
-You can require that users enter a support ticket when they activate the eligible assignment. This is information only field and correlation with information in any ticketing system is not enforced.
+You can require that users enter a support ticket when they activate the eligible assignment. This is information only field and correlation with information in any ticketing system isn't enforced.
 
 ### Require approval to activate
 
-You can require approval for activation of eligible assignment. Approver doesn’t have to be group member or owner. When using this option, you have to select at least one approver (we recommend to select at least two approvers), there are no default approvers.
+You can require approval for activation of eligible assignment. Approver doesn’t have to be group member or owner. When using this option, you have to select at least one approver (we recommend selecting at least two approvers), there are no default approvers.
 
 To learn more about approvals, see [Approve activation requests for PIM for Groups members and owners (preview)](groups-approval-workflow.md).
 

articles/active-directory/privileged-identity-management/pim-how-to-change-default-settings.md

@@ -17,7 +17,7 @@ ms.collection: M365-identity-device-management
 ---
 # Configure Azure AD role settings in Privileged Identity Management
 
-In Privileged Identity Management (PIM) in Azure Active Directory (Azure AD), part of Microsoft Entra, role settings define role assignment properties: MFA and approval requirements for activation, assignment maximum duration, notification settings, and more. Use the following steps to configure role settings and setup the approval workflow to specify who can approve or deny requests to elevate privilege.
+In Privileged Identity Management (PIM) in Azure Active Directory (Azure AD), part of Microsoft Entra, role settings define role assignment properties: MFA and approval requirements for activation, assignment maximum duration, notification settings, and more. Use the following steps to configure role settings and set up the approval workflow to specify who can approve or deny requests to elevate privilege.
 
 You need to have Global Administrator or Privileged Role Administrator role to manage PIM role settings for Azure AD Role. Role settings are defined per role: all assignments for the same role follow the same role settings. Role settings of one role are independent from role settings of another role.
 
@@ -51,11 +51,12 @@ Use the **Activation maximum duration** slider to set the maximum time, in hours
 
 ### On activation, require multi-factor authentication 
 
-You can require users who are eligible for a role to prove who they are using Azure AD Multi-Factor Authentication before they can activate. Multi-factor authentication ensures that the user is who they say they are with reasonable certainty. Enforcing this option protects critical resources in situations when the user account might have been compromised.
+You can require users who are eligible for a role to prove who they are using Azure AD Multi-Factor Authentication before they can activate. Multi-factor authentication helps safeguard access to data and applications, providing another layer of security by using a second form of authentication. 
 
-User may not be prompted for multi-factor authentication if they authenticated with strong credential or provided multi-factor authentication earlier in this session.
-
-For more information, see [Multifactor authentication and Privileged Identity Management](pim-how-to-require-mfa.md).
+> [!NOTE]
+> User may not be prompted for multi-factor authentication if they authenticated with strong credentials, or provided multi-factor authentication earlier in this session. If your goal is to ensure that users have to provide authentication during activation, you can use [On activation, require Azure AD Conditional Access authentication context](pim-how-to-change-default-settings.md#on-activation-require-azure-ad-conditional-access-authentication-context-public-preview) together with [Authentication Strengths](../authentication/concept-authentication-strengths.md) to require users to authenticate during activation using methods different from the one they used to sign-in to the machine. For example, if users sign-in to the machine using Windows Hello for Business, you can use “On activation, require Azure AD Conditional Access authentication context” and Authentication Strengths to require users to do Passwordless sign-in with Microsoft Authenticator when they activate the role. After the user provides Passwordless sign-in with Microsoft Authenticator once in this example, they'll be able to do their next activation in this session without additional authentication because Passwordless sign-in with Microsoft Authenticator will already be part of their token. 
+> 
+> It's recommended to enable Azure AD Multi-Factor Authentication for all users. For more information, see [Plan an Azure Active Directory Multi-Factor Authentication deployment](../authentication/howto-mfa-getstarted.md).
 
 ### On activation, require Azure AD Conditional Access authentication context (Public Preview)
 
@@ -64,11 +65,30 @@ You can require users who are eligible for a role to satisfy Conditional Access
 To enforce this requirement, you need to:
 
 1.	Create Conditional Access authentication context.
+
 1.	Configure Conditional Access policy that would enforce requirements for this authentication context.
+    > [!NOTE]
+    > The scope of the Conditional Access policy should include all or eligible users for a role. Do not create a Conditional Access policy scoped to authentication context and directory role at the same time because during activation the user does not have a role yet, and the Conditional Access policy would not apply. See the note at the end of this section about a situation when you may need two Conditional Access policies, one scoped to the authentication context, and another scoped to the role. 
 1.	Configure authentication context in PIM settings for the role.
 
 :::image type="content" source="media/pim-how-to-change-default-settings/role-settings-page.png" alt-text="Screenshot of the Edit role setting Attribute Definition Administrator page." lightbox="media/pim-how-to-change-default-settings/role-settings-page.png":::
 
+> [!NOTE]
+> If PIM settings have **“On activation, require Azure AD Conditional Access authentication context”** configured, the Conditional Access policies define conditions a user needs to meet to satisfy the access requirements. This means that security principals with permissions to manage Conditional Access policies such as Conditional Access Administrators or Security Administrators may change requirements, remove them, or block eligible users from activating the role. Security principals that can manage the Conditional Access policies should be considered highly privileged and protected accordingly. 
+
+> [!NOTE]
+> We recommend creating and enabling a Conditional Access policy for the authentication context before authentication context is configured in PIM settings. As a backup protection mechanism, if there are no Conditional Access policies in the tenant that target authentication context configured in PIM settings, during PIM role activation, Azure AD Multi-Factor Authentication is required as the [On activation, require multi-factor authentication](pim-how-to-change-default-settings.md#on-activation-require-multi-factor-authentication) setting would be set. This backup protection mechanism is designed to solely protect from a scenario when PIM settings were updated before the Conditional Access policy is created, due to a configuration mistake. This backup protection mechanism won't be triggered if the Conditional Access policy is turned off, in report-only mode, or has eligible user excluded from the policy. 
+
+> [!NOTE]
+> **“On activation, require Azure AD Conditional Access authentication context”** setting defines authentication context, requirements for which the user will need to satisfy when they activate the role. After the role is activated, this does not prevent users from using another browsing session, device, location, etc. to use permissions. For example, users may use an Intune compliant device to activate the role, then after the role is activated sign-in to the same user account from another device that is not Intune compliant, and use the previously activated role from there. 
+> To protect from this situation, create two Conditional Access policies: 
+>1. The first Conditional Access policy targeted to authentication context. It should have “*All users*” or eligible users in its scope. This policy will specify requirements the user needs to meet to activate the role. 
+>1. The second Conditional Access policy targeted to directory roles. This policy will specify requirements users need to meet to sign-in with directory role activated. 
+>
+>Both policies can enforce the same, or different, requirements depending on your needs. 
+>
+>Another option is to scope Conditional Access policies enforcing certain requirements to eligible users directly. For example you can require users eligible for certain roles to always use Intune compliant devices. 
+
 To learn more about Conditional Access authentication context, see [Conditional Access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context).
 
 ### Require justification on activation