HOW TO: Configuring MSCRM 2011 IFD Externally and Internally for a Single Virtual Environment
Recently I have had to configure a virtual environment for IFD to test a MSCRM 2011 solution I have developed. The solution had to work on the internal domain as well as externally. Below I have listed the steps I went through to get IFD working internally and externally on the same machine. Please note that these steps worked for me and my scenario/setup. They may help as a guide for your deployment. This guide expects you to have some knowledge around DNS, Certificate Management, Internet Information Services and Microsoft Dynamics CRM.
Setup
My basic setup in IIS is that the default web site is on port 80 and MSCRM is installed on a seperate web site on port 5555.
The IP Address of my virtual environment is 10.188.11.75
IP Addresses, Domains, and Certificates
MSCRM 2011 IFD requires that a certificate is bound to the MSCRM web site in IIS. As we are setting up an internal and external link we require a domain and sub domain. This means that we require 2 certificates to be created against one web site (MSCRM Web Site). In order to achieve this we need 2 IP Addresses. To achieve all of this follow the directions below.
- Access your current network card settings and create a new IP address against it.
- Create a new DNS forward lookup zone. eg ccxdevserver.com.
- Within ccxdevserver.com create a new sub domain. eg ifd.
- Using SelfSSL generate two wildcard certificates. eg *.ccxdevserver.com, *.ifd.ccxdevserver.com. SelfSSL can be downloaded here.
- If SelfSSL installed the generated certificates on to the default web site remove the bindings.
- Add the certificates to Trusted Root Certification Authorities. This can be achieved from Microsoft Management Console (MMC) by using the Certificate snap in.
- Add the certificates to Personal Certificates. For each cerficate go to all tasks and manage private keys to give the CrmAppPool user read permission on the certificates
- Add 2 https bindings on to the MSCRM website, one for *.ccxdevserver.com and the other for *.ifd.ccxdevserver.com. Make sure that these bindings are specified on two separate IPs. One for internal (10.188.11.75) and one for external (10.188.11.76). Also make sure that they are on a different SSL port than 443. This is because Active Directory Federation Service will be setup on 443.
- We now need to add some DNS host headers. Doing so will make sure things are pointing in the correct places for internal and external IFD. In ccxdevserver.com add AAAA for adfs.ccxdevserver.com that points to 10.188.11.75. Also add AAAA for internalcrm.ccxdevserver.com that points to 10.188.11.75. In ifd.ccxdevserver.com add AAA for auth.ifd.ccxdevserver.com, dev.ifd.ccxdevserver.com and finally one for your organisation name. In my case this is microsoftdynamicscrm.ifd.ccxdevserver.com. All of these entries are for external ifd so they point to 10.188.11.76.
- Finally make sure that your certificates that are installed in the Personal folder have their security settings configured for the AD User of the application pool that CRM is running Under. Typically this is NETWORK SERVICES. This user needs to have Read Access. You can get to the security settings by choosing to manage the private key of the certificate.
Now that should be the network configured. ADFS 2.0 should now be installed.
Active Directory Federation Service 2.0
In this tutorial I am not going to mention what ADFS is. All we need to know is that we need to install and configure it for claims based authentication.
- Download ADFS 2.0 here and start the installation process. Make sure that it installed as a stand alone server and NOT a server farm. Allow ADFS to update its self and install its configuration database.
- Once installed start up ADFS and start the Active Directory Federation Service configuration wizard.
- Set ADFS as a stand alone server.
- Choose your wildcard certificate, NOT THE IFD ONE, eg *.ccxdevserver.com. Set a header of adfs.
- Note down the metadata url then Complete the installation.
- Paste the metadata URL in to explorer to validate that you get the correct XML returned back. The XML will be labelled as adfs.ccxdevserver.com. EG the URL for ccxdevserver will be. https://adfs.ccxdevserver.com/federationmetadata/2007-06/federationmetadata.xml
- While still in ADFS 2.0 select certificates (Service -> Certificates) from the tree view and export the token signing certificate.
- Now Import the exported certificate in to “Trusted Root Certificate Authorities” and “Trusted People”.
With ADFS Installed, CRM now needs to be configured for Claims based authentication.
Configure CRM for Claims Based Authentication
- Open up CRM’s Deployment Manager and click on properties for Microsoft Dynamics CRM.
- Under the Web Address tab turn on HTTPS and enter the correct address for the internal crm. Eg internalcrm.ccxdevserver.com:444.
- While still in the Deployment Manager click on Configure Claims Based Authentication.
- Enter the adfs metadata xml url eg https://adfs.ccxdevserver.com/federationmetadata/2007-06/federationmetadata.xml.
- Select the certificate we are using. eg *ccxdevserver.com
- Finish the wizard and now CRM knows about the ADFS services.
- Note down the internalcrm metadata URL. This will be required to tell ADFS about internal CRM.
Configure ADFS for Internal Claims Based Authentication
- In ADFS click Claims Provider Trust. Select Active Directory. Right click and click Edit Claims Rules.
- Add a new claims rule as “Send LDAP Attribute as Claim”.
- Select Active Directory for the store. Select User-Principle-Name for LDAP and UPN for the outgoing type.
- Save the rule.
- Create a new Relay Party Trust.
- Enter the internal metadata url eg https://internalcrm.ccxdevserver.com:444/federationmetadata/2007-06/federationmetadata.xml.
- Name it internal.
- Now create 3 new rules, pass through or filter an incoming claim rules for UPN and Primary SID, and one Transform an incoming claim rule for Windows Account Name to Name.
- Finally Reset IIS.
At this point you should be able to browse to CRM internally through IFD by using the internal URL that has been setup. eg internalcrm.ccxdevserver.com:444. You should not be asked for authentication details. If you get asked make sure that your domain is in your trusted intranet sites for Internet Explorer.
Setting Up Internet Facing Deployment
- In the Deployment Manager click Configure Internet Facing Deployment.
- Configure the web address but this time using the sub domain certificate. eg *ifd.ccxdevserver.com. Make sure that the discovery service has its own sub domain.
- Accept the auth end point.
- CRM is now configured for Internet deployment. Now we need to inform ADFS about this.
Configure ADFS for External Claims Based Authentication
- In ADFS create a new Relay Party Trust.
- Call it External.
- Enter the auth metadata end point. eg https://auth.ifd.ccxdevserver.com:444/federationmetadata/2007-06/federationmetadata.xml.
- Now create the same pass through and transform as the internal configuration.
Using the external URL you should be able to log in to CRM. If you enter the external URL you will be directed to a login form where you can enter your credentials. Once done you will be directed to CRM. eg https://microsoftdynamicscrm.ifd.ccxdevserver.com:444/ will direct a user to the MicrosoftDynamicsCRM organisation in CRM.
I hope that you found this guide useful.
6 Comments
Leave a comment
You must be logged in to post a comment.
Keep blogging. Anyway, thank you and I anticipate posting once again sometime!
You do realize that you are running an unsupported configuration by binding the https protocol to more than one ip?
This was a solution that I got working for my development environment to test my products over IFD. So everything is basically on the same box. I’m not saying its the right way to do it, just a method that worked for me.
You have really interesting blog, keep up posting such informative posts!
Thx for this great information that you are sharing with us!!!
Fantastic. Now to go away and test this