Multiple tests fail to run correctly when tenant has a privileged Group with access into the tenant via a GDAP relationship

[mattcave]

We work with a number of tenants who have GDAP relationships with multiple vendors (e.g. a vendor that they buy MS licences from). If that GDAP relationship includes the role Global Administrator, a number of tests will fail to run correctly. This is because the call to Get-MtRoleMember will result in a 404 error - the code tries to make a Graph call to https://graph.microsoft.com/v1.0/groups//members but that call (correctly) returns a 404 as that object is not part of the target tenant.

I'm not sure what the correct behaviour is in this scenario.

• Having a Global Admin role on the GDAP relationship is not a good practice, but it's allowed and shouldn't cause the test to throw an error.
• That said, if we cannot pull the details for that group, the test cannot pass because it won't have the information to make a determination.

Perhaps the best course of action is to provide better info about why the test is failing (ie we can't pull all the info we need)?

I believe this affects all MS.AAD.7.x tests

[soulemike]

MS.AAD.7.1 with Direct and Indirect reseller relationship setup, without any role delegations (i.e., Legacy DAP). The tests run successfully.

Will get access to generate a GDAP relationship for my test environment later and test again, as that will likely be the culprit. Just documenting different scenarios to identify scope.

[mattcave]

Example of a configuration that we see causing an error, to help you with reproducing the issue.

[soulemike]

A test with Global Reader

A test with Global Admin

@mattcave do you have a few more examples on maybe narrowing down this?

[mattcave]

There's one more key factor that I didn't include in my initial report. Apologies.

We are authenticating to Graph using delegated access via GDAP. In the screenshot I shared before, we are Augmentt-aef7f162-1724159588768. So we are a CSP "parent", and we are running Maester tests against the "child" tenant. The problem is when there is another CSP parent with GA role on the child tenant.

Does that make sense?

[mattcave]

Did further testing today, and the way we are accessing the problem tenant is not relevant. I get the same error if I Connect-Maester for that tenant interactively from command line.

It also seems that the GDAP relationship does not need to include the GA role in order to trigger this issue. I have a GDAP relationship that includes a number of other lesser-privileged roles that still experiences the error.

For example running MS.AAD.7.2 on this tenant...

1. We run Get-MtRole -CisaHighlyPrivilegedRoles to get the list of Privileged roles (8 in this case)
2. We then Get-MtRoleMember for each Role
3. For the first role (Global Admin), we find 6 users in the tenant with the GA role assigned.
4. For the second role (User Admin), we get a single group that is the AdminAgents group from a CSP parent tenant.
5. When we run Get-MtGroupMember against that Group, it fails with a 404 error.

Trying to get group memberships for a group that has delegated access into the tenant from a "parent" tenant will result in a 404, and hence the test will fail.

I have reproduced this in a test environment, and can share credentials if it helps understand the issue.

[soulemike]

For the second role (User Admin), we get a single group that is the AdminAgents group from a CSP parent tenant. When we run Get-MtGroupMember against that Group, it fails with a 404 error.

This definitely makes sense. As that AdminAgents group would be in a distinct tenant. So is the issue the test skips or fails in the report, or is it just for the Get-MtGroupMember that 404s? I wouldn't expect a client tenant to ever be able to resolve the members of the CSP's AdminAgents group.

Trying to get group memberships for a group that has delegated access into the tenant from a "parent" tenant will result in a 404, and hence the test will fail.

As for logging in to tenants interactively over GDAP to run tests, I would definitely avoid that. The recommendation would be to use an Enterprise App in the client tenant that is based on the App Reg in your tenant. The main reasoning is that the GDAP capabilities will vary for each API and SDK.

[mattcave]

The issue is that the test fails as a result of that 404 error I mentioned. The 404 causes the test to throw an exception which results in a "fail".

I'm not sure what the correct behaviour should be. Fail with an explanation, because we will never be able to tell if the configuration is "Safe" or not? List the unresolvable groups in the test details?

As for logging in to tenants interactively over GDAP to run tests, I would definitely avoid that. The recommendation would be to use an Enterprise App in the client tenant that is based on the App Reg in your tenant. The main reasoning is that the GDAP capabilities will vary for each API and SDK.

Yeh, that's what we're doing. I did that interactive login purely for testing purposes in our QA environment, to eliminate any weirdness as a result of how we're generating the token, and ensure I 100% understand the root cause of the issue.

[soulemike]

I am having an AOBO mapping configured for my test environment. Since the issue isn't with GDAP relationships but rather the AOBO group membership enumeration. @mattcave if you have ideas on how to identify and exclude the AOBO groups feel free to work on a PR. Otherwise I will plan to test and try to identify a solution.