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.
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.
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).
Pre-requisites for installing Federated Identity
- Active Directory domain controllers must run at least Windows Server 2008 or higher with a functional level of mixed mode or native mode.
- 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:
- Leveraging an already existing infrastructure.
- 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.
* 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.