For Azure AD, Microsoft offers and recommends to use Pass-through Authentication (PTA) as the authentication method. This method is then used to authenticate to applications, services and systems connected to Azure AD, like Office 365, Intune and Power BI.
However, there are a couple of things you should know:
Only outbound connections
When using Pass-through Authentication (PTA), the servers in your datacenter(s) will not have to be opened up from the Internet through firewalls. Each PTA Agent, sets up an outbound connection to the Azure Service Bus and don’t even need to be placed in a perimeter network.
However, based on ISO/IEC 17799, some organizations have seen reasons to implement standards that don’t allow systems to setup outbound connections to insecure networks, like the Internet, For these organizations, the way PTA works might be problematic.
While on the subject of legal compliance… ISO/IEC 17799 requires session time-outs as part of section 11.5.6. As the documentation states that PTA Agents make persistent outbound HTTPS connections, this control might also prove bothersome.
Minimum three PTA Agents
Of course, Pass-through Authentication (PTA) is the alternative to Active Directory Federation Services (AD FS).
That’s great, because any serious AD FS deployment would require five servers in the datacenter; 2 AD FS Servers, 2 Web Application Proxies en an Azure AD Connect installation. Ideally, the AD FS Servers are placed in different datacenters with an accompanying Web Application Proxy. This may be scoped down by placing AD FS on Domain Controllers, only requiring three new boxes.
Microsoft recommends a minimum of three PTA Agents in your environment. The Azure AD Connect installation that is used to configure PTA, by default, becomes the first PTA Agent. That’s 3 servers for AD FS vs. 3 servers for AD FS? Well, PTA Agents can also be placed on Domain Controllers, so it’s 1 server vs. 3 servers, actually.
There is such a thing as oversizing your PTA deployment too. As authentication requests are placed on the Azure Service Bus with encryption destined for each PTA Agent, having more PTA Agents equals more encryption overhead and a busy service bus…
Authentication may be highly available… synchronization not so much
When an organization deploys multiple PTA Agents, authentication requests are distributed amongst the PTA Agents. Each PTA Agent is capable of authenticating users independently of the other PTA Agent, as long as it has a connection to a functioning Domain Controller and to the Azure Service Bus.
However, Azure AD Connect still is a single point of failure to the solution. When Azure AD Connect doesn’t function (properly):
- objects are not synchronized
- attributes are not synchronized
- the Authentication Method cannot be changed to PTA or Password Hash Sync (PHS) or to include Seamless Single Sign-on (S3O)
(but it can be changed to AD FS through Windows PowerShell)
This may result in authentication and authorization failures.
Azure AD Premium licenses are required for Azure AD Smart Lock-out
Active Directory Federation Services (AD FS) offers Extranet Lock-out. In recent versions of Windows Server, it even offers Extranet Smart Lock-out. However, Pass-through Authentication (PTA) doesn’t offer lock-outs natively. Yes, Microsoft’s Machine Learning (ML) might detect malicious authentication attempts and block them, but by that time accounts in Active Directory Domain Services may already be locked-out, when organizations use strict settings in (fine-grained) password and account lock-out policies.
When the Azure AD Smart Lock-out feature is to be used with non-default settings, each account that is used with Pass-through Authentication requires an Azure AD Premium license. These licenses may be acquired separately, or as part of the EMS E3 license or Microsoft 365 E3 license.
There is no Azure AD Connect Health for PTA Agents
When contemplating Azure AD Premium, Azure AD Connect Health might also be of interest. Azure AD Connect Health offers integrated monitoring of Microsoft’s Hybrid Identity stack. We install the Azure AD Connect Health agents for monitoring on the following systems:
- Azure AD Connect installations;
- AD FS Servers;
- Web Application Proxies, and;
- Domain Controllers.
Alas, PTA Agents cannot be monitored with Azure AD Connect Health. This means notifications are not sent when PTA Agents are in trouble and root cause analyses are manual and require access to logs and local tools on the Windows Server installations running PTA Agents.
However, the PTA Agents are visible in the Azure AD Portal with their external IP addresses:
- Sign into the Azure Portal with an account that has the Global Admin role.
Perform multi-factor authentication and Privileged Identity Management (PIM), when required.
- In the Azure Portal, select Azure Active Directory in the left navigation pane.
- Select Azure AD Connect in Azure AD’s navigation pane.
- On the Azure AD Connect pane, click the text Pass-through Authentication.
- Review the PTA Agents and their external IP addresses in the Pass-through Authentication pane.
Monitoring the connections to Domain Controllers
When checking PTA Agents in the Azure Portal, you might think that authentication to Azure AD is working flawlessly for your organization, when you see nothing but green check marks.
However, these checkmarks merely indicate that a PTA Agent is authenticated and connected to the Azure Service Bus. It does not mean that it is actually capable of authenticating users. When its connection to a Domain Controller is lost, for some reason, the check mark is there in the Azure Portal, but authentications won’t be possible.
The solution might be to implement Azure AD Connect Health for Active Directory Domain Services (AD DS) and monitor the Domain Controllers that way. Please note that this requires 25 Azure AD Premium licenses in the tenant per Domain Controller, on top of the single license needed for Azure AD Connect Health for the Azure AD Connect installation itself.
No certificate-based authentication
Pass-through Authentication (PTA) offers many features. Combined with Seamless Single Sign-on (S3O), it allows for authenticating end-users towards Azure AD-integrated resources.
However, several features that organizations might need are not offered with PTA and S3O. The most glaring feature that is missing has to be certificate-based authentication. If an organization requires certificate-based authentication, AD FS should be on their to-do list.
Forget about self-managed third-party MFA
Many organizations have already deployed multi-factor authentication (MFA) solutions on-premises in the past few years. The previously mentioned ISO/IEC 17799 standard plays a role in that for some organizations. These investments may become technical debt when Pass-through Authentication (PTA) is deployed. End-users require the organization-managed MFA solution to access on-premises resources, but require one of the four Azure AD-managed MFA solutions (Azure MFA, Trusona, DUO and/or RSA) to access cloud resources. From their point of view, this means that when their mobile number and/or their mobile device changes, they have to change settings and/or register twice. With kids these days switching phones and numbers each year, this becomes a force to recognize.
Roll-over the password for AzureADSSOAcc
We rarely see a Pass-through Authentication (PTA) implementation without Seamless Single Sign-On (S3O) enabled as an authentication method, too. When you enable S3O, an computer account is created: AzureADSSOAcc. It is created in the Computers container, by default.
It is important to frequently roll over the Kerberos decryption key of this computer account (which represents Azure AD) created in your on-premises AD forest. Azure AD Connect does not notify of this caveat. And to do so, is complicated and cannot be automated without adding credentials of an account with the Global Admin role, configured without MFA, to the script.
Don’t disable TLS 1.0 (yet)
Since version 1.2.65 of Azure AD Connect (October 25th, 2018), it supports all other protocols being disabled and only TLS 1.2 being enabled on the machine where Azure AD Connect is installed.
However, when PTA is used as the authentication method and the PTA Agent is installed on the same Windows Server installation as Azure AD Connect, by default, the PTA Agent will not be able to communicate with Azure, when TLS 1.0 is disabled.
It appears the PTA Agent still requires TLS 1.0, for now.
Netwrix
![AzureADBanner[4]](https://dirteam.com/sander/wp-content/uploads/sites/2/2019/03/AzureADBanner4.jpg "AzureADBanner[4]")
Login