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.
- 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
- 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.
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 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).
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.
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.
cd $env:ProgramFiles"\Microsoft Azure Active Directory Connect"
Enable-AzureADSSO -Enable $true
Get next authectication context from Azure.
And login with our Admin account.
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:
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.
Get status and Disable SSO
Disable-AzureADSSOForest -DomainFqdn ad.local
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.
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|
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.
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
Set-AdfsRelyingPartyTrust -TargetName 'Microsoft Office 365 Identity Platform' -SignatureAlgorithm 'https://www.w3.org/2001/04/xmldsig-more#rsa-sha256'
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.
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
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.
# Check the certificates configured in AD FS and Azure AD trust properties for the specified domain
Get-MsolFederationProperty -DomainName cloudpartnerdemo.fi | FL Source, TokenSigningCertificate
# Update token-signing certificate
Update-ADFSCertificate –CertificateType token-signing
# Define ADFS primary server
Set-MSOLAdfscontext -Computer PrimaryADFSServerFQDN
# Update the certificates and the the trust
Update-MSOLFederatedDomain –DomainName YourFederatedDomain
Monitoring trust relationship
You can do this in example with Azure Monitor and Log analytics.
| extend TargetResource = parse_json(TargetResources)
| where ActivityDisplayName contains "Set federation settings on domain" or ActivityDisplayName contains "Set domain authentication"
| project TimeGenerated, SourceSystem, TargetResource.displayName, AADTenantId, OperationName, InitiatedBy, Result, ActivityDisplayName, ActivityDateTime, Type
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.
# Install the MSOnline module if this is first use
# Add the MSOnline module to the PowerShell session
# Get credentials of Azure admin
$Credentials = Get-Credential
# Connect to Azure AD
Connect-MsolService -Credential $Credentials
# Set Your domain to Managed instead of federated
Set-MSOLDomainAuthentication -DomainName YouCustomDomain -Authentication Managed
# When all is OK, switch is back to Federated
Convert-MSOLDomainToFederated -DomainName YouCustomDomain -SupportMultipleDomains
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
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