Dynamics CRM Technical Tip – URL Rewrite for IFD Internet Facing Deployment

At Ledgeview Partners, we see many different technical configurations at our customers’ sites, each one requiring some tweaks here or there.  One of the more confusing elements of a CRM 2011 IFD configuration is the distinction between “internal” and “external” URLs used by CRM and ADFS, and the different way these URLs authenticate users.  For those of you out there supporting all of these configurations, I thought I would pass along a little tip.

In an IFD deployment, ADFS uses claims-based authentication for users accessing CRM from outside the corporate firewall, and Windows Authentication for users accessing CRM from inside the corporate network.  The IFD configuration requires you to assign unique URLs to each authentication scenario.  Microsoft’s best-practice recommendation is for internal users to access CRM with the internal URL so they can automatically pass their domain credentials to ADFS via Windows Authentication, and for external users to access CRM with the external URL where they enter their credentials for ADFS via a claims-based authentication form. 

The problem with this model is that many CRM users have laptops and work both inside and outside the corporate network, which requires them to either switch between URLs depending on their location, or always use the external URL, thus losing the ability to automatically pass their domain credentials via Windows Authentication when working inside the corporate network.

As a workaround, you can implement the URL Rewrite 2.0 module for IIS 7.x on your ADFS server and configure it to detect whether a caller using the external URL is on the internal network, and if so, force Windows Authentication for that user.  This way, ALL users can use the external URL to access CRM, reducing confusion and taking advantage of Windows Authentication when it is available.  Here are the steps to install and setup URL Rewrite:

  • Logon to the ADFS server as a domain admin.
  • Install the URL Rewrite V.20 module from the IIS website: http://www.iis.net/download/urlrewrite.  Click “Install using the Microsoft Web Platform Installer” and follow the instructions to complete the install.
  • Open a command prompt, type IISRESET and hit enter.
  • Launch Notepad with “Run as administrator,” browse to C:\inetpub\wwwroot\ and create a file named web.config.
  • Add the following code to the file and save it.  NOTE: For the REMOTE ADDR value, the pattern is a regular expression that defines an IP address or range of addresses.  In the example shown here translates to 192.168.1-254.1-254, you must modify the expression to match your internal network(s).  For help creating a regular expression, check out this helpful tutorial: http://www.regular-expressions.info/numericranges.html.  You might also find Google’s online regular expression calculator useful: http://support.google.com/googleanalytics/bin/answer.py?hl=en&answer=55572.

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

  <system.web>

     <authentication mode="Windows" />

  </system.web>

  <system.webServer>

    <rewrite>

     <rules>

      <rule name="Strip wauth parameter" enabled="true" stopProcessing="true">

       <match url="(.*)" />

        <conditions>

         <add input="{REMOTE_ADDR}" pattern="\b(?:192)\.(?:168)\.([0-9]{1,3})\.([0-9]{1,3})\b" />

         <add input="{QUERY_STRING}" pattern="(.*)(wauth=.*)(.*)" />

        </conditions>

       <action type="Redirect" url="{R:0}?{C:1}{C:3}" appendQueryString="false" />

      </rule>

     </rules>

    </rewrite>

  </system.webServer>

</configuration> 

  • At the command prompt, type IISRESET and hit enter.
  • From an internal network machine, browse to the external URL of your CRM server – you should be authenticated with Windows Authentication instead of IFD claims authentication.

 By Ledgeview Partners – Wisconsin based Microsoft Dynamics CRM Partner serving the Midwest and Heartland regions

6 thoughts on “Dynamics CRM Technical Tip – URL Rewrite for IFD Internet Facing Deployment”

  1. Hi,

    Nice Post !!

    I have a query. My customer has 6 servers in One farm. Customer wants to have IFD deployment for MS CRM 2011. They want to expose only 2 servers to internet and rest 4 should be on Intranet.

    They do not want to install SSL on 6 servers. My question is how should be our approach in this case ? Also 2 servers on HTTPS and rest 4 on HTTP, will crm work ?

    Also is it possible to have all 6 as HTTP as customer does not want SSL.

    Many thanks in Advance !!

    1. Hi, Avaneesh,
      To my knowledge, you cannot mix and match HTTP and HTTPS front-end servers in a CRM deployment. In Deployment Manager, you determine the internal URL for the entire deployment under Microsoft Dynamics CRM->Properties->Web Addresses. Here you can only select HTTP or HTTPS. The IFD configuration uses this information in the Federation Metadata that is published by CRM. Also, IFD requires SSL — there is no way to do it with HTTP (or without an SSL certificate).

  2. When I make the above changes to the web.config neither my internal nor my external addresses work. I get 500 – Internal server error. Our internal network is 10.10.1.1-254 so I used: pattern=”\b(?:10)\.(?:10)\.([?:10])\.([0-9]{1,3})\b”
    We have crm.domain.com:444 and internalcrm.domain.com:444 and I would love to use just crm.domain.com:444
    Any help or insight would be greatly appreciated.

    1. Hi, Dede, the issue might be in the IP filter, which in your post references 10.10.10.1-254. Try adjusting the filter: “\b(?:10)\.(?:10)\.(?:1)\.([0-9]{1,3})\b” and let me know how it goes.

  3. Hi there, thanks for the article. I found this rewrite rule and thought ‘Great, I won’t need a multiple SAN SSL certificate, I can just make the internal address the same as the external’.
    After a few hours I realised if you do that it only allows windows authentication for external users.
    So just wanted to clarify for other readers, you still need an internalcrm.domain.com, but with this rewrite rule you can tell everyone to go to the same address.
    (I’m still trying to work out the ORGNAME.domain.com thing vs internalcrm.domain.com/ORGNAME, but doesn’t seem to matter with this rule)

Comments are closed.

Show Buttons
Hide Buttons