{"id":2188,"date":"2018-07-11T08:00:10","date_gmt":"2018-07-11T06:00:10","guid":{"rendered":"https:\/\/msb365.abstergo.ch\/?p=2188"},"modified":"2023-06-23T13:19:54","modified_gmt":"2023-06-23T11:19:54","slug":"azure-active-directory-pass-through-authentication","status":"publish","type":"post","link":"https:\/\/www.msb365.blog\/?p=2188","title":{"rendered":"Azure Active Directory Pass-through Authentication"},"content":{"rendered":"

As far we know until today, the best solution form the Microsoft point of view is, to use ADFS to authenticate on-premises users for cloud services such as Azure or Office 365. This is working very well and there are many articles about how to configure the clams etc. can be found in internet and also on my Blog<\/a>.<\/p>\n

However, if a company don\u2019t want to use ADFS for authentication, there is another way Microsoft supports, but it is not so common like the ADFS solution. In this article I want to present an alternative way using AAD with Pass-through.<\/p>\n

\u00a0<\/p>\n

How does that works?<\/h2>\n

To show the whole authentication progress, we are going to use the picture below. The progress is divided in 11 steps:<\/p>\n

\"\"<\/p>\n

When a user tries to sign into an application secured by Azure AD, and if Pass-through Authentication is enabled on the tenant, the following steps occurs:<\/p>\n

\u00a0<\/p>\n

    \n
  1. The user tries to access an application, for example, Outlook Web App.<\/li>\n
  2. If the user is not already signed in, the user is redirected to the Azure AD User Sign-in page.<\/li>\n
  3. The user enters their username and password into the Azure AD sign in page, and then selects the Sign in button.<\/li>\n
  4. Azure AD, on receiving the request to sign in, places the username and password (encrypted by using a public key) in a queue.<\/li>\n
  5. An on-premises Authentication Agent retrieves the username and encrypted password from the queue. Note that the Agent doesn\u2019t frequently poll for requests from the queue but retrieves requests over pre-established persistent connection.<\/li>\n
  6. The agent decrypts the password by using its private key.<\/li>\n
  7. The agent validates the username and password against Active Directory by using standard Windows APIs, which is a similar mechanism to what Active Directory Federation Services (AD FS) uses. The username can be either the on-premises default username, usually userPrincipalName, or another attribute configured in Azure AD Connect (known as Alternate ID).<\/li>\n
  8. The on-premises Active Directory domain controller (DC) evaluates the request and returns the appropriate response (success, failure, password expired, or user locked out) to the agent.<\/li>\n
  9. The Authentication Agent, in turn, returns this response back to Azure AD.<\/li>\n
  10. Azure AD evaluates the response and responds to the user as appropriate. For example, Azure AD either signs the user in immediately or requests for Azure Multi-Factor Authentication.<\/li>\n
  11. If the user sign-in is successful, the user can access the application.<\/li>\n<\/ol>\n

    \u00a0<\/p>\n

    On-premises user sign-in to Azure AD<\/h2>\n

    Let us have a closer look to the sign-in progress from on-premises user to Azure AD.<\/p>\n

    \"\"<\/p>\n

    As we can see in the picture, the on-premises user credentials are \u201csent\u201d to the on-premises agent, these credentials will be validated against the local Active Directory. If the username and password are correct, the user will be able to login.<\/p>\n

    Note: this is only working, if the user account is synchronized to the Azure Active Directory. In our case by using the Azure AD connect.<\/p>\n

    \u00a0<\/p>\n

    Pass-through authentication<\/h2>\n

    The pass-through authentication agent (AuthN agent) only requires outbound firewall ports. The necessary Ports for that are the Port 80 and the Port 443.<\/p>\n

    \"\"<\/p>\n

    Good to know for this solution is that multiple agents can be deployed for the performance and as well for fault tolerance. The communication between the sites works with https only and as default.<\/p>\n

    \u00a0<\/p>\n

    Pass-through authentication installation \u2013 What is going on<\/h2>\n

    Till this chapter we know how the pass-through authentication works and about what we need to think. However, let us have a short look about how the installation has to be done.<\/p>\n

    \"\"<\/p>\n

    By the installation we chose our Azure AD connect server and here we deploy the AuthN agent. The AuthN agent will create then a pair of key (private key and public key) and sends a certificate request to the Azure AD. This is possible because we already have installed and configured our Azure AD connect. Now the Azure Active Directory creates the certificate and stores it together with the public key by itself. The created certificate will be returned to the AuthN and the received certificate will be associated with the private key.<\/p>\n

    \u00a0<\/p>\n

    Pass-through authentication installation \u2013 Steps<\/h2>\n

    For PTA to be enabled on the Azure AD Connect server the following requirements apply:<\/p>\n