This article is a stub and requires massive community input. Please contribute!

Understanding Claims-Based Authentication

Claims-Based Authentication (CBA) is a way to permit an organization to maintain centralized control over access to resources like applications and data, whether or not those resources reside on the organization's network or not. Many organizations use Active Directory to grant users access to network resources like files and SharePoint sites and workspaces. But as cloud-based applications become more prevalent, organizations are faced with the challenge of controlling access to resources that are beyond their domains and firewalls, and users have an increasing number of credentials to remember. As many smaller businesses are already doing, more and more large organizations are using hosted services to replace systems that have traditionally resided within their networks - services like hosted E-mail, remote data backups, payroll services, and, of course, hosted CRM.

As the software company did with SharePoint 2010, Microsoft has begun laying the groundwork for the future of cloud-connected applications by incorporating CBA in Dynamics CRM 2011. With this framework in place, an organization that wishes to configure Dynamics CRM for Internet-Facing Deployment can begin to extend its traditional Active Directory-based authentication structure into the cloud, essentially becoming a provider of a cloud-based application, even if it is initially only intended to act as a "private" cloud.

How Claims-Based Authentication Works with Dynamics CRM

In general, applications that are configured for CBA all work the same way to authenticate users: when a user tries to access the application (in the cloud or on your local network), the user is redirected to a sign-in page to enter his or her credentials. Behind the scenes, the sign-in page checks all of the directories that it trusts (such as your local Active Directory) to see if the user's credentials are valid. If the user's credentials are valid, the sign-in page provides a token for the user, and it is this token that the application accepts as authentication.

For Microsoft Dynamics CRM 2011, a relatively new technology from Microsoft, Active Directory Federation Services 2.0 (AD FS 2.0) is used to provide the sign-in page, the token that is given to the validated user, and the behind-the-scenes trusts between the applications (called Relying Parties) and the directories (called Identity Providers).


Figure 1. Browsing to an external address for a Dynamics CRM organization.


Figure 2. The user is redirected to the AD FS sign-in page. Behind the scenes, this page checks Active Directory to see if the user's credentials are valid.


Figure 3. If the credentials the user enters are valid, the user is given a token and sent back to the Dynamics CRM website.

Steps for Configuring Claims-Based Authentication

The following steps are necessary to configure Claims-Based Authentication for Dynamics CRM in order to provide external access from the internet.

Configuration of your network and DNS.

You will need to configure an address for your users to access Dynamics CRM from outside of your network. The URL that users will use will be in the format https://orgname.domain.com. This will require that you get several items set up:

• DNS: Internally and externally, you will need DNS to resolve https://orgname.domain.com to your Dynamics CRM front-end server.
• SSL Certificate: You will need a wildcard SSL certificate that provides secure access via HTTPS to your Dynamics CRM server in the format of https://*.domain.com. (You can also use a UCC or SAN certificate for this purpose.) The SSL certificate must be installed on all of your Dynamics CRM application and discovery servers.
• Firewall: It is recommended that you use the default port of 443 for external access to the Dynamics CRM website. Your firewall must allow traffic to pass through on this port to the web front-end server.

Configure the Dynamics CRM Deployment Manager.

The Deployment Manager provides an interface where you can configure Dynamics CRM so the system is aware of the servers in your deployment that will be used for CBA.


Figure 4. The Deployment Manager provides access to the Claims-Based Authentication wizard.


Figure 5. The first step in configuring CBA in this wizard is letting Dynamics CRM know where your AD FS 2.0 system's configuration information is located.


Figure 4. The Deployment Manager provides access to the Claims-Based Authentication wizard.


Figure 5. The first step in configuring CBA in this wizard is letting Dynamics CRM know where your AD FS 2.0 system's configuration information is located.


Figure 6. Next, you will specify the information from your SSL certificate. You can get this info from the certificate that you receive from the issuer.


Figure 7. The last step in the wizard will validate the information that you entered and ensure that the Dynamics CRM server can communicate with the AD FS 2.0 website.

Install and configure AD FS 2.0.

Active Directory Federation Services 2.0 (AD FS 2.0) is a free download available from Microsoft. NOTE: AD FS 2.0 must be installed to a default website in IIS. Therefore, if you plan on installing it on the same server with Dynamics CRM, you must install the CRM website to a non-default website in IIS.

Tip:

If you want to configure Internet-Facing Deployment for Dynamics CRM, you must configure Claims-Based Authentication. However, you can configure CBA solely for use inside your network. This might be useful if you have multiple identity providers across your organization.

References

Below is a list of resources that will be invaluable when configuring Claims-Based Authentication for Dynamics CRM.

• Implementation Guide. This link takes you to the download page for the Implementation Guide and a separate document for configuring Claims-Based Authentication.
• AD FS 2.0 Download. Free download of Active Directory Federation Services 2.0.