Chapter 28. Forms Authentication

This chapter is specifically for On-Premises deployments of Microsoft Dynamics CRM 2016. The information presented in this chapter can be used by organizations that want to expose their CRM to the Internet to provide public access to the CRM organization without having to use virtual private network (VPN) connectivity, or take advantage of other features of Microsoft Dynamics CRM 2016 that require Internet-Facing Deployment (IFD) (such as mobility).

The advantage of Integrated Windows Authentication is that it is transparent for users who access the Microsoft Dynamics CRM server from computers that belong to the domain. These users are not required to enter user information such as name and password because they are already authenticated by Active Directory when they initially log on. If you access the Microsoft Dynamics CRM server from a computer that doesn’t belong to the domain, you get the Windows Security dialog shown in Figure 28.1.

The automated login for users who belong to the same domain happens because of a default setting in the Internet Explorer browser. If you want to log in as a different user, change this setting by going to the Tools menu of Internet Explorer and then selecting Internet Options. On the Security tab, click the Local Intranet icon and then click the Custom Level button. Move to the last option and select Prompt for User Name and Password. Click OK to close the dialogs (see Figure 28.2).

If you want to access your CRM server from the Internet or from computers that are outside the network, using claims-based authentication, you must implement the IFD feature.

If you don’t want claims-based authentication, you can leave the configuration set to its default configuration: Windows Authentication. Although IFD is intended to be used by Microsoft Dynamics CRM–hosted service providers to give users a customized login page, you can enable IFD for your own organization with an On-Premises installation, if you want (see Figure 28.3). However, CRM Online uses another type of authentication, based on Office 365 authentication.

While Microsoft Dynamics CRM is installed using the Setup Wizard, you cannot enable IFD using the Setup Wizard. Instead, you must manually configure IFD as described later in this chapter, in the section “Configuring IFD.”

Figure 28.4 shows what happens when you type the Microsoft Dynamics URL for an organization in the browser.

Claims-based authentication requires HTTPS for security reasons, to prevent the username and password from being transmitted over the network in clear text when making a POST method of HTTP, so you must use SSL (Secure Sockets Layer) to protect this sensitive data.

If you try to click the Configure Internet-Facing Deployment link under Tasks, you get a warning dialog, telling you that you must configure claims-based authentication before you can configure IFD (see Figure 28.6).

Click OK to close the warning dialog and then click the first task: Configure the Claims-Based Authentication. However, when you do this, you get another error (see Figure 28.7).

After you click OK to close the warning dialog, you need to go to Properties by right-clicking the top node and selecting the Web Addresses tab. This is where you can configure HTTPS as the binding type. Figure 28.8 shows the default binding, HTTP, which needs to be changed to HTTPS with port 443.

The next sections explain these IFD components.

You can obtain SSL certificates from a number of certificate-issuing authorities, including Verisign, GoDaddy, and Thawte. Be sure to get a multiple-domain certificate or an unlimited subdomain (wildcard) certificate because you will need to use the certificate for at least three URL addresses, as explained later in this chapter, in the “DNS Server Configurations” section.

1. Open the IIS Manager application by searching for “IIS.”

2. Click the server name on the left and then click the Server Certificates icon.

3. Double-click the Server Certificates icon, click the Create Domain Certificate link under the Actions section on the right, and enter your organization information (see Figure 28.11).

4. Click Next and select an online certification authority (see Figure 28.12).

5. Click Finish, and the certificate is created. Notice that if you use a certificate from an online authority, it might take hours to days to get the certificate created.

When this configuration is done, you are almost ready to start working through the Claims-Based Authentication Wizard. If you are running Windows Server 2012 R2, AD FS 3.0 is now included as a built-in server role. However, if you are running anything prior to Windows Server 2012 R2, you need to configure AD FS 2.0. Included here, for your benefit, are discussions about both the AD FS 2.0 and 3.0 configuration options.

1. Run the ADFSSetup.exe application that you downloaded from Microsoft. The Setup Wizard appears.

2. Click Next and accept the terms in the license agreement.

3. Click Next and select the Federation Server option.

4. Click Next. The next screen shows you the list of prerequisite software that this component needs in order to be installed.

5. Click Next. The wizard checks the required software and installs any that is missing. When it finishes, it asks you to restart the server.

To configure AD FS, go to the Start menu and open the AD FS 2.0 Management application that is under the Administrative Tools group.

1. In the Server Manager select Add Roles and Features (see Figure 28.13).

2. In the Add Roles and Features Wizard that appears, click Next to continue.

3. Select Role-Based or Feature-Based Installation. Click Next to continue.

4. Select the destination server. Because you’re installing on the server that you’re currently using, click Next to continue (see Figure 28.14).

5. Select the Active Directory Federation Services option, as shown in Figure 28.15, and click Next to continue.

6. If the system prompts you to install the required features because they aren’t already configured, click Add Features. The installer installs the components and returns you to the wizard screen. Notice that AD FS is now listed in the left navigation area. Click Next to continue.

7. In the AD FS configuration that is displayed, click Next.

8. Confirm that Federation Service is checked (see Figure 28.16). Click Next.

9. Review the confirmation for installation selections and click Install.

10. When installation is complete and the installer displays a confirmation, click Close to complete the installation.

11. At the Server Manager interface, notice that the new role is installed and select AD FS from the left-side navigation.

12. In the AD FS configuration interface that appears in the Server Manager (see Figure 28.17), click More in the warning bar displayed near the top of the screen.

13. In the All Server Task Details and Notifications dialog that appears, select the Run the AD FS Management Snap-In action (see Figure 28.18).

The AD FS 3.0 role is now installed on your Windows server, and it now needs to be configured.

When start the AD FS application, the AD FS Management application present an Overview window as shown in Figure 28.19.

To start the configuration, complete the following steps:

1. Click the AD FS 2.0 Federation Server Configuration Wizard link that is under the Configure This Federation Server section on the Overview window.

2. Select the Create a New Federation Service option (assuming that you are installing the first AD FS on the network; if not, select the other option). Click Next.

3. Select Stand-Alone Federation Server and click Next. (In this example, you are creating a standalone federation server, which is recommended for small implementations. Large organizations need to create server farms.)

4. Select a certificate, as shown in Figure 28.20.

5. Specify the service account or create a new domain account and then click Next. When the configurations are done, you see the results of every task with the status.

6. Remedy any failures and rerun the wizard until you get success.

When the wizard finishes, you can find the URL you need to use when configuring the claims-based authentication on CRM. It should look something like this: https://<<servername>>.<<domain name>>.com/FederationMetadata/2007-06/-FederationMetadata.xml.

You can verify that AD FS has been installed properly by checking in the AD FS 2.0 Management application, as shown in Figure 28.21.

1. From the AD FS 2.0 Management application, go to the ServiceCertificates folder, as shown in Figure 28.22.

2. Right-click the Token-Signing certificate and select View Certificate. The Certificate dialog shown in Figure 28.23 appears.

3. On the Details tab of the Certificate dialog, click Copy to File.

4. In the Certificate Export Wizard dialog that appears, click Next.

5. In the Export File Format dialog, select DER Encoded Binary X.509 and click Next (see Figure 28.24).

6. Enter the filename with the full path where you want to store the certificate file and click Next.

7. Complete the Certificate Export Wizard by clicking Finish.

8. When the message box that says the export was successful appears, click OK.

9. Copy the file you exported to the server where you have CRM 2016 installed and open the Certificates Management snap-in. Go to the Trusted Root Certification Authorities folder, right-click the Certificates folder, and select All Tasks > Import.

10. When the Certificate Import Wizard opens, click Next.

11. In the File to Import dialog that appears, enter the filename with the full path where the certificate file is located and click Next (see Figure 28.25).

12. Leave the default Certificate Store setting, which is Trusted Root Certification Authorities, and click Next.

13. Click Finish.

14. When the message box that says the import was successful appears, click OK.

The configuration of the AD FS service should now be complete. At this point, you need to configure the authentication of Microsoft Dynamics CRM to use the AD FS service. The next section shows how to configure claims-based authentication, which is a required step in this process.

1. To open the wizard, click the Configure Claims-Based Authentication link in the Tasks pane (see Figure 28.26).

2. Enter the Federation URL you got when configuring the AD FS and click Next (see Figure 28.27).

3. Select the SSL certificate and click Next (see Figure 28.28). The wizard validates the settings and system requirements and shows any appropriate errors or warnings to the user.

4. Click Next to review the configurations.

5. Click Apply to apply the changes.

6. Click Finish to close the dialog.

At this point, the claims-based authentication for CRM should be configured. You have one more step before you can finalize the configuration of IFD, which is to add a relying party trust.

To add the trust in AD FS, follow these steps:

1. Open AD FS 2.0 by going to Start > Administrative Tools > AD FS Management.

2. Click the Add Relying Party Trust option that is on the Actions panel on the right. The Add Relying Party Trust Wizard appears. You can also get to this wizard by expanding the Trust Relationships folder, right-clicking the Relying Party Trust folder, and then selecting Add Relying Party Trust.

3. Click Start, and in the Select Data Source step, select Import Data About the Relying Party Published Online or on a Local Network, which should be similar to the following: https://fs.webfortis.com/FederationMetadata/2007-06/FederationMetadata.xml. Figure 28.29 shows the data source selection. Click Next.

4. Enter a display name and click Next (see Figure 28.30).

5. Select the Permit All Users to Access This Relying Party option and click Next.

6. Click Next again to finish. The Edit Claim Rules dialog opens (see Figure 28.31).

Next, you need to complete the following steps to add a rule for the new relying party trust you just created:

1. In the Edit Claim Rules dialog, shown in Figure 28.31, click Add Rule.

2. Select Pass Through or Filter an Incoming Claim from the drop-down and then click Next (see Figure 28.32).

3. Enter a descriptive name for the claim rule and select UPN (User Principal Name) as the incoming claim type (see Figure 28.33).

4. Click Finish.

5. Create another rule for the primary security identifier definition (SID), repeating steps 1–4 but selecting Primary SID as the Incoming Claim Type (see Figure 28.34).

6. Create another rule for the Windows account name, repeating steps 1–4 but selecting the Windows account name as the incoming type and using the Transform an Incoming Claim rule (instead of the previously selected Pass Through or Filter an Incoming Claim) template (see Figure 28.35).

You should now have three rules created, as shown in Figure 28.36.

7. Click OK to close the Edit Claim Rules dialog.

8. Click the Claims Provider Trusts folder on the left, right-click the Active Directory item in the middle, and click Edit Claim Rules on the right.

9. When the Edit Claim Rules for Active Directory dialog appears, click the Add Rule button (see Figure 28.37).

10. In the Choose Rule Type step, leave the default option Send LDAP Attributes as Claims and click Next (see Figure 28.38).

11. Enter UPN as the claim rule name, select Active Directory as the attribute store, select User-Principal-Name as the LDAP attribute, and select UPN as the outgoing claim type, as shown in Figure 28.39. Click Finish to close this dialog. You should now have 11 rules for the Active Directory claims, as shown in Figure 28.40.

You have now completed the necessary server configurations for forms authentication.

1. To open the wizard, click the Configure Internet-Facing Deployment link that is in the Actions panel on the right.

2. Click Next and fill in the Web Application Server Domain, Organization Web Service Domain, and Discovery Web Service Domain fields (see Figure 28.41). Click Next.

3. Enter the external domain (for example, auth.webfortis.com), which is the domain address where the AD FS is installed for authentication (see Figure 28.42). Click Next.

4. Verify that the system checks are met, click Next, review the selections, and complete the wizard.

5. Click Apply to start the configurations. When they are done, you see the results.

6. Click Finish to close the dialog.

7. Restart IIS with the iisreset command.

If you are configuring AD FS 3.0, you need to take an extra step: In the AD FS Management application, expand AD FS, click the Authentication Policies folder from the left list, and click the Edit Global Primary Authentication link that on the right, under Actions.

Finally, make sure you have Forms Authentication selected in both extranet and intranet lists and click OK, as shown in Figure 28.43.

You must complete some necessary DNS configurations, and the ones you need to complete depend on the DNS server you are using. The example in this section uses the Windows DNS Server Manager.

The DNS configurations described here are required for every organization you set up in Microsoft Dynamics CRM. If you are configuring multi-tenancy, you must create a host entry in your DNS server for each organization unless you use a wildcard host entry. This is because IFD uses a URL in this format: https://organizationName.domainName.com.

If your domain name is webfortis.com, your server name is crm2016, and your organization name is Webfortis, the URL to use is https://webfortis.webfortis.com. If you have another organization with the name Test on the same server, it can be accessed using the URL https://test.webfortis.com. You must configure your DNS so that crm2016.webfortis.com, webfortis.webfortis.com, and test.webfortis.com all point to the same IP address.

If you don’t specify the organization name in the URL—for example, http://crm2016.webfortis.com—the Microsoft Dynamics CRM server redirects users to the default organization URL, which in Dynamics CRM 2016 is the first organization that was created during deployment. In this example, this is https://webfortis.webfortis.com/, assuming that Webfortis is configured as the default organization.

Finally, an optional step would be to change the server properties back to HTTP with port 80, instead of HTTPS with port 443.