Azure active directory Azure AD：为什么清单在运行新的MsolServicePrincipalCredential后有空的keyCredentials？

或者keyCredentials为空可以吗？ 也许第一步是哪里出了问题，但还不确定

预期结果：应用程序清单在keyCredentials中具有证书机密，因此应用程序可以执行所述的标记化身份验证

实际结果：keyCredentials为空

步骤1：通过运行以下命令在AD中创建应用程序：

$azureAdApplication=New-AzureADApplication -DisplayName "SetupTest1008" -HomePage "http://www.SetupTest8.com" -IdentifierUris "http://SetupTest8" -Password "SetupTest1234"
$azureAdApplicationPrincipal=New-AzureADServicePrincipal -ApplicationId $azureAdApplication.ApplicationId

注释： 据此，$azureAdApplication.ApplicationId将用于上传证书机密

.\makecert.exe -r -pe -n "CN=123456" -b 12/15/2014 -e 12/15/2016 -ss my -len 2048 c:\tmp\123456.cer

connect-msolservice -credential $credentials
$cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
$cer.Import("c:\tmp\123456.cer")
$binCert = $cer.GetRawCertData()
$credValue = [System.Convert]::ToBase64String($binCert);

New-MsolServicePrincipalCredential -AppPrincipalId
$azureAdApplication.ApplicationId -Type asymmetric -Value $credValue -Usage verify

步骤2：准备证书密码

.\makecert.exe -r -pe -n "CN=123456" -b 12/15/2014 -e 12/15/2016 -ss my -len 2048 c:\tmp\123456.cer

connect-msolservice -credential $credentials
$cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
$cer.Import("c:\tmp\123456.cer")
$binCert = $cer.GetRawCertData()
$credValue = [System.Convert]::ToBase64String($binCert);

New-MsolServicePrincipalCredential -AppPrincipalId
$azureAdApplication.ApplicationId -Type asymmetric -Value $credValue -Usage verify

步骤3：上载证书机密

.\makecert.exe -r -pe -n "CN=123456" -b 12/15/2014 -e 12/15/2016 -ss my -len 2048 c:\tmp\123456.cer

connect-msolservice -credential $credentials
$cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
$cer.Import("c:\tmp\123456.cer")
$binCert = $cer.GetRawCertData()
$credValue = [System.Convert]::ToBase64String($binCert);

New-MsolServicePrincipalCredential -AppPrincipalId
$azureAdApplication.ApplicationId -Type asymmetric -Value $credValue -Usage verify

---

这里的问题是，我们在AAD中有两个单独的目录对象，它们代表您的应用程序，它们之间存在一些混淆：

应用程序对象（全局-与清单相关）

服务主体（本地-与MSOL cmdlet相关）

我们对应用程序对象和服务主体进行了更为正式的描述，但我将尝试为您介绍这些对象之间的一些更一般的区别，以及一些具体的示例，这些示例解决了您在这里看到的CERT问题

应用程序对象是目录中应用程序的全局表示形式。当您作为应用程序开发人员使用Azure管理门户注册应用程序时，您正在开发人员租户中创建应用程序对象，该对象可用于存储有关应用程序的全局属性。此外，还会在租户中创建一个服务主体，如果您是管理员，它会存储应用程序访问租户的隐式同意。这就是为什么租户管理员创建的应用程序不会提示其用户同意

现在让我们假设您的应用程序是多租户的，而另一个租户中有一个用户想要使用它。因为您在家庭租户中注册了一个全局应用程序对象，所以其他用户可以发现并登录您的应用程序。他们不属于您的租户，需要同意您的应用程序，但如果他们同意，则会在第二个租户中创建一个本地服务主体，该租户代表您在该租户中的应用程序。此对象不仅存储用户/管理员对应用程序的同意，还可以用于存储特定于租户的属性。例如，如果要为某个租户添加特定于虚拟机/租户的域和URL，则不希望在全局对象上注册这些属性，而只希望在该租户的本地服务主体上注册这些属性，以便只有他们可以使用这些URL

回到您的具体情况，您可能希望根据您的服务部署到其他租户的方式，提供应用程序可以使用的特定于租户的证书。在这种情况下，您将让外部租户的管理员按照您在问题中描述的方式使用MSOL PowerShell，他们将能够向其服务主体添加证书。此证书可用于在此租户的上下文中验证您的应用程序，但不能在此租户之外使用，因为它仅在服务主体上本地注册

另一方面，如果您希望更新您的全局证书，以便可以在任何租户的上下文中使用新密钥进行身份验证，那么您将更改您的应用程序对象，该对象可通过Azure管理门户中的应用程序清单访问

这就是为什么您看不到AAD PowerShell所做的更改会影响您的清单：最终，您正在更改两个不同的对象，这两个对象都在不同的上下文中表示您的应用程序

如果您需要一种编程方式来修改应用程序对象，我建议您使用Graph API。不幸的是，AAD PowerShell目前不支持读取/修改您的应用程序对象，但这应该会在将来出现。下面是通过Graph API公开的as的一些详细信息。您应该查看对keyCredentials属性进行发布/修补

我希望这有帮助，

---

Shawn Tabrizi

这里的问题是我们在AAD中拥有的两个单独的目录对象之间存在一些混淆，它们代表您的应用程序：

应用程序对象（全局-与清单相关）

服务主体（本地-与MSOL cmdlet相关）

我们对应用程序对象和服务主体进行了更为正式的描述，但我将尝试为您介绍这些对象之间的一些更一般的区别，以及一些具体的示例，这些示例解决了您在这里看到的CERT问题

应用程序对象是目录中应用程序的全局表示形式。当您作为应用程序开发人员使用Azure管理门户注册应用程序时，您正在开发人员租户中创建应用程序对象，该对象可用于存储有关应用程序的全局属性。此外，还会在租户中创建一个服务主体，如果您是管理员，它会存储应用程序访问租户的隐式同意。这就是为什么租户管理员创建的应用程序不会提示其用户同意

现在让我们假设您的应用程序是多租户的，而另一个租户中有一个用户想要使用它。因为您在家庭租户中注册了一个全局应用程序对象，所以其他用户可以发现并登录您的应用程序。他们不属于您的租户，需要同意您的应用程序，但如果他们同意，则会在第二个租户中创建一个本地服务主体，该租户代表您在该租户中的应用程序。此对象不仅存储用户/管理员对应用程序的同意，还可以用于存储特定于租户的属性。F