Azure Active Directory Pass-through Authentication part 2

By rzomerman | | No Comments | Active Directory, Azure

In the initial post, we looked at PTA from a high-level perspective. This post goes into the actuals and internals of the PTA to ensure you can convince your security department on why PtA is a very good idea.

Inside Azure AD there are multiple components that work together to ensure the safety of your accounts and ensure users have a good experience when they login. The central piece of the PtA is the Hybrid Identity Service which orchestrates the login and agent authorization.

But before we dive into the details, first of all the latest features. In the Azure AD blade in Azure under Azure AD Connect you can now find the pass-through authentication option which shows you the status of your agents.

The blade overview shows the authentication options enabled and when the last Azure AD Connect synchronization happened. You can also click the Pass-through authentication option and you will be shows the overview of the agents.

This screen also allows you to download the agents for installation.

PTA’s Inner workings

In the above picture you see the components. The STS (the federation server), which shows the login page asking you for username and password. An SQL database is used to map the agents as we will show later. And then the Service bus where the credentials are actually stored for the agents to pick them up.

In this post we will cover a few scenarios:

  • Agent installation / registration
  • User authentication
  • 2nd agent installation
  • Agent updates
  • Agent Certificate renewals

Agent Installation/Registration

Installing the agent is a matter of running the executable on a member server. After installation, the agent will need to be authorized. In order for the agent to connect to the Azure AD it will require 2 ports to be opened (directly, no proxy support yet). Port 443 is used for all communications with Azure AD. Any data transfer will go over this port. But as certificates are involved, port 80 also needs to be opened for CRL validation. This CRL validation is required to check if a certificate has not been revoked and is a standard operation of the Operating System when using certificates.

During the installation 2 new services will be created:

  • The Microsoft AAD Application Proxy Connector running under NETWORK SERVICE privileges
  • The Microsoft AAD Application Proxy Connector Updater running under NT AUTORITY\SYSTEM

The proxy connector is the application that will actually perform the authentications as well as connecting to Azure AD. The proxy connector updater is responsible for installing newer versions of the application automatically. They are separated to enhance the security of the service as the application dealing with authentications does not have SYSTEM privileges.

When performing the registration, the agent will ask for a username and password of an Azure AD Global Admin account. It’s advised to use a “managed domain” account, such as the admin@domain.onmicrosoft.com equivalent of your domain.

  1. The account is validated by the Azure AD STS service
  2. after a successful login, an authentication token is returned to the agent
    After the token has been received, the actual bootstrap process is kicked off. The bootstrap process registers the agent in Azure AD and ensures it is ready for accepting credentials in a secure manner.
  3. The process begins as the agent creates a new private/public key pair (for a certificate) on the local machine store. It also creates the CSR for that keypair to be signed by the ADCS, as seen below:
  4. The entire package is being sent to the Hybrid Identity Service. The Token received in step 2 is used to gain access to the HIS and the public key of the generated certificate is sent including the CSR to sign the certificate. Note that the private key of the agent does not leave the agent server.
  5. The Hybrid Identity Service puts the public key of the agent certificate in an SQL database and ensures that the TenantID, the IP/name and public key are stored.
  6. The signature for the certificate is returned and stored in the computers certificate store. Note that the certificate created has the Distinguished Name/Common name set to your tenant ID. So, the certificate uniquely identifies your tenant.
  7. The certificate is based on the following characteristics:

    Signature Algorithm: sha512RSA
    Signature Hash Algorithm: sha512
    Issuer: connectorRegistrationCA.msappproxy.net
    Public Key: RSA 2048
  8. The agent can authenticate towards the service using SSL based authentication. It must provide its (self-created but ADCS signed) certificate for which it has the private key. The HIS service can authenticate based on its HIS certificate and as such a mutual authentication can take place. Furthermore, the certificate used by the agent uniquely identifies the Azure AD tenant due to its Common name in the certificate.
  9. After validation of the credentials, the Hybrid Identity Service responds to the agent with a service bus URL and the Access Key to connect to this Service bus. The access key is unique to your tenant and all agents connect to the same service bus and use the same access key.
  10. The connection to the service bus is created and the connection is kept alive. If the connection is dropped, the agent will automatically try to reset it and re-connect.

    Authentication

    The bootstrap process is only used when registering an agent. After the initial registration, the agent is ready for action. In order to see what happens when, we will be looking at an authentication from a user and we will follow the package:

    1. When a user goes to the STS login screen they provide their credentials
    2. instead of authenticating locally on the Azure AD (or sending the user to the on-premises ADFS), the credentials are forwarded to the Hybrid Identity Service.
    3. The HIS then connects to the database and looks up the tenantID and the agent public encryption key.
    4. The credentials are then encrypted using the public key of the agent certificate and then the encrypted package is placed on the service bus.
    5. The agent will collect the service bus package
    6. With the public key which is unique to each agent, it can decrypt the package to expose username and password
    7. With the decrypted username and password (on-premises) it is able to perform a logon against your on-premises Active Directory using the Win32 LogonUser API (with the “dwLogonType” parameter set to “LOGON32_LOGON_NETWORK”).
    8. The response given by the domain controller (allow, deny, must_change_pasword, accountStatus) is forwarded to the Hybrid Identity Service over the mutual authenticated channel (which includes the agent certificate with unique tenantID)
    9. The response from the logon is forwarded to the STS

The other agents

Given the private key of the certificate created by the agent never leaves the server, one might wonder how this will work with multiple agents. Well first we have the registration of the 2nd server which will clarify. Initially the Azure AD Global Admin needs to login to get the token [not shown].

  1. The newly installed agent will create a new unique certificate and CSR file.
  2. Using the Azure AD token, the agent will send its unique private key and CSR to the Hybrid Identity Service.
  3. The Hybrid Identity Service will update the SQL database with the tenantID, the agent name and the unique public key for agent 2.
  4. The CSR for the certificate is signed
  5. The certificate signature is returned for the certificate to be signed.

So now in the database there are 2 public keys for a single tenantID.

When a user signs-in and the credentials are passed to the Hybrid Identity Service, it will create 2 encrypted packages and place them on the Service Bus. When the connector takes the package from the service bus, it knows (based on the name of the package) which encrypted package it should decrypt. Agent 2 will absolutely not be able to decrypt the package that was meant for agent 1.

Certificate renewal

The agent certificates have a default lifetime, and as soon as they need to be renewed an automated process kicks in. But the Hybrid Identity Service can also force the renewal of a certificate. In order for the agent to know it’s time to renew, it will poll the HIS every two hours to check if it needs to renew.

  1. The process initiates by creating a new private/public key combination and a CSR. This is similar to the process during bootstrapping.
  2. The new public key and CSR is sent to the HIS. Instead of asking for Azure AD Global Admin credentials to connect to the Hybrid Identity Service, the old certificate is used to authenticate:
    1. The certificate is validated to see if it’s coming from an actual agent in your tenant
    2. If the old certificate is invalid (time/revoked/etc) the agent is deleted from the tenant automatically and an administrator needs to manually re-register the agent
    3. If all is okay, the process continues
  3. The HIS updates the table in the SQL with the new public key for the agent.
  4. The CSR is signed, and the old certificate is invalidated (added to the CSR of the ADCS)
  5. The signature for the new certificate is returned and the connections are reset

Given the agent runs under the NETWORK SERVICE credentials, it does not have rights to the LOCAL_SYSTEM_MACHINE certificate store anymore. As a result, the new certificate will be placed in the CURRENT_USER certificate store (service account if you check with mmc.exe). So, while you will see an expired certificate in the MACHINE certificate store, but the newer certificates are under the personal (service account) store. Given the updater runs under SYSTEM privileges it will have access to this certificate (for application updates).

Agent Updates

As indicated earlier there are two services installed. Apart from the authentication agent, there is also an updater application that updates the application automatically in the background. The update agent runs under SYSTEM privileges as it needs to be able to download, remove, install an application. Every 2 hours, the updater will poll the HIS to validate if there is a new version available. If so, it will initiate its process.

Security summary

To summarize for your security department:

  • Each agent uses a unique key
  • This key is based on RSA-2048 bits
  • Mutual authentication happens to the HIS
  • The HIS provides a tenant unique key to access the service bus
  • Credentials placed in the service bus are encrypted with the unique agent keys
  • Agents can only decrypt the credentials with their own private key (which cannot leave the agent)
  • Credentials are used to perform a NETWORK logon to the domain controllers only
  • After the result from the domain controller is known, the credentials are dropped from the agent server
  • The result sent to the HIS is based on mutual SSL authentication for the connection and only contains the request GUID and the result (success, wrong password, etc)
  • The agent itself runs under NETWORK privileges and thus no SYSTEM access is required
  • All connections use SSL encryption (tcp 443)
  • HTTP port 80 is only being used for CSR validation for the public certificates (HIS/ServiceBus)
  • The updater ensures that the package is up to date and the latest version is installed
Tagged , ,