internalcrm.domain.com (used later for internal definition of the CRM server access).

adfs.domain.com (used for reference to the ADFS server)

one for the root domain so that domain.com points to the same server. (This is for the ADFS logout URL)

We have two setup here: CRM and CRM2013. So we need to configure crm.iwebscrm.com and crm2013.iwebscrm.com.

Test DNS

You must be able to ping all of those names and get the correct server IP address. Both from computers on the internet, and from the server.

Note: If you have added the DNS records, but still encounter name resolution problems, you can try running on the client ipconfig / flushdns to clean up the cache. You can also click the DNS server root and click CLEAR CACHE so that the server is responding with the latest updates.

Configure AD FS 3.0

3 In the Welcome page , select Create the first federation server in a federation server farm, and then click Next.

4 Select next to continue with the current administrator (must be a domain admin).

5 Choose your SSL certificate (the choice of a certificate created *.domain.com ) ,add a Federation Service name ( for example , sts1.contoso.com), and Select a Service Display Name for your business – selecting the one that is NOT starting with a *, then click Next.

6 Open PowerShell and run the following command: “Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)”

If you don’t you will se the error: Group Managed Service Accounts are not available because the KDS Root Key has not been set.

7 Create a database on this server using Windows Internal Database, click Next.

Or use the local SQL instance etc if you have one.

8 Review Options click Next

9 Pre-requisits checklist, click Configure

10 You should see a message that “This Server was successfully configured

Claims-based authentication configuration CRM 2013 server

Following these steps to set up CRM 2013 bound for the HTTPS and configure the root domain address :

1 Open the CRM Deployment Manager.

2 In the Actions pane , click Properties .

3 Click the Web Address page.

4 In the Binding Type , select HTTPS .

5. You can most likely select Apply at this point, and the default internal address for the CRM will work fine. We however created a new A record in the DNS for “internalcrm” and pointed it to this new server. This allows us to user a clear path for the internal URL.

6 For example, *. contoso.com wildcard certificate, you can useinternalcrm.contoso.com:555 as the network address.

10 On the Specify the security token service page, enter the Federation metadata URL, such ashttps://adfs.fabrikam.com/federationmetadata/2007-06/federationmetadata.xml. In our case because we setup a DNS record for “adfs” we are going to use that: https://adfs.iwebscrm.com/federationmetadata/2007-06/federationmetadata.xml

11 Click Next then select the certificate that we created perviously for the *.domain connection

12 Select Next

13 Select Apply then Finish

14 IMPORTANT – Click View Log File

15 Scroll to the end, and Copy the URL from the bottom of the file.

– This will be used in the next configuration. Note that this is different to the URL used in step 4 above, as it represents the internal URL. Subtle but vital (and the cause of frustration the first 10 times we tried this). In our case the URL looked like this: https://adfs.iwebscrm.com/federationmetadata/2007-06/federationmetadata.xml

16 Click Finish.

17 Validate that you can browse to the URL above. If you cannot view this in a browser, then have a look again at your permissions on the certificate in relation to the account on the application pool in IIS for CRM. Read above: Claims-based authentication configuration CRM 2013server.

18. Once you can browse this URL, you are done here.

Claims-based authentication configuration AD FS 3.0 server

After completion of the previous step, the next step we need AD FS 3.0 to add and configure the statement provider trust ( claims Provider trusts ) and the relying party trust ( Relying Party trusts ).

After you enable claims-based authentication, you must configure Dynamics CRM Server 2013 as a relying party to consume claims from AD FS 3.0 for authenticating internal claims access.

Start AD FS Management. On the Actions menu located in the right column, click Add Relying Party Trust. In the Add Relying Party Trust Wizard, click Start.

On the Select Data Source page, click Import data about the relying party published online or on a local network, and then type the URL you copied earlier from the log file. So that will be https://internalcrm.domain.com/FederationMetadata/2007-06/FederationMetadata.xml. This is the same internalcrm A recored that we checked earlier in the process.

On the Specify Display Name page, type a display name, such as CRM Claims Relying Party, and then click Next.

Click Next on the multi-factor authentication options.

On the Choose Issuance Authorisation Rules page, leave the Permit all users to access this relying party option selected, and then click Next.

On the Ready to Add Trust page, click the checkbox option to Open the Edit Claim Rules, Next, and then click Close.

The Rules Editor appears, click Add Rule. Otherwise, in the Relying Party Trusts list, right-click the relying party object that you created, click Edit Claims Rules, and then click Add Rule.

In the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next.

2. Click the Security tab, click the Local intranet zone, and then click Sites.

3. Click Advanced.

4. In Add this website to the zone, type the URL for your AD FS server, for example, https://sts1.contoso.com.

5. Click Add, click Close, and then click OK.

6. Select the Advanced tab. Scroll down and verify that under Security Enable Integrated Windows Authentication is checked.

7. Click OK to close the Internet Options dialog box.You will need to update the Local intranet zone on each client computer accessing Microsoft Dynamics CRM data internally. To use Group Policy to push this setting to all domain-joined internal client computers do the following.

Test claims-based authentication within the access

You should now be able to use the claims certified to the internal access CRM 2013

Trouble Shooting

If the CRM web page can not be displayed, then run the following iisreset and then try again.

If the CRM web page still does not show, then you may need to setup AD FS 3.0 server setup a SPN (Service Principal Name) . Re-run the Claims-Based Authentication Wizard, and then browse to the Specify the security token service page, note the AD FS 3.0 server in the Federation metadata URL in the name. (In this case sts1.interactivewebs.com )

There was a problem accessing the site. Try to browse to the site again. If the problem persists, contact the administrator of this site and provide the reference number to identify the problem. Reference number: xxx

And or if you look in your log files under ADFS 2.0 You will see errors like this.

In our case, this was because we used the external Metadata URL and not the Internal URL that we should have copied from the “View Log File” When configuring the Claims Based Authentication. Step 14 in the section above.

The IFD configuration CRM 2013 server

When opening Claims certified internal access, you can open by IFD external claims visited. The following describes using the IFDConfiguration Wizard to configure, if you want to learn how to use PowerShell to be configured, refer to the English original.

4 Fill in the correct domain information for the Web Application, Org, and Discovery Web services. Remembering here that in our case: *.interactivewebs.com was the name of the wildcard certificate used, and that PORT 444 was the port we configured for the CRM Web Instance in the bindings for IIS.

Thus we use:

Web Application Server Domain: interactivewebs.com:444

Organization Web Service Domain: interactivewebs.com:444

Web Service Discovery Domain: dev.interactivewebs.com:444

Note – Enter the domain name, rather than the server name .

If the CRM installed on the same server or servers are installed in the same domain, then the Web Application Server Domain and Organization Web Service Domain should be the same .

Web Service Discovery Domain must be a Web Application Server Domain as a subdomain like the “dev.” that we setup in DNS earlier.

The IFD configuration AD FS 3.0 server

After you have enabled IFD on the Microsoft Dynamics CRM Server 2013 you will need to create a relying party for the IFD endpoint on the AD FS server. (Steps below are from the MSDN Blog.

Step6: Start AD FS Management. On the Actions menu located in the right column, click Add Relying Party Trust. In the Add Relying Party Trust Wizard, click Start.

Step7: On the Select Data Source page, click Import data about the relying party published online or on a local network, and then type the URL to locate the federationmetadata.xml file. This federation metadata is created during IFD Setup.

Type this URL in your browser and verify that no certificate-related warnings appear.

Step8: On the Specify Display Name page, type a display name, such as CRM IFD Relying Party, and then click Next

Step9: On the Choose Issuance Authorization Rules page, leave the Permit all users to access this relying party option selected, and then click Next.

Step10: On the Ready to Add Trust page, click Next, and then click Close.

Step11: If the Rules Editor appears, click Add Rule. Otherwise, in the Relying Party Trusts list, right-click the relying party object that you created, click Edit Claims Rules, and then click Add Rule

Step12: In the Claim rule template list, select the Pass Through or Filter an Incoming Claimtemplate, and then click Next.

Step13: Create the following rule#1

Claim rule name: Pass Through UPN (or something descriptive)

Incoming claim type: UPN

Pass through all claim values

Click Finish

Step14: In the Rules Editor, click Add Rule, and in the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next

Step15: Create the following rule#2

Claim rule name: Pass Through Primary SID (or something descriptive)

Incoming claim type: Primary SID

Pass through all claim values

Click Finish

Step16: In the Rules Editor, click Add Rule. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.

Fix the MEX Endpoint

Where “sts1.yourorg.com” replaces ours… you should see an XML endpoint return. We found that after setup of CRM 2013 in the above mentioned environment there was a conflict with the Sandbox port 808 and this caused the failure of the service, giving a 503 error for /adfs/services/trust/mex

In the first paragraph did you mean to say “We already have a popular post for the configuration of IFD setup with CRM 2011. This post is to help those wanting to do the same thing with CRM 2013” ? (Note CRM 2011)

I have two problems the first is when using the internal URL I get a popup dialog box asking for me username and password I put it in and it works. I don’t want users to have to enter in a password they already hate CRM 2013 navigation so we want SSO and not sure why its not working.

Second I have enabled forms based authentication for the external URL yet it still pops up a dialog box asking for username and password.

I found the same problem and it indicated when i experienced it that I had not applied the forms based authentication accurately. Have a read of the: “ADFS 3.0 Extra Steps” – Note my frustration!. Hope that helps!

Any idea how i would go about configuring the “dev.domain.com” DNS entry? this is the one entry i have not seen any way of changing. the reason i ask is that i have 4 CRM servers (separate) that i would like to confgure with a single ADFS Server. All the other URLS are able to be customized in on way or another. I would need to be able to configure dev1 dev2 dev3 dev4 in order for adfs to communicate with all 4 CRM servers.

Great article. simple question: if i did it all and it works – if i open the brower externally for accessing CRM – should I get a token which can be used for about 30 days – means if i try to login a second or third time – i should get no login form, just open IE and access CRM without any manual login due to token. Do I misunderstand SSO and IFD?

No, you get a login page which is the ADFS authentication page that requires a domain/username and a pass. Once you enter it, you will then be good for a longer period. This is covered in other blog posts about the time out after CRM login. You can change the default settings to something long.

Thanks for the information. It would appear that you are correct. Typical MS to not support their own products, with their latest technology. That being said, I would be guessing that the steps mentioned for AD FS 3.0 on CRM 2013 will work just fine with CRM 2015, although I have not had the need to test this yet. Will be doing a guide on CRM 2015 soon when I have the need to get burned with that release.

1. Obvious – Reboot
2. Application Pool – Look close at the account that runs the site.
3. Check permissions on the folder for the site, that the application pool host account has permissions.

All of these should not be an issue if you have followed to the letter. Perhaps roll back and try again. Sometimes a little thing missed can become a big thing. Always takes me a few goes to get things sorted.

Hello please Help,
i have been following your blog.
I have setup ADFS and CRM 2015 on same machine.
i created a wildcard cert and binding is also done.
My Server Ip shows : 192.168.11.2
my Static public ip shows : 182.xx.xx.xx

i created auth.domain.com, dev, crm , internalcrm,etc HOST A records in forward lookup zone with Static Ip.
is it correct? Do all the Host A records need to have Static public Ip?
i tried creating host a records with publc static ip but i am not able to ping them from outside my network. am i missing something/? PLEASEEEEEEEEEEE help!!!! i have no one else to ask 🙁

Sree, Sounds like you are wanting to set up CRM and your AD server on one machine. This is not supported by Microsoft, and although we have done it ourselves for a virtual machine for testing. The troubles in setting this up were huge. Took us weeks to get it sorted, and we did not document the process.