ADFS Integration with Dynamics 365 - Part 2

To have a bettering understanding of the information you are going to read below, it is advised to read part one of the article first.

In this article we will be talking about the configurations needed for switching the normal Dynamics 365 authentication from the Windows Challenge authentication to ADFS authentication. This will allow us to add additional trusted identity providers from external domains other than the ones configured during Dynamics 365 installation.

We will start with the configurations needed from Dynamics 365 side and then proceed with ADFS configurations.

Dynamics 365 Configurations:

1. Go to the Deployment Manager and change the binding type for Dynamics 365 to HTTPS from the environment properties as the communication between Dynamics 365 and ADFS must be encrypted.
2. Run the "Configure Claims Based Authentication" wizard in the Deployment Manager.
3. On the Specify the Security Token Service page, enter the URL for the ADFS federation metadata mentioned in Part 1. (It will be similar to this format: https://adfs.companyname.com/federationmetadata2007-06/federationmetadata.xml)
4. Install the Encryption certificate on frontend Dynamics 365 servers, in the Local Machine Certificate Store.
5. On the Specify the Encryption Certificate page, select the encryption certificate installed from the previous step.
6. Go to the Local Machine Certificate Store using MMC and set Dynamics 365 IIS App pool service account to have read permissions for the private key of the encryption certificate from the Local Machine Certificate Store.
7. Make sure that the System Check page is not showing any errors and click Apply.
8. The final page from the wizard will show up the Dynamics 365 Relying federation metadata URL ("https://dynamics365.companyname.com/federationmetadata2007-06/federationmetadata.xml") that we need to Save, as we will use it to configure the ADFS relying party trust in the following section.

Please note that you can configure HTTPS port on 443 normally for Dynamics 365 frontend servers as long as ADFS is not installed on the same machine, as ADFS uses this same port for publishing its HTTP services. You will find most knowledge articles using configuration on 444; which is not mandatory.

We will not go through the ADFS server configurations as this is not the purpose of this series. And we assume that ADFS is already configured on the same domain in which Dynamics 365 was installed, so we will go ahead with ADFS required configurations to integrate with our Dynamics 365 deployment.

ADFS Configurations:

1. Configure the claims provider trust to retrieve and send the User Principal Name (UPN):
   1. In the Rules Editor, click Add Rule
   2. In the Claim rule template list, select the Send LDAP Attributes as Claims template, and then click Next
      1. Claim rule name: UPN Claim Rule 
      2. Attribute store: Active Directory
      3. LDAP Attribute: User Principal Name
      4. Outgoing Claim Type: UPN
2. Configure Dynamics 365 as relaying party trust:
   1. Open the Add Relying Party Trust Wizard from the ADFS management console and click Start.
   2. In the Select Data Source page, choose "Import data about the relying party published online or on a local network", then type the Dynamics 365 federation metadata URL that we copied in step 8 in the previous section.
   3. In Specify Display Name page, enter any descriptive display name and click Next.
   4. Configure the multi-factor authentication as required.
   5. In the Choose Issuance Authorization Rules page, leave the Permit all users to access this relying party option selected, and then click Next.
   6. On the Ready to Add Trust page, click Next
   7. On Finish Page, click the checkbox option to Open the Edit Claim Rules, Next, and then click Close.

After finalizing all these configurations, we need to do IIS reset on Dynamics 365 frontend servers and restart ADFS windows services on the ADFS servers.

Finally, the good thing about integrating ADFS with Dynamics CRM for identity authentication is that we are decoupling the authentication logic from Dynamics 365 and keeping it inside ADFS. This will allow trusting other external identity providers whether they are on the cloud or on-premises as well as applying the required claims rules on them since ADFS supports advanced claims management capabilities.

For example, we had one complex case in which we needed to trust users from three identity providers for a single Dynamics 365 deployment. Two of them were on-premise with different ADFS versions and one was using Azure AD. We were able of doing such authentication requirements easily using ADFS and its claims management mapping options.

I hope this series of articles has provided you with an overview of the many possibilities we have to support multiple authentication options for Dynamics 365 deployments using ADFS.