Monday, 26 May 2014

Configure Claim Based authentication in Ms Dynamics CRM 2013 using ADFS 3.0 ( Windows Server 2012 R2) part 1

I decided to set up a dev environment on my shiny new laptop for those rare occasions when I'm on the road without access to the office servers.

I thought it would be a breeze but there are a few gotchas, so I thought I would document the process here. On part 1 I describe how to install and test ADFS on Windows 2012 R2 and in part 2, I describe how to configure Ms Dynamics CRM 2013 to use claim based authentication.

Pre-Requisites:
  • A working installation of MS Dynamics CRM 2013.
  • A wildcard certificate with private key.
  • A separate server for ADFS.
  • A domain account with domain administrator privileges.
  • Host (A) Record on DNS Server for Federation Server Name.
If you don't have a wildcard certificate, the simplest way to generate one is by using IIS Manager, see this for details.

It is possible to host ADFS on the same server as Dynamics and since ADFS doesn't use IIS anymore (I think, I'm not 100% sure on this), there are no requirements for ADFS to be on the default site, however, you will need to have different host headers for ADFS and MS Dynamics CRM 2013.

Installing ADFS is really simple, just run a PowerShell console with elevated permissions (i.e. Run as Administrator) then run the following commands:
Import-Module ServerManager

Add-WindowsFeature -Name ADFS-Federation

You should see something like this:


I will configure it through the GUI rather than with the PowerShell command as it should make a few things clearer.

On the Server Manager Dashboard click on Notifications and then on configure the federation service on this server.
This will bring up the ADFS Configuration Wizard.


Accept the default and click Next.


If the account you are logged in to the server with has the correct privileges then click Next, otherwise change the account and press Next.


If the wildcard certificate is already installed then there is no need to import it, just selected from the drop down menu.

It's worth stressing here that the Federation Service Name MUST be different from the FQDN of the server. The reason for this is that the following SPN will be set against the service account:
host/Federation Service Name 
In my example it will be:
host/sts1.taleb.local
If this is the same as the FQDN of the server, this SPN will not be set as it's already set against the server account and ADFS will not work correctly.

As I said on the pre-reqs, an A Record is needed for this name in your DNS Server.



Select the Service Account and Click Next.


Accept the default and click Next.


I've skipped the Confirm Overwrite step as I've had to do it agains to take the screenshots. Anyway, at this point you can see the script that can be use to reproduce the GUI installation.


Click Configure and after a short while, you should then see this screen:


Time to ensure that ADFS is working correctly.





 On clicking Sign In, you'll get a prompt like this:

And now you've signed in to ADFS :)

This part has mostly concentrated on ADFS, in part 2 I discuss how to configure Ms Dynamics CRM 2013 for claims based authentication.

1 comment:

  1. Great post i was looking for this information on https://infosecaddicts.com which is here. thanks so much for this post.

    ReplyDelete