CRM 2011 and Claims Based Authentication with Internet Facing Deployment

Introduction

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.

References:

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

http://www.interactivewebs.com/blog/index.php/server-tips/microsoft-crm-2011-how-to-configure-ifd-hosted-setup/

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

http://www.youtube.com/watch?v=ZD5qaa-G99E

Install Enterprise Certificate Authority;

http://aaronwalrath.wordpress.com/2010/04/16/install-an-enterprise-certificate-authority-in-windows-2008-r2/

Edit – adding this link to a Microsoft White Paper;

http://blogs.msdn.com/b/crm/archive/2014/02/14/white-paper-refresh-configure-ifd-for-crm-server.aspx

http://www.microsoft.com/en-us/download/details.aspx?id=41701

 

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.

Certificates

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

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/adfs.yourdomain.com 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.

Testing

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;
    • adfs.yourdomain.com (AD FS server based)
    • crm.yourdomain.com (CRM server based)
    • dev.yourdomain.com (CRM server based)
    • auth.yourdomain.com (CRM server based)
    • CRMorganisation.yourdomain.com (CRM server based)
  • Create a wild card certificate for *.yourdomain.com. (REALLY IMPORTANT; make the ‘Issued to’ AND ‘friendly name’ to be exactly *.yourdomin.com). The Microsoft YouTube demo has a great section on what to do here.
  • Apply the permissions to read the certificate for
    • NETWORK SERVICE
    • 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;

https://adfs.yourdomain.com/federationmetadata/2007-06/federationmetadata.xml

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 crm.yourdomain.com
    • 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://crm.yourdomin.com:444/Orgname/main.aspx (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;

https://adfs.yourdomain.com/federationmetadata/2007-06/federationmetadata.xml

  • 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.

https://crm.yourdomain.com:444/FederationMetadata/2007-06/FederationMetadata.xml

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://crm.yourdomin.com:444/Orgname/main.aspx and authenticate straight through without needing to enter a username or password. You should see (very briefly) the https://adfs.yourdomain.com 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 crm.yourdomain.com 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: yourdomain.com:444 (CRM Org names get put in front of this)
    • Organization Web Service Domain: yourdomain.com:444 (CRM Org names get put in front of this)
    • Web Service Discovery Domain: dev.yourdomain.com:444 (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: auth.yourdomain.com:444 (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 auth.yourdomain.com:444 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 ‘crm.yourdomain.com:444/federationdata…. 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 https://auth.yourdomain.com:444/FederationData….XML URL for the FederationData information.

  • Ensure that the URL resolves and displays information from the auth.yourdomain.com:444 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
Advertisements

17 Responses to “CRM 2011 and Claims Based Authentication with Internet Facing Deployment”


  1. 1 yessudhanshu September 10, 2012 at 10:22 pm

    very nicely explained few issue and challenges with precautions..
    thanks bro

  2. 2 Will Last November 25, 2012 at 2:25 am

    The IFD setup guide that you referenced at: http://www.interactivewebs.com/blog/index.php/server-tips/microsoft-crm-2011-how-to-configure-ifd-hosted-setup/

    is a terrifice place. Thanks for your tips

  3. 3 Alex January 23, 2013 at 2:34 am

    I have a question about this method of CRM authentication. I implemented CRM Claims and IFD with ADFS 2.0. Can I revert the configuration back and use CRM as it used to be before?

    • 4 Ian Luxton - CRM January 23, 2013 at 8:02 am

      Hi Alex, Yes this is easy enough to do. The CBA and IFD are managed through the CRM Deployment Manager and can be reverted to a ‘typical’ deployment through there. DNS records should be tidied also.

  4. 5 Craig Nakamoto March 27, 2013 at 4:29 am

    In this scenario, do you know if it is possible to allow logins from additional UPN suffixes? We have a multi-tenant environment and the UPN’s are user1@domain1.com, user2@domain1.com, user1@domain2.com, etc. and we want then to be able to log in to CRM using claims-based auth but using these usernames instead of domainname\user. We followed basically the same solution you have outlined and it all works, but we are not able to use the alternate UPN suffixes. Thanks! Craig

    • 6 Ian Luxton - CRM March 27, 2013 at 7:37 am

      Hi Craig, Glad to hear you got your IFD working! Sorry, I don’t know the answer to your question. This sounds more like ADFS functionality and supported authentication issue? If anyone else has delved into this please let us know. Here is a high level article on the architecture for a multi domain configuration:
      http://msdn.microsoft.com/en-us/library/hh699756.aspx
      Sorry I couldn’t provide more info.

      • 7 Craig Nakamoto March 28, 2013 at 5:24 am

        Thanks Ian, I think it is ADFS functionality as well. Unfortunately there is not much documentation out there to help me. I can find solutions for this problem that relate to Windows Azure and Office 365, but not for a self-hosted multi-tenant CRM environment.

  5. 8 Paul Ryan July 4, 2013 at 3:35 pm

    Hi Ian, thanks heaps for this article. Hey, i want to provide my customers with a CRM instance which utilises their own domain name. ie: crm.customer1.com crm.customer2.com etc.

    currently all URLs are: customer1.serviceprovider.com customer2.serviceprovider.com

    is there a way we can achieve this on a multi-tenanted environment?

    • 9 Ian Luxton - CRM July 17, 2013 at 8:38 am

      Hi Paul, Thanks for the good question. THis is a little beyond my scale of knowledge.

      It sounds like something ADFS has to sort out? CRM will not support the multiple domains but if you can work out the DNS and ADFS pass through it may work?

      Sorry I can’t be more helpful.

  6. 10 Erez David September 25, 2013 at 5:40 am

    Thanks. Greats post.
    I use yours and the following blog:
    http://dynamics.co.il/configuring-crm-2011-ifd/
    and it save me a lots of time and headache

  7. 11 shawn January 7, 2014 at 5:47 am

    the one head scratcher for me is, how does the external URL end up being https://name_of_the_org.domain.com? (in your case https://CRMDefault.yourdomain.com:444) I can not figure out how or why the Org name becomes the first part of the URL. I have worked through setting this up and successfully have gotten it working two times but still do not get that small part of it.

    • 12 Ian Luxton - CRM January 25, 2014 at 1:48 pm

      Hi Shawn, The URL changes with the IFD and CBA work that you are doing. The ADFS and CRM ‘conversion’ changes the URL string to suit external connectivity. Not sure on the exact technical reasons how. You will notice on any 3rd party hosted CRM service the URL string is org.domain.com (for example).

  8. 13 Javier February 7, 2014 at 11:39 pm

    Hi,
    Is it possible disconect form a IFD from CRM,
    I mean, once you get a service with user/pass OrganizatinService(CrmConnection) next later time i get the service with user/wrongpass the service is working. Note the pass is wrong.

    code Example
    var connectionString = string.Format(“Url={0}; Username={1}; Password={2};”, crmServerUrl, userName, password);

    var connection = CrmConnection.Parse(connectionString);

    service = new OrganizationService(connection);

    (the second time with the wrong pass works. )

    • 14 Ian Luxton - CRM February 8, 2014 at 12:08 pm

      Hi Javier, Sorry – I have no idea about this. If I understand your comment it sounds more like a bug in CRM? You might want to post your question to a Microsoft forum so a person that understands the issue has a chance to read it.

  9. 16 Abby October 18, 2016 at 7:13 pm

    This is my first time go to see at here and i am actually happy to read everthing at one
    place.


  1. 1 CRM 2011 - Pre-Install checklist for IFD/ ADFS setup - cRm Musings - Microsoft Dynamics CRM - Microsoft Dynamics Community Trackback on May 29, 2013 at 2:20 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: