Enhance AAD provider to handle nested PIM groups and refactor Get-PrivilegedUser to reduce code duplication

[tkol2022]

🗣 Description

The general impetus for this PR was a publicly reported edge case where the AAD provider crashes when an admin assigns a nested group to an AAD PIM group as an Eligible assignment. In order to implement the fix, I determined that augmenting the current code in Get-PrivilegedUser was a bad idea because it had already become hard to maintain with lots of duplication, so I refactored Get-PrivilegedUser to call a new helper function named LoadObjectDataIntoPrivilegedUserHashtable which takes a user or a group as an argument, fetches the metadata about the object and loads the metadata into the PrivilegedUsers hashtable which is used to form the privileged_users section of the provider JSON document. The other major defect that this PR addresses is that the code now handles a scenario where a user or a group is deleted from the directory in the hours before running ScubaGear, this can cause ScubaGear to crash if the object was Eligible assigned to a PIM group.

Both of the defects described above, the nested groups and the deleted objects cause ScubaGear to crash with a 404 (NotFound) Request_ResourceNotFound error, even though the root cause is completely unrelated.

*I have some Write-Warning statements dispersed in the code right now which are only to assist the pull request reviewers with testing the various scenarios. These will be removed.

Iterative list of code changes:

• Added helper function LoadObjectDataIntoPrivilegedUserHashtable to handle fetching of metadata for users and groups
• Added code in helper function to handle nested PIM groups causing 404 crash
• Added code in helper function to handle deleted objects causing 404 crash
• Refactored Get-PrivilegedUser to reduce code duplication and simplify the logic
• Added usage of Get-MgBetaDirectoryObject to helper function to determine if an object is a user or a group (which is needed in some code paths). Thanks to @thetolkienblackguy for this recommendation.
• Changed TenantHasPremiumLicense parameter used in multiple functions from type "switch" to "bool" because we are using the parameter as a bool in the way we are calling the respective functions.
• Added new ScubaGear dependency for Graph Powershell module Microsoft.Graph.Beta.DirectoryObjects which is needed for Get-MgBetaDirectoryObject cmdlet

Closes #1288
Closes #1306
Closes #1305
Closes #1303

ToDo

• Add more comments into the code since there is a lot going on
• Remove Write-Warning which are there for PR testing before merging to main

🧪 Testing

Due to the size of the PR description, I provide testing instructions as detailed comments. Each reviewer should have a comment template with multiple test cases associated with your name.

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• PR targets the correct parent branch (e.g., main or release-name) for merge.
• Changes are limited to a single goal - eschew scope creep!
• Changes are sized such that they do not touch excessive number of files.
• All future TODOs are captured in issues, which are referenced in code comments.
• These code changes follow the ScubaGear content style guide.
• Related issues these changes resolve are linked preferably via closing keywords.
• All relevant type-of-change labels added.
• All relevant project fields are set.
• All relevant repo and/or project documentation updated to reflect these changes.
• Unit tests added/updated to cover PowerShell and Rego changes.
• Functional tests added/updated to cover PowerShell and Rego changes.
• All relevant functional tests passed.
• All automated checks (e.g., linting, static analysis, unit/smoke tests) passed.

✅ Pre-merge checklist

• PR passed smoke test check.

• Feature branch has been rebased against changes from parent branch, as needed

  Use Rebase branch button below or use this reference to rebase from the command line.

• Resolved all merge conflicts on branch

• Notified merge coordinator that PR is ready for merge via comment mention

✅ Post-merge checklist

• Feature branch deleted after merge to clean up repository.
• Verified that all checks pass on parent branch (e.g., main or release-name) after merge.

[tkol2022]

Testing Instructions for Reviewers

*** Important: See my separate comment on the security impacts of testing this PR.

At a high level these are the scenarios that require testing:

• AAD group is assigned to a PIM group causes the tool to crash (nested groups) (G5 / E5 / GCC High)
• AAD user or group is deleted before running ScubaGear causes the tool to crash (G5 / E5 / GCC High)
• Regression test AAD to ensure that ScubaGear still produces correct results for users / groups assigned to highly privileged roles, including groups that are PIM groups (G5 / E5 / GCC High / G3). Notice that this is the only scenario that applies to G3 because the other scenarios require PIM.

*Note: I added warning output statements that will show up in your Powershell console when you are testing. This will help you observe the objects (users and groups) that ScubaGear is processing so you can track your testing scenarios.
*Note: Coordinate with other testers if you plan to test in the same tenant so that you don't accidentally "step on each other's toes" so to speak with test scenarios you are setting up.

Overall Scenario 1 - AAD group is assigned to a PIM group causes the tool to crash (nested groups)

Review issue #1306 to understand the scope of the problem and see screenshots here and here. Follow the steps to reproduce the problem in #1306 and document the results in the comment template associated with your name.

Overall Scenario 2 - AAD user or group is deleted before running ScubaGear causes the tool to crash

Review issue #1305 to understand the scope of the problem and follow the steps described there to reproduce the problem and document the results in the comment template associated with your name.

Overall Scenario 3 - Regression test AAD to ensure that ScubaGear still produces correct results for users / groups assigned to highly privileged roles, including groups that are PIM groups

For regression testing scenarios, follow the comment template associated with your name.

[tkol2022]

Security Guidance for testing this PR

Since testing this PR requires making assignments of users and groups to highly privileged roles, this introduces operational security risks to the tenants that you will use for testing. Follow this guidance to reduce risks.

I sent you an email with the subject "managing risks with test accounts" that describes the paradigm that I setup which uses a special Entra Id group and conditional access policy that I associate with test users to handle operational risks. Read that for specifics. I plan to setup the same paradigm in all our test tenants so that you can leverage it.

1. Document the test user / group objects that you will create in detail so that we can track them and you can delete them when they are not needed anymore.
2. For each test user that you create, disable the user as the account is being created so that it is not possible to login as that account.
3. For each test user that you create, add them to the special group described in my email.
4. Develop a naming convention that uniquely defined test users belonging to "you" as a tester.
5. Once testing of the PR has completed and this PR gets merged, remove the groups and users that are no longer necessary from Entra Id.

*Note: we might want to leave some of the test objects (users and groups) that you created in Entra Id for the long term, if we plan to use those objects to perpetually test the AAD provider in ScubaGear (via automated or manual testing). We can discuss this at the stand-up.

[tkol2022]

Nanda - Overall Scenario 1 - Test Results - AAD group is assigned to a PIM group causes the tool to crash (nested groups)

• Repeat the tests below in each tenant. You are responsible for setting up your own test users and groups with unique names that are specific to your testing.
• Run the ScubaGear main branch code against the tenant for a specific scenario and verify that it crashes under the conditions described. Then run the fix branch associated with this PR. We are running the main branch and observing the crash to ensure that the fix was successful.

Branch	Tenant	Scenario	Expected Results	Actual Results
main	G5	Scenario 1 - Nested group assignment in PIM for Groups (Active assigned to role)	crash 404 error	[ENTER INFO HERE]
main	G5	Scenario 2 - Nested group assignment in PIM for Groups (Eligible assigned to role)	crash 404 error	[ENTER INFO HERE]
main	G5	Scenario 3 - Nested group assignment in PIM for Groups (PIM group circular reference)	crash 404 error	[ENTER INFO HERE]
fix	G5	Scenario 1 - Nested group assignment in PIM for Groups (Active assigned to role)	no crash	[ENTER INFO HERE]
fix	G5	Scenario 2 - Nested group assignment in PIM for Groups (Eligible assigned to role)	no crash	[ENTER INFO HERE]
fix	G5	Scenario 3 - Nested group assignment in PIM for Groups (PIM group circular reference)	no crash	[ENTER INFO HERE]

[tkol2022]

Nanda - Overall Scenario 2 - Test Results - AAD user or group is deleted before running ScubaGear causes the tool to crash

• Repeat the tests below in each tenant. You are responsible for setting up your own test users and groups with unique names that are specific to your testing.
• Run the ScubaGear main branch code against the tenant for a specific scenario and verify that it crashes under the conditions described. Then run the fix branch associated with this PR. We are running the main branch and observing the crash to ensure that the fix was successful.

Branch	Tenant	Scenario	Expected Results	Actual Results
main	G5	Scenario 1 - Deleted user (Active role assignment)	crash 404 error	[ENTER INFO HERE]
main	G5	Scenario 2 - Deleted user (Eligible role assignment)	crash 404 error	[ENTER INFO HERE]
main	G5	Scenario 3 - Deleted group (Active role assignment)	crash 404 error	[ENTER INFO HERE]
main	G5	Scenario 4 - Deleted group (Eligible role assignment)	crash 404 error	[ENTER INFO HERE]
fix	G5	Scenario 1 - Deleted user (Active role assignment)	no crash	[ENTER INFO HERE]
fix	G5	Scenario 2 - Deleted user (Eligible role assignment)	no crash	[ENTER INFO HERE]
fix	G5	Scenario 3 - Deleted group (Active role assignment)	no crash	[ENTER INFO HERE]
fix	G5	Scenario 4 - Deleted group (Eligible role assignment)	no crash	[ENTER INFO HERE]

[tkol2022]

Nanda - Overall Scenario 3 - Regression test AAD to ensure that ScubaGear still produces correct results for users / groups assigned to highly privileged roles

• Repeat the tests below in each tenant. You are responsible for setting up your own test users and groups with unique names that are specific to your testing.
• Run the ScubaGear main branch code against the tenant for a specific scenario and it will produce a provider JSON file. Then run the fix branch associated with this PR to produce another JSON file. You will compare the two files (specifically the privileged_users section) and ensure that the fix branch didn't leave out any privileged users that the main branch detected. Depending on the test case, the fix branch may contain additional users that are not in the main branch - this will only occur if you are testing nested PIM groups which was not covered in our previous code - nevertheless there should never be a situation where the main branch identified a privileged user(s) that the fix branch did not identify.
• When setting up scenarios, it is best to include more than a single user for an assignment. This tests that our code effectively iterates through each of the assignments. For example, if you are testing role assignments to the Sharepoint Administrator role as Active, setup two or three users and assign them to the role instead of just one. Same thing if you are testing group to role assignments - for the group that is assigned to the role, place multiple users into the group and then check the provider JSON to ensure that ScubaGear identifies all of the users in the group.
• Only the first four scenarios apply to G3 tenants because those do not have PIM.
• The term PIM group below denotes an Entra Id group that has been onboarded to PIM and is shown when you navigate to the Entra Id Privileged Identity Management portal page named Manage > Groups (screenshot below). In contrast and for clarity, the term Regular group denotes an Entra Id group that has NOT been onboarded to PIM - it only exists in the Entra Id Groups page.

• When I say "user is assigned to the PIM group" I am referring to the assignment that occurs in the PIM group assignments page.

Branch	Tenant	Scenario	Expected Results	Actual Results
main	G5	Scenario 1 - User is assigned to privileged role as Active	the user is included in the provider JSON	[ENTER INFO HERE]
main	G5	Scenario 2 - User is assigned to privileged role as Eligible	the user is included in the provider JSON	[ENTER INFO HERE]
main	G5	Scenario 3 - Regular Group is assigned to privileged role as Active	all users that are members of the group are included in the provider JSON	[ENTER INFO HERE]
main	G5	Scenario 4 - Regular Group is assigned to privileged role as Eligible	all users that are members of the group are included in the provider JSON	[ENTER INFO HERE]
main	G5	Scenario 5 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Eligible	the user is included in the provider JSON	[ENTER INFO HERE]
main	G5	Scenario 6 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Active	the user is included in the provider JSON	[ENTER INFO HERE]
main	G5	Scenario 7 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Eligible	the user is included in the provider JSON	[ENTER INFO HERE]
main	G5	Scenario 8 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Active	the user is included in the provider JSON	[ENTER INFO HERE]
fix	G5	Scenario 1 - User is assigned to privileged role as Active	the user is included in the provider JSON	[ENTER INFO HERE]
fix	G5	Scenario 2 - User is assigned to privileged role as Eligible	the user is included in the provider JSON	[ENTER INFO HERE]
fix	G5	Scenario 3 - Regular Group is assigned to privileged role as Active	all users that are members of the group are included in the provider JSON	[ENTER INFO HERE]
fix	G5	Scenario 4 - Regular Group is assigned to privileged role as Eligible	all users that are members of the group are included in the provider JSON	[ENTER INFO HERE]
fix	G5	Scenario 5 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Eligible	the user is included in the provider JSON	[ENTER INFO HERE]
fix	G5	Scenario 6 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Active	the user is included in the provider JSON	[ENTER INFO HERE]
fix	G5	Scenario 7 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Eligible	the user is included in the provider JSON	[ENTER INFO HERE]
fix	G5	Scenario 8 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Active	the user is included in the provider JSON	[ENTER INFO HERE]

[tkol2022]

@mitchelbaker-cisa @buidav I provided three template comments above with @nanda-katikaneni name on them. You can copy paste those comments to create your own template. Feel free to tweak it for what works best for you. Use the slack to communicate across the review team or with me if you have questions or comments.

[tkol2022]

You need to run Initialize-Scuba before executing the fix branch to install the Powershell dependency module for a new Cmdlet that was introduced in this fix.

[gdasher]

Few questions. But mainly I think you need to add some unit tests for your new function with mock data. Please do that.

[tkol2022]

@mitchelbaker-cisa @nanda-katikaneni @buidav I corrected a flaw in how the recursion count was being processed so make sure to test that the recursion stops after 2 levels deep in the tree. I added a temporary print statement to help you keep track of which level in the recursion tree is processing while ScubaGear is executing.

[tkol2022]

Few questions. But mainly I think you need to add some unit tests for your new function with mock data. Please do that.

@gdasher I added some new unit tests including one for recursion that helped identify a flaw in how I was incrementing the recursion count. Please check them out.

[nanda-katikaneni]

Tested high-level scenarios#1 (AAD group is assigned to a PIM group causes the tool to crash) and scenario#2 (AAD user or group is deleted before running ScubaGear causes the tool to crash) and their individual test cases on G5 and E5 tenants. For all test cases with main branch, AAD testing crashes with 404 error for the "highly privileged access" group. With fix branch, no crashes and test results as expected. Also ran regression tests and compared json's with main and fix branches - results as expected.

TBD: full functional test runs on fix branch after the rebase.

[mitchelbaker-cisa]

Overall, the testing scenarios 1-3 behave as expected. I have the last 8 scenarios to do with the fix applied but will be finished with that soon.

Overall Scenario 1 - Test Results - AAD group is assigned to a PIM group causes the tool to crash (nested groups)

Branch	Tenant	Scenario	Expected Results	Actual Results
main	G5	Scenario 1 - Nested group assignment in PIM for Groups (Active assigned to role)	crash 404 error	404 (NotFound), Errorcode: Request_ResourceNotFound
main	G5	Scenario 2 - Nested group assignment in PIM for Groups (Eligible assigned to role)	crash 404 error	404 (NotFound), Errorcode: Request_ResourceNotFound
main	G5	Scenario 3 - Nested group assignment in PIM for Groups (PIM group circular reference)	crash 404 error	404 (NotFound), Errorcode: Request_ResourceNotFound
fix	G5	Scenario 1 - Nested group assignment in PIM for Groups (Active assigned to role)	no crash	no crash, reports generated
fix	G5	Scenario 2 - Nested group assignment in PIM for Groups (Eligible assigned to role)	no crash	no crash, reports generated
fix	G5	Scenario 3 - Nested group assignment in PIM for Groups (PIM group circular reference)	no crash	no crash, reports generated

Overall Scenario 2 - Test Results - AAD user or group is deleted before running ScubaGear causes the tool to crash

Branch	Tenant	Scenario	Expected Results	Actual Results
main	G5	Scenario 1 - Deleted user (Active role assignment)	crash 404 error	404 (NotFound), Errorcode: Request_ResourceNotFound
main	G5	Scenario 2 - Deleted user (Eligible role assignment)	crash 404 error	404 (NotFound), Errorcode: Request_ResourceNotFound
main	G5	Scenario 3 - Deleted group (Active role assignment)	crash 404 error	404 (NotFound), Errorcode: Request_ResourceNotFound
main	G5	Scenario 4 - Deleted group (Eligible role assignment)	crash 404 error	404 (NotFound), Errorcode: Request_ResourceNotFound
fix	G5	Scenario 1 - Deleted user (Active role assignment)	no crash	no crash, reports generated
fix	G5	Scenario 2 - Deleted user (Eligible role assignment)	no crash	no crash, reports generated
fix	G5	Scenario 3 - Deleted group (Active role assignment)	no crash	no crash, reports generated; tried with owner role and same result
fix	G5	Scenario 4 - Deleted group (Eligible role assignment)	no crash	no crash, reports generated

Overall Scenario 3 - Regression test AAD to ensure that ScubaGear still produces correct results for users / groups assigned to highly privileged roles

Branch	Tenant	Scenario	Expected Results	Actual Results
main	G5	Scenario 1 - User is assigned to privileged role as Active	the user is included in the provider JSON	users with active assignment of sharepoint admin included in provider JSON
main	G5	Scenario 2 - User is assigned to privileged role as Eligible	the user is included in the provider JSON	users with eligible assignment of sharepoint admin included in provider JSON
main	G5	Scenario 3 - Regular Group is assigned to privileged role as Active	all users that are members of the group are included in the provider JSON	two users with no role assignment, but active assigned to a regular group with sharepoint admin; both users included under privileged_users
main	G5	Scenario 4 - Regular Group is assigned to privileged role as Eligible	all users that are members of the group are included in the provider JSON	two users with no role assignment, but eligible assigned to a regular group with sharepoint admin; both users included under privileged_users
main	G5	Scenario 5 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Eligible	the user is included in the provider JSON	two users with no role assignment, but eligible assigned to a PIM group with sharepoint admin as active; both users included under privileged_users
main	G5	Scenario 6 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Active	the user is included in the provider JSON	two users with no role assignment, but active assigned to a PIM group with sharepoint admin as active; both users included under privileged_users
main	G5	Scenario 7 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Eligible	the user is included in the provider JSON	two users with no role assignment, but eligible assigned to a PIM group with sharepoint admin as eligible; both users included under privileged_users
main	G5	Scenario 8 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Active	the user is included in the provider JSON	two users with no role assignment, but active assigned to a PIM group with sharepoint admin as eligible; both users included under privileged_users
fix	G5	Scenario 1 - User is assigned to privileged role as Active	the user is included in the provider JSON	users with active assignment of sharepoint admin included in provider JSON
fix	G5	Scenario 2 - User is assigned to privileged role as Eligible	the user is included in the provider JSON	users with eligible assignment of sharepoint admin included in provider JSON
fix	G5	Scenario 3 - Regular Group is assigned to privileged role as Active	all users that are members of the group are included in the provider JSON	two users with no role assignment, but active assigned to a regular group with sharepoint admin; both users included under privileged_users
fix	G5	Scenario 4 - Regular Group is assigned to privileged role as Eligible	all users that are members of the group are included in the provider JSON	two users with no role assignment, but eligible assigned to a regular group with sharepoint admin; both users included under privileged_users
fix	G5	Scenario 5 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Eligible	the user is included in the provider JSON	two users with no role assignment, but eligible assigned to a PIM group with sharepoint admin as active; both users included under privileged_users
fix	G5	Scenario 6 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Active	the user is included in the provider JSON	two users with no role assignment, but active assigned to a PIM group with sharepoint admin as active; both users included under privileged_users
fix	G5	Scenario 7 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Eligible	the user is included in the provider JSON	two users with no role assignment, but eligible assigned to a PIM group with sharepoint admin as eligible; both users included under privileged_users
fix	G5	Scenario 8 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Active	the user is included in the provider JSON	two users with no role assignment, but active assigned to a PIM group with sharepoint admin as eligible; both users included under privileged_users

[nanda-katikaneni]

Summary of results for E5 and G5 Tenants:

Overall Scenario 1 - Test Results for E5 and G5 tenants - AAD group is assigned to a PIM group causes the tool to crash (nested groups)

Branch	Tenant	Scenario	Expected Results	Actual Results
main	E5 & G5	Scenario 1 - Nested group assignment in PIM for Groups (Active assigned to role)	crash 404 error	crash 404
main	E5 & G5	Scenario 2 - Nested group assignment in PIM for Groups (Eligible assigned to role)	crash 404 error	crash 404
main	E5 & G5	Scenario 3 - Nested group assignment in PIM for Groups (PIM group circular reference)	crash 404 error	crash 404
fix	E5 & G5	Scenario 1 - Nested group assignment in PIM for Groups (Active assigned to role)	no crash	no crash, report generated
fix	E5 & G5	Scenario 2 - Nested group assignment in PIM for Groups (Eligible assigned to role)	no crash	no crash, report generated
fix	E5 & G5	Scenario 3 - Nested group assignment in PIM for Groups (PIM group circular reference)	no crash	no crash, report generated.

Overal Scenario 2 - Test Results for E5 and G5 tenants - AAD user or group is deleted before running ScubaGear causes the tool to crash

Branch	Tenant	Scenario	Expected Results	Actual Results
main	E5 & G5	Scenario 1 - Deleted user (Active role assignment)	crash 404 error	crash 404 (NotFound)
main	E5 & G5	Scenario 2 - Deleted user (Eligible role assignment)	crash 404 error	crash 404 (NotFound)
main	E5 & G5	Scenario 3 - Deleted group (Active role assignment)	crash 404 error	crash 404 (NotFound)
main	E5 & G5	Scenario 4 - Deleted group (Eligible role assignment)	crash 404 error	crash 404 (NotFound)
fix	E5 & G5	Scenario 1 - Deleted user (Active role assignment)	no crash	no crash, reports generated
fix	E5 & G5	Scenario 2 - Deleted user (Eligible role assignment)	no crash	no crash, reports generated
fix	E5 & G5	Scenario 3 - Deleted group (Active role assignment)	no crash	no crash, reports generated
fix	E5 & G5	Scenario 4 - Deleted group (Eligible role assignment)	no crash	no crash, reports generated

Overall scenario # 3 is done with only E5 tenant - expected results for most (will add after couple more tests); regression functional tests on the E5 tenant with fix branch worked fine (G5 functional tests tbd).

Based on the review/testing so far, only suggestion is to remove the debug print statements before merge - while its really useful in debugging the nested PIM groups, the command line execution for aad has become very chatty. As an alternative, consider on-demand debugging feature/flag for a future release.

[mitchelbaker-cisa]

Looks great Ted, please refer to my comment above on completed test scenarios and their results. Last ask from me is to create an issue to capture how we might approach building functional tests for handling nested PIM groups and deleted users/groups.

[nanda-katikaneni]

Overall Scenario 3 - Test results for E5 tenant - regression test AAD to ensure that ScubaGear still produces correct results for users / groups assigned to highly privileged roles

Branch	Tenant	Scenario	Expected Results	Actual Results
main	E5	Scenario 1 - User is assigned to privileged role as Active	the user is included in the provider JSON	user is included in provider JSON
main	E5	Scenario 2 - User is assigned to privileged role as Eligible	the user is included in the provider JSON	user is included in provider JSON
main	E5	Scenario 3 - Regular Group is assigned to privileged role as Active	all users that are members of the group are included in the provider JSON	users are included in the provider JSON
main	E5	Scenario 4 - Regular Group is assigned to privileged role as Eligible	all users that are members of the group are included in the provider JSON	users are included in the provider JSON
main	E5	Scenario 5 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Eligible	the user is included in the provider JSON	users are included in the provider JSON
main	E5	Scenario 6 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Active	the user is included in the provider JSON	users are included in the provider JSON
main	E5	Scenario 7 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Eligible	the user is included in the provider JSON	users are included in the provider JSON
main	E5	Scenario 8 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Active	the user is included in the provider JSON	users are included in the provider JSON
fix	E5	Scenario 1 - User is assigned to privileged role as Active	the user is included in the provider JSON	users are included in the provider JSON
fix	E5	Scenario 2 - User is assigned to privileged role as Eligible	the user is included in the provider JSON	users are included in the provider JSON
fix	E5	Scenario 3 - Regular Group is assigned to privileged role as Active	all users that are members of the group are included in the provider JSON	users are included in the provider JSON
fix	E5	Scenario 4 - Regular Group is assigned to privileged role as Eligible	all users that are members of the group are included in the provider JSON	users are included in the provider JSON
fix	E5	Scenario 5 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Eligible	the user is included in the provider JSON	users are included in the provider JSON
fix	E5	Scenario 6 - PIM group is assigned to privileged role as Active - User is assigned to PIM group as Active	the user is included in the provider JSON	users are included in the provider JSON
fix	E5	Scenario 7 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Eligible	the user is included in the provider JSON	users are included in the provider JSON
fix	E5	Scenario 8 - PIM group is assigned to privileged role as Eligible - User is assigned to PIM group as Active	the user is included in the provider JSON	users are included in the provider JSON

[nanda-katikaneni]

No additional comments.

[tkol2022]

Looks great Ted, please refer to my comment above on completed test scenarios and their results. Last ask from me is to create an issue to capture how we might approach building functional tests for handling nested PIM groups and deleted users/groups.

Created #1340 - Looking for someone to lead that issue to improve the functional testing of PIM functionality.

[tkol2022]

@nanda-katikaneni ready to go

[tkol2022]

@nanda-katikaneni I fixed the unit tests. Ready for merge.