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

Question

Я пытаюсь получить доступ к API-интерфейсам API OData Dynamics 2016 из консольного приложения.

Мы Dynamics CRM 2016 установлен, настроен претензий на основе аутентификации, и с помощью AD FS v3.0.

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

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

• в браузере я получаю приглашение для входа в Windows, и вводить действительные учетные данные всегда привожу к HTTP 401 несанкционированных ошибок
• в Брауэре, если перейти к Web API URL после того входом в системе на страницах, то я могу доступ к веб-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 по-прежнему не работает, но теперь возможно использование аутентификации на предъявителя. Я могу использовать this snippet для получения OAuth конечной точки для маркеров поколения, и использовать AuthenticationContext.AcquireTokenAsync выдать маркер, а затем передать его в Authorization HTTP Header ... но, несмотря ни на что, я получаю эту ошибку:

  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/

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

Answer 1

От this answer от форума сообщества динамиков, похоже, что 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 endpoints и ранее связанный ответ, я не уверен, что авторизация uri является правильной (например, https://login.windows.net), поэтому вы убедитесь, что это правильно. Также указано, что вы должны использовать URL-адрес конечной точки OAuth и использовать заголовок WWW-Authenticate, который возвращает действительный, даже если этот маршрут ответит 401. Я уверен, что вы уже видели this example, но он дает довольно полный обзор auth и как извлекается токен с использованием AcquireTokenAsync, где вы передаете свой ресурс и идентификатор клиента. Я также мог бы просмотреть обновленную страницу, и это не имеет отношения к вашему делу.

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

---

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

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