CRM & ADFS woes (the connector story)

So I have been doing some ADFS 3.0 work as of late. Part of this work included getting CRM 2016 to use ADFS for authentication instead of the normal AD (IWA) approach. Getting the user side of it set up is not that hard, and there are many good sources for correct information. Now it turns out CRM has some hidden integration complexity. Though not directly from CRM itself, but the Connector for Microsoft Dynamics (which has not changed since CRM 2011). This was making a stink and would not connect to ADFS. At the time I did not know that the error was caused by the connector not being able to talk to ADFS server because of a firewall issue, so I wrongfully assumed that the error had something to do with ADFS configuration. This analysis was done on internal federation configuration and not using IDF (published external using ADFS Proxy), i.e using the Intranet configuration for the CRM RP with Windows Authentication only active.

Example of connector error:

So let’s break down the information that is out there on the big wide web. The first suggestion one will find a lot of post from CRM experts on, is to enable the adfs/services/trust/13/username endpoint on ADFS to make the connector work. Mostly the reason I think this is so prevalent, is that the error message the connector spews out says in plain text that is cannot reach http://adfs.mydomain.com/adfs/services/trust/13/username. So most wrongfully assumes that this endpoint must be activated. So here is the thing, with ADFS 3.0 at least, the default configuration has some other endpoint active, that will conflict with the username one. These are usernamemixed and  kerberosmixed. You can check what is active in the endpoints part of the ADFS admin util, and you can open the MEX document and see what endpoints are advertised.

Just open https://adfs.mydomain.com/adfs/services/trust/mex in a browser and look for http://adfs.mydomain.com/adfs/services/trust/13/username, https://adfs.mydomain.com/adfs/services/trust/13/usernamemixed,
https://adfs.mydomain.com/adfs/services/trust/13/kerberosmixed. Note in the default configuration only the 2 last are active. Also the big difference between these are that username is published using HTTP and others are on HTTPS. So the morale of the story is that if you absolutely need username, you will most likely need to deactivate the two others. Though in the case of the connector this is NOT needed. The default configuration for ADFS is enough to get the connector to work. The reason most likely for the username URL being in the connector error message is because it is the last in the list it tries. As long as the kerberosmixed is working this should be the first one the connector will try.
You can kind of check that it is working by browsing the URL in a browser. If you do not get 503 or a could not display error message, it is a good indication that the endpoint is operating, and that you can reach it. If there still are problems connecting I would look for at firewall, routing and access rights for the user running the connector.

The other most prevalent suggestion going hand in hand with the endpoint activation suggestion, is to change the Federation Service Identifier from HTTP to HTTPS. First of all, just don’t. This is an URI (read up on it) and not an URL, so changing this for getting the connector to work just don’t make sense. Though some places on the web swears that this is the magic bullet to solve your woes. No it is not… do not be tempted by the dark side here.

The other CRM related problem I have seen is compiling a client for use with a XRMService. As with the connector if there are some connection problems against ADFS you will get a similar error.

An example of this:

You also see the error contains reference to the username endpoint. This is in this case also a red herring, and will send you looking in all the wrong places.

The first thing I would do is to look at the compile command line, and see if you are running CRMSVCUTIL with switches that can generate this error.

If you are doing something like this:

Do this instead:

No seriously it’s not ADFS’s fault, trust me!