Microsoft Dynamics CRM 2011 and Claims-Based Authentication
Transcript of Microsoft Dynamics CRM 2011 and Claims-Based Authentication
Configuring Claims-based Authentication for Microsoft Dynamics CRM 2011
Microsoft Corporation
Published February 2011
Updated August 2011
AbstractMicrosoft Dynamics CRM 2011 replaces forms authentication used in Microsoft
Dynamics CRM 4.0 with claims-based authentication, an identity access solution designed to
provide simplified user access and single sign-on access to Microsoft Dynamics CRM.
This document provides information about:
Installing and configuring AD FS 2.0.
Installing and configuring Microsoft Dynamics CRM Server 2011 claims-based authentication for internal access, external access (IFD), or both internal and external access.
Federation trusts, Microsoft Office Outlook connections, and other configuration considerations.
This document is provided "as-is". Information and views expressed in this document, including
URL and other Internet Web site references, may change without notice. You bear the risk of
using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real
association or connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any
Microsoft product. You may copy and use this document for your internal, reference purposes.
© 2011 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Excel, Hyper-V, Internet Explorer, Microsoft Dynamics, Microsoft
Dynamics logo, MSDN, Outlook, Notepad, SharePoint, Silverlight, Visual C++, Windows,
Windows Azure, Windows Live, Windows PowerShell, Windows Server, and Windows Vista are
trademarks of the Microsoft group of companies.
All other trademarks are property of their respective owners.
Contents
Configuring Claims-based Authentication for Microsoft Dynamics CRM 2011................................4
About Claims Authentication........................................................................................................4
Prerequisites............................................................................................................................... 5
Recommended Reading..............................................................................................................5
Terminology................................................................................................................................. 5
Upgrading from Microsoft Dynamics CRM 4.0............................................................................7
Authentication Models.................................................................................................................8
Windows Authentication...........................................................................................................8
Claims-based authentication: internal access..........................................................................9
Claims-based authentication: external access.......................................................................10
Planning for Claims-based Authentication.................................................................................11
Microsoft Dynamics CRM Server 2011 and AD FS 2.0 conditions.........................................11
Certificate selection and requirements...................................................................................11
DNS configuration..................................................................................................................13
Firewall configuration.............................................................................................................14
Implementing Claims-based Authentication: Internal Access....................................................14
Install and configure AD FS 2.0..............................................................................................14
Configure the Microsoft Dynamics CRM Server 2011 for claims-based authentication..........16
Configure the AD FS 2.0 server for claims-based authentication...........................................21
Test internal claims-based authentication..............................................................................23
Implementing Claims-based Authentication: External Access...................................................24
Configure the Microsoft Dynamics CRM Server 2011 for IFD................................................24
Configure the AD FS 2.0 server for IFD.................................................................................29
Test external claims-based authentication.............................................................................30
Claims Access and Partner Companies....................................................................................31
Configure Microsoft Dynamics CRM for Outlook to Use Claims-based Authentication..............31
Additional Considerations..........................................................................................................33
Manually updating a claims provider......................................................................................33
Claims-based authentication and security token expiration...................................................34
System time synchronization and claims-based authentication.............................................35
Enabling AD FS 2.0 token signing..........................................................................................35
Certificate name length limit...................................................................................................37
Include AD FS servers in the local intranet zone....................................................................37
Send us your feedback about this document.............................................................................37
Configuring Claims-based Authentication for Microsoft Dynamics CRM 2011
Published: February 2011
Updated: August 2011
About Claims Authentication
Prerequisites
Recommended Reading
Terminology
Upgrading from Microsoft Dynamics CRM 4.0
Authentication Models
Planning for Claims-based Authentication
Implementing Claims-based Authentication: Internal Access
Implementing Claims-based Authentication: External Access
Claims Access and Partner Companies
Configure Microsoft Dynamics CRM for Outlook to Use Claims-based Authentication
Additional Considerations
About Claims AuthenticationMicrosoft Dynamics CRM 4.0 uses Integrated Windows authentication to authenticate internal
users and forms authentication to enable Internet access for external users not using VPN.
Microsoft Dynamics CRM Server 2011 replaces forms authentication with claims-based
authentication, an identity access solution designed to provide simplified user access and single
sign-on access to Microsoft Dynamics CRM data.
Claims-based authentication is built on Windows Identity Foundation (WIF), a framework for
building claims-aware applications and security token service (STS) that is standards-based and
interoperable. Interoperability is provided through reliance on industry standard protocols such as
WS-Federation, WS-Trust, and Security Assertion Markup Language 1.1 (SAML).This document
uses Active Directory Federation Services 2.0 (AD FS 2.0) as the identity provider.
In claims-based authentication, an identity provider, or security token service, responds to
authentication requests and issues SAML security tokens that include any number of claims
about a user, such as a user name and groups the user belongs to. A relying party application
receives the SAML token and uses the claims inside to decide whether to grant the client access
to the requested resource. Claims-based authentication can be used to authenticate your
organization's internal users, external users, and users from partner organizations.
4
For more information about claims authentication, see the Recommended Reading section of this
document.
This document has the following goals:
Provide information about installing and configuring AD FS 2.0.
Provide information about installing and configuring Microsoft Dynamics CRM Server 2011 claims-based authentication for internal access, external access (IFD), or both internal and external access.
Provide information about federation trusts, Microsoft Office Outlook connections, and other configuration considerations.
PrerequisitesBefore configuring Microsoft Dynamics CRM Server 2011 for claims-based authentication, you
should have a solid understanding of the following:
1. The Microsoft Dynamics CRM Server 2011 installation process.
2. Token-based authentication as used in claims-based authentication.
3. AD FS 2.0 installation and configuration.
4. Public key infrastructure (PKI) administration and digital certificates.
Recommended Reading Windows Server 2008 R2 Active Directory Federation Services 2.0
(http://go.microsoft.com/fwlink/?LinkId=200771)
AD FS 2.0 Step-by-Step and How To Guides (http://go.microsoft.com/fwlink/?LinkId=180357)
Claims-Based Identity for Windows.pdf (http://go.microsoft.com/fwlink/?LinkID=209773)
MSDN content
A Guide to Claims–based Identity and Access Control (http://go.microsoft.com/fwlink/?LinkID=188049)
Using Active Directory Federation Services 2.0 in Identity Solutions (http://go.microsoft.com/fwlink/?LinkID=209776)
Video
Configuring IFD with Microsoft Dynamics CRM 2011 (http://go.microsoft.com/fwlink/?LinkID=209777)
Certificates and public key infrastructure
Application Security - Certificates (http://go.microsoft.com/fwlink/?LinkId=200774)
Certificate Requirements for Federation Servers (http://go.microsoft.com/fwlink/?LinkId=182466)
Terminology
5
Term Definition
Active Directory Federation Services (AD FS) A component of Windows Server 2003 R2 and
Windows Server 2008 that supports identity
federation and Web single sign-on (SSO) for
Web browser–based applications.
Claim A statement that one subject makes about itself
or another subject. For example, the statement
can be about a name, identity, key, group,
privilege, or capability. Claims have a provider
that issues them, and they are given one or
more values.
Claim rule A rule that is written in the claim rule language
in AD FS 2.0 that defines how to generate,
transform, pass through, or filter claims.
Claims-aware application A relying party software application that uses
claims to manage identity and access for users.
In this document, Microsoft Dynamics CRM is
the claims-aware application.
Claims provider A Federation Service that issues claims for a
particular transaction. In Microsoft Dynamics
CRM Server 2011 claims-based authentication,
AD FS 2.0 issues claims for its users to the
relying party - the Microsoft Dynamics CRM
server.
Federation server A computer running Windows Server 2008 or
Windows Server 2008 R2 that has been
configured using the AD FS 2.0 Federation
Server Configuration Wizard to act in the
federation server role. A federation server
issues tokens and serves as part of a
Federation Service.
Federation Service A logical instance of a security token service
such as AD FS 2.0.
Identity provider A Web service that handles requests for trusted
identity claims and issues SAML tokens. An
identity provider uses a database called an
identity store to store and manage identities
and their associated attributes. For this
document, AD FS 2.0 is the identity provider
6
Term Definition
and Active Directory Domain Services (AD DS)
is the identity store.
Relying party An application that consumes claims to make
authentication and authorization decisions. For
example, the Microsoft Dynamics CRM server
receives claims that determine whether users in
a partner organization can access your
Microsoft Dynamics CRM data.
Relying party trust A trust object, in the AD FS 2.0 snap-in, that is
created to maintain the relationship with a
Federation Service or with an application that
consumes claims from this Federation Service.
Upgrading from Microsoft Dynamics CRM 4.0If your Microsoft Dynamics CRM 4.0 deployment is configured for an Internet-facing deployment
(IFD), after the upgrade to Microsoft Dynamics CRM Server 2011 is complete you must complete
the following steps to re-enable IFD:
1. Install and configure AD FS 2.0.
2. From the Microsoft Dynamics CRM 2011 Deployment Manager, run the Configure Claims-Based Authentication Wizard to configure the Microsoft Dynamics CRM Server 2011 server for claims-based authentication.
3. Configure the AD FS 2.0 server for claims-based authentication.
Claims-based authentication must be enabled in Microsoft Dynamics CRM before
configuring and enabling IFD.
4. From the Microsoft Dynamics CRM 2011 Deployment Manager, run the Internet-Facing Deployment Configuration Wizard to configure the Microsoft Dynamics CRM server for IFD.
5. Configure the AD FS 2.0 server for IFD.
Be aware that AD FS 2.0 requires the default Web site for installation. If the default Web
site is already in use for Microsoft Dynamics CRM 4.0, you must install AD FS 2.0 on a
different server.
Enabling anonymous authenticationTo use Microsoft Dynamics CRM 4.0 for Outlook (Update Rollup 7 or later) with Microsoft
Dynamics CRM Server 2011 IFD, you must enable anonymous authentication for the 2007 SPLA
CrmDiscoveryService on each server where Microsoft Dynamics CRM Server 2011 is installed.
For other requirements, see Microsoft Dynamics CRM for Outlook software requirements
(http://go.microsoft.com/fwlink/?LinkID=210780) in the Microsoft Dynamics CRM Planning Guide.
Important Important
7
1. Open Internet Information Services (IIS) Manager.
2. In the Connections pane, select the Microsoft Dynamics CRM Server 2011 Web site, and then navigate to the following folder: MSCRMServices\2007\SPLA
3. In Features View, double-click Authentication.
4. On the Authentication page, select Anonymous Authentication.
5. In the Actions pane, click Enable to use Anonymous authentication with the default settings.
For more information about enabling anonymous authentication in IIS, see Enable Anonymous
Authentication (IIS 7) (http://go.microsoft.com/fwlink/?LinkId=205316).
Authentication ModelsThe following authentication methods are supported by Microsoft Dynamics CRM Server 2011:
Windows Authentication
Claims-based authentication: internal access
Claims-based authentication: external access
Claims-based authentication: internal and external access
Your choice of authentication method depends on your organization's design and deployment
goals.
Windows AuthenticationAs in Microsoft Dynamics CRM 4.0, you can use Windows Authentication in Microsoft Dynamics
CRM Server 2011 to authenticate clients using NTLM or Kerberos. Windows Authentication is
best suited for an intranet environment where all users are members of your Active Directory
domain.
Windows Authentication flows as follows:
To enable anonymous authentication
8
Claims-based authentication: internal accessIf you have a multiple domain environment where trust does not exist between the domains, or
where some users exist in a different identity provider such as a partner organization, you can
use claims-based authentication to handle internal user authentication.
Claims authentication flows as follows:
1. The client sends a request to access the Microsoft Dynamics CRM Web site.
2. IIS refuses the connection and redirects the user to the trusted claims provider for Microsoft Dynamics CRM (STS/AD FS 2.0).
3. The client sends a request for a token from AD FS 2.0.
9
4. AD FS 2.0 returns a 401.1 error.
5. The client validates authentication with Active Directory (Kerberos).
6. Active Directory validates the client.
7. The Client contacts AD FS 2.0 with a valid Kerberos ticket.
If the client already has a valid Kerberos ticket on the network, this ticket is presented
to AD FS 2.0 in the first request.
8. AD FS 2.0 provides a claim for access to Microsoft Dynamics CRM data.
9. The client presents the claim from AD FS 2.0 to the Microsoft Dynamics CRM server.
10. The Microsoft Dynamics CRM server decrypts and validates the claim and presents the user with the requested information.
Microsoft Dynamics CRM security roles and profiles are respected. The claims token
only replaces Windows Authentication.
Claims-based authentication: external accessAccessing Microsoft Dynamics CRM data over the Internet through an Internet-facing deployment
(IFD) is now done with claims-based authentication.
The flow for claims with IFD access is largely unchanged from the flow described above for
internal access. The major difference is that user authentication does not include a Kerberos
ticket. When accessing AD FS, users are prompted for credentials on an AD FS 2.0 login screen.
If more than one identity provider is trusted by AD FS 2.0, users are prompted to select an identity
provider. Users then enter their credentials and the AD FS 2.0 server validates these login
credentials with the selected identity provider.
Note Important
10
Planning for Claims-based AuthenticationThe following section covers considerations to be made and actions to be taken prior to a claims-
based authentication deployment.
Microsoft Dynamics CRM Server 2011 and AD FS 2.0 conditionsBefore you configure claims-based authentication, note the following conditions for the Web
components:
1. If you are installing Microsoft Dynamics CRM Server 2011 in a single server configuration, be aware that AD FS 2.0 installs on the default Web site. Therefore, you must create a new Web site for Microsoft Dynamics CRM Server 2011.
2. Before you enable claims-based authentication, Microsoft Dynamics CRM Server 2011 must be running on a Web site that has been configured to use Secure Sockets Layer (SSL). Microsoft Dynamics CRM Server Setup will not configure the Web site for SSL.
3. Microsoft Dynamics CRM Server 2011 must be running on a Web site that has a single binding. Multiple IIS bindings, such as a Web site with two HTTPs or two HTTP bindings, are not supported for running Microsoft Dynamics CRM Server 2011.
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 2011.
Certificate selection and requirementsCertificate selection plays a critical role in securing communication between clients and Microsoft
Dynamics CRM Server 2011 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:
Application Security - Certificates (http://go.microsoft.com/fwlink/?LinkId=200774)
Certificate Requirements for Federation Servers (http://go.microsoft.com/fwlink/?LinkId=182466)
Certificates are required for the following in Microsoft Dynamics CRM Server 2011 claims-based
authentication.
Claims encryption. Claims-based authentication requires identities to provide an encryption certificate for authentication. This certificate should be signed by a trusted certification authority (CA).
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 Web site with two HTTPS or two HTTP bindings, are not supported for running Microsoft Dynamics CRM Server 2011.
Consider the following when selecting a certificate for your configuration.
11
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 Server 2011 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 is recommended only for testing purposes. If you
use a self-signed certificate, it must be imported into the Trusted Root Certification Authorities
store of all Microsoft Dynamics CRM Server 2011 servers and client computers accessing
Microsoft Dynamics CRM Server 2011.
The default Web site certificate
After you have obtained and installed a certificate, the certificate must be bound to the default
Web site before you can use AD FS 2.0.
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
(http://go.microsoft.com/fwlink/?LinkId=143106)
The Microsoft Dynamics CRM Server 2011 Web site certificate
When enabling claims-based authentication, the Microsoft Dynamics CRM Server 2011 Web site
must be accessible via HTTPS. You must bind your SSL certificate to the Microsoft Dynamics
CRM Server 2011 Web site.
1. Open IIS Manager.
2. In the Connections pane, expand the Sites node in the tree, and then click the Microsoft Dynamics CRM Server 2011 Web site.
To bind an SSL certificate to the default Web siteTo bind an SSL certificate to the Microsoft Dynamics CRM Server 2011 Web site
12
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. Under Port, enter a port number other than 443 (for example, 444), and then click OK.
Note
Setting the port number to a port other than 443 is not needed if your AD FS
server and your Microsoft Dynamics CRM Server 2011 are separate servers.
8. Click Close.
9. Add a host record in DNS for internal access to Microsoft Dynamics CRM Server 2011 (for example, internalcrm.contoso.com).
Regarding the AD FS 2.0 token-signing certificate
AD FS 2.0 servers use a token-signing certificate created by the AD FS 2.0 Configuration Wizard
to digitally sign all security tokens that they produce. By default, Microsoft Dynamics CRM Server
2011 does not check for the presence or validity of this certificate and does not use AD FS 2.0
token signing. To enable validation and use of the AD FS 2.0 token-signing certificate, see the
Additional Considerations section at the end of this document.
DNS configurationBefore configuring Microsoft Dynamics CRM Server 2011 for claims-based authentication, you
should configure your domain records in DNS so the various Microsoft Dynamics CRM Server
2011 endpoints resolve correctly. If you are setting up Microsoft Dynamics CRM Server 2011 in a
test lab, you can configure records in the hosts.ini file instead of DNS. Hosts.ini use is not
recommended for a production environment.
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.
Once you've created the forward lookup zone, create DNS records for the following domain
names:
Internal URL used to access Microsoft Dynamics (for example, internalcrm.contoso.com).
External URL used to access Microsoft Dynamics - Web Application Server domain (for example, orgname.contoso.com).
To add a forward lookup zone in DNS
13
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 2.0 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 2.0 server when retrieving the Microsoft Dynamics CRM IFD federationmetadata.xml file.
Firewall configurationYou must set your firewall to allow inbound traffic on the ports used for Microsoft Dynamics CRM
Server 2011 and AD FS 2.0. The default port for HTTPS (SSL) is 443.
Implementing Claims-based Authentication: Internal AccessEnabling claims-based authentication for internal access to Microsoft Dynamics CRM Server
2011 data involves the following steps:
1. Install and configure AD FS 2.0.
2. Configure the Microsoft Dynamics CRM Server 2011 server for claims-based authentication.
3. Configure the AD FS 2.0 server for claims-based authentication.
4. Test internal claims-based authentication.
Install and configure AD FS 2.0A variety of STS providers can be used with Microsoft Dynamics CRM Server 2011. This
document uses Active Directory Federation Services (AD FS) 2.0 for the security token service.
AD FS 2.0 installs on the default Web site. Before installing AD FS 2.0, you must create a
new Web site for Microsoft Dynamics CRM Server 2011.
Download AD FS 2.0
AD FS 2.0 is a free upgrade to the AD FS version included in Windows Server 2008 R2. You do
not need to install the version included in Windows Server 2008 R2 before installing AD FS 2.0.
You can download AD FS 2.0 from the following location: Active Directory Federation Services 2.0
RTW (http://go.microsoft.com/fwlink/?LinkID=204237).
Install AD FS 2.0
Once downloaded, install the AD FS 2.0 software. Select the federation server role in the setup
wizard.
Important
14
For information about installing AD FS 2.0, see Install the AD FS 2.0 Software
(http://go.microsoft.com/fwlink/?LinkId=192792).
Configure AD FS 2.0
To configure AD FS 2.0 for Microsoft Dynamics CRM Server 2011 claims authentication, do the
following steps:
1. On the AD FS 2.0 server, click Start, and then click AD FS 2.0 Management.
2. On the AD FS 2.0 Management page, click AD FS 2.0 Federation Server Configuration Wizard.
3. On the Welcome page, select Create a new Federation Service, and then click Next.
4. On the Select Deployment Type page, select Stand-alone federation server, and then click Next.
5. Select your SSL certificate, add the Federation Service name (for example, sts1.contoso.com), and then click Next.
You only add the federation service name if you are using a wildcard certificate for
the AD FS 2.0 Web site.
If you install AD FS 2.0 and Microsoft Dynamics CRM Server 2011 on the same
server, do not use the same URL for the Federation Service name and internal claims
access to Microsoft Dynamics CRM Server 2011. For example ,if you use
sts1.contoso.com for the Federation Service name do not use
https://sts1.contoso.com:444 for internal Microsoft Dynamics CRM data access.
Note
15
6. Review the settings on the Summary page, and then click Next.
7. Click Close to close the AD FS 2.0 Configuration Wizard.
8. If you have not created a host record in DNS for the federation server name you specified in Step 5 above, do so now.
Verifying AD FS 2.0 installation
Use the following steps to verify the AD FS 2.0 installation:
1. Open Internet Explorer.
2. Browse to the URL of the federation metadata. For example, https://sts1.contoso.com/federationmetadata/2007-06/federationmetadata.xml
3. Verify that no certificate-related warnings appear.
Configure the Microsoft Dynamics CRM Server 2011 for claims-based authenticationAfter you have installed AD FS 2.0, you need to set the Microsoft Dynamics CRM Server 2011
binding type and root domains before you enable claims-based authentication.
16
Set Microsoft Dynamics CRM Server 2011 binding to HTTPS and configure the root domain Web addresses
1. Start the Deployment Manager.
2. In the Actions pane, click Properties.
3. Click the Web Address tab.
4. Under Binding Type, select HTTPS.
5. Verify that the Web addresses are valid for your SSL certificate and the SSL port bound to the Microsoft Dynamics CRM Server 2011 Web site. Because you are configuring Microsoft Dynamics CRM Server 2011 to use claims authentication for internal access, use the host name for the root domain Web addresses. The port number should match the settings for the Microsoft Dynamics CRM Server 2011 Web site in IIS.
For example, for a *.contoso.com wildcard certificate, you would use
internalcrm.contoso.com:444 for the Web addresses.
If you install AD FS 2.0 and Microsoft Dynamics CRM Server 2011 on separate servers,
do not specify port 443 for the Web Application Server, Organization Web Service, or
Discovery Web Service.
6. Click OK.
Warning
To set the binding type to HTTPS and set Web addresses
17
If Microsoft Dynamics CRM for Outlook clients were configured using the old
binding values, these clients will need to be configured with the new values.
The CRMAppPool account and the Microsoft Dynamics CRM encryption certificate
Claims data sent from Microsoft Dynamics CRM to AD FS 2.0 is encrypted using a certificate you
specify in the Configure Claims-Based Authentication Wizard. The CRMAppPool account of each
Microsoft Dynamics CRM Web application must have read permission to the private key of the
encryption certificate.
1. On the Microsoft Dynamics CRM Server 2011, create a Microsoft Management Console (MMC) with the Certificates snap-in console that targets the Local computer certificate store.
2. In the console tree, expand the Certificates (Local Computer) node, expand the Personal store, and then click Certificates.
3. In the details pane, right-click the encryption certificate specified in the Configure Claims-Based Authentication Wizard, point to All Tasks, and then click Manage Private Keys.
4. Click Add, (or select the Network Service account if that is the account you used during Setup) add the CRMAppPool account, and then grant Read permissions.
You can use IIS Manager to determine what account was used during setup for the
CRMAppPool account. In the Connections pane, click Application Pools, and then
check the Identity value for CRMAppPool.
5. Click OK.
Warning
18
Configuring claims-based authentication using the Configure Claims-Based Authentication Wizard
Run the Configure Claims-Based Authentication wizard to enable claims authentication on your
Microsoft Dynamics CRM Server 2011.
1. Start the Deployment Manager.
2. In the Deployment Manager console tree, right-click Microsoft Dynamics CRM, and then click Configure Claims-Based Authentication.
3. Review the contents of the page, and then click Next.
4. On the Specify the security token service page, enter the Federation metadata URL, such as https://sts1.contoso.com/federationmetadata/2007-06/federationmetadata.xml.
This data is typically located on the Web site where the Active Directory Federation
Services (AD FS) 2.0 is running. To verify the correct URL, open an Internet browser by
using the URL to view the federation metadata. Verify that no certificate-related warnings
appear.
5. Click Next.
6. On the Specify the encryption certificate page, specify the encryption certificate in one of two ways:
In the Certificate box, type the name of the certificate. Type the complete common name (CN) of the certificate by using the format CN=certificate_subject_name.
Under Certificate, click Select, and then select a certificate.
This certificate is used to encrypt authentication security tokens that are sent to the AD
FS 2.0 security token service.
Note
The Microsoft Dynamics CRM service account must have Read permissions for
the private key of the encryption certificate. See the CRMAppPool account and
the Microsoft Dynamics CRM encryption certificate topic.
7. Click Next.
The Configure Claims-Based Authentication Wizard verifies the token and certificate that
you specified.
8. On the System Checks page, review the results, perform any steps required to fix problems, and then click Next.
9. On the Review your selections and then click Apply page, verify your selections, and then click Apply.
10. Note the URL you must use to add the relying party to the security token service. View and save the log file for later reference.
11. Click Finish.
Configuring claims-based authentication using Windows PowerShell
To configure claims-based authentication using the Configure Claims-Based Authentication Wizard
19
1. Open a Windows PowerShell prompt.
2. Add the Microsoft Dynamics CRM Windows PowerShell snap-in:
PS > Add-PSSnapin Microsoft.Crm.PowerShell
3. Get the claims-based authentication settings:
PS > $claims = Get-CrmSetting -SettingType "ClaimsSettings"
4. Configure the claims-based authentication object:
PS > $claims.Enabled = 1 (or $true)
PS > $claims.EncryptionCertificate = certificate_name
PS > $claims.FederationMetadataUrl = federation_metadata_URL
Where:
1 = "true".
certificate_name is the name of the encryption certificate.
federation_metadata_URL is the federation metadata URL for the security token service. (For example, https://sts1.contoso.com/federationmetadata/2007-06/federationmetadata.xml.)
5. Set the claims-based authentication values:
PS > Set-CrmSetting $claims
Configure the AD FS 2.0 server for claims-based authenticationAfter enabling claims-based authentication, the next step is add and configure claims provider
trusts and relying party trusts in AD FS 2.0.
Configure Claims Provider Trusts
You need to add a claims rule to retrieve the user principal name (UPN) attribute from Active
Directory and send it to Microsoft Dynamics CRM as a UPN.
1. On the computer that is running Windows Server where the AD FS 2.0 federation server is installed, start AD FS 2.0 Management.
2. In the Navigation Pane, expand Trust Relationships, and then click Claims Provider Trusts.
3. Under Claims Provider Trusts, right-click Active Directory, and then click Edit Claims Rules.
4. In the Rules Editor, click Add Rule,
To configure claims-based authentication using Windows PowerShellTo configure AD FS 2.0 to send the UPN LDAP attribute as a claim to a relying party
20
5. In the Claim rule template list, select the Send LDAP Attributes as Claims template, and then click Next.
6. Create the following rule:
Claim rule name: UPN Claim Rule (or something descriptive)
Add the following mapping:
i. Attribute store: Active Directory
ii. LDAP Attribute: User Principal Name
iii. Outgoing Claim Type: UPN
7. Click Finish, and then click OK to close the Rules Editor.
Configure relying party trusts
After you enable claims-based authentication, you must configure Microsoft Dynamics CRM
Server 2011 as a relying party to consume claims from AD FS 2.0 for authenticating internal
claims access.
1. On the computer that is running Windows Server where the AD FS 2.0 federation server is installed, start AD FS 2.0 Management.
2. On the Actions menu located in the right column, click Add Relying Party Trust.
3. In the Add Relying Party Trust Wizard, click Start.
4. 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 claims setup. Use the URL listed on the last
page of the Configure Claims-Based Authentication Wizard (before you click Finish). For
example,
https://internalcrm.contoso.com:444/FederationMetadata/2007-06/FederationMetadata.x
ml. Verify that no certificate-related warnings appear.
5. Click Next.
6. On the Specify Display Name page, type a display name, such as CRM Claims Relying Party, and then click Next.
7. On the Choose Issuance Authorization Rules page, leave the Permit all users to access this relying party option selected, and then click Next.
8. On the Ready to Add Trust page, click Next, and then click Close.
9. 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.
Important
Be sure the Issuance Transform Rules tab is selected.
10. In the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next.
To configure relying party trusts
21
11. Create the following rule:
Claim rule name: Pass Through UPN (or something descriptive)
Add the following mapping:
i. Incoming claim type: UPN
ii. Pass through all claim values
12. Click Finish.
13. In the Rules Editor, click Add Rule, in the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next:
Claim rule name: Pass Through Primary SID (or something descriptive)
Add the following mapping:
i. Incoming claim type: Primary SID
ii. Pass through all claim values
14. Click Finish.
15. In the Rules Editor, click Add Rule,
16. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.
17. Create the following rule:
Claim rule name: Transform Windows Account Name to Name (or something descriptive)
Add the following mapping:
i. Incoming claiming type: Windows account name
ii. Outgoing claim type: Name
iii. Pass through all claim values
18. Click Finish, and when you have created all three rules, click OK to close the Rules Editor.
22
This illustration shows the three relying party trust rules you create.
Test internal claims-based authenticationYou should now be able to access Microsoft Dynamics CRM Server 2011 internally using claims
authentication.
1. Start the Deployment Manager.
2. Expand the Deployment Manager node, and then click Organizations.
3. Right-click your organization, and then click Browse. This will take you to your internal Web site (for example, https://internalcrm.contoso.com:444).
The Microsoft Dynamics CRM Server 2011 Web page should display without logon prompts. In
the browser, notice that the AD FS 2.0 URL is loaded and then directed back to the Microsoft
Dynamics CRM Server 2011 server.
Troubleshooting
If the Microsoft Dynamics CRM Server 2011 Web site does not display, at a command prompt,
run the iisreset command, and then try browsing to the Microsoft Dynamics CRM Server 2011
Web site again.
23
If the Microsoft Dynamics CRM Server 2011 Web site again fails to display, you may need
register the AD FS 2.0 server as a ServicePrincipalName (SPN). Rerun the Configure Claims-
Based Authentication Wizard and advance to the Specify the security token service page. Note
the AD FS 2.0 server in the Federation metadata URL (for example, sts1.contoso.com).
1. Open a command prompt.
2. Type the following commands: (replace your data in the example command below)
c:\>setspn -a http/sts1.contoso.com contoso\crmserver$
c:\>iisreset
3. Retry browsing to the Microsoft Dynamics CRM Server 2011 Web site.
Implementing Claims-based Authentication: External AccessTo enable claims-based authentication for external access to Microsoft Dynamics CRM Server
2011 data, do the following:
1. Complete the steps in the previous section, Implementing Claims-based Authentication - Internal Access.
2. Configure the Microsoft Dynamics CRM Server 2011 server for IFD.
3. Configure the AD FS 2.0 server for IFD.
4. Test external claims-based authentication.
Configure the Microsoft Dynamics CRM Server 2011 for IFDWith internal claims authentication access enabled on Microsoft Dynamics CRM Server 2011, you
can now enable external claims access through IFD.
Configure an Internet-facing deployment using the Configure Internet-Facing Deployment Wizard
1. Start the Deployment Manager.
2. In the Deployment Manager console tree, right-click Microsoft Dynamics CRM, and then click Configure Internet-Facing Deployment.
3. Click Next.
4. On the Make Microsoft Dynamics CRM available to users who connect through the Internet page, type the domains for the specified Microsoft Dynamics CRM Server 2011 roles, and then click Next.
Important
Specify domains, not servers.
If your deployment is on a single server or on servers that are in the same domain,
To configure an Internet-facing deployment using the Configure Internet-Facing Deployment Wizard
24
the Web Application Server Domain and Organization Web Service Domain will be identical.
The Discovery Web Service Domain must be a resolvable host name and not a root domain. For example: dev.contoso.com.
The Discovery Web Service domain must not match an organization's fully qualified domain name (FQDN). For example, the Discovery Web Service Domain should not be: orgname.contoso.com.
The domains must be valid for the SSL certificate's common name or names.
The domains must be set to resolve correctly in DNS to your Microsoft Dynamics CRM servers holding the server roles.
The domains can be in a different domain than the domain which the Microsoft Dynamics CRM servers reside.
Example domains:
Web Application Server Domain: contoso.com:444
Organization Web Service Domain: contoso.com:444
Discovery Web Service Domain: dev.contoso.com:444
With the example settings above, if your organization name was "orgname", clients would
access your Microsoft Dynamics CRM web site with the following URL:
https://orgname.contoso.com:444.
For more information about Web addresses on multiple servers, see Install Microsoft
Dynamics CRM Server 2011 on multiple computers (http://go.microsoft.com/fwlink/?
LinkID=199532) in the Microsoft Dynamics CRM Installing Guide.
25
5. In the Enter the external domain where your Internet-facing servers are located box, type the external domain information where your Internet-facing Microsoft Dynamics CRM Server 2011 servers are located, and then click Next.
The domain you specify must be a sub-domain of the Web Application Server Domain
specified in the previous step. By default, "auth." is pre-pended to the Web Application
Server Domain.
Important
The external domain is used by the AD FS 2.0 server when retrieving the Microsoft Dynamics CRM IFD federationmetadata.xml file.
The external domain must not contain an organization name.
The external domain must not contain an underscore character (“_”).
The external domain must be valid for the SSL certificate's common name or names.
The external domain must be set to resolve correctly in DNS to your Microsoft Dynamics CRM server holding the Web Application Server role.
Example domain:
External Domain: auth.contoso.com:444
6. On the System Checks page, review the results, fix any problems, and then click Next.
7. On the Review your selections and then click Apply page, verify your selections, and then click Apply.
8. Click Finish.
9. Run the following command at a command prompt: iisreset
26
10. If you have not already done so, add host records in DNS for the IFD endpoints (for example: orgname.contoso.com, auth.contoso.com, dev.contoso.com)
1. Open a Windows PowerShell prompt.
2. Add the Microsoft Dynamics CRM Windows PowerShell snap-in:
PS > Add-PSSnapin Microsoft.Crm.PowerShell
3. Get the IFD settings:
PS > $ifd = Get-CrmSetting -SettingType "IfdSettings"
4. Configure the IFD object:
PS > $ifd.Enabled = 1 (or $true)
PS > $ifd.DiscoveryWebServiceRootDomain =
Discovery_Web_Service_Domain
PS > $ifd.ExternalDomain = External_Server_Domain
PS > $ifd.OrganizationWebServiceRootDomain=
Organization_Web_Service_Domain
PS > $ifd.WebApplicationRootDomain =
Web_Application_Server_Domain
where:
1 = "true".
Discovery_Web_Service_Domain is the discovery Web service domain.
External_Server_Domain is the external server domain.
Organization_Web_Service_Domain is the organization Web server domain.
Web_Application_Server_Domain is the Web application server domain.
For the domain paths, the values for the paths must be in the form:
server:port
or
server.domain.tld:port,
where:
server is the computer name
domain is the complete sub domain path where the computer is located
tld is the top level domain, such as com or org
The :port designation is required if you are not using the standard http port (80) or https port (443).
To Configure an Internet-facing deployment using Windows PowerShell
27
Typically, in a Full Server or Front-end Server role deployment, the path values are the
same. However, if you deploy Microsoft Dynamics CRM on multiple servers with separate
server roles, that is, where the Web Application Server, Organization Web Service, or
Discovery Web Service server roles are located on different servers, these path values
will be different:
Web Application Server. WebApplicationServerName.domain.tld:port
Organization Web Service. OrganizationWebServiceServerName.domain.tld:port
Discovery Web Service. DiscoveryWebServiceServerName.domain.tld:port
5. Set the Internet-facing deployment object.
PS > Set-CrmSetting $ifd
Configure the AD FS 2.0 server for IFDAfter you have enabled IFD on the Microsoft Dynamics CRM Server 2011 you will need to create
a relying party for the IFD endpoint on the AD FS 2.0 server.
Configure relying party trusts
1. On the computer that is running Windows Server where the AD FS 2.0 federation server is installed, start AD FS 2.0 Management.
2. On the Actions menu located in the right column, click Add Relying Party Trust.
3. In the Add Relying Party Trust Wizard, click Start.
4. 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. For example,
https://auth.contoso.com:444/FederationMetadata/2007-06/FederationMetadata.xml.
Type this URL in your browser and verify that no certificate-related warnings appear.
5. Click Next.
6. On the Specify Display Name page, type a display name, such as CRM IFD Relying Party, and then click Next.
7. On the Choose Issuance Authorization Rules page, leave the Permit all users to access this relying party option selected, and then click Next.
8. On the Ready to Add Trust page, click Next, and then click Close.
9. 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.
Important
To configure relying party trusts
28
Be sure the Issuance Transform Rules tab is selected.
10. In the Claim rule template list, select the Pass Through or Filter an Incoming Claim template, and then click Next.
11. Create the following rule:
Claim rule name: Pass Through UPN (or something descriptive)
Add the following mapping:
i. Incoming claim type: UPN
ii. Pass through all claim values
12. Click Finish.
13. 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:
Claim rule name: Pass Through Primary SID (or something descriptive)
Add the following mapping:
i. Incoming claim type: Primary SID
ii. Pass through all claim values
14. Click Finish.
15. In the Rules Editor, click Add Rule,
16. In the Claim rule template list, select the Transform an Incoming Claim template, and then click Next.
17. Create the following rule:
Claim rule name: Transform Windows Account Name to Name (or something descriptive)
Add the following mapping:
i. Incoming claim type: Windows account name
ii. Outgoing claim type: Name
iii. Pass through all claim values
18. Click Finish, and when you have created all three rules, click OK to close the Rules Editor.
Test external claims-based authenticationYou should now be able to access Microsoft Dynamics CRM Server 2011 externally using claims
authentication. Browse to your Microsoft Dynamics CRM Server 2011 Web site's external address
(for example: https://orgname.contoso.com:444). You should see a screen like the following:
29
Sign in and verify that you have external access to Microsoft Dynamics CRM Server 2011.
Claims Access and Partner CompaniesTo provide access to an additional federation server, for example, if you want a partner company
to have access to your Microsoft Dynamics CRM Server 2011 data, the partner company’s
federation server needs to have a trust relationship with your AD FS 2.0 federation server. For
more information about federation trusts, see Provide Users in Another Organization Access to
Your Claims-Aware Applications and Services (http://go.microsoft.com/fwlink/?LinkID=203813).
1. On the AD FS 2.0 server used with Microsoft Dynamics CRM Server 2011, create a claims provider trust for the partner company’s federation server. Add a claims rule to pass through UPN claims. Use the following settings:
Data Source: the path to the partner company’s federation data.
Claim rule template: Pass Through or Filter an Incoming Claim
Claim rule name: Pass through UPN (or something descriptive)
To set up a federation trust
30
Incoming claim type: UPN
Pass through all claim values
2. On the partner company’s federation server, create a relying party trust for the AD FS 2.0 server used with Microsoft Dynamics CRM Server 2011. Use the following settings:
Data Source: the path to the AD FS 2.0 server used with Microsoft Dynamics CRM Server 2011 federation data.
Rule type: Issuance Transform Rules
Claim rule template: Send LDAP Attributes as Claims
Claim rule name: LDAP UPN --> Claim UPN (or something descriptive)
LDAP Attribute: User-Principal-Name
Outgoing Claim Type: UPN
Configure Microsoft Dynamics CRM for Outlook to Use Claims-based AuthenticationMicrosoft Dynamics CRM 4.0 for Outlook with Update Rollup 7 or later is compatible with
Microsoft Dynamics CRM Server 2011. In an Internet-facing deployment (IFD), the URL of the
Microsoft Dynamics CRM 4.0 Server will probably change when you upgrade it to Microsoft
Dynamics CRM Server 2011. This URL change is likely because of the requirements for Secure
Sockets Layer (SSL) and the Internet Information Services (IIS) binding limitations. If there is a
URL change, either upgrade to Microsoft Dynamics CRM 2011 for Outlook or use the
Configuration Wizard to point Microsoft Dynamics CRM 4.0 to the new URL. For more
information, see Microsoft Dynamics CRM 4.0 for Outlook compatibility with Microsoft Dynamics
CRM 2011 Server (http://go.microsoft.com/fwlink/?LinkID=211027) in the Microsoft Dynamics
CRM Planning Guide.
You can connect Microsoft Dynamics CRM for Outlook on one Active Directory domain to a
Microsoft Dynamics CRM server in a different Active Directory domain. You can do this when the
credentials that Microsoft Dynamics CRM for Outlook uses on its own domain are authenticated
by a server on the other domain. To make this work, use AD FS 2.0.
In an environment that supports claims-based authentication, a client (such as Microsoft
Dynamics CRM for Outlook) can use federated AD FS 2.0 to connect to the Microsoft Dynamics
CRM Server 2011. The client obtains credentials through federated AD FS 2.0 and uses these
credentials to be authenticated on a different Active Directory domain to connect to the Microsoft
Dynamics CRM Server 2011.
After federation is established, the client can use either its current domain credentials or different
domain credentials when attempting to connect to the Microsoft Dynamics CRM Server 2011. You
specify which domain and which Active Directory to use through the home realm - an identity
provider that authenticates the user.
31
Set up a client for claims-based authenticationIn the following procedure, you create a registry key on a single client computer. You may also
want to consider using group policy so that you can make this registry change on multiple client
computers.
1. Make sure that a Web browser on the client can reach the Microsoft Dynamics CRM Server 2011 URL with no certificate errors. If you use a self-signed certificate, you will need to import it to avoid certificate errors. After you import any needed certificates, you should be able to connect to the organization by using non-federated credentials.
2. To use federated credentials, specify HomeRealmUrl in the Windows registry, as shown here:
a. With Administrator privileges, open the Registry Editor.
b. Open the registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\MSCRMClient.
c. Create the registry string HomeRealmUrl.
d. Enter the value data of the federated AD FS 2.0. This URL will end in /adfs/services/trust/mex. For example, https://adfs.contoso.com/adfs/services/trust/mex.
e. Close the Registry Editor.
f. Configure Microsoft Dynamics CRM for Outlook. For more information, see Task 2: Configure Microsoft Dynamics CRM for Outlook (http://go.microsoft.com/fwlink/?LinkID=210778) in the Microsoft Dynamics CRM Installing Guide.
You should now be able to connect Microsoft Dynamics CRM for Outlook to Microsoft Dynamics
CRM Server 2011 by using claims-based authentication.
Use an administrative template (.adm) fileModify the following sample data to create an .adm file to use group policy to publish the
HomeRealmUrl registry setting.
CLASS MACHINE
CATEGORY "Microsoft Dynamics CRM"
KEYNAME "Software\Policies\Microsoft\MSCRMClient"
POLICY "Home Realm URL"
EXPLAIN "Allow Administrator to specify the Home Realm URL for federated domains."
PART "Specify Home Realm URL (example:
https://adfs.contoso.com/adfs/services/trust/mex" EDITTEXT REQUIRED
VALUENAME "HomeRealmUrl"
END PART
To set up the client
32
END POLICY
END CATEGORY
For more information, see Administrative Template File Format (http://go.microsoft.com/fwlink/?
LinkID=182923).
Additional ConsiderationsThe following section covers additional considerations for your claims-based authentication
deployment.
Manually updating a claims providerBy default, AD FS 2.0 updates a relying party trust from federation metadata every 24 hours. You
should manually update the relying party trust metadata if you make any of the following changes:
You change the encryption certificate used for claims-based authentication.
You change the root domain Web addresses. To view these settings:
a. Start the Deployment Manager.
b. In the Actions pane, click Properties.
c. Click the Web Address tab.
You create a new organization.
You change the domains for the server roles for Microsoft Dynamics CRM Server 2011 entered in the IFD Configuration Wizard. To view these settings:
a. Start the Deployment Manager.
b. In the Deployment Manager console tree, right-click Microsoft Dynamics CRM, and then click Configure Internet-Facing Deployment.
c. Click Next.
You change the external domain.
You change the certificate common name. To view these settings:
a. Start the Deployment Manager.
b. In the Deployment Manager console tree, right-click Microsoft Dynamics CRM, and then click Configure Claims-Based Authentication.
c. Click Next twice.
1. Click Start, point to Administrative Tools, and then click AD FS 2.0.
2. Click the AD FS 2.0\Trust Relationships folder, and then click either Claims Provider Trusts or Relying Party Trusts, depending on which trust you want to update.
3. In the details pane, right-click the claims provider trust or relying party trust that you want to update from federation metadata.
To manually update a relying party trust from federation metadata
33
4. Click Update from Federation Metadata, and then click Update.
You can specify how often the Federation Service will monitor the federation metadata of relying
parties and claims providers that are enabled for federation metadata monitoring.
1. Open a Windows PowerShell prompt.
2. Set the monitoring interval:
PS > Set-ADFSProperties -MonitoringInterval <int>
where:
<int> is the interval in minutes
Claims-based authentication and security token expirationThe lifetime of a default security token for a claims-based authentication deployment using AD FS
2.0 is 60 minutes. By default, Microsoft Dynamics CRM Server 2011 is configured to display the
Authentication is Required dialog box 20 minutes before the token expires.
In the Authentication is Required dialog box, if you click Cancel, the token expires as indicated.
When the security token expires, you will need to start a new browser session to Microsoft
Dynamics CRM to access your data. Any unsaved changes will be lost.
In the Authentication is Required dialog box, if you click Sign In, the Sign-Out page appears.
When you close the Sign-Out page, one of the following occurs:
If you have not deployed an Internet-facing deployment (IFD), you will automatically re-authenticate with domain credentials and a new security token will be issued.
If you have an IFD deployment, you will be required to re-authenticate by entering your credentials on the login page.
By using Windows PowerShell, you can change the TokenLifetime property for the relying party
objects that you created from 60 minutes to a longer period, such as 480 minutes (8 hours):
1. Open a Windows PowerShell prompt.
2. Add the AD FS 2.0 snap-in to the Windows PowerShell session:
PS > Add-PSSnapin Microsoft.Adfs.PowerShell
3. Configure the relying party token lifetime:
PS > Get-ADFSRelyingPartyTrust -Name "relying_party"
PS > Set-ADFSRelyingPartyTrust -Targetname "relying_party" -
TokenLifetime 480
where:
relying_party is the name of the relying party that you created.
To set the interval for monitoring metadata for trust partners using Windows PowerShell
34
System time synchronization and claims-based authenticationThe system time on the computer running the security token service (STS) must be synchronized
with the computer running Microsoft Dynamics CRM. Servers on the same domain are normally
synchronized automatically through the Windows Time service. If your STS server and Microsoft
Dynamics CRM Server 2011 are on separate domains, you should periodically monitor the
system time on the two servers to ensure that the time difference is not greater than 5 minutes.
Enabling AD FS 2.0 token signingBy default, Microsoft Dynamics CRM Server 2011 does not check for the presence or validity of
the AD FS 2.0 token signing certificate and does not use AD FS 2.0 token signing. To enable
validation and use of the AD FS 2.0 token-signing certificate, create the
TrustedIssuerCertificateValidation registry entry on all Front End Servers.
1. Click Start, click Run, type regedit, and then press Enter.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM
3. Create the following registry entry:
Value name: TrustedIssuerCertificateValidation
Value type: String
Value data: (one of the following)
Value Data Description
None No validation of the certificate is done.
PeerTrust The certificate is valid if it is in the trusted
people store.
PeerOrChainTrust The certificate is valid if the chain builds
to a certification authority in the trusted
root store.
PeerOrChainTrust The certificate is valid if it is in the trusted
people store, or if the chain builds to a
certification authority in the trusted root
store.
nNote
The Custom value is not supported in Microsoft Dynamics CRM Server 2011.
4. Close the Registry Editor.
To create the TrustedIssuerCertificateValidation registry
35
For more information, see X509CertificateValidationMode Enumeration
(http://go.microsoft.com/fwlink/?LinkID=209771).
Note the following information regarding enabling AD FS 2.0 token signing:
By default, AD FS 2.0 creates a self-signed certificate for signing tokens.
If token signing is enabled, when the signing certificate expires AD FS 2.0 creates a
new signing certificate. The new signing certificate will need to be moved to the
Trusted Root Certification Authorities store of all Microsoft Dynamics CRM Server
2011 servers.
To use the self-signed certificate, do the following:
1. On the AD FS 2.0 server, open AD FS 2.0 Management, expand Service, and then expand Certificates.
2. Double-click the token-signing certificate, click the Details tab, and then click Copy to File.
3. Proceed through the Certificate Export Wizard using default values and save the certificate.
1. On the Microsoft Dynamics CRM Server 2011 server, open MMC and add the Certificates Manager Snap-in.
2. Import the token-signing certificate into the Trusted Root Certification Authorities store.
You can use a signed certificate from a trusted CA instead of the self-signed certificate generated by AD FS 2.0.
For more information, see Certificate Requirements for Federation Servers
(http://go.microsoft.com/fwlink/?LinkId=182466).
Certificate name length limitThe name of the encryption certificate selected in the Configure Claims-Based Authentication
wizard cannot be longer than 128 characters.For more information, see the KB article: Certificate
name length error (http://go.microsoft.com/fwlink/?LinkID=214096).
Include AD FS servers in the local intranet zoneYou should include AD FS 2.0 servers used in Microsoft Dynamics CRM Server 2011 claims
authentication in the local intranet zone of Microsoft Internet Explorer. This is necessary to allow
Internet Explorer to pass credentials to AD FS 2.0 for internal use of claims-based authentication.
1. Open Internet Explorer.
Note Export the signing certificate. Import the signing certificate.To add AD FS 2.0 servers to the local intranet zone - Microsoft Internet Explorer 8
36
2. Click the Tools button, and then click Internet Options.
3. Click the Security tab, and then click Local intranet.
4. Click Sites.
5. Click Advanced.
6. In Add this website to the zone, type the URL of the AD FS 2.0 server. For example, https://sts1.contoso.com.
7. Click Add.
8. Click Close, and then click OK twice.
Send us your feedback about this documentWe appreciate hearing from you. To send your feedback, click the following link and type your
comments in the message body.
The subject-line information is used to route your feedback. If you remove or modify the
subject line, we may be unable to process your feedback.
Send feedback (http://go.microsoft.com/fwlink/?LinkID=212006)
Note
37