Run an Azure Script is failing: CloseError: ClientSecretCredential authentication failed
This project deployed successfully earlier today, and then I updated to V2023.2 (Build 13175). Now deployments are failing with the ClientSecretCredential auth error.
The underlying azure account was refreshed June 19th, so it didn’t just expire.
Hi @seanl,
Thanks for getting in touch!
Is your deployment step using the bundled AzureRM tools or pre-installed AZ CLI on the server/worker?
Also, is there any additional error or stack provided when the error occurs?
Regards,
Paul
If you head to Infrastructure > Accounts and test the relevant Azure account, is that successful?
Assuming that works, could be worth creating a test project and just running a basic Azure script step to see if that runs successfully.
May help narrow down if it is a problem with the account auth as a whole or a specific resource within the account.
We have 2 accounts- Dev and Prod. Both tested successfully.
I attempted to re-deploy this project to Prod, and it’s failing with the same error. Dev and Prod are in 2 separate tenants.
Looking closer at the error, it’s using Connect-AzAccount:
The previously successful deployment used Az Login:
But attempt 1 of 5 failed- perhaps there was code that first tries Connect-AzAccount, then falls back to Az Login on attempt 2, but that fallback was removed?
Can you send over the full task log for the failed deployment and the previous successful one?
I’ve sent a secure upload link to you in a DM.
We’re likely going to have to get our engineers to take a look to see if anything has been changed here.
Logs sent.
Thanks for that.
Looking over the logs, am I correct that the actual App deployment works fine? It’s just the slot-swapping script step that is experiencing the error?
That seems even stranger.
Correct. It’s an az command to swap slots after the deployment.
I created a simple project with one Run an Azure Script step:
$apps = az webapp list -o tsv
write-host $apps
I believe the previous version I had installed was Octopus.2023.1.9749 based on downloads in my temporary files. What version can I safely roll back from Octopus.2023.2.13175 without database issues?
Unfortunately, the only safe rollback is to install 2023.1.9749 and restore a database backup from before the upgrade.
Further testing shows it’s a problem with “Run on the Octopus Server on behalf of each deployment target” when the deployment target is an Azure App Service.
When I select “Run on the Octopus Server” with a powershell script, this successfully connects:
$tenant = $OctopusParameters[“AzureAcct.TenantId”]
$user = $OctopusParameters[“AzureAcct.Client”]
$pass = $OctopusParameters[“AzureAcct.Password”]
az login --service-principal -u $user -p $pass --tenant $tenant
$apps = az webapp list -o tsv
write-host $apps
When I change the step to “On behalf of”, the step fails before it even attempts to run the powershell.
Hi @seanl,
Just stepping in for Paul while he’s offline, cheers for those extra details!
I recalled this error previously where it was resolved by adding the following to the top of the script to enforce TLS1.2: Credential error when running azure script step - #7 by clare.martin
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
Microsoft has some great docs about the TLS problem: Solving the TLS 1.0 Problem - Security documentation | Microsoft Learn
Hope that helps but feel free to reach out with any questions at all!
Best Regards,
Added the SecurityProtocol line to the top of the powershell script, and it still fails.
TLS 1.2 is the only active security protocol on the Octopus server.
This appears to be a problem with “Run on the Octopus Server on behalf of each deployment target”, as I can change to “Run on the Octopus Server” and Az Login completes successfully.
The engineers suggested that as the Connect-AzAccount is the command that is failing and that it looks to fail at least once on the previously successful job, it would be worth testing that out directly on the machine.
Can you test running that command on the Octopus Server (but outside of Octopus) with the same Azure credentials? It may generate a clearer error when running it in this way.
Connect-AzAccount -Credential $creds -TenantId $OctopusAzureADTenantId -SubscriptionId $OctopusAzureSubscriptionId -Environment $AzureEnvironment -ServicePrincipal
So something is broken with Connect-AzAccount in my environment, as Az Login works with the same credentials.
Was there fallback behavior to Az Login that was recently removed?
Update- I was able to resolve the problem.
Running Connect-AzAccount with -debug showed the classic TLS error “System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm”
However TLS 1.2 was the only enabled protocol in the registry.
This lead me to another article: Azure AD Connect: TLS 1.2 enforcement for Azure Active Directory Connect - Microsoft Entra | Microsoft Learn
I did not have the .NETFramework\v4.0.30319 registry entries listed in the article. After adding the entries and rebooting, Connect-AzAccount completes successfully.
Glad you were able to locate and resolve the issue. Appreciate the detailed resolution steps; they’ll likely come in handy in future.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
