AD Connect Federation High-Availability Identity SSO

Azure AD Connect – How to extend your Active Directory Domain to Azure AD ? Part 3 | Federation


What is exactly a federated solution ?

It enables applications to redirect to Azure AD for user authentication instead of prompting for its own password. Federated single sign-on is supported for applications that support protocols such as SAML 2.0, WS-Federation, or OpenID Connect, and is the richest mode of single sign-on.

It implements an authentication mechanism that can use federated identity. It separates user authentication from the application code, and delegate authentication to a trusted identity provider. This can simplify development and allow users to authenticate using a wider range of identity providers (IdP) while minimizing the administrative overhead. It also allows you to clearly decouple authentication from authorization.

The trusted identity providers include corporate directories, on-premises federation services, other security token services (STS) provided by business partners, or social identity providers that can authenticate users who have, for example, a Microsoft, Google, Yahoo!, or Facebook account.

The following picture illustrates the Federated Identity pattern when a client application needs to access a service that requires authentication. The authentication is performed by an IdP that works in concert with an STS. The IdP issues security tokens that provide information about the authenticated user. This information, referred to as claims, includes the user’s identity, and might also include other information such as role membership and more granular access rights.




This model is often called claims-based access control. Applications and services authorize access to features and functionality based on the claims contained in the token. The service that requires authentication must trust the IdP. The client application contacts the IdP that performs the authentication. If the authentication is successful, the IdP returns a token containing the claims that identify the user to the STS (note that the IdP and STS can be the same service). The STS can transform and augment the claims in the token based on predefined rules, before returning it to the client. The client application can then pass this token to the service as proof of its identity.

Why would you use federated identity ?

  • Single sign-on in the enterprise. You want your employees the possibility to single sign-on and authenticate outside of the corporate security boundary ( cloud-based application) without having them to re-sign-on every time they access the application.
  • Expend your application to multiple partners. You want your corporate employees to single sign-on and authenticate but also want your business partners who dont have accounts in the company to access the application. This is common in business-to-business applications, applications that integrate with third-party services, and where companies with different IT systems have merged or shared resources.
  • Federated identity in SaaS applications. In this scenario independent software vendors provide a ready-to-use service for multiple clients or tenants. Each tenant authenticates using a suitable identity provider. For example, business users will use their corporate credentials, while consumers and clients of the tenant will use their social identity credentials.



  1. The user tries to access an application, for example, Outlook Web App or Box.
  2. If the user is not already signed in, the user is redirected to the Azure AD User Sign-in page.
  3. The user enters their username into the Azure AD sign in page, and then hits tab.
  4. Azure AD detects HRD (Home Realm Discovery) based on the domain and submits a token request to the federated IdP (e.g. AD FS, PingFederate, ect.)
  5. AD FS receives the SAML Request
  6. AD FS prompts for forms-based authentication with username and password (Windows Integrated Authentication may be performed if applicable)
  7. AD FS performs a Username and Password validation to local Active Directory
  8. Successful update to AD FS
  9. AD FS returns a token Response with claims based on rules for Azure AD’s original request
  10. Azure AD evaluates the response and responds to the user as appropriate. For example, Azure AD either signs the user in immediately or requests for Azure Multi-Factor Authentication
    (Note: this is where Conditional Access is applied).
  11. If the user sign-in is successful, the user can access the application.

Key Points

  • Effort. A federated authentication system relies on an external trusted system to authenticate users. Some companies want to reuse their existing federated system investment with their Azure AD hybrid identity solution. The maintenance and management of the federated system falls outside the control of Azure AD. It’s up to the organization by using the federated system to make sure it’s deployed securely and can handle the authentication load.
  • Cost. Require a farm, at least 4 servers for the services to be highly-available. Use Azure AD Connect to interconnect the native federation.
  • User experience. The user experience of federated authentication depends on the implementation of the features, topology, and configuration of the federation farm. Some organizations need this flexibility to adapt and configure the access to the federation farm to suit their security requirements. For example, it’s possible to configure internally connected users and devices to sign in users automatically, without prompting them for credentials. This configuration works because they already signed in to their devices. If necessary, some advanced security features make users’ sign-in process more difficult.
  • Advanced scenarios. A federated authentication solution is usually required when customers have an authentication requirement that Azure AD doesn’t support natively. Consider the following common requirements:
    • Authentication that requires smartcards or certificates.
    • On-premises MFA servers or third-party multifactor providers.
    • Authentication by using a third-party authentication solutions.
    • Sign in that requires an sAMAccountName, for example, DOMAIN\username, instead of a User Principal Name (UPN), for example,
  • Business continuity. The federated farm should be configured in an internal network and perimeter network topology to ensure high availability for authentication requests. Deploy password hash synchronization along with federated authentication as a backup authentication method when the primary authentication method is no longer available. An example is when the on-premises servers aren’t available.
  • Architecture complexity. Federated systems typically require a more significant investment in on-premises infrastructure. Most organizations choose this option if they already have an on-premises federation investment. And if it’s a strong business requirement to use a single-identity provider. Federation is more complex to operate and troubleshoot compared to cloud authentication solutions.
  • Access rights granularity. Authentication tools make it possible to configure access control based on role claims contained in the authentication token. This is often referred to as role-based access control (RBAC), and it can allow a more granular level of control over access to features and resources.
  • Claim-based specifications. Claims-based authentication using social identity providers doesn’t usually provide information about the authenticated user other than an email address, and perhaps a name. Some social identity providers, such as a Microsoft account, provide only a unique identifier. The application usually needs to maintain some information on registered users, and be able to match this information to the identifier contained in the claims in the token. Typically this is done through registration when the user first accesses the application, and information is then injected into the token as additional claims after each authentication.
  • Manage the identity providers. If there’s more than one identity provider configured for the STS, it must detect which identity provider the user should be redirected to for authentication. This process is called home realm discovery. The STS might be able to do this automatically based on an email address or user name that the user provides, a subdomain of the application that the user is accessing, the user’s IP address scope, or on the contents of a cookie stored in the user’s browser.


Comparing methods

Consideration Password hash synchronization + Seamless SSO Pass-through Authentication + Seamless SSO Federation with AD FS
Where does authentication happen? In the cloud In the cloud after a secure password verification exchange with the on-premises authentication agent On-premises
What are the on-premises server requirements beyond the provisioning system: Azure AD Connect? None One server for each additional authentication agent Two or more AD FS servers

Two or more WAP servers in the perimeter/DMZ network

What are the requirements for on-premises Internet and networking beyond the provisioning system? None Outbound Internet access from the servers running authentication agents Inbound Internet access to WAP servers in the perimeter

Inbound network access to AD FS servers from WAP servers in the perimeter

Network load balancing

Is there an SSL certificate requirement? No No Yes
Is there a health monitoring solution? Not required Agent status provided by Azure Active Directory admin center Azure AD Connect Health
Do users get single sign-on to cloud resources from domain-joined devices within the company network? Yes with Seamless SSO Yes with Seamless SSO Yes
What sign-in types are supported? UserPrincipalName + password

Windows Integrated Authentication by using Seamless SSO

Alternate login ID

UserPrincipalName + password

Windows Integrated Authentication by using Seamless SSO

Alternate login ID

UserPrincipalName + password

sAMAccountName + password

Windows Integrated Authentication

Certificate and smart card authentication

Alternate login ID

Is Windows Hello for Business supported? Key trust model

Certificate trust model with Intune

Key trust model

Certificate trust model with Intune

Key trust model

Certificate trust model

What are the multifactor authentication options? Azure MFA

Custom Controls with conditional access*

Azure MFA

Custom Controls with conditional access*

Azure MFA

Azure MFA server

Third-party MFA

Custom Controls with conditional access*

What user account states are supported? Disabled accounts
(up to 30-minute delay)
Disabled accounts

Account locked out

Password expired

hours

Disabled accounts

Account locked out

Password expired

hours

What are the conditional access options? Azure AD conditional access Azure AD conditional access Azure AD conditional access

AD FS claim rules

Is blocking legacy protocols supported? Yes Yes Yes
Can you customize the logo, image, and description on the sign-in pages? Yes, with Azure AD Premium Yes, with Azure AD Premium Yes
What advanced scenarios are supported? Smart password lockout

Leaked credentials reports

Smart password lockout Multisite low-latency authentication system

AD FS extranet lockout

Integration with third-party identity systems

Where to verify Current User Sign-in settings in your environment

Verify your current user sign-in settings by logging into the Azure AD portal with a Global Administrator account.


0 comments on “Azure AD Connect – How to extend your Active Directory Domain to Azure AD ? Part 3 | Federation

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s

%d bloggers like this: