Credential Provider Fails with Sign-in frequency Conditional Access Policy #529
Comments
afscrome
changed the title
afscrome
changed the title
|
@afscrome can you provide more information about how the cred provider is being called - with nuget.exe, msbuild or dotnet cli? and what MSAL login method was used if it was interactive? what is the exit code (This might be in the nuget logs )? I would have expected NuGet to retry and send isRetry=true, which I would expect to grab fresh tokens regardless of session token cache. We have known work item to improve the cache to check if the token is near expiration, and refresh if so. Also, this would be really helpful to know if this is experienced outside of visual studio. There are multiple NuGet credproviders shipped with VS and isolating which one, or if it's the interaction of both + nuget, would help narrow down the issue. There is a known issue for the visual studio credprovider around re-authenticating accounts with certain conditional access policies for folks with multiple accounts in the keychain (where the work around requires reauthenticating in the visual studio keychain before trying to access a feed). |
embetten
added
bug
|
We experience this issue with both Visual Studio and dotnet CLI. In Visual Studio it shows itself up as an infinite loop of prompting to log in to the artifact feed. In dotnet CLI it shows up as broker prompt which 403s followed by a device code requests which also produces a 403 exception , even though I completed both the device code and broker logins successfully. Dotnet cli seems to provide a loop of Device Code prompts, although it may actually be one per project (I haven't had the patience to keep doing the prompts to see if they stop) I can also reproduce this raw with the credential provider - both with 1.1 and 1.3. & $env:userprofile\.nuget\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.exe -I -V Verbose -U "https://pkgs.dev.azure.com/REDACTED/_packaging/REDACTED/nuget/v3/index.json"This first prompts me with a Broker request
Which fails, and then prompts for Device Code
If I do something in the Azure Devops UI in a web browser then repeat the same request to the credential provider exe, everything works perfectly.
If I look at the sign in events in the Entra Sign in logs, I see a few errors. In Interactive sign ins, I see For what it's worth, we experience a very similar issue with the git credential provider - if you haven't visited the ADO UI withint eh past 10 hours (very common at the begining of the day), the git credential provider will continually 403 until you open ADO in your UI.
Although we're doing some testing as it looks like we're able to mitigate that issue by forcing the git credential provider to use oauth over PAT tokens, and to use the windows account broker with the following in .gitconfig [credential]
azreposCredentialType = oauth
msauthUseBroker = trueUnfortunately this doesn't work for all our users as we have some applications which require running Visual Studio as admin. My company has separate admin & non admin accounts, and the account broker doesn't work when running as another user. |
|
First and foremost, I recommend turning off the session token cache for your org with these conditional access policies. Setting the env variable The issue is that an on-behalf-of call on the ADO server side is failing the conditional access policy. ADO doesn't expose the necessary claims for re-authentication to the downstream resource (see these docs ). However, logging into the ADO UI refreshes the token for the on-behalf-of call and satisfies the downstream claims. This is also why it's needed for GCM. TL;DR |
embetten
added
work-around
If your organization has a conditional access policy with a short Sign-in frequency (in my case 10 hours), then the Azure Devops credential provider fails with a 403 error if you haven't logged in to the Azure Devops UI in the time since your token was issued.
The exception comes from
artifacts-credprovider/CredentialProvider.Microsoft/CredentialProviders/Vsts/VstsCredentialProvider.cs
Line 161 in b66855c
{ "$id": "1", "innerException": null, "message": "VS403463: The conditional access policy defined by your Microsoft Entra administrator has failed.", "typeName": "Microsoft.VisualStudio.Services.Common.VssServiceException, Microsoft.VisualStudio.Services.Common", "typeKey": "VssServiceException", "errorCode": 0, "eventId": 3000 }The problem seems to be that whilst the Entra token was obtained interactively,
tokenProvider.IsInteractiveis false, so the call to the SessionTokens api doesn't extend the session lifetime in Azure Devops. This causes some nasty knock on effects in Visual Studio which gets into an infinite loop of prompting to auth to the credential provider without showing any error.Since Azure Devops supports Entra auth natively, you could skip this whole problem by using the already obtained bearer token by replacing the above line with something like:
It would also be nice if a 403 error would show more details of the error from the response body - I had to pull the source code and crack open the debugger to find out that conditional access policies were the cause of this error and not the verbose output.
The text was updated successfully, but these errors were encountered: