Сброс пароля REST-вызов возвращает 403 с использованием принципала службы

Question

Я пытаюсь выполнить следующий API, используя токен-носитель, выданный субъекту службы, а не пользователю AD. Да, я знаю, что это графа AD Graph против Microsoft Graph, но у меня есть свои причины:)

https://graph.windows.net/GUID-REDACTED/users/GUID-REDACTED?api-version=1.6

Я получаю сообщение об ошибке 403, несмотря на тот факт, что я предоставил этому участнику все разрешения приложений для «Windows Azure Active Directory» (и Microsoft Graph). Я также применил согласие администратора (через предоставление разрешений) на портале. Обратите внимание, что запрос на чтение всех пользователей (т. Е. Удалить последний GUID с URL-адреса выше) завершается успешно.

Токен на предъявителя содержит следующие семь утверждений (любопытно, что в AD предоставлено ВОСЕМЬ разрешений):

    "Device.ReadWrite.All",
    "Directory.Read.All",
    "Member.Read.Hidden",
    "Directory.ReadWrite.All",
    "Domain.ReadWrite.All",
    "Application.ReadWrite.OwnedBy",
    "Application.ReadWrite.All"

Токен был получен через:

 var context = new AuthenticationContext($"https://login.microsoftonline.com/{tenantId}");

 var m = new HttpRequestMessage()
 var accessToken = context.AcquireTokenAsync("https://graph.windows.net", credentials).Result.AccessToken;
 m.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);

Я попробовал аналог этого через конечную точку Microsoft Graph, но с ADAL AuthenticationContext и получил тот же результат 403. Если я использую Microsoft Graph Explorer, он работает. В этом случае я вошел как пользователь, хотя. При сравнении областей в токенах (scp) есть различия (потому что у пользователя есть определенные области 'пользователя'), но ничего, что сразу выглядит подозрительным.
Directory.AccessAsUser.All относится к области действия пользователя, но не к области идентификации приложения, но для меня это имеет смысл, если только эта область (неправильно?) Требуется для операции, которую я пытаюсь выполнить.

Есть идеи, что мне здесь не хватает? Есть ли ссылка, которая отображает области / роли, необходимые для реальных операций API? Нужна ли SP роль каталога, как это понадобится пользователю?

Answer 1

Как сказал @ MarcLaFleur , давать приложениям разрешения на сброс пароля пользователя не очень хорошая идея. Но если у вас нет другого выбора, вы все равно можете использовать поток учетных данных клиента для достижения этой цели. Но это не рекомендуется, если у вас нет другого выбора.

Решение:

Вы можете назначить Company Administrators Роль своему принципалу Сервиса. Вы можете обратиться к этому документу , чтобы сделать это.

1. Используйте AAD Powershell для подключения AAD:

Connect-AzureAD

2. Получить роль администратора компании:

$role = Get-AzureADDirectoryRole | Where-Object {$_.displayName -eq 'Company Administrator'}

3. Назначьте роль своему SP:

Add-AzureADDirectoryRoleMember -ObjectId $role.ObjectId -RefObjectId $yoursp.ObjectId