如何使用Azure AD Graph API访问服务主体? [英] How to use Azure AD Graph API access for service principals?

查看：91
本文介绍了如何使用Azure AD Graph API访问服务主体?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我有一个使用adal4j的有效Azure AD/Azure守护程序应用程序，该应用程序使用了用户/密码身份验证.由于ADFS的问题，我希望也能够使用服务主体(客户端ID/秘密)进行身份验证.对于应用程序的Azure(非AD)部分，这似乎很好用，因为可以为有问题的订阅定义SP角色，但是对于Azure AD部分，我得到:

I have a working Azure AD/Azure daemon application using adal4j that uses user/password authentication. Due to issues with ADFS, I wish to also be able to authenticate using a service principal (client ID/secret). This seems to work fine for the Azure (non-AD) portion of the app, as the SP roles can be defined for the subscriptions in question, however for the Azure AD part, I get:

response code 403, error: Authorization_RequestDenied: Insufficient privileges to complete the operation.

...这是在第一次调用Graph API时发生的-我使用 https://graph.windows.net 作用域.

...this occurs on the first call to the Graph API - I get valid tokens from AuthenticationContext.acquireToken() using the https://graph.windows.net scope.

我的帐户是目录中的所有者.我尝试使用该应用程序上的授予权限"按钮，还尝试构造一个同意URL(有效)，并使用该URL同意该应用程序在目录中具有必要的特权.似乎都没有影响.

My account is an Owner in the directory. I've tried using the "Grant Permissions" button on the app, and have also tried fabricating a consent URL (which works) and using that to consent to the app having the necessary privileges in the directory. Neither seems to affect this.

该应用程序是本机应用程序，因为它是守护程序/服务应用程序，因此不能参与OAuth2同意.

The app is a Native app, as it is a daemon/service app, so can't participate in OAuth2 consent.

如何使用SP访问Azure AD Graph API进行身份验证?提醒一下，该应用程序可以使用(非ADFS)用户名/密码，而SP可以使用Azure API，而不能使用Azure AD Graph API.

How does one access the Azure AD Graph API using a SP to authenticate? As a reminder, unchanged, the app works with (non-ADFS) user/password, and the SP works with the Azure API, just not Azure AD Graph API.

谢谢...

P.S.我还使用Azure Graph API尝试了此操作，Microsoft现在推荐使用Azure Graph API，而不是Azure AD Graph API.结果相同，并且与用户/密码凭据类似.

P.S. I've also tried this with the Azure Graph API, which Microsoft now recommends instead of the Azure AD Graph API. Same result, and similarly works with user/password creds.

将其修改为从某种程度上消除adal4j的问题-这似乎更像是一个通用的Azure AD问题.这是使用curl的问题示例:

Amending this to kind of take adal4j out of the picture - this seems to be more of a generic Azure AD problem. Here's an example of the problem, using curl:

客户凭证令牌请求:

curl --request POST "https://login.windows.net/367cxxxx41e5/oauth2/token" --data-urlencode "resource=https://graph.windows.net" --data-urlencode "client_id=9d83yyyy08cd" --data-urlencode "grant_type=client_credentials" --data-urlencode "client_secret=secret"

客户凭证令牌响应:

{"token_type":"Bearer","expires_in":"3599","ext_expires_in":"0","expires_on":"1491486990","not_before":"1491483090","resource":"https://graph.windows.net","access_token":"eyJ0zzzz2zVA"}

使用客户端凭据令牌进行Azure AD REST查询:

Azure AD REST query using client credentials token:

curl "https://graph.windows.net/367cxxxx41e5/tenantDetails" --header "Authorization: eyJ0xxxx2zVA" --header "Accept: application/json;odata=minimalmetadata" --header "api-version: 1.6"

使用客户端凭据令牌对AD REST进行响应:

Azure AD REST response using client credentials token:

{"odata.error":{"code":"Authorization_RequestDenied","message":{"lang":"en","value":"Insufficient privileges to complete the operation."}}}

现在，与进行对比(请注意相同的租户ID/应用ID):

Now, contrast that with (note the same tenant ID/app ID):

密码凭证令牌请求:

curl --request POST "https://login.windows.net/367cxxxx41e5/oauth2/token" --data-urlencode "resource=https://graph.windows.net" --data-urlencode "client_id=9d83yyyy08cd" --data-urlencode "grant_type=password" --data-urlencode "username=bozo@clown.com" --data-urlencode "password=password"

密码凭证令牌响应:

{"token_type":"Bearer","scope":"Directory.AccessAsUser.All Directory.Read.All Group.Read.All Member.Read.Hidden User.Read User.Read.All User.ReadBasic.All","expires_in":"3599","ext_expires_in":"0","expires_on":"1491489157","not_before":"1491485257","resource":"https://graph.windows.net","access_token":"eyJ0zzzz0EXQ","refresh_token":"AQABzzzzAgAA"}

使用密码凭据令牌进行Azure AD REST查询:

Azure AD REST query using password credentials token:

curl "https://graph.windows.net/367cxxxx41e5/tenantDetails" --header "Authorization: eyJ0xxxx0EXQ" --header "Accept: application/json;odata=minimalmetadata" --header "api-version: 1.6"

使用密码凭证令牌对AD REST进行响应:

Azure AD REST response using password credentials token:

{"odata.metadata":"https://graph.windows.net/367cxxxx41e5/$metadata#directoryObjects/Microsoft.DirectoryServices.TenantDetail","value":[{"odata.type":"Microsoft.DirectoryServices.TenantDetail","objectType":"Company","objectId":"367cxxxx41e5","deletionTimestamp":null,"assignedPlans":[{"assignedTimestamp":"2017-02-24T03:25:33Z","capabilityStatus":"Enabled","service":"SharePoint","servicePlanId":"e95byyyyc014"},...

目前，我怀疑SP是在创建应用程序时由Azure AD默认创建的，不包含必要的权限.我将尝试使用指定的权限创建一个新的SP.这样的例子比比皆是，但所有例子都集中在目标应用程序上，它们是一些神话般的LOB应用程序，而不是Azure AD.而且，就像半熟的门户通常一样，必须使用CLI来完成此操作.

My suspicion at this point is that the SP, created by default by Azure AD when the app was created, doesn't include the necessary permissions. I'll try creating a new SP with the rights specified. Examples of this abound, but all are focused on the target app being some mythical LOB app, not Azure AD. And, as seems usual with the half-baked portal, the CLI must be used to do this.

</snark>

此外，我已经验证了具有读者"角色的任何人都应该能够执行该查询.我已将贡献者"和所有者"添加到SP中，但没有任何效果.

Also, I've verified that anyone with Reader role should be able to execute that query. I've added both Contributer and Owner to the SP, with no effect.

另外，FWIW，我已经验证了SP在理论上具有我在门户中输入的Azure AD(及其他)权限.我想.

Also also, FWIW, I've verified that the SP has, in theory, the Azure AD (and other) permissions I entered in the portal. I think.

    PS C:\> Get-AzureADServicePrincipalOAuth2PermissionGrant -objectid 'a9f9xxxx5377'|format-list -property consenttype,resourceid,scope

ConsentType : AllPrincipals
ResourceId  : c569xxxxe7f0
Scope       : Member.Read.Hidden User.Read User.ReadBasic.All User.Read.All Group.Read.All Directory.Read.All
              Directory.AccessAsUser.All

ConsentType : AllPrincipals
ResourceId  : 3318xxxx66a5
Scope       : user_impersonation

ConsentType : AllPrincipals
ResourceId  : 8c0fxxxx4198
Scope       : User.Read.All User.ReadBasic.All Group.Read.All Directory.Read.All Directory.AccessAsUser.All User.Read

PS C:\> get-azureadobjectbyobjectid -objectids 'c569xxxxe7f0','3318xxxx66a5','8c0fxxxx4198'

 ObjectId     AppId                                DisplayName
--------     -----                                -----------
8c0fxxxx4198 00000003-0000-0000-c000-000000000000 Microsoft Graph
3318xxxx66a5 797f4846-ba00-4fd7-ba43-dac1f8f63013 Windows Azure Service Management API
c569xxxxe7f0 00000002-0000-0000-c000-000000000000 Microsoft.Azure.ActiveDirectory

推荐答案

根据您的描述，根据我的经验，我认为该问题是由两个原因引起的.

According to your description, per my experience, I think the issue was caused by two reasons.

  1. 不要在Azure门户上的Azure AD中的已注册应用程序的Required permissions选项卡中添加Windows Azure Active Directory (Microsoft.Azure.ActiveDirectory)的api访问，如下所示，并选择相关权限.
  1. Not add api access of Windows Azure Active Directory (Microsoft.Azure.ActiveDirectory) in the Required permissions tab of your registed application in Azure AD on Azure portal as below and select the related permissions.

作为参考，您可以参考其他SO线程

As references, you can refer to the other SO thread Trouble with authorization using client_credentials Azure AD Graph API or the offical document here and a helpful blog.

  1. 不为此服务主体分配Contributor.您需要运行下面的powershell命令来执行此操作.

  1. Not assign Contributor for this service principal. You need to run the powershell command below to do this.

New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName 'applicationID'

或者您也可以参考我的答案以获取另一个SO线程

Or you can also refer to my answer for another SO thread Cannot list image publishers from Azure java SDK to do this via Azure CLI or just on Azure portal.

希望有帮助.

这篇关于如何使用Azure AD Graph API访问服务主体?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆