oauth http-status-code-401 dynamics-crm-2016 adfs3.0

oauth - 401 al acceder a las API web de Dynamics CRM 2016



http-status-code-401 dynamics-crm-2016 (1)

Estoy luchando para acceder a las API web OData Web de Dynamics 2016 CRM desde una aplicación de consola.

Tenemos instalado Dynamics CRM 2016 , configurado con autenticación basada en notificaciones y utilizando AD FS v3.0.

Según tengo entendido, una aplicación de consola (o aplicación web) debería poder acceder a las API web mediante la autenticación integrada de Windows (es decir, NTML o Kerberos) sin ningún tratamiento especial ... o quizás el flujo de OAuth debería funcionar cuando está habilitado.

Para un usuario normal que accede a las "páginas" de Dynamics, la autenticación funciona bien (la redirección a la página de inicio de sesión de AD FS), pero el acceso a las API de OData no parece funcionar (por ejemplo: https://crm.domain.org/api/discovery/v8.0/ ):

  • en un navegador, obtengo una solicitud de inicio de sesión de Windows y al escribir credenciales válidas siempre se produce un error no autorizado HTTP 401
  • en un navegador, si navego a una URL de la API web después de haber iniciado sesión en las páginas, entonces puedo acceder a las API web (es decir, se deben configurar algunas cookies y ya estoy implícitamente autorizado)
  • Del código, usando un HttpClient con credenciales específicas válidas (o credenciales actuales), también obtengo un 401

Cosas que he probado:

  • Si deshabilito completamente la autenticación basada en notificaciones, HttpClient funciona bien y puedo acceder a las API de OData

  • si dejo habilitada la autenticación basada en Reclamaciones y activo OAuth a través de PowerShell Add-PSSnapin Microsoft.Crm.PowerShell ; $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings; $ClaimsSettings.Enabled = $true ; Set-CrmSetting -Setting $ClaimsSettings ; Add-PSSnapin Microsoft.Crm.PowerShell ; $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings; $ClaimsSettings.Enabled = $true ; Set-CrmSetting -Setting $ClaimsSettings ; .

    La autenticación integrada de Windows todavía no funciona, pero ahora es posible usar la autenticación de portador. Puedo usar este fragmento de código para recuperar el punto final de OAuth para la generación de tokens, y usar AuthenticationContext.AcquireTokenAsync para emitir un token, y luego pasarlo en el Encabezado HTTP de Authorization ... pero luego, pase lo que pase, recibo este error:

    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/

Me estoy perdiendo de algo ? ¿Es eso posiblemente un problema de configuración?

A partir de esta respuesta del foro de la comunidad de dinámicas, parece que la API es bastante estricta con los parámetros y los encabezados que requiere. Al realizar la solicitud, asegúrese de tener establecidos los encabezados Cache-Control: no-cache y Content-Type: application/x-www-form-urlencoded .

En la solicitud posterior para acceder a la api con el token recuperado, debe establecer el encabezado de Authorization en la forma de Bearer: TOKEN (vale la pena señalar, ya que muchas personas pensaron que podían colocar el token directamente), la OData-Version: 4.0 , Cache-Control: no-cache y Accept: application/json también.

Mirando los diferentes endpoints OAuth y la respuesta vinculada anteriormente, no estoy seguro de que el uri de autorización sea el correcto (por ejemplo, https://login.windows.net ), así que asegúrese de que sea correcto. También se indica que debe usar la url de punto final de OAuth y el encabezado WWW-Authenticate que devuelve el válido, incluso si esta ruta responde con un 401. Estoy seguro de que ya vio este ejemplo , pero proporciona un resumen bastante completo. descripción general de un flujo de autenticación y cómo se recupera el token utilizando AcquireTokenAsync donde pasa su recurso y su ID de cliente. También podría estar viendo una página actualizada y no es relevante en su caso.

También desea verificar si el ID de recurso que especificó es el correcto, algunas personas informaron que deben especificar uno en la forma de https://crm3.domain.org/ o https://crm4.domain.org/ del desnudo, así que eso podría ser una cosa.

También podría ser un problema de configuración, dado lo que dijo @l sobre el hecho de que una IP funcionaría en lugar del nombre de dominio. Muy bien podría ser un problema de certificado, donde no se valida correctamente o no es de confianza, por lo que se crea el error que se ve incluso si no es el mensaje adecuado. También asegúrese de que su puerto 443 esté permitido a través de su (s) servidor (es) de seguridad.

Una post interesante en la que el autor explica que la configuración de Form Authentication de la Consola de administración de AD FS fue necesaria para que él procediera (es CRM 2013, pero aún podría estar relacionado).