Configuring CRM Claims Based Authentication with User Certificates

Microsoft Dynamics CRM 2011 supports claims-based authentication in both internal and Internet-facing deployments. Claims-based authentication leverages Active Directory Federated Services (ADFS) to enable Single Sign-On (SSO) and allows you to establish complex trust relationships between other domains and organizations.

One of the issues with enabling claims-based authentication on CRM, or with any relying party that passes a wsignin1.0 request to your Security Token Service (STS) with the optional ‘wauth’ parameter, is that it specifies a specific method for authenticating the user. For CRM, this is fine if you want to authenticate your internal users with Windows authentication, and your external users with Forms based authentication, but if you want to use some other mode, you are stuck. You can configure and reconfigure the default settings for ADFS all day and night, but as long as the relying party is sending its request with ‘wauth’ in the URL, ADFS will ignore your default settings.

Of course, I refused to believe this, so I reconfigured my ADFS server to prefer to authenticate users with a certificate, and then tried to connect to CRM. Of course, the system attempts a Windows Integrated-style authentication anyway, displaying a dialog box prompting me for my user name and password. I typed it in, and was able to access CRM, but it wasn’t until I clicked “Log Off” in the CRM interface and was redirected to the “You have been signed off.” ADFS page that I was prompted for my certificate!

Changing 'wauth' in the CRM Configuration Database

So, how can we get around this?  We need to get CRM to set that‘wauth’ parameter correctly to tell ADFS that we want to authenticate the user with a certificate. A little research revealed that this is possible with CRM, though likely unsupported; so take the following advice totally at your own risk:

Open up SQL Management Studio and connect to the CRM configuration database “MSCRM_CONFIG”. Let’s take a look at the current state of the federation provider settings by running a quick query:

SELECT * FROM dbo.FederationProviderProperties

The results should show a few rows, the ones we’re interested in are the one with the “ColumnName” as “IntegratedAuthenticationMethod” and “IfdAuthenticationMethod”. If you take a look at the “NVarCharColumn”, *ahem*, column, for those two values, you should see the default entries of “urn:federation:authentication:windows” and “urn:oasis:names:tc:SAML:1.0:am:password”, respectively. I’m not sure who was responsible for the names in this schema, but I promise you it wasn’t me.

These values are used by CRM to build the URL passed to the STS when an authentication request is made. Assuming that you have claims-based authentication working and configured, go ahead and update the “IntegratedAuthenticationMethod”to tell the STS that we would like a certificate-based authentication method:

UPDATE dbo.FederationProviderProperties
SET NVarCharColumn=’urn:ietf:rfc:2246’
WHERE ColumnName=’IntegratedAuthenticationMethod’

Here, “urn:ietf:rfc:2246” is what specifies SSL/TLS Certificate Based Client Authentication. A list of some of the authentication methods defined in the SAML specification can be found here. I haven't experimented with anything other than the certificate based authentication method.

As it turns out, since we are authenticating using a user certificate that is associated with an Active Directory account, we don’t have to make any changes to the claims rules in our ADFS configuration.  So, open up a command window, do an “iisreset” and try and connect to your CRM server again. Your browser should now prompt you to present a certificate to the server, and if you’ve already generated a user certificate that corresponds to an Active Directory account that is associated with CRM (you have, haven’t you?) then you can select and submit it. You should be now be logged onto CRM using claims-based authentication with a certificate-based authentication method!

Other Thoughts

Going into the CRM database and making this change is certainly unsupported by Microsoft, but I have tested this successfully on both Internet Explorer and Firefox with a user certificate and have had no problems. To be honest with you, I’m as surprised as you are that it still works after making this change. My next step will be to see if I can get SharePoint to work using the same authentication method and demonstrate a working SSO environment.

I also am left wondering if it still makes sense to go through the trouble of configuring CRM for a full-blown Internet Facing Deployment when using this method. The main purpose of an IFD is to provide the forms-based login page, since a Windows integrated login doesn't make sense over the Internet. If you are using certificates for authentication both internally and externally, it makes sense that you can use the claims-based authentication with certificates to handle both scenarios.