Deep dive into AD FS and MS WAP – WAP Registration

Hi everyone,

In today’s blog entry I’ll be doing a deep dive into how the Microsoft Web Application Proxy (WAP) established a trust with the Active Directory Federation Service (AD FS) (I’ll be referring to this as registration) in order to act as a reverse proxy for AD FS.  In my first entry into this series I covered the business use cases that would call for such an integration as well as providing an overview of the lab environment I’ll be using for the series.  So what does registration mean?  Well, the best way to describe it is to see it in action.

Figuring out how to capture the conversation took some trial and error.  This is where Sysinternals Process Explorer comes into play.  I went through the process of registering the WAP with AD FS using the Remote Access Management Console configuration utility and monitored the running processes with Process Explorer.  Upon reviewing the TCP/IP activity of the Remote Access Management Console process (RAMgmtUI.exe) I observed TCP connectivity to the AD FS farm.

RemoteReg

The process is running as the logged in user, in my case the administrator account I’ve configured.  This meant I would need to run Fiddler using the logged in user context rather than having to do some funky with running it as SYSTEM or another security principal using PSEXEC.

I started up Fiddler and configured it to intercept HTTPS traffic as per the configuration below.  Ensure that you’ve trusted the Fiddler root certificate so Fiddler can establish a man-in-the-middle (MITM) scenario.

fiddlerconfig.png

I next ran the Remote Access Management Console and initiated the Web Application Proxy Configuration wizard.   Here I ran the wizard a few different times specifying invalid credentials on the AD FS server to generate some web requests.  The web conversation below popped up Fiddler.

failedlog.png

Digging into the third session shows an HTTP POST to sts.journeyofthegeek.com/adfs/Proxy/EstablishTrust with a return code of 401 Unauthorized which we would expect given our application doesn’t know if authentication is required yet and didn’t specify an Authorization header.

estab1

Session four shows another HTTP POST to the same URL this time with an Authorization header specifying Basic authentication with our credentials Base64 encoded.  We receive another 401 because we have invalid credentials which again is expected.

succlog.png

What’s interesting is the JSON object being posted to the URL.  The JWT includes a key named SerializedTrustCertificate with a value of a Base64 encoded public-key certificate as the value.

json.png

Copy and pasting the encoded value to notepad and saving the file with a CER extension yields the certificate below of which the WAP has both the public and private key pairs.  The certificate is a 2048-bit key length self-signed certificate.

cert.png

At this point the WAP will attempt numerous connections to the /adfs/Proxy/GetConfiguration URL with a query string of api-version=2 as seen in the screenshot below.  It will receive a 401 back because Fiddler needs a copy of the client certificate to provide to the AD FS server.  At this point I let it time out and eventually the setup finished.

getconfig.png

So what does the configuration information look like from AD FS when it’s successfully retrieved?  So to see that we have to now pay attention to the Microsoft.IdentityServer.ProxyService.exe process which runs as the Active Directory Federation Services service (adfssrv).

adfservice.png

Since the process runs as Network Service I needed to get a bit creative in how I captured the conversation with Fiddler.  The first step is to export the public-key certificate for the self-signed certificate generated by the WAP, name it ClientCertificate.cer, and to store it in the Network Service profile folder in C:\Windows\ServiceProfiles\NetworkService\Documents\Fiddler2.   By doing this Fiddler will use that certificate for any website requiring client certificate authentication.

The next step was to start Fiddler as the Network Service security principal.  To do this I used PSEXEC with the following options:

Psexec -i -u “NT AUTHORITY\Network Service” “C:\Program Files (x86)\Fiddler2\Fiddler.exe.

I then restarted the Active Directory Federation Service on the WAP and boom there are our successful GET from the AD FS server at the /adfs/Proxy/GetConfiguration URL.

getconfigsuc.png

The WAP receives back a JSON object with all the configuration information for the AD FS server as seen below.  Much of this is information about endpoints the AD FS server is supporting.  Beyond that we get information the AD FS service configuration.  The WAP uses this configuration to setup its bindings with the HTTP.SYS kernel mode driver.  Yes the WAP uses HTTP.SYS in the same way AD FS uses it.

config1.png

config2.png

So what did we learn?  When establishing the trust with the AD FS server (I’m branding this registration 🙂 ) the WAP does the following:

  1. Generates a 2048-bit self-signed certificate
  2. Opens an HTTPS connection with an AD FS server
  3. Performs a POST on /adfs/Proxy/EstablishTrust providing a JSON object containing the public key certificate and authenticating to the AD FS server with the credentials provided with the wizard using Basic authentication.If the authentication is successful the AD FS server establishes the trust.  (I’ll dig into this piece in the next post)
  4. Performs a GET on /adfs/Proxy/GetConfiguration using the self-signed certificate to authenticate itself to the AD FS server.
  5. Consumes the configuration information and configures the appropriate endpoints with calls to HTTP.SYS.

So that’s the WAP side of the fence for establishing the trust.  In my next post I’ll briefly cover what goes on with the AD FS server as well as examining the LDAP calls (if any) to AD DS during the registration process.

See you next time!

Azure AD Pass-through Authentication – How does it work? Part 1

Hi everyone. I decided to take a break from the legacy and jump back to modern. Today I’m going to do some digging into Microsoft’s Azure AD Pass-through Authentication solution. The feature was introduced into public preview in December of 2016 and was touted as the simple and easy alternative to AD FS. Before I jump into the weeds of pass-through authentication, let’s do a high level overview of each option.

I will first cover the AD FS (Active Directory Federation Services) solution. When AD FS is used a solution for authentication to Azure Active Directory, it’s important to remember that AD FS is simply a product that enables the use of a technology to solve a business problem. In this instance the technology we are using is modern authentication (sometimes referred to as claims-based authentication) to solve the business problem of obtaining some level of assurance that a user is who they say they are.

When Azure AD and AD FS are integrated to enable the use of modern authentication, the Windows Services Federation Language (WS-FED) standard is used. You are welcome to read the standard for details, but the gist of WS-FED is a security token service generates logical security tokens (referred to assertions) which contain claims. The claims are typically pulled from a data store (such as Active Directory) and contain information about the user’s identity such as logon ID or email address. The data included in claims has evolved significantly over the past few years to include other data about the context of the user’s device (such as a trusted or untrusted device) and user’s location (coming from a trusted or untrusted IP range). The assertions are signed by the security token service (STS) and delivered to an application (referred to as the relying party) which validates the signature on the assertion, consumes the claims from the assertion, and authorizes the user access to the application.

You may have noticed above that we never talked about a user’s credentials. The reason for that is the user’s credentials aren’t included in the assertion. Prior to the STS generating the assertion, the user needs to authenticate to the STS. When AD FS is used, it’s common for the user to authenticate to the STS using Kerberos. Those of you that are familiar with Active Directory authentication know that a user obtains a Kerberos ticket-granting-ticket during workstation authentication to a domain-joined machine. When the user accesses AD FS (in this scenario the STS) the user provides a Kerberos service ticket. The process to obtain that service ticket, pass it to AD FS, getting an assertion, and passing that assertion back to the Azure AD (relying party in this scenario) is all seamless to the user and results in a true single sign-on experience. Additionally, there is no need to synchronize a user’s Active Directory Domain Services password to Azure AD, which your security folk will surely love.

The challenge presented with using AD FS as a solution is you have yet another service which requires on-premises infrastructure, must be highly available, and requires an understanding of the concepts I have explained above. In addition, if the service needs to be exposed to the internet and be accessible by non-domain joined machines, a reverse proxy (often Microsoft Web Application Proxy in the Microsoft world) which also requires more highly available infrastructure and the understanding of concepts such as split-brain DNS.

Now imagine you’re Microsoft and companies want to limit their on-premises infrastructure and the wider technology mark is slim in professionals that grasp all the concepts I have outlined above. What do you do? Well, you introduce a simple lightweight solution that requires little to no configuration or much understanding of what is actually happening. In come Azure AD Pass-through authentication.

Azure AD Pass-through authentication doesn’t require an STS or a reverse proxy. Nor does it require synchronization of a user’s Active Directory Domain Service password to Azure AD. It also doesn’t require making changes to any incoming flows in your network firewall. Sounds glorious right? Microsoft thinks this as well, hence why they’ve been pushing it so hard.

The user experience is very straightforward where the user plugs in their Active Directory Domain Services username and password at the Azure AD login screen. After the user hits the login screen, the user is logged in and go about their user way. Pretty fancy right? So how does Microsoft work this magic? It’s actually quite complicated but ingeniously implemented to seem incredibly simplistic.

The suspense is building right? Well, you’ll need to wait until my next entry to dig into the delicious details. We’ll be using a variety of tools including a simple packet capturing tool, a web proxy debugging tool, and an incredibly awesome API monitoring tool.

See you next post!