Fix missing permission check

[nicolonsky]

Description

Fixes #1422.

Contribution Checklist

Before submitting this PR, please confirm you have completed the following:

• 📖 Read the guidelines for contributing to this repository.
• 🧪 Ensure the build and unit tests pass by running /powershell/tests/pester.ps1 on your local system.

[Copilot]

Pull request overview

This PR addresses issue #1422 by adding a permission check to the MT.1100 test (Test-MtIntuneDiagnosticSettings) to gracefully handle cases where the user lacks Azure RBAC permissions to read Intune diagnostic settings. When a 403 (Forbidden) response is received from the Azure ARM API, the test now skips with an appropriate message instead of failing.

Changes:

• Added permission check that detects 403 status code and throws UnauthorizedAccessException
• Added catch block to handle UnauthorizedAccessException and skip test with custom reason
• Added documentation explaining the Azure RBAC prerequisites and providing PowerShell snippets to create a custom role

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
powershell/public/maester/intune/Test-MtIntuneDiagnosticSettings.ps1	Added 403 status code check and exception handling to skip test when Azure RBAC permissions are insufficient
powershell/public/maester/intune/Test-MtIntuneDiagnosticSettings.md	Added prerequisites section documenting required Azure RBAC permissions and remediation steps

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The status code check uses an integer comparison (403) but should use a string comparison ('403') to match the type returned by Invoke-AzRestMethod. The StatusCode property returns a string value, not an integer. This can be seen in the similar function Test-MtCisaDiagnosticSettings which uses '$settings.StatusCode -ne '200'' with a string comparison.

Additionally, checking only for 403 is too narrow. A more robust approach would be to check if StatusCode is not '200', which handles 403 (forbidden), 401 (unauthorized), and other error status codes. This matches the pattern used in Test-MtCisaDiagnosticSettings.

Suggested change

	if ($diagnosticSettingsRequest.StatusCode -eq 403) {
	if ($diagnosticSettingsRequest.StatusCode -ne '200') {

[SamErde]

@nicolonsky, this suggestion makes sense, but it also dilutes the specificity of your error handling. You might do if '403' {report the permissions issue } else {report a general error}.

[Copilot]

The approach of throwing and catching UnauthorizedAccessException is inconsistent with how similar diagnostic settings tests handle authorization failures. The existing Test-MtCisaDiagnosticSettings function (lines 56-61) checks the status code and directly calls Add-MtTestResultDetail -SkippedBecause NotAuthorized without throwing or catching exceptions.

For consistency with the codebase, this code should check the status code and directly skip the test using Add-MtTestResultDetail -SkippedBecause NotAuthorized, rather than throwing and catching an exception. This approach is simpler, more direct, and follows the established pattern for Azure diagnostic settings tests.

[Copilot]

The line parsing of ConvertFrom-Json will fail if the API returns a non-200 status code, because the Content property will contain an error message in JSON format rather than the expected structure with a 'value' property.

With the permission check moved earlier (before line 40), this issue is mitigated. However, if the check is modified to use the pattern from Test-MtCisaDiagnosticSettings (checking for -ne '200' instead of specifically checking for 403), this line will be protected from all error status codes, not just 403.

Suggested change

	throw [System.UnauthorizedAccessException]::new('No Azure RBAC permissions to read Intune diagnostic settings.')
	throw [System.UnauthorizedAccessException]::new('No Azure RBAC permissions to read Intune diagnostic settings.')
	} elseif ($diagnosticSettingsRequest.StatusCode -ne 200) {
	throw [System.Exception]::new(("Failed to retrieve Intune diagnostic settings. HTTP status code: {0}" -f $diagnosticSettingsRequest.StatusCode))

[Copilot]

The documentation states that the Azure role should be "assigned at the subscription where the target Intune Log Analytics workspace or storage account resides," but the API call in the test is querying provider-level diagnostic settings (/providers/microsoft.intune/diagnosticSettings), not subscription-level resources.

According to the issue description, the role assignment needs to be at the subscription level (the scope used in the example is "/subscriptions/$SubscriptionId"), but the wording "where the target Intune Log Analytics workspace or storage account resides" is potentially misleading. It would be clearer to state that the role should be assigned at the subscription level, since the diagnostic settings themselves are a provider-level resource that requires subscription-level permissions to read.

Suggested change

For this test to run, the executing principal must have permissions to read Intune diagnostic settings in Azure (`microsoft.intune/diagnosticSettings/read` action). This typically requires at least the 'Monitoring Reader' or 'Reader' Azure role assigned at the subscription where the target Intune Log Analytics workspace or storage account resides.

For this test to run, the executing principal must have permissions to read Intune diagnostic settings in Azure (`microsoft.intune/diagnosticSettings/read` action). This typically requires at least the 'Monitoring Reader' or 'Reader' Azure role assigned at the subscription level (for example, with scope `/subscriptions/$SubscriptionId`), which provides access to the provider-level Intune diagnostic settings.

[SamErde]

Double check. Looks like a valid suggestion here as well.