Perform hands-on prototyping of how the existing AAD 7.6 through 7.9 policy configurations affect users assigned to roles via PIM for Groups

[tkol2022]

💡 Summary

Currently, in AAD policies 7.6 through 7.9 are related to security configurations in the PIM portal that are associated with "roles". Now that we have enhanced AAD to consider PIM for Groups, we need to test the AAD policies above and see how they affect users that are assigned to roles via membership in a PIM group. Two outcomes can occur from this testing:

1. We do not need to update the baseline or ScubaGear. The existing configurations are appropriate and will work fine when an organization is using PIM for Groups to make user assignments.
2. We find that some use cases are not covered with our existing code and baseline so we need to revise the baseline and add a code enhancement to Get-PrivilegedRole in the AAD provider.

Implementation notes

• Create a spreadsheet that documents each test case
• Execute the tests against the test tenant and document the results
• If necessary open an issue to revise the baseline document
• If necessary open an issue to enhance the AAD code

[tkol2022]

Prototyping Results

The addition of PIM for Groups into the scope of AAD policies 7.6 through 7.9 requires additional configurations of the respective settings at the "group" level - we currently only support the settings applied at the "role" level. See the discussion of gaps and conclusions below. Policies 7.6, 7.8 and 7.9 were tested together because they are all related to "activation", whereas 7.7 is related to "assignment".

Spreadsheet with detailed test results is attached.
PIM role settings scenarios.xlsx

Terminology

• Activation - Role activation is the process of a user selecting a role that they are "eligible" for, and clicking on the Activate button in PIM. This is a process that typically gets initiated by the user.
• Assignment - An administrator "assigns" a role to a user. The role can be assigned as either eligible or active.

AAD 7.6 - Activation of the Global Administrator role SHALL require approval.
AAD 7.7 - Eligible and Active highly privileged role assignments SHALL trigger an alert.
AAD 7.8 - User activation of the Global Administrator role SHALL trigger an alert.
AAD 7.9 - User activation of other highly privileged roles SHOULD trigger an alert.

The following gaps in the existing ScubaGear code (and policy configuration in the baseline) were noted based on the testing:

• If a PIM group is assigned to a privileged role as an Active assignment (the recommended approach), the security configuration settings for policies 7.6, 7.8, 7.9 are not applied by the system. This is because in this scenario, the user never has to "activate" their role assignment directly - instead the user activates their membership into a PIM group. The configurations to require an approval and send an email notification upon user activation of their role are bypassed.
• If a PIM group is assigned to a privileged role as an Active assignment, the security configuration for policy 7.7 is not applied either. Whenever an administrator assigns a user to a PIM group (regardless of Eligible or Active), that event is not treated as an assignment to a role so the configuration setup by policy 7.7 (which is at the role level) is out of scope and the alert is bypassed.

Conclusions

• One potential approach to handle these gaps is to augment the baseline so that the same configurations described in policies 7.6 through 7.9 are also applied to the PIM group. I tested the configurations when they are applied to the group and they behave in the same manner as when they are applied to the role. The configurations are applied at the "Member" not the "Owner" in PIM for Groups.
• If we add policies to check the configurations of PIM groups, we would need to determine which specific PIM groups to examine because not all of them will be assigned to the privileged roles within the scope of the baseline (currently 8 specific roles). Our code would need to check which PIM groups are assigned as Active to a privileged role and then inspect the configurations of those PIM groups.
• I haven't performed the research to determine which MS Graph Cmdlet can retrieve the PIM group configurations. I imagine that one exists because I was able to find one that retrieved PIM group assignments for policies 7.1 through 7.5 in the previous release.
• If an organization decides to use PIM for Groups (which makes practical sense for reasons previously discussed), would that organization need to configure security settings for both PIM for Roles (our current scope) and PIM for Groups? I believe the answer is yes because otherwise the security policies associated with 7.6 through 7.9 would only be partially applied (i.e. we wouldn't be covering the gap usage scenarios described in the bullets above).
• In theory, if we believe that configuring role security settings and group security settings could be viewed as burdensome, even though it is a one-time configuration, we could develop a utility script that an administrator could execute, that would apply the respective configurations to the required roles and PIM groups.