Posts Tagged 'AD FS 2.0'

CRM 2011 and Claims Based Authentication with Internet Facing Deployment


So why am I writing this? Because even though there is information on this topic on the net, my findings were different to others. There were a number of annoying, time sapping, things that I had to work out for myself.
My intention was to set up the Claims Based Authentication (CBA) and Internet Facing Deployment (IFD) on a Virtual Server. To achieve this I have to deploy everything on one server as my laptop would struggle to run more than one server at a time.
Part of this information is about CBA and IFD directly, but mostly relates to CBA and IFD on the same server as CRM. This info will help those installing AD FS and CRM on the same server more.


InteractiveWebs great Blog; Microsoft CRM 2011 How to Configure IFD Hosted Setup;

Microsoft Tutorial configuring CBA and IFD (using 2 different Servers);

Install Enterprise Certificate Authority;

Edit – adding this link to a Microsoft White Paper;


Things I learned the hard way

Base Server

It was more effort than it was worth to try and configure an existing image to suit. There were simply too many configuration compatibility issues to resolve.

If your server has the default web site messed with, start a clean server install.

If configuring all services on one server, don’t try to make the CRM web site have the same SSL port as the AD FS 2.0 secure (default) site.

AD FS and configuring Relay Party Trusts is REALLY fussy about any URL bindings and/or certificate issues. Keep the 2 products apart as much as possible. IIS Port numbers is how these products stay apart.

SQL Server Reporting Services

By default SQL Server Reporting Services uses its own ‘pseudo web server’ application (for want of a better name) and it binds to port 80 and SSL port 443 by default on install. Use the SSRS configuration tool to undo the 443 binding. This is only an issue if you are putting AD FS 2.0 on the SQL server.

AD FS 2.0

Microsoft has built in a lengthy delay to the AD FS 2.0 service (adfssrv) starting. I read 2 minutes delay on a post somewhere. From what I read online (sorry, lost the reference) there are known issues with the service starting too early.


You need a perfect domain wild card certificate. You will waste hours trying to get bindings to work on specific (named) certificates. In the end AD FS and CRM won’t play nice. Certificate errors based on name will cause unresolvable problems.

To get a wild card certificate you must be (have access to) a Domain Root Certificate Authority. You must be an Enterprise Administrator to perform this task. You could purchase one easily enough but a wildcard Domain Certificate generated correctly works perfectly for this job. I am not sure on implications of connecting to the server externally and using self-generated domain certificates.


SPNs are critical for the URLs that connect these services. Make sure that you have all the SPNs assigned to the correct server/s for the DNS listings that you are using. You will get cryptic ‘do not have permission’ errors in the responding websites and think that the installations/configurations have failed.

The command line format that you need is not that difficult:

>Setspn –A http/ SERVERNAME

Add a line for CRM and AUTH as well. You do not need to provide SPNs for all the CRM organisations that you might host. SPNs are primarily for the communications between AD FS and CRM so that the services trust each other.

Command Line

IISreset is your friend. Use it often. MOST of the configurations below required an iisreset to display things correctly.


Keep checking the URLs for the FederationData URL’s and CRM. They should all keep working as you go. If they stop working, don’t go further until the issue is resolved.

Foundation Server

  • A clean Server install with Windows patches applied as you go. Ideally using different servers for each service (SQL Server, AD FS 2.0 and CRM).
  • IIS server role installed and untouched with a clean default web site.
  • SSRS using port 80 only. Preferably SQL server on another server.
  • If a development server, install the Active Directory Certificate Services as an ‘Enterprise Certificate Authority’.
  • Get all your DNS and AD user account records setup.
  • Create your wild card domain certificate and set it up with the correct permissions.
  • Set all the SPNs required for the various server names and services
  • IE Sec turned off for Domain Accounts. This actually resolves most of the settings in the next point.
  • Get IE settings correct from the beginning;
    • Add your domain to Trusted Sites (or Intranet if a single demo/dev server like mine)
    • Set ‘Automatically login with current username and password’ for that IE security zone.
    • Uncheck the IE Options > Advanced > Do not save encrypted pages to disk. This stops XML rendering in your browser, something that is critical to this process.
    • I found that you had to enable ‘Compatibility Mode’ to view the XML files in IE also. Not sure how critical this is and I suspect it too is part of IE SEC?
  • Leave AD FS 2.0 and CRM installation and configuring CBA and IFD as the last things to do, and really where my info below picks up.

The CBA and IFD process

The following is the process of installing and configuring. I really do not want to do a line by line entry like InteractiveWebs wonderful info.

Use the above with the Microsoft Tutorial YouTube clip.

I referred to both often to get everything completed. Most of the ‘how to’ detail for tasks described below is covered in InteractiveWebs blog if you scan through it. This info is a little more padding around their how-to.

The CRM Server install section can be performed before installing AD FS 2.0. I have ordered things this way to keep IIS as simple as possible.

Step 1 – Get the Best Start configuration sorted out.

  • AD Service Accounts for each of the CRM Services (4 of them);
    • CRM Application Service
    • CRM Asynchronous Service
    • CRM Deployment Web Service
    • CRM Sandbox Service
  • DNS records for all the communication that is going to happen;
    • (AD FS server based)
    • (CRM server based)
    • (CRM server based)
    • (CRM server based)
    • (CRM server based)
  • Create a wild card certificate for * (REALLY IMPORTANT; make the ‘Issued to’ AND ‘friendly name’ to be exactly * The Microsoft YouTube demo has a great section on what to do here.
  • Apply the permissions to read the certificate for
    • CRM Application Service domain user account
    • CRM Deployment Web Service domain user account

Step 2 – Install and setup AD FS 2.0

  • Install AD FS 2.0
  • Check the Application Pool identity and if not NETWORK SERVICE then change to that and restart IIS.
  • Do the initial configuration (not Relaying Party Trusts yet). You CAN set up the AD FS to specify Active Directory as a Claims Provider in the Claims Provider Trusts area.
  • Check that the XML returns to IE with the correct URL in the content;

Don’t go any further until you have the XML displaying perfectly in IE

Step 3 – Install CRM

We now leave the referenced tutorial information and get CRM installed in such a way as to make your life a lot easier configuring CBA and IFD. I am not going to cover detail on how to install Microsoft Dynamics CRM server or related products at this point, just note the bits that matter for the context of this article.

  • Create a new website in IIS. I called mine ‘CRMHolder’
    • Create (and point) the web site physical path to a folder in C:\inetpub\CRMHolder. Don’t worry about permissions or anything. The CRM install bypasses this. You can delete the CRMHolder folder (I know, it rhymes) after everything is working
    • Remove the http binding on port :80
    • Assign a https binding to port :444 (anything other than 443)
    • Add a host header called
    • Test Internet explorer can get to your new HTTPS  web site with NO certificate errors:
  • Go through and install CRM in your favourite way using the AD users for the service accounts etc.
  • Avoid making your first CRM organisation name ‘crm. This will get tangled in IIS and DNS and IFD. I used ‘CRMDefault’ for an organisation name as I like to have an out of the box install available for demos but anything that suits you would be fine.
  • Make sure that you select an existing web site and point the CRM install wizard to your ‘CRMHolder’ web site. Do NOT select the default web site.
  • Make sure that CRM is working on HTTPS:// (an internal URL).
  • If the above works and you have a working secure CRM server, you can delete the folder in inetpub called ‘CRMHolder’ (confirm that it is empty) and the IIS AppPool with the same name. The CRMHolder website will now be the Microsoft Dynamics CRM website and the web files will be in C:\Program Files\Microsoft Dynamics CRM\CRMWeb\
  • Install the CRM Server Reporting Extensions at the end as this is a good way to prove that SSRS is still working.
  • Delete the CRMHolder directory and Application Pool if you want to, they will not affect anything going forward.

Step 4 – Configure CRM for Claims Based Authentication

I found that this part goes quite smooth IF all the prerequisites have been fulfilled and proven ok.

  • Follow the tutorial information to configure CRM for claims based authentication. You HAVE to have the AD FS XML URL that we confirmed is working;

  • Also note the hint by IneractiveWebs to review the CRM CBA configuration log file and copy the last URL in there to somewhere handy. It will be pointing to the CRM Federation XML information.

Don’t go any further until you have the XML displaying perfectly in IE – from BOTH URLs

Step 5 – Configure the Relaying Party Trust in AD FS 2.0

Now follow the tutorial to configure the Relaying Party Trust rules. The information contained there is perfect and I did not do anything different.

At the end of this process you should be able to go to your internal CRM web site HTTPS:// and authenticate straight through without needing to enter a username or password. You should see (very briefly) the URL take the request and rapidly pass you through to CRM. The first login after restarting the server can take a while if you really want to see the effect but subsequent connections are really fast.

Step 6 – Configure CRM for Internet Facing Deployment

With CBA working seamlessly, we now configure CRM for Internet Facing Deployment. Overall the process is VERY similar to configuring CBA. The one part that I got really confused on and there was not much info out there, was the URLs to enter into the CRM IFD wizard.

  • Important, make sure that there are no host headers in the IIS Microsoft Dynamics CRM web site bindings. Leave the hostname blank and accepting requests on port 444 (or whatever port you set). This is important as it then means that your various CRM organisations will connect through and (more importantly) the Configuring Relaying Party Trusts will accept the external FederationData XML URL as unique.
  • Configure CRM for IFD (CRM Deployment Manager > etc…)
  • For the Domain Server Role URLs enter:
    • Web Application Server Domain: (CRM Org names get put in front of this)
    • Organization Web Service Domain: (CRM Org names get put in front of this)
    • Web Service Discovery Domain: (Has nothing to do with – and should avoid – CRM organisation names but must resolve to your CRM server in DNS)
  • The External Domain URL enter (set by default):
    • External Domain: (This resolves back to the CRM server in DNS and must NOT be:
      • The name of the Web Service Discovery Domain
      • The name of ANY CRM organisation you want to host
  • This URL is what is used for the final AD FS 2.0 relaying party trust FederationData XML information. The URL is not used publically. It cannot, under any circumstance, be ‘…. etc.xml’ as this is what was used for Claims Based Authentication Relaying Party Trust relationship with CRM. Otherwise AD FS will give this error:

“Error message: MSIS7612: Each party on relying trust must be unique across all relying party trusts in ADFS 2.0″

Step 7 – Configure the AD FS 2.0 IFD Relaying Party Trust

This process is exactly the same as CBA configuration other than you use the….XML URL for the FederationData information.

  • Ensure that the URL resolves and displays information from the FederationData XML URL. (Check those IIS CRM bindings – are gone – if you are getting no connection to the web site!)

Don’t go any further until you have the XML displaying perfectly in IE – from all 3 XML URLs

  • Configure the rules for IFD as per CBA and the tutorials
  • Don’t forget an IISreset after configuring AD FS.
  • Test connecting to CRM using the externally formatted URL like;
  • The Internal URL will still use AD FS to authenticate but will pass your credentials through immediately.
  • The External URL will prompt with a login screen like this:

  • Login with your domain account username and password as usual