Delen via


Testing Both IFD & Windows Authentication

Deep In The Motherlode…

As part of my development work I sometimes need to test applications using both IFD and Windows authentication on my Virtual PC demo environment. However, looking through the various blog posts here and here, it seemed that no-one had come up with a solution to be able to run both authentication models side-by-side when the CRM client and CRM server are on the same virtual machine. After a couple of days playing around with various network settings, DNS entries and the IFD Configuration Tool, I stumbled upon the magic configuration that enables this to work.

I tend to build my own Virtual PC images (my current environment is 32-bit Windows Server 2008 SP2, SQL Server 2008 SP1, SharePoint Server 2007 SP2, Visual Studio 2008 SP1 and CRM 4.0 Update Rollup 4), and I use a variation on the two network adapter configuration that Menno described recently in his blog – You can get details of this configuration from my May 2006 blog post here.

STEP 1 – Set up a second static IP address on the same subnet as your primary IP address. You can do this by opening the network adapter properties, navigating to the Advanced TCP/IP Settings page and adding a second IP address. In this example, my primary IP address is 192.168.0.1 with subnet mask 255.255.255.0, and my second IP address is 192.168.0.2 with the same subnet mask.

Network Adapter Configuration

STEP 2 – Add a couple of additional DNS Server entries. In this example my server name is “server” and my domain name is “demo.com”, and I access CRM through the URL https://server:5555/orgname. When using IFD authentication, I decided I wanted to use the URL format https://orgname.crm.demo.com so I needed to create three new entries in the DNS Manager console.

  1. In the “demo.com” domain, create a new child domain called “crm”
  2. In the “crm.demo.com” domain, create a new host (A) record with a blank hostname and IP address 192.168.0.2 – this allows you resolve the address “crm.demo.com”, and you can test this works by opening a command prompt and running the command “Ping crm.demo.com”.
  3. In the “crm.demo.com” domain, create a new host (A) record with a hostname of “*” and IP address 192.168.0.2 – This allows you to resolve any address in the “crm.demo.com” domain. You can test this works by opening a command prompt and running the command “Ping orgname.crm.demo.com”.

DNS Manager Configuration

STEP 3 – Install and run the IFD Configuration Tool

  1. Selecting “IFD+On Premise” as the authentication strategy.
  2. Add the IFD internal network address 192.168.0.1 and subnet mask 255.255.255.255 – It is really important the you use 255.255.255.255 subnet mask, since this means that IFD will work from our second IP address.
  3. Select “crm.demo.com:5555” as the IFD App and SDK root domains.
  4. Select “localhost:5555” as the AD App and SDK root domains. Unfortunately I haven’t been able to get this to work when using “server:5555” as the root domain.

IFD Configuration Tool

That’s it, and you should be good to go – obviously you need to use your own IP address ranges and DNS domain names, but the principle is the same. As you can see below, I can access my CRM org “Microsoft CRM” using either method, simply by typing in a different URL.

URL https://localhost:5555/microsoftcrm for Windows Authentication

CRM 4.0 With Windows Auth

URL https://microsoftcrm.crm.demo.com:5555 for IFD authentication:

CRM 4.0 With IFD Auth

This posting is provided "AS IS" with no warranties, and confers no rights.

Laughing Boy Chestnuts Pre-School

Comments

  • Anonymous
    June 17, 2009
    Deep In The Motherlode… As part of my development work I sometimes need to test applications using both