Update AAD baseline policies and instructions to include PIM for Groups

[tkol2022]

💡 Summary

Azure AD policies that rely on the AAD PIM APIs need to be augmented to account for the PIM for Groups feature. Currently those baseline policies only include PIM for Roles and therefore are incomplete.

This issue is scoped to update the AAD baseline document policies and instructions to include PIM for Groups . This is only about updating the baseline. We have separate issues for updating the code.

All of the AAD policies in section 7 of the baseline are impacted by this change except for MS.AAD.7.5. See a detailed impact analysis in the comments.

Acceptance criteria

• Update the respective Azure AD baseline policies and implementation steps to account for PIM for Groups

[tkol2022]

Impact Analysis

I performed hands-on testing and determined the impact of adding PIM for Groups to five Azure AD policies. Details included below.

Azure AD policies affected by the PIM for Groups feature:

MS.AAD.7.1 A minimum of two users and a maximum of eight users SHALL be provisioned with the Global Administrator role
I assigned Ted's PIM Test Group to Global Admin as an active assignment. Test user Alex did not have his membership in Ted's PIM Test Group activated but he is eligible - then I ran ScubaGear and Alex did not show up in the report output so the code doesn't handle this scenario. I then activated Alex's membership in Ted's PIM Test Group, ran ScubaGear and Alex showed up in the report output. The code must be fixed to include users that are PIM eligible (but not activated) to be a member of a Group that has been assigned to a privileged role. The code must handle groups assigned to a privileged role as either eligible or active.
The code currently handles scenarios where a user is an "activated" member of a PIM group assigned to a privileged role.

MS.AAD.7.2 Privileged users SHALL be provisioned with finer-grained roles instead of Global Administrator
This policy must be updated the handle the same scenario as 7.1. The count in our formula must be revised to include users that are PIM eligible (but not activated) to be a member of a Group that has been assigned to a privileged role.

MS.AAD.7.3 Privileged users SHALL be provisioned cloud-only accounts separate from an on-premises directory or other federated identity providers
This policy must be updated the handle the same scenario as 7.1. The code must be fixed to include users that are PIM eligible (but not activated) to be a member of a Group that has been assigned to a privileged role.

MS.AAD.7.4 Permanent active role assignments SHALL NOT be allowed for highly privileged roles.
*Note this policy is changing during Emerald from what it is today. It is no longer looking at the PIM configuration settings for each role, but instead looking at the active assignments to see if any users / groups are permanently assigned.
This policy must be updated to handle the same scenario as 7.1 for items listed as having a "permanent" active role assignment with some additional logic. The following scenario would need to be covered. For each privileged role, go through the groups listed as having a permanent active role assignment. For each group check if there are users (either Member or Owner) that are PIM assigned to the group with permanent "active" group membership.
To summarize, this checks if there are items with both permanent active assignment in the PIM Role assignments and in the respective PIM Group assignments.

MS.AAD.7.6 Activation of the Global Administrator role SHALL require approval
This policy becomes more complex with the inclusion of PIM for groups. Now instead of just checking the PIM configuration setting (Require approval to active) for the privileged roles, we must also check the same PIM configuration setting for any PIM groups assigned to privileged roles. PIM Groups have their own configuration settings.
The complication comes in when you consider that we probably wouldn't want to create a scenario where there is an approval to active a role and an approval to activate membership in a group assigned to the role. That would create the need for a double approval which wouldn't make operational sense. Therefore we may end up having to create logic for checking if the role requires approval to activate or if the group requires approval to activate membership, but NOT both.

MS.AAD.7.7 Eligible and Active highly privileged role assignments SHALL trigger an alert, MS.AAD.7.8 User activation of the Global Administrator role SHALL trigger an alert, MS.AAD.7.9 User activation of other highly privileged roles SHOULD trigger an alert
This policy would need to be augmented with additional checks that also examine the PIM Group configuration settings for similar values (alerts sent for user to group membership assignments and activation). We would only examine PIM group configurations that are assigned to privileged roles (as either eligible or active).

Further Analysis Needed

PIM for Groups has a concept of a Member versus an Owner of a group. Each type has their own configuration settings and therefore we might need to check both for the policies. This requires further hands-on prototyping and analysis.

Policies NOT affected by the PIM for Groups feature even though they make calls to PIM APIs:

MS.AAD.7.5 Provisioning users to highly privileged roles SHALL NOT occur outside of a PAM system.
This is not affected because this policy checks the Active Assignments list for entries that have a Start Time of null and an End Time of Permanent. It is only possible to create such an entry from outside of AAD PIM by using the 365 admin center and directly assigning users / groups to privileged roles, therefore such as assignment cannot occur from within PIM for Groups.

[gdasher]

Upon further reflection, I think this issue should be a priority for flipper. Happy to discuss on slack why that is.

[tkol2022]

This is blocked on the completion of #755

[tkol2022]

Record of changes to the baseline to support PIM for Groups

Intro

• Moved the warning about these instructions being labor intensive to the beginning of the section since it applies to all the policies.

7.1

• Had to redesign most of the instructions to account for PIM for Groups and added a Final Count section to make this more clear to the audience

7.2

• Revised the instructions to align with the new calculation we are using in Implement ScubaGear policy check for MS.AAD.7.2v1 #760.

7.3

• Step 4 added a sentence to support PIM for Groups

7.4

• Step 4 created a new subsection that describes each exception case.
• Added groups enrolled in PIM for Groups as an exception case

7.5

• Step 4 removed the Eligible assignments from the scope since only the Active assignments are applicable
• No other changes needed since step 5 does not change when the group is enrolled in PIM for Groups.