Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mattcave opened this issue Nov 6, 2024 · 8 comments

Comments

@mattcave
Copy link
Contributor

mattcave commented Nov 6, 2024

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/<group_id>/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
Copy link
Contributor

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

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
Copy link
Contributor Author

mattcave commented Nov 6, 2024

Screenshot 2024-11-06 at 11 08 40 AM
Example of a configuration that we see causing an error, to help you with reproducing the issue.

@soulemike
Copy link
Contributor

A test with Global Reader

image
image

A test with Global Admin

image
image

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

@mattcave
Copy link
Contributor Author

mattcave commented Nov 7, 2024

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
Copy link
Contributor Author

mattcave commented Nov 8, 2024

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.

@mattcave mattcave changed the title Multiple tests fail to run correctly when tenant has a GDAP relationship that includes Global Administrator role Multiple tests fail to run correctly when tenant has a privileged Group with access into the tenant via a GDAP relationship Nov 8, 2024
@soulemike
Copy link
Contributor

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
Copy link
Contributor Author

mattcave commented Nov 14, 2024

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants