401 при доступе к веб-интерфейсам Dynamics CRM 2016

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

У нас установлена Dynamics CRM 2016, настроена с проверкой подлинности на основе утверждений и с использованием AD FS версии 3.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 ODatali >
если я отключу проверку подлинности на основе утверждений, а активировать 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/

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

Ответ 1

От этот ответ от форума сообщества динамиков, похоже, что 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, где вы передаете свой ресурс и идентификатор клиента. Я также мог бы просмотреть обновленную страницу, и это не относится к вашему делу.

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

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

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