401 при доступе к веб-API Dynamics CRM 2016

Мне не удается получить доступ к веб-API OData Dynamics 2016 CRM из консольного приложения.

У нас установлен Dynamics CRM 2016, настроенный с проверкой подлинности на основе утверждений и с использованием AD FS v3.0.

Насколько я понимаю, консольное приложение (или веб-приложение) должно иметь возможность доступа к веб-API с использованием встроенной проверки подлинности Windows (например, NTML или Kerberos) без какой-либо специальной обработки ... или, возможно, поток OAuth должен работать, когда он включен.

Для обычного пользователя, обращающегося к «страницам» Dynamics, проверка подлинности работает нормально (перенаправление на страницу входа в AD FS), но доступ к API OData, похоже, не работает (например: https://crm.domain.org/api/discovery/v8.0/):

  • в браузере я получаю запрос на вход в Windows, и ввод действительных учетных данных всегда приводит к несанкционированной ошибке HTTP 401
  • в браузере, если я перейду к URL-адресу веб-API после входа на страницы, я могу получить доступ к веб-API (т.е. должны быть установлены некоторые файлы cookie, и я уже неявно авторизован)
  • из кода, используя HttpClient с конкретными действительными учетными данными (или текущими учетными данными), я также получаю 401

Вещи, которые я пробовал:

  • если я полностью отключу аутентификацию на основе утверждений, HttpClient будет работать нормально, и я смогу получить доступ к API OData

  • если я оставлю включенной проверку подлинности на основе утверждений и активирую OAuth через PowerShell Add-PSSnapin Microsoft.Crm.PowerShell ; $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings; $ClaimsSettings.Enabled = $true ; Set-CrmSetting -Setting $ClaimsSettings ;.

    Встроенная проверка подлинности Windows по-прежнему не работает, но теперь возможно использование проверки подлинности на предъявителя. Я могу использовать этот фрагмент для получения конечной точки OAuth для генерации токена. , и используйте AuthenticationContext.AcquireTokenAsync, чтобы выдать токен, а затем передать его в Authorization HTTP-заголовке ... но затем, несмотря ни на что, я получаю эту ошибку:

    Bearer error=invalid_token, error_description =Error during token validation!, authorization_uri=https://our.adfs.domain.org/adfs/oauth2/authorize, resource_id=https://crm.domain.org/

Я что-то упускаю ? это возможно проблема конфигурации?


oauth http-status-code-401 dynamics-crm-2016 adfs3.0
person tsimbalar    schedule 30.05.2016    source источник
comment
Я также разместил вопрос на форумах сообщества Dynamics CRM, на всякий случай community .dynamics.com / crm / f / 117 / t / 201151   -  person tsimbalar    schedule 30.05.2016
comment
вы смогли решить эту проблему?   -  person Alex Gordon    schedule 10.05.2017
comment
мы просто отказались от этого пути и в конечном итоге использовали устаревший Dynamics SDK вместо рекомендуемых веб-API ...   -  person tsimbalar    schedule 10.05.2017
comment
вы пробовали использовать IP вместо URL-адреса организации? вот что мы сделали, и это решило нашу проблему   -  person Alex Gordon    schedule 10.05.2017
comment
Я не пробовал, но, честно говоря, наш проект, связанный с Dynamics, теперь завершен, я сомневаюсь, что мы найдем время, чтобы исследовать эту проблему. Но спасибо за подсказку! :)   -  person tsimbalar    schedule 12.05.2017

Ответы (1)


arrow_upward
7
arrow_downward

Из этого ответа форума сообщества по динамике, похоже, что api довольно строго относится к параметрам и заголовкам, которые требуются. При выполнении запроса убедитесь, что у вас установлены заголовки Cache-Control: no-cache и Content-Type: application/x-www-form-urlencoded.

В последующем запросе на доступ к api с полученным токеном вы должны установить заголовок Authorization в форме Bearer: TOKEN (стоит отметить, поскольку многие люди действительно думали, что могут напрямую поместить токен), а также OData-Version: 4.0, Cache-Control: no-cache и Accept: application/json.

Рассматривая различные конечные точки OAuth и ранее связанный ответ, я Я не уверен, что URI авторизации правильный (например, https://login.windows.net), поэтому убедитесь, что он правильный. Также указано, что вы должны использовать URL-адрес конечной точки OAuth и использовать заголовок WWW-Authenticate, который возвращает действительный, даже если этот маршрут ответит 401. Я уверен, что вы уже видели этот пример, но он дает довольно полный обзор потока аутентификации и того, как получить токен с помощью AcquireTokenAsync, где вы передаете свой ресурс и clientID. Возможно, я просматриваю обновленную страницу, и это не имеет отношения к вашему случаю.

Вы также хотите проверить, является ли указанный вами идентификатор ресурса правильным, некоторые люди сообщили, что должны указать его в форме https://crm3.domain.org/ или https://crm4.domain.org/ вместо простого, так что это может быть одно.

Это также может быть проблема конфигурации, учитывая, что @l сказал о том, что IP-адрес будет работать вместо имени домена. Это вполне может быть проблема с сертификатом, когда он не прошел правильную проверку или не является надежным, что создает ошибку, которую вы видите, даже если это не соответствующее сообщение. Также убедитесь, что ваш 443 порт разрешен через ваш брандмауэр (-ы).

Один интересный post, в котором автор объясняет, что для продолжения ему требовалась Form Authentication настройка консоли управления AD FS (это CRM 2013, но все же может иметь отношение).

person Balthazar    schedule 16.05.2017