Получение ошибки Невозможно проверить доступ к чтению каталога для appId при попытке программного доступа к Graph REST API из приложения .net

Я пытаюсь автоматизировать получение отчетов AD с помощью Graph REST API из приложения .net на С#.

Я создал субъект-службу (используя регистрацию приложений) на новом портале Azure. Для этого субъекта-службы настроена вся необходимая информация для OAuth 2.0:

  1. Идентификатор приложения или идентификатор клиента (создается автоматически)
  2. Ключ или секрет клиента
  3. Идентификатор арендатора (из идентификатора каталога Azure Directory)

Субъект-служба также имеет соответствующие разрешения для "Microsoft Graph" как "Чтение данных каталога".

Я могу получить токен с помощью REST API из приложения .net, но когда я пытаюсь использовать этот токен в своем коде, я получаю сообщение об ошибке: "Невозможно проверить доступ на чтение каталога для appId".

Мой код для вызова REST API с использованием токена (я изменил идентификаторы GUID для идентификатора арендатора и т. д.):

        var client2 = new RestClient("https://graph.windows.net/a0a00aa0-aaaa-0000-0000-00000e0000aa/reports?api-version=beta");
        var request2 = new RestRequest(Method.GET);
        request2.AddHeader("cache-control", "no-cache");
        request2.AddHeader("authorization", "Bearer " + token);
        request2.AddHeader("content-type", "application/json");
        IRestResponse response2 = client2.Execute(request2);
        Console.WriteLine(response2.Content);

Ошибка, которую я получаю:

{
  "error":{
    "code":"Unable to check Directory Read access for appId: 00000aa-aaaa-0a0a-0000-000000000000","message":"message:Unable to check Directory Read access for appId: 00000aa-aaaa-0a0a-0000-000000000000\n client-request-id:00aa0a0a-48bf-4bf8-ae40-a2976a3c6910 timestamp:2017-04-28 01:38:52Z"
  }
}

Я проверил, что учетные данные нигде не кэшируются, как указано в некоторых блогах. Я даже запустил код с пустой виртуальной машины и получил ту же ошибку. Любые указатели для устранения этой ошибки или что может быть причиной этого.

ОБНОВЛЕНИЕ - 28.04.2017

Я решил это. Я знаю точные шаги, которые решают это для меня. Но я не знаю основной концепции. Если кто-нибудь может объяснить мне это и как это сделать через PowerShell или графический интерфейс (даже в 2 строки), я приму это как ответ. Шаги, которые я предпринимаю, следующие:

  1. Создайте субъект-службу/приложение в регистрации приложений.
  2. Добавьте разрешение для Windows Azure AD для «Вход и чтение профиля пользователя» и «Чтение данных каталога». Я также добавил разрешения для Microsoft Graph для «Чтение данных каталога», так как мне также нужно сделать несколько вызовов для этого.
  3. Добавьте URL-адрес ответа для Postman, например "https://www.getpostman.com/oauth2/callback. ".
  4. Используйте помощник Postman OAuth 2.0, чтобы получить токен. Во время процесса он предоставляет экран ниже. После того, как я нажму «Принять», он сгенерирует токен.
  5. Теперь я могу делать запросы, используя код С#.

Что я пробовал: я пытался использовать «Предоставить разрешения» в колонке «Требуемые разрешения» в регистрации приложений, но это не сработало и привело к той же ошибке.

ВОПРОС. Я хочу понять, что именно делает приведенное ниже диалоговое окно и как это сделать с помощью графического интерфейса или PowerShell.

Запрос разрешений


person Aman Sharma    schedule 28.04.2017    source источник


Ответы (1)


Я тестирую вызов API, и он работает. В вашем описании:

Субъект-служба также имеет соответствующие разрешения для "Microsoft Graph" как "Чтение данных каталога".

Вы устанавливаете разрешения для «Microsoft Graph» (Micorosft Graph API), но в своем коде вы запрашиваете API Azure AD Graph (https://graph.windows.net/) конечная точка для информации отчета. Это может вызвать проблему. Если вы хотите использовать Azure AD Graph API, вам необходимо установить разрешения для «Windows Azure Active Directory».

Обновить

Платформа согласия используется для упрощения разработки мультитенантных веб-приложений и собственных клиентских приложений, которым требуется доступ к веб-API, защищенным клиентом Azure AD, отличным от того, в котором зарегистрировано клиентское приложение.

При использовании мультитенантного приложения, когда пользователь из другого клиента впервые входит в приложение, Azure AD запрашивает у него согласие на разрешения, запрошенные приложением. Если они дают согласие, то в клиенте пользователя создается представление приложения, называемое субъектом-службой, и вход может быть продолжен.

Разрешения только для приложений всегда требуют согласия администратора клиента. Если ваше приложение запрашивает разрешение только для приложения, и пользователь пытается войти в приложение, будет отображаться сообщение об ошибке, в котором говорится, что пользователь не может дать согласие. Для некоторых делегированных разрешений также требуется согласие администратора арендатора. Например, разрешение «Чтение данных каталога». Это означает, что для того, чтобы обычный пользователь (т. е. глобальный администратор должен сначала войти в систему и дать согласие на разрешение от имени организации. Вам необходимо использовать учетную запись администратора, чтобы дать согласие на соответствующее разрешение, как показано на рисунке. Щелкните здесь и здесь подробнее о согласии пользователей и администраторов .

person Nan Yu    schedule 28.04.2017
comment
Я также предоставил разрешения Windows Azure AD. Ваш комментарий определенно полезен, поэтому голосую. Я только что решил это. В моем случае это была проблема с разрешениями. Мне не хватало делегированного разрешения в Azure AD для входа и чтения профиля пользователя. Я поделюсь шагами, чтобы понять это, в отдельном комментарии. - person Aman Sharma; 28.04.2017
comment
Я предоставил обновление. Можете ли вы просмотреть и дайте мне знать, если у вас есть какие-либо идеи. Я ценю вашу помощь и вклад в это. - person Aman Sharma; 28.04.2017
comment
Спасибо @Nan Yu - MSFT Ваш ответ и ваш блог очень хорошо объяснили концепции. Я принял ваш ответ как ответ. Еще раз спасибо всем за помощь! - person Aman Sharma; 01.05.2017