401 when accessing Dynamics CRM 2016 Web APIs

Question

I am struggling to access the Dynamics 2016 CRM OData Web APIs from a console application.

We have Dynamics CRM 2016 installed, configured with Claims-based authentication, and using AD FS v3.0.

My understanding is that a console app (or web app) should be able to access the Web APIs using Windows integrated authentication (i.e. NTML or Kerberos) without any special treatment ... or maybe the OAuth flow should work when enabled.

For a regular user accessing Dynamics "pages", the authentication works fine (redirection to AD FS log in page), but accessing the OData APIs does not seem to work (for instance : https://crm.domain.org/api/discovery/v8.0/ ) :

• in a browser I get a Windows login prompt and typing valid credentials always results in a HTTP 401 unauthorized error
• in a brower, if I navigate to a Web API url after having logged on on the pages , then I can access the Web APIs (i.e. some cookies must be set and I am already implicitly authorized)
• from code, using an HttpClient with specific valid credentials (or current credentials) , I also get a 401

Things I have tried :

• if I disable Claims-based authentication completely , HttpClient works fine and I can access the OData APIs

• if I leave Claims-based authentication enabled, and activate OAuth via PowerShell Add-PSSnapin Microsoft.Crm.PowerShell ; $ClaimsSettings = Get-CrmSetting -SettingType OAuthClaimsSettings; $ClaimsSettings.Enabled = $true ; Set-CrmSetting -Setting $ClaimsSettings ;.

  Windows integrated authentication still does not work, but using Bearer authentication is now possible. I can use this snippet to retrieve the OAuth Endpoint for token generation, and use AuthenticationContext.AcquireTokenAsync to issue a token, and then pass it in the Authorization HTTP Header ... but then, no matter what, I get this 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/

Am I missing something ? is that possibly a configuration issue ?

Funicular

I've also posted the question on the Dynamics CRM Community Forums, just in case community.dynamics.com/crm/f/117/t/201151 – Funicular

have you been able to resolve this? – Taxicab

we just gave up on that path, and ended up using the "on its way to obsolescence" Dynamics SDK instead of the "recommended" Web APIs ... – Funicular

did you try to use the IP instead of the url of the org ? that's what we did and it solved ourissue – Taxicab

I haven't tried it but, to be fair, our project connected to Dynamics is now finished, I doubt we'll take the time to investigate around this issue. Thanks for the hint, though ! :) – Funicular

Answer 1

From this answer from the dynamics community forum, it looks like the api is pretty strict about the parameters and headers it requires. When doing the request, make sure you have the Cache-Control: no-cache and Content-Type: application/x-www-form-urlencoded headers set.

In the subsequent request to access the api with the retrieved token you should set the Authorization header in the form of Bearer: TOKEN (worth noting since a lot of people actually thought they could directly put the token), the OData-Version: 4.0, Cache-Control: no-cache and Accept: application/json ones too.

Looking at the different OAuth endpoints and the previously linked answer, I'm not sure the authorization uri is the right one (eg https://login.windows.net), so do you make sure that's correct. It's also stated that you should use the OAuth endpoint url and use the WWW-Authenticate header that returns the valid one, even if this route will respond with a 401. I'm sure you already saw this example, but it provides a pretty complete overview of an auth flow and how the token is retrieved using AcquireTokenAsync where you pass your resource and clientID. I might also be looking at an updated page and it's not relevant in your case.

You also want to check if the resource id you specified is the correct one, some people reported to have to specify one in the form of https://crm3.domain.org/ or https://crm4.domain.org/ instead of the bare one, so that could be one thing.

---

It could also be a configuration issue, given what @l said about the fact an IP would work instead of the domain name. It could very well be a certificate problem, where it's not validated correctly or untrusted, thus creating the error you see even if it's not the appropriate message. Also make sure your 443 port is allowed through your firewall(s).

One interesting post where the author explains that the Form Authentication setting of the AD FS Management Console was required for him to proceed (it's CRM 2013, but might still be related).

Advisement