如何对服务主体使用Azure AD Graph API访问？

我有一个使用adal4j的Azure AD / Azure守护程序应用程序，它使用用户/密码身份验证 . 由于ADFS问题，我希望能够使用服务主体（客户端ID /机密）进行身份验证 . 这似乎适用于应用程序的Azure（非AD）部分，因为可以为相关订阅定义SP角色，但是对于Azure AD部分，我得到：

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

...这是在第一次调用Graph API时发生的 - 我使用https://graph.windows.net范围从AuthenticationContext.acquireToken（）获取有效令牌 .

我的帐户是目录中的所有者 . 我已经尝试使用应用程序上的“授予权限”按钮，并且还尝试制作同意URL（可以正常工作）并使用它来同意在目录中具有必要权限的应用程序 . 似乎都没有影响到这一点 .

该应用程序是Native应用程序，因为它是一个守护程序/服务应用程序，因此无法参与OAuth2同意 .

如何使用SP进行身份验证来访问Azure AD Graph API？作为提醒，未更改，该应用程序使用（非ADFS）用户/密码，并且SP与Azure API一起使用，而不是Azure AD Graph API .

谢谢...

附：我也尝试使用Azure Graph API，Microsoft现在推荐使用Azure Graph API，而不是Azure AD Graph API . 相同的结果，同样适用于用户/密码信用 .

修改这个以使adal4j脱离图片 - 这似乎更像是一个通用的Azure AD问题 . 以下是使用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查询：

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

使用客户端凭据令牌的Azure AD REST响应：

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

现在，将其与（注意相同的租户ID /应用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查询：

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

使用密码凭据令牌的Azure AD REST响应：

{"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"},...

此时我的怀疑是，创建应用时由Azure AD默认创建的SP不包含必要的权限 . 我将尝试创建一个具有指定权限的新SP . 这方面的例子比比皆是，但都集中在目标应用程序是一些神秘的LOB应用程序，而不是Azure AD . 而且，正如半生不熟的门户网站通常所见，必须使用CLI来执行此操作 .

</snark>

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

另外，FWIW，我已经验证了SP在理论上具有我在门户中输入的Azure AD（和其他）权限 . 我认为 .

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