Unit 6: Implement and Manage Federation

1. What Is Federation?

Federation in Microsoft Entra ID (Azure AD) allows organizations to delegate authentication to an on-premises identity provider (IdP) such as Active Directory Federation Services (AD FS) or PingFederate.

When you federate your domain, Microsoft Entra ID does not perform authentication directly. Instead, it redirects users to your on-premises IdP to verify their credentials. Once authenticated, the IdP issues a security token that Entra ID trusts. This process allows users to sign in to cloud resources using their on-premises passwords — but with more advanced control and custom policies.

2. Why Use Federation?

Federation is typically used by large enterprises or organizations that have:

• Strict compliance or security requirements that prevent password hashes from being stored or synchronized in the cloud.
• The need for advanced authentication scenarios, such as:
• Smart card or certificate-based authentication.
• Custom multi-factor authentication (MFA) solutions.
• Third-party identity providers integrated with existing infrastructure.
• A complex environment with multiple forests or existing AD FS deployments.
• A requirement for custom claim rules to control access decisions at the identity provider level.

Example: A government agency must comply with a regulation requiring smart card-based authentication for all users. Since neither PHS nor PTA supports smart card logins, federation using AD FS is the only viable option.

3. How Federation Works

Here’s the high-level process of how a federated authentication flow occurs:

• The user navigates to a Microsoft cloud resource (like Outlook Web App or SharePoint Online).
• Microsoft Entra ID checks the domain suffix of the username (e.g., @contoso.com) and sees that the domain is federated.
• Entra ID redirects the user’s authentication request to the organization’s AD FS endpoint (or PingFederate, depending on setup).
• The user authenticates with their credentials, smart card, or MFA on-premises.
• The on-premises federation service issues a security token that asserts the user’s identity.
• The token is sent back to Microsoft Entra ID, which validates it.
• Microsoft Entra ID issues its own OAuth or SAML token, granting access to the requested cloud service.

This allows for single sign-on (SSO) and centralized policy control — while authentication remains entirely under your organization’s management.

4. Components of a Federated Environment

A typical federated identity architecture consists of the following key components:

Diagram (Conceptual):

User → Web Browser → Microsoft Entra ID → Redirect to AD FS/WAP → AD DS

| | | |

| |<-- Trust ------>|<-- Federation Trust->|

5. Configuring Federation Using Microsoft Entra Connect

You can set up federation during or after installing Microsoft Entra Connect.

During Installation

• Launch Microsoft Entra Connect and select Customize.
• On the User sign-in screen, choose Federation with AD FS.
• Continue the setup until you reach Configure AD FS.

Steps for Federation Setup

• Specify AD FS Servers
• Add one or more servers where AD FS will be installed.
• These should be domain-joined and on the internal network.
• For production environments, deploy a redundant AD FS farm using load balancing.
• Specify Web Application Proxy (WAP) Servers
• These servers are deployed in the DMZ (external-facing network).
• They handle authentication requests from users outside the corporate network.
• WAP servers forward requests securely to internal AD FS servers.
• Configure the Service Account
• Choose a group managed service account (gMSA) or a regular domain user account for the AD FS service.
• This account is used by AD FS to access AD and sign tokens.
• Select the Domain to Federate
• Choose the custom domain (e.g., contoso.com) that will be federated.
• Microsoft Entra Connect configures trust settings in both AD FS and Microsoft Entra ID automatically.
• Complete Installation
• Entra Connect establishes the trust relationship, creates the relying party trust in AD FS, and sets up the endpoints required for SSO.

6. Prerequisites for Deploying Federation

Before deployment, ensure the following:

7. Federation with PingFederate

If your organization uses PingFederate instead of AD FS, Microsoft Entra Connect can integrate with it as the federation provider.

Requirements:

• PingFederate version 8.4 or later.
• A TLS/SSL certificate for the federation service name.
• A metadata exchange URL for federation trust establishment.

Configuration:

• In Entra Connect, choose Set up federation using PingFederate.
• Select the verified domain to federate.
• Export settings for the PingFederate admin.
• The PingFederate administrator imports these settings, updates configuration, and provides back the server URL and port.
• Entra Connect verifies and completes the setup.

Use case example: A multinational company already uses PingFederate for Salesforce and ServiceNow authentication. They can reuse the same IdP infrastructure to federate Microsoft Entra ID.

8. Managing Federation with Microsoft Entra Connect Tools

After federation is configured, you can rerun Entra Connect to manage and maintain it. Common federation management tasks include:

9. Alternate Sign-In ID

By default, Microsoft Entra ID uses the User Principal Name (UPN) for sign-in. However, if your on-premises environment uses non-routable UPN suffixes (like user@contoso.local) or you prefer to sign in with another attribute (e.g., mail), you can configure AlternateID.

Example:

• AD DS UPN: john.doe@contoso.local
• Email address: john.doe@contoso.com

You can set the mail attribute as the sign-in ID instead of UPN. When you enable federation with AlternateID, Microsoft Entra Connect automatically adjusts AD FS claim rules to use this attribute for authentication.

10. Device Writeback and Conditional Access

Device Writeback is a feature that allows devices registered in Microsoft Entra ID to be written back to on-premises Active Directory. This enables device-based Conditional Access for on-prem applications protected by AD FS.

Purpose:

• Ensures that only trusted, compliant devices can access applications.
• Allows AD FS to include the “isManaged” claim in authentication tokens, proving the device’s trust status.

How it works:

• Devices are registered with Microsoft Entra ID (e.g., via Intune or Windows Autopilot).
• Microsoft Entra Connect writes back the device objects to the RegisteredDevices container in AD.
• AD FS reads the device information and issues appropriate claims for Conditional Access policies.

Container locations in AD:

• Configuration: CN=Device Registration Configuration,CN=Services,CN=Configuration,<ForestDN>
• Registered devices: CN=RegisteredDevices,<DomainDN>

11. High Availability and Disaster Recovery

Because authentication now depends on your on-premises federation infrastructure, high availability is critical.

Best practices:

• Deploy at least two AD FS servers behind a load balancer.
• Deploy two WAP servers in the DMZ for external access.
• Use SQL Server or Windows Internal Database (WID) replication for AD FS configuration.
• Monitor AD FS health using Microsoft Entra Connect Health.
• Keep SSL certificates renewed and synchronized across all federation servers.

Disaster recovery option: If your federation service becomes unavailable, you can temporarily switch to Password Hash Synchronization (PHS) as a fallback authentication method to restore access quickly.

12. Federation vs Other Authentication Methods

13. Real-World Example

Scenario: A national healthcare organization requires two-factor authentication using physical smart cards for all employees. They must comply with healthcare data protection laws that prohibit password hashes from being stored outside the country.

Solution:

• Deploy AD FS farm with two servers in the data center.
• Deploy two Web Application Proxy servers in the DMZ.
• Configure federation with Microsoft Entra ID using Entra Connect.
• Implement smart card-based login via AD FS.
• Enable Device Writeback to enforce Conditional Access.

Result: Users authenticate using their smart cards to both on-prem and cloud apps. All authentication occurs within the organization’s trusted network, ensuring compliance and security.

14. Troubleshooting Common Federation Issues

15. Exam Tips

• Federation delegates authentication to AD FS or PingFederate.
• AD FS farms require WAP servers for external access.
• Use AlternateID for non-routable UPN domains.
• Device Writeback enables device-based Conditional Access.
• Federation supports smart cards, certificates, and third-party MFA.
• Always deploy redundant servers for HA.
• Use Entra Connect Health to monitor AD FS.
• If federation fails, you can temporarily switch to PHS to restore sign-ins.

16. Summary

Federation provides the most advanced, customizable, and policy-driven authentication model in hybrid identity.

It’s ideal for organizations that need:

• Centralized control of authentication policies.
• Support for legacy, third-party, or hardware-based authentication methods.
• Assurance that passwords never leave the corporate network.

Although more complex to deploy and maintain, federation gives administrators maximum flexibility — while still integrating seamlessly with Microsoft Entra ID and cloud services.