401 beim Zugriff auf Dynamics CRM 2016 Web APIs

Question

Ich habe Schwierigkeiten, die Dynamics 2016 CRM OData Web APIs von einer Konsolenanwendung zugreifen.

Wir haben Dynamics CRM 2016 installiert, konfiguriert mit Ansprüche basierte Authentifizierung und unter Verwendung von AD FS v3.0.

Mein Verständnis ist, dass eine Konsolen-App (oder Web-App) auf die Web-APIs mit Windows integrierte Authentifizierung (dh NTML oder Kerberos) ohne besondere Behandlung zugreifen sollte ... oder vielleicht sollte der OAuth-Flow funktionieren, wenn aktiviert .

Für einen normalen Benutzer Zugriff auf Dynamics „Seiten“, funktioniert die Authentifizierung in Ordnung (Umleitung auf AD FS Login-Seite), aber den OData-APIs zugreifen scheint nicht (zum Beispiel: https://crm.domain.org/api/discovery/v8.0/): arbeiten

• in einem Browser erhalte ich eine Anmeldeaufforderung von Windows und die Eingabe einer gültigen Berechtigungsnachweis immer zu einer HTTP 401 nicht autorisierte Fehler
• in einem brower, wenn ich auf eine Web-API-uRL nach haben angemeldet auf den Seiten navigieren, dann kann ich Zugriff auf die Web APIs (dh einige Cookies müssen gesetzt sein und ich bin bereits implizit autorisiert)
• von Code, ein Httpclient mit spezifischen gültigen Anmeldeinformationen (oder aktuellen Anmeldeinformationen) verwendet wird, ich auch

Things 401 bekommen habe ich versucht:

• wenn ich Ansprüche basierte Authentifizierung vollständig deaktivieren , Httpclient funktioniert gut und ich kann die OData APIs

• zugreifen, wenn ich Ansprüche basierte Authentifizierung aktiviert, verlassen und aktivieren OAuth über Powershell Add-PSSnapin Microsoft.Crm.PowerShell ; $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings; $ClaimsSettings.Enabled = $true ; Set-CrmSetting -Setting $ClaimsSettings ;.

  Windows integrierte Authentifizierung funktioniert immer noch nicht, aber die Bearer-Authentifizierung ist jetzt möglich. Ich kann this snippet verwenden, um die OAuth Endpoint für Token Generation abzurufen, und verwenden Sie AuthenticationContext.AcquireTokenAsync ein Token auszustellen, und es dann in der Authorization HTTP Header passieren ... aber dann, egal was passiert, bekomme ich diesen Fehler:

  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/

Fehle ich etwas? ist das möglicherweise ein Konfigurationsproblem?

Answer 1

Von this answer aus dem Dynamics Community Forum sieht es aus wie die API ist ziemlich streng über die Parameter und Header, die es erfordert. Stellen Sie bei der Anforderung sicher, dass die Header Cache-Control: no-cache und Content-Type: application/x-www-form-urlencoded festgelegt sind.

In der anschließenden Anfrage die api mit dem abgerufenen Token zuzugreifen, die Sie in Form von Bearer: TOKEN die Authorization Header gesetzt sollte (erwähnenswert, da tatsächlich eine Menge Leute dachten, sie direkt das Token setzen könnte), die OData-Version: 4.0, Cache-Control: no-cache und Accept: application/json auch.

Mit Blick auf die verschiedenen OAuth endpoints und die zuvor verknüpfte Antwort, bin ich nicht sicher, die Autorisierung uri ist die richtige (zB https://login.windows.net), also stellen Sie sicher, dass das korrekt ist. Es wird auch gesagt, dass Sie die OAuth-Endpunkt-URL verwenden und die WWW-Authenticate -Header verwenden sollten, die die gültige zurückgibt, auch wenn diese Route mit einem 401 antwortet. Ich bin sicher, Sie haben bereits gesehen this example, aber es bietet einen ziemlich vollständigen Überblick über eine Auth Flow und wie das Token abgerufen wird mit AcquireTokenAsync, wo Sie Ihre Ressource und ClientID übergeben. Möglicherweise sehe ich auch eine aktualisierte Seite, die in Ihrem Fall nicht relevant ist.

Sie möchten auch überprüfen, ob die von Ihnen angegebene Ressourcen-ID die richtige ist, einige Leute müssen eine in Form von https://crm3.domain.org/ oder https://crm4.domain.org/ statt der nackten angeben, so dass eine Sache sein könnte.

Es könnte auch ein Konfigurationsproblem sein, wenn man bedenkt, was @l über die Tatsache sagte, dass eine IP anstelle des Domainnamens funktionieren würde. Es könnte durchaus ein Zertifikatsproblem sein, bei dem es nicht korrekt oder nicht vertrauenswürdig validiert wird, wodurch der angezeigte Fehler erzeugt wird, selbst wenn es nicht die richtige Nachricht ist. Stellen Sie außerdem sicher, dass Ihr Port 443 durch Ihre Firewall (s) erlaubt ist.

Eine interessante post wo der Autor erklärt, dass die Form Authentication Einstellung der AD FS Management Console für ihn erforderlich war (es ist CRM 2013, aber möglicherweise immer noch verwandt).