Azure CLI间歇性地无法作为服务主体登录 [英] Azure CLI intermittently fails to login as a service principal

问题描述

我使用服务主体登录Azure CLI（屏蔽了详细信息）。

I'm logging in to the Azure CLI using a service principal (details masked).

az login --service-principal --username "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" --password "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" --tenant "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

大部分时间按预期工作。大约20％的时间失败（35次登录，失败7次）。

Most of the time it works as expected. Approximately 20% of the time it fails (in 35 logins, it failed 7 times).

Get Token request returned http error: 401 and server response: {"error":"invalid_client","error_description":"AADSTS7000215: Invalid client secret is provided.\r\nTrace ID: f754a810-b66c-4fc3-a9cf-338f4e800400\r\nCorrelation ID: 58e66cea-dd86-4a9b-8400-f51e1a82c841\r\nTimestamp: 2019-03-01 00:37:57Z","error_codes":[7000215],"timestamp":"2019-03-01 00:37:57Z","trace_id":"f754a810-b66c-4fc3-a9cf-338f4e800400","correlation_id":"58e66cea-dd86-4a9b-8400-f51e1a82c841"}

我在Windows 10上使用的是2.0.59的CLI。

I'm using 2.0.59 of the CLI on Windows 10.

我使用了这个服务主体的一些不同的客户机密，最奇怪的是一些工作没有问题（约50次成功登录），但其他人经常像上面那样失败。我正在生成然后使用秘密作为自动化管道的一部分，
所以我不能依赖静态的工作秘密。

I've used a few different client secrets with this service principal, and what's most odd is some work without an issue (~50 successful logins), but others regularly fail like above. I'm generating then using the secrets as part of an automation pipeline, so I can't rely on a static working secret.

这里有什么我不知道的？或者这是Azure CLI或Azure AD中的缺陷？

Is there something I'm missing here? Or is this a defect in the Azure CLI or Azure AD?

推荐答案

现在运行相同的命令可以100％正常运行。  ;

Running the same command now works 100% of the time. 

我跑了10分钟没有问题：

I ran this for 10 minutes without issue:

while(

true）{
Start-Sleep -seconds 2; 
获取日期; 
az云集 - 名称AzureCloud;
az login --service-principal --username" XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" --password" XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" --tenant"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX""}

true){
Start-Sleep -seconds 2; 
Get-Date; 
az cloud set --name AzureCloud;
az login --service-principal --username "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" --password "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" --tenant "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}

我怀疑AAD中存在一些传播延迟，但存在较小的失败风险对于新的服务主要秘密。有谁知道这种延迟可能是什么？

I suspect there is some propagation delay in AAD that gives a small risk of failure for new service principal secrets. Does anyone know what this delay might be?

这篇关于Azure CLI间歇性地无法作为服务主体登录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！