AWS/Azure/OpenShift

Pass-Through Authentication Principle: Azure Active Directory integration with on-Premise AD using PTA

Azure Active Directory (AAD) is a Microsoft cloud-based multi-tenant directory and provides identity and access management capabilities in the cloud. It provides MFA to help protect users from 99.9% of cybersecurity attacks. This is the backbone of the Office 365 system, and it can sync with on-premise Active Directory and provide authentication to other cloud-based systems via OAuth. It helps employees sign in and access resources or internal resources, such as apps on your corporate network and intranet, along with any cloud apps developed by your own organization. Please see the following guide Azure Active Directory integration with on-Premise AD using PTA for more information and also this guide for reasons to deploy AAD, how to set up Azure AD Tenant, how to add or delete users, and set permissions in Azure Active Directory, and how to use the built-in AAD Connect troubleshooting tool.

Pass-Through Authentication (PTA) allows users to sign in to both on-premises and cloud-based applications using the same passwords. Here, you do not have to care about SSO.

Take a look at this link to see various options that are possible for Integrating Azure Active Directory with on-Premise Active Directory.

Microsoft

Note: No passwords in the cloud, all authentications have to be performed on-premises. Therefore, when users sign in using Azure AD, this feature validates users’ passwords directly against your on-premises Active Directory. See the link below for how this is done

An alternative to this method is the Azure AD Password Hash Synchronisation. In this method, the the authentication happens in the cloud. See the link below for methods for integrating Azure Active Directory with on-Premise Active Directory.

Below are the steps on how PTA works
On-premises you have an agent (Microsoft AAD App Proxy Connector) constantly polling your Azure AD to check if there are credentials up to date. It is worth noting that, it is your agent that is constantly contacting Azure AD and not Azure AD contacting your agent, so there are no incoming ports to open.

  1. When the user types its credentials, they are put in a queue in Azure AD and retrieved by the on-premises agent.
  2. The agent verifies them and updates the queue with something like “good creds” or “bad creds”.
  3. Azure AD validates the authentication or prompts the user for its credentials again if they were incorrect.

So, it is great to know that we don’t rely on ADFS to authenticate but still do not have SSO for your domain-joined machines. As at the time of this writing, there is currently a preview feature as described by Pierre Audonnet [MSFT]. He explained that there is currently a new preview feature called the Azure AD Connect Seamless SSO. This means you will have SSO functionalities for domain-joined machines when they are connected on-premise, just like you had an ADFS farm. See the link for more information

Note: The major difference between AD FS and PTA is that, outside the complexity of AD FS, it enables us to support other methods of Password Authentication, 3rd party MFA, and Smart Cards Authentication. PTA is able to perform seamless SSO using Kerberos

I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x
Kindly subscribe to TechDirectArchive
This is default text for notification bar