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!

Helpful hints for resolving AD FS problems – Part 2

Welcome back to part two of my series of posts which looks at resolving problems with AD FS.  You can check out part 1 here.  In this post I’ll look another problem you may encounter while administering the service.

With the introduction of AD FS 2012 R2, Microsoft de-coupled AD FS from IIS.  AD FS running on MS versions 2012 R2 or later now use the HTTP Server API (more often referred to as HTTP.SYS).  HTTP.SYS is a kernal mode drive that was introduced in Windows Server 2003 and is used by a Windows system to listen for HTTP and HTTPS requests (check out this article for a detailed breakdown of how it works.)  Infrastructure services such as IIS and WINRM use the driver.  By integrating AD FS directly with HTTP.SYS, Microsoft was able to cut the footprint of the solution by eliminating the need for IIS.  Awesome right?  Of course it is, however, it is a bit more challenging to troubleshoot.

Issue 2: Replacing the AD FS Service Communications certificate

The service communications certificate is one of the “big three” certificates used within an AD FS implementation.  The certificate that is assigned as the service communications certificate is used to protect web communication between clients and the AD FS service (i.e. SSL/TLS).  Like any certificate, it will have a standard lifecycle and will eventually need to be replaced.  When that time comes, you can run into a very interesting problem depending on how you go about replacing that certificate.

If you’ve been managing an AD FS instance for any period of time, you’ve more than likely become quite familiar with the AD FS Management Console.  When replacing the certificate in AD FS 2012 R2 or above, you may be tempted to use the Set Service Communications Certificate action seen below.  Let’s give it a try shall we?

ADFSMMCSC

I first requested a new web certificate from the instance of AD CS through the Certificate MMC and placed it in the Computer store.  I then granted READ access to the private key for the service account AD FS is using.  After that I used the Set Service Communications Certificate action and selected the new certificate.  A quick check of the thumbprint of the certificate now being used matches the thumbprint of the new certificate (pay attention to the thumbprint, I’ll reference it again later).  Last step is to restart the AD FS service.

Screen Shot 2017-06-10 at 3.12.06 PM.png

Let’s now test the sample claim app I described in my first post.

Screen Shot 2017-06-10 at 2.58.35 PM

Uh oh.  What happened?  A check of the Application, System, and AD FS Admin logs shows no errors or warning nor does the AD FS Debug after another attempt.  Heck, even the log for the HTTP.SYS kernal driver httperr.log in C:\Windows\System32\LogFiles\HTTPERR is empty.  This is yet another instance of where the answer could not be found in any of the logs I reviewed because it’s another error related to the integration with HTTP.SYS.  What to do next?

Much of the administration of the integration with HTTP.SYS is doing using netsh.  Here we’re going to look at the certificate bindings configured for the HTTP listeners using the command http showsslcert from the netsh command prompt.

Screen Shot 2017-06-10 at 3.07.19 PM.png

Well our bindings are there, but look at the thumbprint: 12506a00b40617b096002089383015bbbb99e970.  That thumbprint does not match the thumbprint for the new certificate I set for the Service Communications certificate.  So what happened?  My best guess is when one of the HTTPS listeners are hit, the configuration in the AD FS database does not match the configuration of the HTTP.SYS listeners causing AD FS to crash.  How do we fix it?  Come to find out from this blog, there is one additional command that needs to be run to setup the listeners with the proper bindings, Set-AdfsSslCertificate.  After using the Set-AdfsSslCertificate and setting it with the new thumbprint then restarting the AD FS service, netsh http showsslcert now shows the correct thumbprint and the sample claim app is now working as expected.

Screen Shot 2017-06-10 at 3.26.51 PM

What you should take from this post is that while integrating with HTTP.SYS helps to limit the AD FS footprint, it also adds some intricacies to troubleshooting the service when it stops working.  In the next and final post in this series I will cover an issue that can pop up when a Web Application Proxy (WAP) is integrated in the mix.

See you next post!