News Ticker

Single Sign On for Microsoft Dynamics CRM Online (Part 2) – Federate Identity Model

In the previous post, we discussed about Synchronized Identity model of Single Sign On with Azure Active Directory and local Active Directory for a Dynamics CRM Online deployment. While Synchronized Identity is a Same Sign On experience, Federate Identity is a Single Sign On model. Federate Identity allows users to authenticate against the local Active Directory and adds the identity federation dimension.

Federated Identity

Image source:

What is Federated Identity model

In this model, users sign in with their corporate user ID to access Dynamics CRM and unlike Synchronized Identity model, authentication always happen on-premises against the organisation’s identity infrastructure. Thus users are offered a “true” single sign on.

With the previously discussed Synchronized Identity model or “same sign on” model, users will have to re-enter at least once the same on-premises credentials when accessing Dynamics CRM.

With Federate Identity Model, IT professionals need to manage password policy only on-premises and the on-premises infrastructure stores and controls the password policy. Password reset also occurs on-premises only.

Image source: “”

Image source: “”

How to achieve Federated Identity

Directory Synchronization is required for this model in order to keep the on-premises identity infrastructure in sync with Azure AD/Office 365 tenant. Federated Identity is achieved by installing and configuring Active Directory Federation Services (AD FS).

Image source: “Azure AD/Office 365 Single Sign-On with AD FS in Windows Server 2012 R2 – Part 1 (Microsoft Whitepaper)”

Image source: “Azure AD/Office 365 Single Sign-On with AD FS in Windows Server 2012 R2 – Part 1 (Microsoft Whitepaper)”


Pre-requisites for installing Federated Identity

  1. Active Directory domain controllers must run at least Windows Server 2008 or higher with a functional level of mixed mode or native mode.
  2. The client windows must run latest service packs of Windows 7.8/8.1/10

Support for multi-factor authentication (MFA) can be provided if such a solution is deployed on-premises.

When do I choose Federated Identity over Synchronized Identity

Implementing Federated identity model requires both to deploy, operate and maintain a highly available fault-tolerant federation infrastructure to deliver the federation service. AD FS provides the security tokens that needed by Azure Active Directory for Office365 tenant to authenticate a user. In the event of Security Token Service (STS) becomes unavailable, the possibility to fall backing to password sync is offered by Azure AD.

Generally, reasons for choosing Federate Identity model correspond to a series of advanced scenarios and relate to the following two distinct areas:

  1. Leveraging an already existing infrastructure.
  2. Complying with policy requirements.

 Leveraging an already existing infrastructure

  • Organisation may already have invested in Federated Identity Infrastructure based on AD FS.
  • Organisation may already been using Microsoft Forefront Identity Management (FIM) 2010 R2 to manage the on-premises identity lifecycle with multiple Active Directory and/or non-MS repositories, the Azure AD connector can be added, as a new connector, to easily integrate with Azure AD.

Complying with policy requirements

  • A true Single Sign On is required and not a “Same Sign On” through password hash sync.
  • Credentials (Password) synchronization to public cloud isn’t permitted as per organisation’s security policy.
  • Conditional Access Control is a security policy requirement. Using ADFS extranet access to Dynamics CRM application based on multiple factors, including user, network location, device (AD Workplace Join) can be controlled.
  • Audit of authentication attempts to Azure AD/Office365 is required. Login time restrictions are imposed. For example, if we wish to log out an idle user after 8 hrs. Using ADFS if a user is successfully authenticated and has consequently obtained a security token to gain access to Azure AD/Office 365, the security token’s life time can be restricted to a specified duration.
  • Disabling a user account must be immediate. ADFS bases STS solution can immediately block a user account thanks to its reliance on local AD. In the synchronized identity model, the replication of user accounts – including attributes like status disabled – occurs by default every 3 hours, meaning that the user could at most be able to logon to Azure AD during this delay.

A decision matrix for the identity models

The following table suggests a decision matrix to synthetize the considerations regarding the two identity models: Synchronized Identity and Federated Identity.

Identity Model Comparison Matrix

* With password sync

** including Azure AD Basic or Premium capabilities

*** Using user password reset



In this blog post, we have discussed the Federated Identity basics and the conditions which may demand the same to be implemented. In the next post I’ll delve into the understanding the authentication flow in case of Federated Identity and finish the series by describing how to support Multi-Factor Authentication using ADFS.

About Dipankar Bhattacharya (59 Articles)
A multi-skilled Dynamics 365 Professional with strong experience in delivering IT projects especially across multiple industries. A Microsoft technology evangelist, a regular speaker at tech events, blogger and avid reader. Certified IT Architect and well versed in Solution Architecture of Business Applications using Microsoft platforms like Dynamics 365, Azure and Office 365.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: