First, … well obviously… do as told: and update both the server (on windows 2012) with update 13 and the Exchange CRM plugin (on windows 2008). While web-centric interaction with ADFS (on windows 2012) worked with CRM out of the box, one needs updates to get further.
Then, configure IFD. In our case, the details are:
if we visit auth.rapmlsqa.:4430 we see ADFS present a form that challenges the user. Looking at the parameters and contrasting them with the earlier run for the internalCRM SP, we notice the difference in the wauth parameters:
We also note the change of realm.If one attempts to use what seems to interwork with ADFS from the internalCRM project, things fail – with constant failed (user) authentication messages (apparently). In reality, there is no “new” SP configuration at the ADS IDP yet. So add it! Per information here; modifying URLs suitably.
In our case it all becomes
Then add the ADFS claim rules, for UPN, PrimarySID, and Name (as for internal CRM SP). With this done, we can get a basic handshake by presenting our rapmlsqa\Administrator (and password) credentials (though this doesn’t yet make a successful landing on the webapp):
However if you use the “organizational” naming variant, things work (which makes SOME sense).
Now, to the active STS. We follow the formal support advice on how to upgrade the above so it works with v2.1 of ADFS (that built into Windows Server 2012, that is). This resolves those clients exception that complains about being unable to find the username binding (in the mex data that they cannot resolve, till the new mex address is configured):
Trying the SDK’s sample project didn’t work, with fiddler still showing that the proxy is going to the wrong mex address. SO, we iisreset – guessing the webapp (to now be reloaded) had cached the values.
Remember, NSA is spying on you. It’s a username binding, not kerberos.