Azure Active Directory应用程序和服务主体

Question

Azure Active Directory具有很好的应用程序和服务主体概念，可以作为应用程序进行身份验证，例如用于CI平台或SaaS应用程序。

现在有多种创建方式，例如将MSOL与cmdlet结合使用：

New-MsolServicePrincipal -DisplayName "My new API app" -Type password -Value $myClientSecret

这可以很好地工作（在我使用分配了一些角色给服务主体后Add-MsolRoleMember，我可以访问Graph API）。但是我仍然有一些问题：

1. 为什么此cmdlet不需要首先创建应用程序？
2. 此cmdlet是否同时创建-应用程序和服务主体？
3. 为什么在经典和新的Azure门户中都看不到该应用程序？

也许有人可以回答我第四个问题：上述MSOL cmdlet和New-AzureRmADApplication+ New-AzureRmADServicePrincipalcmdlet有什么区别？我什么时候应该使用它们中的哪一个？

Answer 1

ARM cmdlet 和新的 Azure AD v2 cmdlet 均使用 Azure AD Graph API。

然而，New-MsolServicePrincipal事实并非如此。它呼吁https://provisioningapi.microsoftonline.com/provisioningwebservice.svc使用 SOAP。它是一个遗留 API，您不应该使用它。

服务主体必须始终有一个 appId，即创建它的应用程序的客户端 ID。

该字段appOwnerTenantId标识应用程序来自哪个租户。它可以为 null。MS 内部应用程序（例如 Graph API、Azure 门户等）就是这种情况。而且使用 创建的服务主体也是如此New-MsolServicePrincipal，并且省略了appId.

所以问题1和2的答案是：如果没有指定，则会自动创建一个应用程序。但我不确定它是在哪里创建的，因为它无法通过 Graph API 获得。这是一个纯粹的服务身份。而且appId每次都是不同的，所以它不仅仅是使用一些占位符应用程序。

至于问题 3：您在门户中看不到应用程序的原因是因为它无法通过 Graph API 获得，它隐藏在某个地方。至于服务主体，主体需要一个非常具体的魔术标签才能显示在企业应用程序列表中。AFAIK，你不能用New-MsolServicePrincipalor指定它New-AzureRmADServicePrincipal指定它。

第四个问题的答案是，MSOL cmdlet 使用旧版 API，而两个较新的选项则使用 Azure AD Graph API。ARM cmdlet 创建一个您可以在门户中看到的应用程序。他们仍然创建了一个您在企业应用程序列表中看不到的应用程序。

不过，在没有应用程序的情况下创建服务主体时，不同 cmdlet 的行为有所不同：

1. New-MsolServicePrincipal：使用某种隐藏应用程序创建主体，类似于 MS 内部应用程序（还设置 servicePrincipalType=Legacy）
2. New-AzureRmADServicePrincipal：为您创建一个应用程序，然后创建服务主体（该应用程序在门户中可见，但由于缺少标签，该主体只能通过应用程序的刀片可见）
3. New-AzureADServicePrincipal：不允许您在不提供 appId 的情况下创建它

如果您希望主体显示在企业应用程序列表中，就像您通过门户创建它一样，您可以使用 v2 cmdlet 提供必要的标签：

New-AzureADServicePrincipal -Tags @("WindowsAzureActiveDirectoryIntegratedApp") -AppId ed5fa582-3991-4114-87da-30081c4105fb

在我看来，新的 v2 cmdlet 是最好的，至少它们允许您以类似于 Portal 的方式创建服务主体。如果您的目的是创建一个在 ARM API 中使用 RBAC 的服务身份，那么 ARM cmdlet 就可以了，因为主体对此可见。