When Dynamics CRM platform is configured for claims based access, the following error will be recorded in ADFS event log.

 

Open PowerShell command window and type in Get-AdfsRelyingPartyTrust -Name [RP Name]

The properties EncryptionCertificateRevocationCheck and SiginingCertificateRevocationCheck should be set to none by running the following commands, CRM in the commands below is the name of he Replying Party Trust set up in ADFS which will change according how RP is set up.:

Set-AdfsRelyingPartyTrust -TargetName CRM -EncryptionCertificateRevocationCheck None

Set-AdfsRelyingPartyTrust -TargetName CRM -SigningCertificateRevocationCheck None

 

As part of CRM implementation if you need to see the ER diagram for the various entities used in custom solution download the ER diagram generator tool here

After configuring CBA (claims-based authentication) for CRM 2015 if you get the following error while browsing to the organization:

 

Run the following power shell command to set the CRL (Certificate Revocation List) check to none and then the claims from ADFS should flow through to enable browsing to the organization.

 

In Step1 we looked at configuring the CRM platform with the aid of Deployment Manager GUI to enable claims based authentication. In this post we will look at the steps involved in configuring Relying Party trust in AD FS. Microsoft has provided a detailed guide here. I did find some issues while configuring the claims rule set and will highlight it as we walk through the steps.

1. Create rule for Claims provider trust (Active Directory) for UPN

Right click choose Edit Claims and then “Add Rule..” in the dialog box

Click Finish to add this Rule, the Acceptance Transform Rules looks like

 

2. Create Relying Party trust, choose Relying Party Trust in the AD FS Management console.

Once the above steps are completed the Edit Claims Rules dialog box opens up where we configure the Rules.

 

 

Edit Global Primary Authentication policy to enable Forms Based Authentication.

 

Once the above steps are completed go DEV-WFE01 and try accessing the CRM organization I have set up an org called ACM. (could be any name)

https://xrm.dev.local/ACM comes up with the following:

This will redirect to:

https://sts.dev.local/adfs/ls/wia?wa=wsignin1.0&wtrealm=https%3a%2f%2fxrm.dev.local%2f&wctx=rm%3d1%26id%3dc68e12fd-17d4-4b11-aa86-1cd38f8c1784%26ru%3d%252fACM%252fdefault.aspx&wct=2015-11-22T19%3a12%3a23Z&wauth=urn%3afederation%3aauthentication%3awindows

and once successful will display the main page of CRM Organization:

 

 

This completes configuring claims based authentication for Dynamics CRM platform

 

 

 

In the article there is description of how claims based authentication works in the context of CRM platform. In this post I will details the steps involved to get this working for the deployment scenario as shown here. The detailed information will be split into posts viz., Step 1 & Step2

Pre-Requisites:

1. Setup and configure Active Directory Fedaration Services (AD FS) on Windows Server 2012 R2 and the steps involved are described here
2. Enabled CRM platform for Claim-based Authentication and this is done through Deployment Manager. The steps are detailed below with the a series of screen snap shots.
3. Set up Relying-Party trust in AD FS

• Open Deployment Manager GUI and the summary screen will indicate whether claims-based authentication is enabled/disabled.

• Click on Configure Claims-Based Authentication and if the access point is not set to use HTTPS the following will be displayed

• Click on Action > Properties and enter the following settings

• Now click on Configure Claims-Based Authentication

• Click on View the log file to make note of the url that needs to be added to the Relying Party trust in the AD FS management console.

Things to Check:

By default the CRM platform set up does not configure the web site for SSL. This step needs to done manually.

Once the above steps are completed. You need to ensure that browsing to the Internal Federation Metadata URL as indicated above returns content without any errors. If the following error is displayed then the cause will be missing read permissions for the private key on the certificate.

Resolution: Open MMC and assign read permissions to service account used for the certificate in use.

Once the internal federation metadata URL loads the XML data without any errors the expected Claims set from ADFS is listed as below and while configuring ADFS the outgoing claims will be upn,name and primarysid

The following are the guidelines specific to SQL Server instance to be used for CRM 2015 platform:

• Don’t modify system tables on the SQL instance where Dynamics CRM is to be deployed.
• Full-text indexing must be installed.
• CRM organization databases have auto growth setting of 256MB. For intensive database transactions increase the auto growth value to improve performance.
• Set Max degree of parallelism to 1 in SQL Server to improve the overall application performance on multiprocessor systems.

Dynamics CRM platform creates two databases:

• MSCRM_CONFIG: Contains the CRM metadata, such as configuration and location information specific to each organization database.
• OrganizationName_MSCRM: The main organization database where CRM data is stored viz., entity (aka table) records, activities etc. There will be several of these organization databases depending on the number of the organizations setup using CRM Deployment Manager.

SQL Server Connection & SSRS:

• Dynamics CRM connection to SQL Server is only via Windows Authentication.
• Dynamics CRM Reporting Extensions are data processing extensions and are installed on the Microsoft SQL Server Reporting Services server. Two data processing extensions: Fetch data processing extension for Fetch-based reports and SQL data processing extensions.
• The identity account running the instance of Microsoft SQL Server Reporting Services must be added to PrivReportingGroup AD security group.
• Separate deployments of Microsoft Dynamics CRM cannot share one SQL Server Reporting Services server. But a single deployment of Microsoft Dynamics CRM can use the same SQL Server Reporting servers.

For Internal Access

1. The client sends a request to access the Dynamics CRM website.
2. IIS refuses the connection and sends a HTTP 302 and redirect to ADFS
3. The client sends a request for a security token to ADFS
4. ADFS returns a HTTP 401.1 error indicating the client must supply a Kerberos ticket
5. The client sends an Kerberos Authentication request to Active Directory
6. Active Directory validates the client and sends a Kerberos ticket
7. The client sends a request for security token to ADFS along with the Kerberos ticket.

Typically for internal access the Client logons to internal domain example mydomain.com and is already validated by Active Directory and hence the Kerberos ticket is already available so steps 4 through to 7 are skipped.

8. ADFS provides a security token containing claims for providing access to CRM data
9. The client sends the security token containing claims as obtained from ADFS to CRM server
10. The CRM server decrypts and validates the security token and presents the user with the information.

For External Access

The flow is similar to Internal Access with the exception of the following:

• The Client will not be logging onto the domain directly and hence there is no Kerberos ticket.
• The ADFS will present the client a logon page to select a attribute store at which point they enter the credentials which are then validated against Active Directory.