Bearer Token Expiring During Solution Import since v0.0.82

[mhemp2021]

Hi all,

We cannot succesfully import our Solution... It appears it's a bug introduced after 0.0.77 (as that version 0.0.77 was working last week).

• Our solution takes over an hour to import (but usually < 1.5 hrs).
• We are running Async and not publishing as part of the import.
• What it seems like to me is that the bearer token is not being refresh when imports are longer than an hour (some builds have failed between 1hr and 1.5hrs).

Options being used:

solution import --path xxxx.zip --async true --import-as-holding false --force-overwrite false --publish-changes false --skip-dependency-check false --convert-to-managed false --max-async-wait-time 240 --activate-plugins true --settings-file xxx.json'

Important parts of the log:

Task : Power Platform Import Solution Description : Power Platform Import Solution Version : 0.0.84 Author : Microsoft

....

Solution Importing... Waiting for asynchronous operation 6c33d1fd-fafa-ec11-82e6-002248186ad1 to complete with timeout of 04:00:00 Processing asynchronous operation... execution time: 00:00:00 and 1% complete Processing asynchronous operation... execution time: 00:00:04 and 2% complete Processing asynchronous operation... execution time: 00:00:08 and 3% complete Processing asynchronous operation... execution time: 00:00:12 and 4% complete Processing asynchronous operation... execution time: 00:00:16 and 5% complete Processing asynchronous operation... execution time: 00:00:20 and 6% complete Processing asynchronous operation... execution time: 00:00:24 and 7% complete Processing asynchronous operation... execution time: 00:00:28 and 8% complete Processing asynchronous operation... execution time: 00:00:32 and 9% complete

....

Processing asynchronous operation... execution time: 01:11:43 and 100% complete Processing asynchronous operation... execution time: 01:11:47 and 100% complete Processing asynchronous operation... execution time: 01:11:51 and 100% complete Processing asynchronous operation... execution time: 01:11:55 and 100% complete Processing asynchronous operation... execution time: 01:11:59 and 100% complete Processing asynchronous operation... execution time: 01:12:03 and 100% complete Processing asynchronous operation... execution time: 01:12:08 and 100% complete Processing asynchronous operation... execution time: 01:12:12 and 100% complete Processing asynchronous operation... execution time: 01:12:16 and 100% complete Processing asynchronous operation... execution time: 01:12:20 and 100% complete Microsoft PowerPlatform CLI Version: 1.15.10+g15dc5d3

Error: The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Bearer authorization_uri=https://login.microsoftonline.com/xxxx/oauth2/authorize, resource_id=https://xxxx.crm6.dynamics.com/'. The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Bearer authorization_uri=https://login.microsoftonline.com/xxxx/oauth2/authorize, resource_id=https://xxxx.crm6.dynamics.com/'. The remote server returned an error: (401) Unauthorized.

[remyblok]

Yes, I am experiencing the same issue.

[davidjenni]

@mhemp2021 @remyblok @faranakt @vladnega what authN schema are your tasks using? appID/SPN or user/password? I'd assume appID?

thx

[remyblok]

I'm indeed using AppId/SPN for login. Thanks for investigating.

[Faranakt]

We use SP for Authentication. There are so many regression issues including the old bug where it times out every hour. Anyway you can roll back to previous version? This is causing so much stress for our deployments. Or Allow us use previous versions until this version is stable as recommended in previous comments

[vladnega]

I support @faranakt's suggestion of allowing us to use previous versions. Is there a particular reason why the task version is not changed whenever there is a new release and you keep it locked to 0.1.0?

[mhemp2021]

@mhemp2021 @remyblok @Faranakt @vladnega what authN schema are your tasks using? appID/SPN or user/password? I'd assume appID?

Using Classic Pipeline... Generic Service Connection Type Username and Password

[davidjenni]

@mhemp2021 @remyblok @Faranakt @vladnega Thanks for confirming. With appID/SPN authN in MSAL (which MSAL calls confidential clients), the MSAL stack does not keep a refresh token; it simply assumes the secret is still known once the access token expires (typ, after 60 min). For security reasons, the pac CLI used within the tasks does not keep that secret on disk.

We will be rolling back to the previous PowerShell implementation, which will appear as >= 1.0.85, so newly queued jobs will pick up that rollback automatically Watch this discussion thread for more updates: https://github.com/microsoft/powerplatform-build-tools/discussions/144

[mhemp2021]

Thanks David.

[davidjenni]

I support @Faranakt's suggestion of allowing us to use previous versions. Is there a particular reason why the task version is not changed whenever there is a new release and you keep it locked to 0.1.0?

@vladnega @Faranakt There's no simple answer to that, but it is a fair question. I've tried to illustrate the challenge in this discussion thread: https://github.com/microsoft/powerplatform-build-tools/discussions/145

[Faranakt]

When will you roll back? we are having major issues right now with the pipelines it is almost unsuable currently, We have never had issues like this and been using it for over 2 years across multiple projects. Something has gone very wrong with the recent release , we are on round 5 and counting

[davidjenni]

@Faranakt we have deployed 1.0.85, which is the same as the latest PS-based 1.0.41

[Faranakt]

Still times out for us , have you fixed the time out issues ? we are constantly retriggering the deployments

[Faranakt]

ok it might have been just the timing, the new run looks like old times and the logs are so much better thanks!

[mhemp2021]

Seems to be OK here on 85, will know more tomorrow.

Thanks!

[tiemar]

I got around this by adding a hughe maximum wait time and continue on error. As I was pretty shure even when the error araises the import was long finished. So this was a kind of workaround but always takes time to figure it out.

Maybe you could populate the old version as new "Preview Import Task". So we can exchange the step and test it before we do another try like this?

[davidjenni]

I got around this by adding a hughe maximum wait time and continue on error. As I was pretty shure even when the error araises the import was long finished. So this was a kind of workaround but always takes time to figure it out.

Maybe you could populate the old version as new "Preview Import Task". So we can exchange the step and test it before we do another try like this?

We don't have too many choices on pinning and/or distinguishing existing vs preview tasks, see discussion #145

[davidjenni]

Will resolve this as duplicate to #129 AB#2780591: PP.BT / pac CLI deploy package: deployment errors out once accessToken has expired

dupe to #129

[davidjenni]

Re-opening this issue, since it was incorrectly duped to #129:

• this issue deals with the bearer token/accessToken NOT refreshing after its 60 min expiration time in connection that use AppID/SPN. The deeper reason for that is, the AAD MSAL client models appID/clientSecret authN via its ConfidentialApp object model. One distinction that ConfApp has, it only results in an accessToken, but no local refreshToken. The pac CLI itself does NOT store the initial clientSecret, hence it cannot request a new accessToken.

We have added support into the common cli-wrapper that allows the clientSecret to be remembered for the duration of a AzDO task. This fix shipped with the latest PP-BT >= 2.0.3 (i.e. the v2 tasks)

[davidjenni]

de-duped, now resolving again. Fix is in v2.0.3 and newer, see migration docs: https://aka.ms/pp-bt-migrate-to-v2

[improving-jeffd]

Version 2.0.4 and this issue just happened Friday, Saturday and this morning. We are reverting to 0.x for now.

Logs show the last successful check to get the progress of the solution import was at execution time 00:59:24 and was at 66%. Then the next log message is the same error as OP was getting.

We are using a service connection with clientId/Secret setup in DevOps.

[davidjenni]

@improving-jeffd see also the final comment in #179 & 180: v2.0.5 was published earlier today to address this.