Pac Solution Check Error AADSTS65002

Pac Solution Check Error AADSTS65002

Comments 0 Comment

The Problem

When attempting to run [Pac Solution Check] in the Power Platform PAC CLI on a GCCH Tenant the Pac Solution Checker returns an error AADSTS65002 about consent between first party application and resource preauthorization.

This came up when working with a GCCH client (That’s the US Government High Security Cloud) when running the following command:

#Authenticate using GCCH
pac auth create --name PMagDef --cloud UsGovHigh

#Run Sln Checker - also GCCH - Noting --cloud vs --geo differences.
pac solution check --path SomePackage.zip --geo USGovernmentL4
##OR## 
pac solution check --path SomePackage.zip --customEndpoint "high.api.advisor.powerapps.us"

The CLI returns the following error:

Error: AADSTS65002: Consent between first party application ‘9cee029c-6210-4654-90bb-17e6e9d36617’ and first party resource ‘c9299480-c13a-49db-a7ae-cdfe54fe0313’ must be configured via preauthorization – applications owned and operated by Microsoft must get approval from the API owner before requesting tokens for that API. Trace ID: 48ff82b8-c5f6-4e6c-ba2a-14638d3a5e00 Correlation ID: 01d01e9b-ea3b-475f-9f53-b14606529b6d Timestamp: 2024-09-09 19:12:32Z

The Helpful Bit

As the error suggests, this is security related, and appears to be a bug, or rather a development and configuration oversight on the part of the Microsoft Power Platform Build tools team.

First, you may note the terms ‘Cloud’ and ‘Geo’ are used somewhat interchangeably, or inconsistently, in Microsoft services, including within the PAC CLI.  That the authentication line expects –cloud, whereas the solution checker expects –geo is not an error, nor are the parameters ‘UsGovHigh’ or USGovernmentL4.  As far as I am aware, this was just a terminology change as Azure has evolved. If anyone reading this can explain the history, reason for the changes, and any technical differences between these, please do!  For the purpose of this post, it is something to check but is not the cause of this error. You may also note that using the –customEndpoint parameter to specify the GCCH solution checker endpoint didn’t resolve the issue.

The error occurs because the default app registration used by the PAC CLI to connect to the Solution Checker is not authorized.    To understand this concept, in Azure, every application that connects to Microsoft services and/ or External APIs is tracked with an ‘App Registration’, which is globally unique identifier representing that application.  Within each tenant that uses the app, One or more Service Principal (SPN) and/or user principals are created for authentication and privilege management. Auth credentials and permissions are assigned to each principal governing what access it has when connecting as that app, to other services.   For security purposes, each MSFT Cloud (Commercial, GCC, GCCH) is hosted on separate infrastructure, and so a separate app registration is created in each one to govern its use in that respective cloud.

In this case of the PAC CLI running in GCCH to access the Solution Checker in this instance:

  • PAC CLI is represented as App ‘9cee029c-6210-4654-90bb-17e6e9d36617’
  • The PowerApps-Advisor is the Solution Checker, and is registered as ‘c9299480-c13a-49db-a7ae-cdfe54fe0313’
  • These AppIDs will vary based on whether you are in Commercial, GCC, GCCH cloud.

This error then implies either 1) Someone one at MSFT changed one of these App Registrations and/or forgot to give permissions to the CLI app to access the Solution Checker or 2) it is somehow blocked in your tenant.  Let’s start with the latter, as it is within our control.

Both the PAC CLI and Solution Checker service are ‘First Party’, MSFT provided applications, which are generally permitted by default in Commercial tenants, for core platform services to run, but not may not be in GCCH tenants, which follow stricter security policies. Why wouldn’t the solution checker be enabled by default? I’m not sure, but possibly it might expose vulnerabilities specific to your tenant in the solutions you send to it.   Who knows? John Galt.  Even in a commercial tenant, it can be disabled.  So, first, verify this.  Find them in your Azure settings under Enterprise Applications > Al Applications.  

Now, the trick.  There is no guarantee the app registration will be called exactly what you are expecting.   MSFT Documentation Solution Checker failing Due to Disabled First-Party Application indicates to search for ‘PowerApps-Advisor,’ but the assumption here is generally Commercial clouds, and it may be called something different in GCC/GCCH, so I searched just ‘Power’, ‘Solution’, and ‘Checker.’ No clear matches came up.  Searching the app IDs from the error also didn’t pull up.  Unfortunately, the search supports searching by Name or ObjectID (The SPN in your tenant), not the globally unique Application ID.  The ‘Enterprise Applications’ shown here are the SPNs in your own tenant, not the App Registrations themselves.

If you click +New Application to create an Enterprise App SPN for it in your own tenant, and search for Power, the closest match is the Microsoft PowerApps service, along with a security note as to why it is not enabled by default in a GCCH tenant.

The result – the app registration doesn’t appear to be blocked – we can’t even find it registered in the GCCH cloud.

The Solution

You can work around this by creating your own app registration, instead of using the default one provided for the Pac CLI. This is not uncommon. In fact, for the Power Automate HTTP with Entra ID Connectors, you might have noted there is both a pre-authorized and non-pre-authorized one. The difference is simply that one the former uses a MSFT provided app registration, but for more secure environments, the later requires you to provide your own registration.

Creating an app registration also isn’t difficult, but I’ll direct you to the instructions here:

Tutorial: Register an app with Microsoft Entra ID (Microsoft Dataverse) – Power Apps | Microsoft Learn

Once you have created it, you will want to grant it permissions to the PowerApps-Advisor application, which is the registration for Solution Checker:

Note, if you grant ONLY this permission, the PAC CLI will not be able to perform other operations without switching authentication profiles.  So, either grant the additional Power Apps Service privileges as you see fit, create two authentication profiles using pac auth create and switch between them to run the solution checker.  If you already have an existing app registration, then of course, you can just grant it the permissions necessary to access the PowerApps-Advisor service.

Once you have the app registration, you will use that to authenticate with the PAC CLI, so your Pac Auth Create will require you to provide the AppID and Secret.

I have submitted a bug report to Microsoft for this issue.  In the meanwhile, hopefully this bit of info has proven useful, and you’ve learned a few things.

Conclusion

If you get the AADSTS65002 error when attempting to run the solution checker from the PAC CLI, verify the app registration is available and unblocked in your tenant via the Azure portal, and create your own app registration if necessary.

References

Leave a Reply

Your email address will not be published.