Section 5 – Implement an Identity Management Solution – Implement and manage hybrid identity – PTA, SSO and ADFS

In this section I will cover:

• implement and manage Pass-Through Authentication (PTA)
• implement and manage seamless Single Sign-On (SSO)
• implement and manage Federation (excluding manual ADFS deployments)

What is PTA?

Azure Active Directory (Azure AD) Pass-through Authentication allows your users to sign in to both on-premises and cloud-based applications using the same passwords. 

This feature is an alternative to Azure AD Password Hash Synchronization, which provides the same benefit of cloud authentication to organizations. However, certain organizations wanting to enforce their on-premises Active Directory security and password policies, can choose to use Pass-through Authentication instead.

Feature highlights

• Supports user sign-in into all web browser-based applications and into Microsoft Office client applications that use modern authentication.
• Sign-in usernames can be either the on-premises default username (UserPrincipalName) or another attribute configured in Azure AD Connect (known as Alternate ID).
• The feature works seamlessly with Conditional Access features such as Multi-Factor Authentication (MFA) to help secure your users.
• Integrated with cloud-based self-service password management, including password writeback to on-premises Active Directory and password protection by banning commonly used passwords.
• Multi-forest environments are supported if there are forest trusts between your AD forests and if name suffix routing is correctly configured.
• It is a free feature, and you don’t need any paid editions of Azure AD to use it.
• It can be enabled via Azure AD Connect.
• It uses a lightweight on-premises agent that listens for and responds to password validation requests.
• Installing multiple agents provides high availability of sign-in requests.
• It protects your on-premises accounts against brute force password attacks in the cloud.

Key security capabilities

These are the key security aspects of this feature:

• It’s built on a secure multi-tenanted architecture that provides isolation of sign-in requests between tenants.
• On-premises passwords are never stored in the cloud in any form.
• On-premises Authentication Agents that listen for, and respond to, password validation requests only make outbound connections from within your network. There is no requirement to install these Authentication Agents in a perimeter network (DMZ). As best practice, treat all servers running Authentication Agents as Tier 0 systems (see reference).
• Only standard ports (80 and 443) are used for outbound communication from the Authentication Agents to Azure AD. You don’t need to open inbound ports on your firewall.
  • Port 443 is used for all authenticated outbound communication.
  • Port 80 is used only for downloading the Certificate Revocation Lists (CRLs) to ensure that none of the certificates used by this feature have been revoked.
  • For the complete list of the network requirements, see Azure Active Directory Pass-through Authentication: Quickstart.
• Passwords that users provide during sign-in are encrypted in the cloud before the on-premises Authentication Agents accept them for validation against Active Directory.
• The HTTPS channel between Azure AD and the on-premises Authentication Agent is secured by using mutual authentication.
• Protects your user accounts by working seamlessly with Azure AD Conditional Access policies, including Multi-Factor Authentication (MFA), blocking legacy authentication and by filtering out brute force password attacks.

Components involved

For general details about Azure AD operational, service, and data security, see the Trust Center. The following components are involved when you use Pass-through Authentication for user sign-in:

• Azure AD STS: A stateless security token service (STS) that processes sign-in requests and issues security tokens to users’ browsers, clients, or services as required.
• Azure Service Bus: Provides cloud-enabled communication with enterprise messaging and relays communication that helps you connect on-premises solutions with the cloud.
• Azure AD Connect Authentication Agent: An on-premises component that listens for and responds to password validation requests.
• Azure SQL Database: Holds information about your tenant’s Authentication Agents, including their metadata and encryption keys.
• Active Directory: On-premises Active Directory, where your user accounts and their passwords are stored.

How to setup?

Download and install the agent, after this one You will see it under the authentication agents.

and done.

And You can see from Azure portal that it’s enabled.

In production environments, we recommend that you have a minimum of 3 Authentication Agents running on your tenant. There is a system limit of 40 Authentication Agents per tenant. And as best practice, treat all servers running Authentication Agents as Tier 0 systems (see reference).

SSO

PTA SSO

Set up your Azure AD Connect server: If you use Pass-through Authentication (PTA) as your sign-in method, no additional prerequisite check is required.

PHS SSO

If you use password hash synchronization (PHS) as your sign-in method, and if there is a firewall between Azure AD Connect and Azure AD, ensure that:

• You use version 1.1.644.0 or later of Azure AD Connect.
• If your firewall or proxy allows, add the connections to the allowed list for *.msappproxy.net URLs over port 443. If you require a specific URL rather than a wildcard for proxy configuration, you can configure tenantid.registration.msappproxy.net, where tenantid is the GUID of the tenant where you are configuring the feature. If URL-based proxy exceptions are not possible in your organization, you can instead allow access to the Azure datacenter IP ranges, which are updated weekly. This prerequisite is applicable only when you enable the feature. It is not required for actual user sign-ins.

What is Seamless SSO?

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) automatically signs users in when they are on their corporate devices connected to your corporate network. When enabled, users don’t need to type in their passwords to sign in to Azure AD, and usually, even type in their usernames.

Seamless SSO creates a computer account named AZUREADSSOACC in your on-premises Active Directory (AD) in each AD forest. The AZUREADSSOACC computer account needs to be strongly protected for security reasons. Only Domain Admins should be able to manage the computer account. Ensure that Kerberos delegation on the computer account is disabled, and that no other account in Active Directory has delegation permissions on the AZUREADSSOACC computer account. Store the computer account in an Organization Unit (OU) where they are safe from accidental deletions and where only Domain Admins have access.

It’s recommend that you roll over the Kerberos decryption key at least every 30 days.

To enable SSO

Open PowerShell and.

Then

Next

Get next authectication context from Azure.

And login with our Admin account.

Get status

You can see from the computer object when it was changed.

Roll out the feature for end-users

You can gradually roll out Seamless SSO to your users using the instructions provided below. You start by adding the following Azure AD URL to all or selected users’ Intranet zone settings by using Group Policy in Active Directory:

• https://autologon.microsoftazuread-sso.com

In addition, you need to enable an Intranet zone policy setting called Allow updates to status bar via script through Group Policy.

Group policy location is User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page. Then select Site to Zone Assignment List.

Add the following

Go to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone. Then select Allow updates to status bar via script.

To Disable

Get status and Disable SSO

Once done, manually delete the computer object from AD.

What is Federation?

You can federate your on-premises environment with Azure AD, you establish a trust relationship between the on-premises identity provider and Azure AD. Azure AD Connect can manage federation between on-premises Active Directory Federation Service (AD FS) and Azure AD.

Define primary server

Add Federation services server name and add.

And exit.

Now You can edit more settings inside Azure AD Connect.

View federation configuration

From here You can see the config of the farm.

In example the farm behavior level has four stages:

Windows Server Version	FBL	AD FS Configuration Database Name
2012 R2	1	AdfsConfiguration
2016	3	AdfsConfigurationV3
2019	4	AdfsConfigurationV4

Quick tip! ADFS farm can have 5 ADFS servers without using external SQL database.

Creating a trust

Connect to Azure AD and to Your Local domain. Then select Azure AD domain to federate.

Trust will create between the services.

You can also see from ADFS server management that we don’t have any.

And configure.

Once done, you will see trust created.

Verifying the connection

In my example I will use my local ADFS name and against all supported documentation I have it running in my DC, why this is bad?

Administrative accounts and groups, domain controllers, Federation services and Cloud sync services and domains with direct or indirect administrative control over the AD forest are all part of Tier 0. Tier 0 administrators can manage and control assets across all levels, although they can only log in to Tier 0 assets interactively. A domain administrator should never log in to a Tier 2 asset interactively.

Here’s PAM tier model from Microsoft’s documentation.

All of that in mind, You can test with this setup, not put to production.

Change signature hash algorithm for Microsoft 365 relying party trust

With GUI

And PowerShell

Certificates

Azure AD attempts to monitor the federation metadata, and update the token signing certificates as indicated by this metadata. 30 days before the expiration of the token signing certificates, Azure AD checks if new certificates are available by polling the federation metadata.

• If it can successfully poll the federation metadata and retrieve the new certificates, no email notification or warning in the Microsoft 365 admin center is issued to the user.
• If it cannot retrieve the new token signing certificates, either because the federation metadata is not reachable or automatic certificate rollover is not enabled, Azure AD issues an email notification and a warning in the Microsoft 365 admin center.

Automatic renewal

To allow the certificates to be renewed automatically, check the following:

• The AD FS property AutoCertificateRollover must be set to True. This indicates that AD FS will automatically generate new token signing and token decryption certificates, before the old ones expire.

• The AD FS federation metadata is publicly accessible. Check that your federation metadata is publicly accessible by navigating to the following URL from a computer on the public internet (off of the corporate network)

Public access to federation metadata https://YouFederationServicepublicFQDN/federationmetadata/2007-06/federationmetadata.xml

Manual management

Within Azure AD Connect You can Update SSL, token-signing and decryption certificates.

And to no big surprise, You can also do it with PowerShell.

Monitoring trust relationship

You can do this in example with Azure Monitor and Log analytics.

When disaster strikes

ADFS will become a Single Point Of Failure component when You enable it. You should have multiple because all the login will be directed to Your on-premises installation of ADFS.

If You have to quickly fix user sign-in’s after Federation services are down, use these.

Things to remember

PTA is an alternative to Azure AD Password Hash Synchronization

It can be enabled via Azure AD Connect

Azure AD Connect should be treated as Tier 0 component

Azure AD Seamless SSO automatically signs users in when they are on their corporate devices connected to your corporate network

Seamless SSO creates computer account named AZUREADSSOACC

ADFS farm can have 5 servers without external SQL. After this limit You need external SQL database.

ADFS service should be treated as Tier 0

Link to main post