[Bug] AADSTS65002 when adding SQL Server Data Source

[rmorales87atx]

Describe the bug

In a GCC moderate environment, pac / npm CLI commands that enumerate SQL connector data sources (pac code list-datasets / add-data-source -a shared_sql) fail with AADSTS65002 (first-party preauthorization). In the same environment, auth profile, and CLI session, Dataverse table and Power Automate flow operations via the CLI succeed. Only the SQL/connector-runtime path is failing.

App IDs in the error:

• Client 9cee029c-6210-4654-90bb-17e6e9d36617 = Power Platform CLI
• Resource d93420f9-abc8-46b7-b7fc-30ec1f007ee2 = connector-runtime/connectivity API
  (the only first-party resource not preauthorized for the PAC app in this GCC tenant)

Steps to Reproduce

1. pac auth create --cloud UsGov --environment <GCC env> as an interactive
   user (not service principal). Profile works: Dataverse + flow CLI ops succeed.
2. Create a SQL Server connection using an on-premises Data Gateway
   (Windows Authentication, application service account).
3. pac code list-datasets -a shared_sql -c <connectionId>
4. Observe AADSTS65002.

Expected behavior

pac code list-datasets returns available datasets for the SQL connection,
consistent with Dataverse/flow CLI operations succeeding in the same profile.

Actual behavior

Fails immediately with AADSTS65002; the CLI never reaches the connector. Auth is correct and not the cause: --cloud UsGov is the correct value for GCC moderate, identity is an interactive user, and Dataverse + flow CLI operations work in the same auth profile/environment. Only the connector-runtime token request (resource d93420f9-...) is rejected. Reproduces identically on the VS Code-bundled pac 2.6.4 and the current standalone npm CLI 1.1.3.

Screenshots or Error Messages

Error: AADSTS65002: Consent between first party application
'9cee029c-6210-4654-90bb-17e6e9d36617' and first party resource
'd93420f9-abc8-46b7-b7fc-30ec1f007ee2' 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: 8c63a7c9-7f94-4ffa-88f1-bb7973a40500
Correlation ID: bca5fde0-8068-41dd-ba89-47465a1096ee
Timestamp: 2026-05-15 15:45:38Z

Environment information

• Cloud: GCC (moderate)
• pac CLI: 2.6.4+ga48832 (bundled with VSCode Power Platform Tools extension)
• npm @microsoft/power-apps CLI: 1.1.3
• Node: 24.12.0
• OS: Windows 11
• pac auth create: --cloud UsGov, specific environment, interactive user (not SP)
• Connector: SQL Server via on-premises data gateway, Windows Authentication
  (application service account)

Additional context

Bug seems to be localized to the SQL/connector-runtime path. In the same GCC environment, auth profile, and CLI version:

CLI operation	Result
pac auth / Dataverse table add-data-source	pass
Power Automate flow operations (list/add)	pass
pac code list-datasets -a shared_sql (gateway SQL conn)	fail (AADSTS65002)
Non-SQL connector, e.g. add-data-source -a shared_office365users	pass

[eschavez]

Thanks for the detailed repro and the excellent connector-by-connector comparison table — that really helps narrow the scope.

We've reproduced the pattern you're describing: in GCC (moderate), the PAC CLI (9cee029c-...) successfully acquires tokens for Dataverse and Power Automate but is rejected by the connector-runtime resource (d93420f9-...) with AADSTS65002. This is a first-party preauthorization gap — the PAC CLI app needs to be explicitly preauthorized for the connector-runtime API in the GCC sovereign cloud endpoint, and it currently is not (or the preauthorization hasn't propagated to your tenant yet).

A couple of things we're looking at on our end:

• Preauthorization status for GCC — we're checking whether the PAC CLI ↔ connector-runtime preauthorization has been applied to GCC moderate, similar to what's in place for commercial tenants.
• Connector-specific path — we note that non-SQL connectors (e.g. shared_office365users) succeed; those likely use a different token audience. The shared_sql path via on-premises data gateway may have an additional scope requirement that surfaces this gap specifically.

In the meantime, there's no known CLI-side workaround for an AAD preauthorization rejection — this needs to be resolved on the service side.

We'll update this thread when we have more information. If you're blocked, reaching out to Microsoft support referencing correlation ID bca5fde0-8068-41dd-ba89-47465a1096ee may accelerate the investigation on the AAD side.

[rmorales87atx]

Thanks for the quick response! For one of my solutions this pushes me to simply transition the data into Dataverse (90% of it is already there, just haven't had much excuse to move the rest). For another this would be a blocker, but that one isn't even ready for actual development yet so it's clear for now.