In my previous post, I talked about Password Hash Sync, in this post I’ll be discussing Azure Active Directory Pass-Through Authentication.
What is the need of pass-through authentication?
If an organization is hesitant to share or
expose the password outside their on-premise AD environment, then they should
use pass-through authentication instead of password hash synchronization.
Passwords are never stored in Azure AD in any form
Authentication happens in an on-premise AD
environment as Azure AD now talks Kerberos
If an organization wants to enforce its
on-premise AD security and password policies
User can sign into cloud bases and on-premise
applications using the same password
Unlike ADFS, there is no additional
configuration setting, infrastructure or maintenance is required. So, it is
cost-effective as well.
No additional ports need to be open in the on-premise
environment; only port 443 and 80 is used.
Provides single seamless sign-on feature for
domain-joined machines
How does pass-through authentication work?
Firstly, we need to install an authentication
agent on the server where ADA Connect is installed.
Whenever a user tries to sign in to Azure AD,
Azure AD encrypts the password using a public key and place it in the queue
On-premise authentication already has a
pre=established connection with Azure AD, so the agent makes an outbound call
to retrieve the username and password.
Authentication agent decrypts the password using
a private key
After decrypting the password, authentication
agent validates username and password from DC using standard Windows APIs
mechanism which similar to the mechanism used by ADFS
Domain Controller then evaluates the request and
returns its response to the authentication agent, and then the authentication
agent forwards that response to Azure AD.
Azure AD performs its checks if Azure AD finds
out that user has MFA enabled then it challenges for MFA and if MFA is not
enabled then user authenticates
One of the main features, pass-through authentications,
provides a seamless-single sign-on. So, how does Seamless SSO works in case
of pass-through authentication?
At the AAD Connect configuration, AAD connect
creates a computer account that represents Azure AD in on-premise AD.
When a user tries to sign in to Azure AD from a
domain-joined machine, JavaScript is used to request Kerberos ticket for the
computer account
As the machine is domain joined which means it
has a direct line of sight with Domain Controller, it can acquire a Kerberos
ticket
That Kerberos will include the identity of the
user, which will be forwarded to the Azure AD and Azure AD lets the user sign
in silently.
Things to remember:
In order to allow Azure Ad to receive the Kerberos
ticket, there are 2 URLs that needs to add to the user’s internet setting using
GPO
Microsoft recommends installing multiple
authentication agent in an on-premise environment for high availability as
authentication agent is set to auto-update so while installing updates users
might not be able to authenticate if there is only one authentication agent
installed.
Pass-through authentication creates below types
of the log, which may contain personal data:
Azure AD Connect trace log files.
Authentication Agent trace log files.
Windows Event Log files.
It is essential to do clean up the logs in every 48 hours.
In order to automate it, a scheduled task can be created in the task scheduler
to run every 48 hours. Below are the 2 PS scripts which can be used:
$Files = ((Get-Item -Path
“$env:programdata\aadconnect\trace-*.log”).VersionInfo).FileName
Foreach ($file in $Files) {
{Remove-Item -Path $File
-Force}
}
$Files = ((Get-childitem -Path
“$env:programdata\microsoft\azure ad connect authentication
agent\trace” -Recurse).VersionInfo).FileName
Foreach ($file in $files) {
{Remove-Item -Path $File
-Force}
}
Pass-through authentication is not integrated
with Azure AD Connect Health.