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

Опитвам се да автоматизирам извличането на AD отчети с помощта на Graph REST API от .net приложение в C#.

Създадох принципал на услугата (с помощта на регистрации на приложения) в новия портал на Azure. Този принципал на услугата има цялата необходима информация, конфигурирана за OAuth 2.0:

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

Принципалът на услугата също има разрешения, зададени по подходящ начин за „Microsoft Graph“ като „Четене на данни от директорията“.

Мога да извлека токена с помощта на REST API от .net приложение, но когато се опитвам да използвам този токен в моя код, получавам грешката: „Не мога да проверя достъпа за четене на директория за appId".

Моят код за извикване на REST API с помощта на токена е (промених GUID за ID на клиента и т.н.):

        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-4-2017

Разреших това. Знам точните стъпки, които решават това за мен. Но не знам основната концепция. Ако някой може да ми обясни това и как да направя това чрез PowerShell или GUI (дори в 2 реда), ще приема това като отговор. Стъпките, които предприемаме са:

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

Какво опитах: Опитах да използвам „Предоставяне на разрешения“ в полето „Необходими разрешения“ в Регистрации на приложения, но това не проработи и доведе до същата грешка.

ВЪПРОС: Искам да разбера какво точно прави диалоговият прозорец по-долу и как мога да направя това чрез GUI или PowerShell.

Подкана за разрешения


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


Отговори (1)


Тествам API повикването и работи. Във вашето описание:

Принципалът на услугата също има разрешения, зададени по подходящ начин за „Microsoft Graph“ като „Четене на данни от директорията“.

Задавате разрешенията за „Microsoft Graph“ (Micorosft Graph API), но във вашия код правите заявка към Azure AD Graph API (https://graph.windows.net/) крайна точка за информация в отчета. Това може да причини проблема. Ако искате да използвате API на Azure AD Graph, трябва да зададете разрешения за „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