CloseError: ClientSecretCredential authentication failed: Retry failed after 4 tries. Retry settings can be adjusted in ClientOptions.Retry.
February 13th 2023 10:15:03Error
At D:\Octopus\Work\20230213091359-214459-71\Octopus.AzureContext.ps1:97 char:5
What does ClientSecretCredential authentication failed mean?
Thank you for contacting Octopus Support and welcome to the forums!
Sorry to see you are having issues with the Run an Azure Script Step, we have not seen that error before but from the looks of it it seems like it might be an invalid Client Secret/Application password, however, it is odd that the Account itself in the Infrastructure page is showing as valid. Do you have the Application password/key setup for that?
Would you be able to test this outside of Octopus in a PowerShell session on the Octopus Server? Does that run the write host command or are you getting the same error?
Hi Anders,
Just stepping in for Clare who is offline at present.
I did see a similar issue around TLS12 and Powershell and I was wondering if you could rule this out in your scenario. This is an older issue so it may already by fixed but its worth checking by updating your PS script:
If this doesn’t help we will keep looking and get a resolution for you.
I tried adding [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12; to the script above - and now it works!
So I tried adding it to the Azure step, just before the “Write-Host” part - but the step still fails. Not too surprising, because it looks like the error occurs in your internal script that tries to connect to Azure:
CloseError: ClientSecretCredential authentication failed: Error
At D:\Octopus\Work\20230214072443-214619-77\Octopus.AzureContext.ps1:97 char:5
February 14th 2023 08:25:45Error
+ Login-AzureRmAccount -Credential $creds -TenantId $OctopusAzureAD ...
Moreover - it’s still strange that the Account is verified fine in Octopus. But maybe your verification process actually uses TLS1.2?
Anyway - I think adding a system-wide registry key (as suggested by the Microsoft article) to our Octopus Server machine might fix the overall issue - but that’s not something I am able to try just yet.
Great news Paraic managed to guide you to a part way solution, to be honest usually if the issue is TLS related it does show in the error message and a google of the CloseError: ClientSecretCredential authentication failed error you were getting did not mention TLS so good spot by Paraic there.
As for the verification, yes Octopus uses TLS 1.2 as default so that would be why that works from the infrastructure > Accounts screen, from your screenshot of your step it looks like you are running the Azure Script on the Octopus Server but using the tools installed on the worker. This would mean if you are getting the same error on the Octopus Server when running outside of Octopus and you add the [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12 line to it and it works…you would need to add that system wide registry key and reboot for Octopus to pick up that PowerShell will now use TLS 1.2.
I am sorry I do not have better news for you but Octopus can only use what is on that box at the time if you are running that script using the tools on the worker so you will need to force the use of TLS 1.2 for powershell in order to get this to work.
Reach out if you set that system wide registry key and reboot and this still does not work as we can dig a bit deeper but I am confident doing that will fix this issue.
