Merge pull request #225253 from amsliu/revert-224793-pim-settings-update

Revert "pim settings update"

Author: Court72

.openpublishing.redirection.active-directory.json

@@ -11058,12 +11058,12 @@
     },
     {
       "source_path_from_root": "/articles/active-directory/privileged-identity-management/concept-privileged-access-versus-role-assignable.md",
-      "redirect_url": "/azure/active-directory/privileged-identity-management/concept-pim-for-groups",
+      "redirect_url": "azure/active-directory/privileged-identity-management/concept-pim-for-groups",
       "redirect_document_id": false
     },
     {
       "source_path_from_root": "/articles/active-directory/privileged-identity-management/groups-features.md",
-      "redirect_url": "/azure/active-directory/privileged-identity-management/concept-pim-for-groups",
+      "redirect_url": "azure/active-directory/privileged-identity-management/concept-pim-for-groups",
       "redirect_document_id": false
     },
     {

articles/active-directory/privileged-identity-management/concept-pim-for-groups.md

@@ -11,7 +11,7 @@ ms.subservice: pim
 ms.topic: overview
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 01/25/2023
+ms.date: 01/11/2023
 ms.author: amsliu
 ms.custom: pim 
 ms.collection: M365-identity-device-management
@@ -22,11 +22,11 @@ ms.collection: M365-identity-device-management
 
 # Privileged Identity Management (PIM) for Groups (preview)
 
-With Azure Active Directory (Azure AD), part of Microsoft Entra, you can provide users just-in-time membership in the group and just-in-time ownership of the group using the Azure AD Privileged Identity Management for Groups feature. These groups can be used to govern access to various scenarios that include Azure AD roles, Azure roles, as well as Azure SQL, Azure Key Vault, Intune, other application roles, and third party applications.
+With Azure Active Directory (Azure AD), part of Microsoft Entra, you can provide users just-in-time membership in the group and just-in-time ownership of the group using the Azure AD Privileged Identity Management for Groups feature. These groups can be used to govern access to a variety of scenarios that include Azure AD roles, Azure roles, as well as Azure SQL, Azure Key Vault, Intune, other application roles, and 3rd party applications.
 
 ## What is PIM for Groups?
 
-PIM for Groups is part of Azure AD Privileged Identity Management – alongside with PIM for Azure AD Roles and PIM for Azure Resources, PIM for Groups enables users to activate the ownership or membership of an Azure AD security group or Microsoft 365 group. Groups can be used to govern access to various scenarios that include Azure AD roles, Azure roles, as well as Azure SQL, Azure Key Vault, Intune, other application roles, and third party applications.
+PIM for Groups is part of Azure AD Privileged Identity Management – alongside with PIM for Azure AD Roles and PIM for Azure Resources, PIM for Groups enables users to activate the ownership or membership of an Azure AD security group or Microsoft 365 group. Groups can be used to govern access to a variety of scenarios that include Azure AD roles, Azure roles, as well as Azure SQL, Azure Key Vault, Intune, other application roles, and 3rd party applications.
 
 With PIM for Groups you can use policies similar to ones you use in PIM for Azure AD Roles and PIM for Azure Resources: you can require approval for membership or ownership activation, enforce multi-factor authentication (MFA), require justification, limit maximum activation time, and more. Each group in PIM for Groups has two policies: one for activation of membership and another for activation of ownership in the group. Up until January 2023, PIM for Groups feature was called “Privileged Access Groups”.
 
@@ -65,14 +65,6 @@ There are two ways to make a group of users eligible for Azure AD role:
 
 To provide a group of users with just-in-time access to Azure AD directory roles with permissions in SharePoint, Exchange, or Security & Microsoft Purview compliance portal (for example, Exchange Administrator role), be sure to make active assignments of users to the group, and then assign the group to a role as eligible for activation (Option #1 above). If you choose to make active assignment of a group to a role and assign users to be eligible to group membership instead, it may take significant time to have all permissions of the role activated and ready to use.
 
-## Privileged Identity Management and group nesting
-
-In Azure AD, role-assignable groups can’t have other groups nested inside them. To learn more, see [Use Azure AD groups to manage role assignments](../roles/groups-concept.md). This is applicable to active membership: one group cannot be an active member of another group that is role-assignable.
-
-One group can be an eligible member of another group, even if one of those groups is role-assignable.
-
-If a user is active member of Group A, and Group A is an eligible member of Group B, the user can activate their membership in Group B. This activation will be only for the user that requested the activation for, it does not mean that the entire Group A becomes an active member of Group B.
-
 ## Next steps
 
 - [Bring groups into Privileged Identity Management (preview)](groups-discover-groups.md)

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

@@ -18,9 +18,9 @@ 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/ownership assignment properties: MFA and approval requirements for activation, assignment maximum duration, notification settings, etc. Use the following steps to configure role settings – i.e., setup 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).
+You need to have Global Administrator, Privileged Role Administrator, or group Owner permissions to manage settings for membership/ownership assignments of the group. Role settings are defined per role per group: all assignments for the same role (member/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).
 
 
 ## Update role settings
@@ -53,28 +53,14 @@ Follow these steps to open the settings for a group role.
 
 Use the **Activation maximum duration** slider to set the maximum time, in hours, that an activation request for a role assignment remains active before it expires. This value can be from one to 24 hours.
 
-### On activation, require multi-factor authentication
+### Require multi-factor authentication (MFA) on activation
 
 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.
 
 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).
 
-### On activation, require Azure AD Conditional Access authentication context (Public Preview)
-
-You can require users who are eligible for a role to satisfy Conditional Access policy requirements: use specific authentication method enforced through Authentication Strengths, elevate the role from Intune compliant device, comply with Terms of Use, and more. 
-
-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.
-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":::
-
-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
 
 You can require that users enter a business justification when they activate the eligible assignment.
@@ -113,8 +99,7 @@ And, you can choose one of these **active** assignment duration options:
 ### Require multi-factor authentication on active assignment
 
 You can require that administrator or group owner provides multi-factor authentication when they create an active (as opposed to eligible) assignment. Privileged Identity Management can't enforce multi-factor authentication when the user uses their role assignment because they are already active in the role from the time that it is assigned.
-
-Administrator or group owner may not be prompted for multi-factor authentication if they authenticated with strong credential or provided multi-factor authentication earlier in this session.
+User may not be prompted for multi-factor authentication if they authenticated with strong credential or provided multi-factor authentication earlier in this session.
 
 ### Require justification on active assignment