Tuomas Kesti

Dynamics 365 on-premise claims-based authentication configuration issue of not recognizing the federation metadata

/in /by

The other day I was configuring one of our Dynamics 365 on-premise environments for claims-based authentication and IFD when I ran into an issue which I had not seen before. This blog post is about telling you the details about that issue and how to resolve it.

So, I had all the basic stuff configured the same way which I have done those for other environments at least a million times before. This includes:

  • Installation and configuration of Windows virtual servers on Azure
  • Configuration of Azure private network for these VM’s
  • Configuration of domain controllers and lifting the other VM’s to this domain
  • Patching all these VM’s
  • Basic installation of Dynamics 365 and patching it with the latest and greatest
  • Adding the needed DNS entries
  • Testing that CRM works well using Windows authentication
  • Installation of standalone ADFS service for this domain
  • Purchasing wildcard SSL certificate to be used for both CRM and ADFS services
  • Setting the certificate to IIS binding of CRM
  • Setting the proper privileges to the certificate for the CRM app pool ID
  • Setting the CRM to use https endpoint for its services on the deployment manager console

Pretty much everything was setup and all should have been running smoothly. The only thing missing was to run the claims based authentication and IFD wizards from the CRM deployment manager and off we go in publishing this CRM service out for the whole world to enjoy. Then I ran into this:

 

The error is something which I had not seen before: “federation metadata URL is not available”. What do you mean it is not available? I had just tried to access the very same URL using the browser on the same machine with the same credentials without any issues. Furthermore, ADFS endpoints were checked to have the same ones enabled that I always do for CRM. Firewall had the needed ports open. I had done the iisreset, restart of ADFS and CRM async services. Restart of the VM. Nothing helped.

Then I tried to save the federation metadata as XML file locally from browser and add the file for the CRM claims based authentication wizard. You don’t necessarily have to add it using a URL but you can do it as a file reference as well. Naturally it is not the most dynamic solution of the world but does the needful for testing this. And voilà, the EDW showed all green in CRM claims based authentication wizard.

It must be something in terms of accessing the URL. That’s what the error message says. And as always, error messages show the truth that is out there, right? Well, almost.

Next thing that I thought to check were the SSL bindings. Using the good old netsh command, I checked that all the proper bindings were set to the proper SSL certificate. But then what could be blocking the access to the URL? Until after hours and hours of banging my head to the firewall it cleared to me. Those guys in the network team. They had ranted about disabling the unnecessary TLS and SSL versions of these VM’s for security reasons. So, I fired one of my dearest friends, iiscrypto.exe, up and running and tried to enable the TLS 1.0 and 1.1 as well as SSLv3 for testing purposes. Reboot the server and tried running the CRM claims based authentication wizard again. This time using the URL as the federation metadata, not the XML file. End result on the EDW: all green and ready to rock.

Summary: it seems that for some reason, while configuring the CRM claims based authentication using the deployment manager wizard, the older TLS versions and SSLv3 are needed. After running the configuration and doing the rest of the stuff for IFD, I disabled these bad boys again. And it seems that CRM is still working as perfectly as a toilet in the Finnish night train going from Helsinki to Kolari.

Read more: