fix: use the connected environment's Graph endpoint in Test-MtConditionalAccessWhatIf - #2077
Conversation
…onalAccessWhatIf Test-MtConditionalAccessWhatIf posted to https://graph.microsoft.com/beta regardless of which cloud the session was connected to, so the Conditional Access What If evaluation could only ever work in the Global cloud. In a sovereign tenant the request goes to the wrong host and the CAWhatIf tests (MT.1033, MT.1034) cannot pass. Derive the base URI from the connected environment instead, matching how Invoke-MtGraphRequest already resolves it: (Get-MgEnvironment -Name (Get-MgContext).Environment).GraphEndpoint This resolves correctly for every environment Get-MgEnvironment knows about, including China (https://microsoftgraph.chinacloudapi.cn), USGov, USGovDoD and the newer sovereign clouds.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe Conditional Access What If request now derives its Microsoft Graph beta endpoint from the connected environment. A missing environment defaults to Global, and unresolved endpoints produce an explicit error. Existing request and result handling remain unchanged. ChangesConditional Access What If
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@powershell/public/maester/entra/Test-MtConditionalAccessWhatIf.ps1`:
- Around line 214-219: Move the Get-MgContext/Get-MgEnvironment
endpoint-resolution logic into the existing try block so lookup failures reach
its catch handler. Add -ErrorAction Stop, validate that the Graph context and
environment are available, then construct $graphBaseUri from the environment’s
GraphEndpoint using Get-MgEnvironment -Name before invoking the request.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: d96ebf02-da4a-4c2f-8b2a-2be316e8bb4c
📒 Files selected for processing (1)
powershell/public/maester/entra/Test-MtConditionalAccessWhatIf.ps1
Up to standards ✅🟢 Issues
|
Move the endpoint resolution into the try so a failed lookup reaches the existing catch instead of escaping the function. When no Graph context is available, (Get-MgContext).Environment returns null and Get-MgEnvironment -Name $null throws a terminating parameter binding error. Default to Global in that case, consistent with Initialize-MtSession, so an unconnected session reports the Graph authentication error rather than a binding failure. Also guard against an environment name that Get-MgEnvironment cannot resolve. It returns null silently, which would otherwise collapse the request URI to a relative path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
📑 Description
Closes #2076
Test-MtConditionalAccessWhatIfposted tohttps://graph.microsoft.com/beta/identity/conditionalAccess/evaluateregardless of which cloud the session was connected to. In a sovereign tenant the evaluation request goes to the Global host, so the CA What If tests (MT.1033,MT.1034) cannot pass there even whenConnect-MgGraphwas given the correct environment.This was found running Maester against a China tenant, where the session connects to
https://microsoftgraph.chinacloudapi.cnbut this one call still went tograph.microsoft.com.The fix derives the base URI from the connected environment, matching how
Invoke-MtGraphRequestalready resolves it:Get-MgEnvironmentresolves this correctly for every environment it knows about, so the call now follows the session:https://graph.microsoft.comhttps://microsoftgraph.chinacloudapi.cnhttps://graph.microsoft.ushttps://dod-graph.microsoft.ushttps://graph.svc.sovcloud.{de,fr,sg}Behaviour in the Global cloud is unchanged.
✅ Checks
/powershell/tests/pester.ps1locally.ℹ️ Additional Information
Local test status: the full
pester.ps1suite runs with 10334 tests and 0 failures, and PSScriptAnalyzer reports no findings on the changed file.Kept deliberately to one function, but as noted in #2076 the same hardcoded-host pattern appears elsewhere and may be worth a follow-up. Happy to cover the remaining call sites in this PR or open separate ones, whichever you prefer:
Test-MtHighRiskAppPermissions(2 calls)Get-MtTotalEntraIdUserCountSend-MtMail(2 calls)Send-MtTeamsMessageGetOrganizationLogosInvoke-MtAzureRequestalso references the Global host, but as an explicitif (-not $baseUri)fallback default, so that one looks intentional and is left alone.For the record,
Test-EIDSCA.Generated.Tests.ps1contains 44 occurrences ofhttps://graph.microsoft.com, but all of them are literal text inside test descriptions (Check if "https://graph.microsoft.com/beta/...") rather than API calls, so nothing to change there.Summary by CodeRabbit