EIDSCA.AP08 test fails when no User Consent is configured.

[michelderooij]

Scenario:
The ManagePermissionGrantsForSelf is not configured (admin-only consent).

Test:
https://graph.microsoft.com/beta/policies/authorizationPolicy
.permissionGrantPolicyIdsAssignedToDefaultUserRole | Sort-Object -Descending | select-object -first 1 = 'ManagePermissionGrantsForSelf.microsoft-user-default-low'

EIDSCA.AP08 test fails because permissionGrantPolicyIdsAssignedToDefaultUserRole does not contain ManagePermissionGrantsForSelf and returns something else, in my case:

Your tenant is configured as ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team.
The recommended value is 'ManagePermissionGrantsForSelf.microsoft-user-default-low' for policies/authorizationPolicy

If admin-only is configured (more strict), result should be Pass.

[merill]

@Cloud-Architekt fyi

[JeanPhilippeGeorge]

Hello,

I have the same problem. Only admin are allowed to approve applications with workflow configured.

It seems it has been replace by theses tests:

• MS.AAD.5.1: Only administrators SHALL be allowed to register applications
• MS.AAD.5.2: Only administrators SHALL be allowed to consent to applications.
• MS.AAD.5.3: An admin consent workflow SHALL be configured for applications
• MS.AAD.5.4: Group owners SHALL NOT be allowed to consent to applications

The 3 first tests succeeds, the fourth fails. The user interface for setting the "group owner ..." has disapeared

If I remember correctly I had disabled that. And last time I saw that parameter MS said they were deprecating it.

[JeanPhilippeGeorge]

And I forget to mention that MS.AAD.5.1: Only administrators SHALL be allowed to register applications. succeeds bcause with the following test result: Your tenant have a conditional policy that "Require MFA for internal users (admins not included) - Basic", which require MFA for all clouds app.

Which seems not related to the title.

[JonesMikael]

While on this topic I also see strange result on MT.1024: Entra Recommendation - Do not allow users to grant consent to unreliable applications. It fails even though we have set up even more strict setting:

[Snozzberries]

• MS.AAD.5.4: Group owners SHALL NOT be allowed to consent to applications

The 3 first tests succeeds, the fourth fails. The user interface for setting the "group owner ..." has disapeared

Yes, this is a concern, and it is still unclear how we want to handle alternative checks from those explicitly defined by CISA. (e.g., comment & #194 )

[Cloud-Architekt]

In the past, we have decided to follow Microsoft's recommendation to allow consent for low risky classifications in EIDSCA. However, there are valid scenarios for customers to block user consent in general. In that cases, it would be great to have the option to waive or customize the value for this check. This is something we would like to integrate as a feature.

Currently, the only option is to host a customized version of the EIDSCA.json file with the adjusted RecommendValue. You can build customized EIDSCA by providing AadSecConfigUrl parameter in Update-EidscaTests.

[JeanPhilippeGeorge]

Thanks for the clarifications.

I don't remember which security tests i made was recommanding the consent workflow ;-)