Plan for claims-based authentication
The following section covers considerations to be made and actions to be taken prior to a claimsbased authentication deployment.
In This Section
Microsoft Dynamics CRM Server and AD FS conditions
Certificate selection and requirements
DNS configuration
Firewall configuration
See Also
Deployment scenarios in this document
Implement claims-based authentication: internal access
Microsoft Dynamics CRM Server and AD FS conditions
Before you configure claims-based authentication, note the following conditions for the web components:
1. If you are installing Microsoft Dynamics CRM Server in a single server configuration, be aware that AD FS installs on the default website. Therefore, you must create a new website for Microsoft Dynamics CRM Server.
Note
This does not apply to Windows Server 2012 R2 as AD FS in Windows Server 2012
R2 is no longer dependent on IIS.
2. Before you enable claims-based authentication, Microsoft Dynamics CRM Server must be running on a website that has been configured to use Secure Sockets Layer (SSL). Microsoft
Dynamics CRM Server Setup will not configure the website for SSL.
3. Microsoft Dynamics CRM Server be running on a website that has a single binding. Multiple
IIS bindings, such as a website with two HTTPS or two HTTP bindings, are not supported for running Microsoft Dynamics CRM Server.
4. When claims-based authentication is enabled, HTTPS must be used in your browser for both internal and external access to Microsoft Dynamics CRM Server.
Certificate selection and requirements
Certificate selection plays a critical role in securing communication between clients and Microsoft
Dynamics CRM Server when using claims authentication. You should have a solid understanding of digital certificates before implementing claims-based authentication.
The following references provide an introduction to certificates and public key infrastructure (PKI) technologies:
14
Application Security - Certificates
Certificate Requirements for Federation Servers
Certificates are required for the following in Microsoft Dynamics CRM Server claims-based authentication.
Claims encryption. Claims-based authentication requires a certificate to encrypt claims sent to the relying party. This certificate should be issued by a trusted certification authority (CA) and should be trusted by the computer where you are installing Microsoft Dynamics CRM
Server so it must be located in the local Personal store where the Configure Claims-Based
Authentication Wizard is running.
SSL (HTTPS) encryption. The certificate for SSL encryption should be valid for host names similar to org.contoso.com, auth.contoso.com, and dev.contoso.com. To satisfy this requirement you can use a single wildcard certificate (*.contoso.com), or a certificate that supports Subject Alternative Names, or individual certificates for each name. Individual certificates for each host name are only valid if you use different servers for each web server role. Multiple IIS bindings, such as a website with two HTTPS or two HTTP bindings, are not supported for running Microsoft Dynamics CRM Server.
Consider the following when selecting a certificate for your configuration.
Wildcard certificate (recommended). A wildcard certificate supports internal and external
access requirements for a single domain. For example, *.contoso.com certificate supports the externally accessed domains org1.contoso.com and org2.contoso.com as well as the internally accessed domain internalcrm.contoso.com. Because the external domain name must resolve for internal access, you cannot use the server name for internal access. If you wish, you can use separate Microsoft Dynamics CRM servers for internal and external claims access to allow the server name to be used for internal access.
Subject Alternative Name (SAN) certificate. Use a SAN certificate if you wish to use a different
address for your internal domain that does not match your external domain. For example, your internal domain is org.contoso.local and your external domain is org.contoso.com. Be aware that third-party certificate providers typically do not provide certificates for .local domains.
Self-signed certificate. A self-signed certificate should only be used for testing purposes and not
in a production deployment. If you use a self-signed certificate, it must be imported into the
Trusted Root Certification Authorities store of all Microsoft Dynamics CRM servers and client computers accessing Microsoft Dynamics CRM Server. For information on how to import a certificate, see Help in the Certificates Microsoft Management Console (MMC). See “Creating a self-signed wildcard certificate for a test deployment” below for information on creating a selfsigned wildcard certificate.
Certificate expiration Because there’s some pain and effort involved with updating a certificate,
consider purchasing a certificate with an extended expiration period – three or more years.
Important
If you use a certificate that is created by using a custom certificate request, the template that was used must be the Legacy key template. Custom certificate requests created by using the CNG key template are incompatible with Microsoft Dynamics CRM. For more
15
information about custom certificate request templates, see Create a Custom Certificate
Request .
The default website certificate for Windows Server 2008 and Windows
Server 2012.
Note
These steps apply to Windows Server 2008 and Windows Server 2012. They do not apply to Windows Server 2012 R2.
After you have obtained and installed a certificate, the certificate must be bound to the default website before you can use AD FS.
Bind an SSL certificate to the default website
1. Open IIS Manager.
2. In the Connections pane, expand the Sites node in the tree, and then click the Default
Web Site.
3. In the Actions pane, click Bindings.
4. In the Site Bindings dialog box, click Add.
5. Under Type, select https.
6. Under SSL certificate, select your SSL certificate and then click OK.
7. Click Close.
For more information about adding binding to a site, see Add or Edit Site Binding Dialog Box
The Microsoft Dynamics CRM Server website certificate
When enabling claims-based authentication, the Microsoft Dynamics CRM website must be accessible via HTTPS. You must bind your SSL certificate to the Microsoft Dynamics CRM website.
Bind an SSL certificate to the Microsoft Dynamics CRM Server website
1. Open IIS Manager.
2. In the Connections pane, expand the Sites node in the tree, and then click the Microsoft
Dynamics CRM website.
3. In the Actions pane, click Bindings.
4. In the Site Bindings dialog box, click Add.
5. Under Type, select https.
6. Under SSL certificate, select your SSL certificate.
7. Click Close.
See the section below DNS configuration to add a host record in DNS for internal access to
Microsoft Dynamics CRM Server (for example, internalcrm.contoso.com).
16
Regarding the AD FS token-signing certificate
AD FS servers use a token-signing certificate created by the AD FS Configuration Wizard to digitally sign all security tokens that they produce. By default, Microsoft Dynamics CRM Server does not check for the presence or validity of this certificate and does not use AD FS token
signing. To enable validation and use of the AD FS token-signing certificate, see Enable AD FS token signing in the Additional Considerations section at the end of this document.
Creating a self-signed wildcard certificate for a test deployment
You can create a self-signed wildcard certificate using one of the following programs. The certificate created is not publicly trusted and should only be used for testing.
Makecert.exe
You can use Makecert.exe (Certificate Creation Tool) to generate a self-signed wildcard certificate for testing purposes. Makecert.exe is available in the Microsoft Windows Software
Development Kit for Windows Server 2008 and .NET Framework 3.5.
The following are the settings used for a wildcard certificate used to create test deployments for this document: makecert.exe -r -pe -n "CN=*.contoso.com" -b 01/01/2010 -e 01/01/2050 -eku
1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel
Cryptographic Provider" -sy 12
The self-signed certificate created with Makecert.exe is installed in the local computer’s Personal store and is not trusted. To set certificate trust, copy the self-signed certificate (for example
*.contoso.com) from the Personal store to the Trusted Root Certification Authorities store. For more information, see Help in the Certificates Microsoft Management Console (MMC).
Tip
Start a command prompt as an administrator before running makecert.exe.
For more information on Makecert.exe settings, see MakeCert .
SelfSSL
Download the IIS 6.0 Resource Kit and install the SelfSSL tool. For more information, see:
Configuring CCF to Use HTTPS (SSL) on IIS 6.0
See Also
Changing the SSL certificate
DNS configuration
Before configuring Microsoft Dynamics CRM Server for claims-based authentication, you should configure your internal and public domain records so the various Microsoft Dynamics CRM Server
17
and AD FS endpoints resolve correctly. If you are setting up Microsoft Dynamics CRM Server in a test lab, you can configure internal records in the hosts file instead of DNS. Hosts use is not recommended for a production environment.
You will create DNS records for the following domain names:
Internal URL used to access Microsoft Dynamics (for example, internalcrm.contoso.local).
External URL used to access Microsoft Dynamics - Web Application Server domain (for example, orgname.contoso.com).
Microsoft Dynamics CRM Organization Web Service domain. Differs from the record used for external access if you have separate domains (for example, orgname.subdm.contoso.com).
Microsoft Dynamics CRM Discovery Web Service domain (for example, dev.contoso.com).
AD FS server (for example, sts1.contoso.com).
External IFD URL - Microsoft Dynamics CRM IFD federation endpoint (for example, auth.contoso.com). This record will be used by the AD FS server when retrieving the
Microsoft Dynamics CRM IFD federationmetadata.xml file.
Important
There are several names that cannot be used for host records, for example: support, help, and home. To view a complete list of reserved names, open the dbo.ReservedNames table in the MSCRM_CONFIG database on the Microsoft Dynamics
CRM server and review the names in the ReservedName column.
Example DNS Settings – AD FS and Microsoft Dynamics CRM on separate servers
The following are example DNS settings for a two-server deployment. Two public IP addresses are required for external access to Microsoft Dynamics CRM – one for the Microsoft Dynamics
CRM server and one for the AD FS server. Two internally hosted DNS zones are required: contoso.local and contoso.com.
Important
If you would rather not have a public connection for your AD FS server, you can use an
AD FS proxy server. You can use federation server proxies to provide intermediary services between an Internet client and a federation server that is behind a firewall (not published on the Internet) on your corporate network.
Microsoft Dynamics CRM server always needs to talk to the AD FS server but the
Internet client should talk to the AD FS proxy server. This can be achieved by pointing the sts.domain.com DNS record externally to the AD FS proxy server and internally to the
AD FS server. The DNS records example table below covers the AD FS proxy scenario.
For more information, see Deploying Federation Server Proxies .
The following table contains records configured in the Internal DNS Zone: contoso.local.
18
Name Type Data Comment
Internal DNS Zone: contoso.local crmserver Host (A)
The following record is configured in DNS on your internal server.
The IP address of the server where Microsoft
Dynamics CRM is installed.
Configured in DNS on your internal server.
The following table contains records configured in the Internal DNS Zone: contoso.com.
Name
Internal DNS
Zone: contoso.com sts1
Type Data Comment
The following record is configured in DNS on your internal server.
This record is only needed if you use an AD FS proxy server.
IP address of your AD FS server. crmserver.contoso.local internalcrm Alias
(CNAME)
Configured in DNS on your internal server.
Used in the internal URL to access Microsoft Dynamics
CRM. Internal URL: https://internalcrm.contoso.com
The following table contains records that must be created with your public host domain
service.
Name
Public DNS: contoso.com
Type Data Comment
The following records are created with your public host domain service.
For performance and redundancy purposes you could also create these records in the contoso.com zone on your internal DNS server.
19
Name
orgname dev sts1 auth
Type
Host (A)
Host (A)
Host (A)
Host (A)
Data
IP address of your
Microsoft Dynamics
CRM public-facing internet connection.
IP address of your
Microsoft Dynamics
CRM public-facing internet connection.
Comment
Used in the external URL to access Microsoft Dynamics CRM.
External URL: https://orgname.contoso.com
The Microsoft Dynamics
CRMDiscovery Web Service.
IP address of your
AD FS server public-facing internet connection.
If you use an AD FS proxy server, this would be the IP address of the public-facing internet connection of the proxy server.
The AD FS server or AD FS proxy server.
IP address of your
Microsoft Dynamics
CRM public-facing internet connection.
The Microsoft Dynamics CRM
IFD federation endpoint. This record will be used by the AD FS server when retrieving the
Microsoft Dynamics CRM IFD federationmetadata.xml file.
Add a forward lookup zone in DNS
1. Open DNS Manager by clicking Start, pointing to Administrative Tools, and then clicking DNS.
2. In the console tree, right-click a DNS server, and then click New Zone to open the New
Zone Wizard.
3. Follow the instructions in the wizard to create a forward lookup zone of type: primary zone, secondary zone, or stub zone.
20
