ADFS Deep-Dive
Julia Heaslet
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.
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.
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.
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.
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.
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 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.
Hi there! My name is Matt Felton and I am a long time geek with a passion for technology. I have over 20 years experience in the industry that spans the technology stack. These days you'll find me spending my time in the cloud space. I started Journey Of The Geek many years ago when I saw an opportunity to provide in-depth technical deep dives to peel back the onion on technologies and products. I enjoy sharing what I've learned and giving back to the industry. Plus there is no better way to learn a topic than to teach it. I hope you enjoy and if you have questions feel free to reach out via the comments or LinkedIn.
DISCLAIMER
All views expressed on this site are my own and do not represent the opinions of any entity whatsoever of which I have been, am now, or will be affiliated.
Today I continue my series of posts that cover a behind the scenes look at how Active Directory Federation Service (AD FS) and the Microsoft Web Application Proxy (WAP) interact. In my first post I explained the business cases that would call for the usage of a WAP. In my second post I did a deep dive into the WAP registration process (MS refers to this as the trust establishment with AD FS and the WAP). In this post I decided to cover how user certificate authentication is achieved when AD FS server is placed behind the WAP.
Once the secure session is established the WAP passes the HTTP GET request to the AD FS server. It adds a number of headers to the request which AD FS consumes to identify the client is coming from the WAP. This information is used for a number of AD FS features such as enforcing additional authentication policies for Extranet access.
My best guess on the above two sessions is the first session is where AD FS performs home realm discovery and maybe some processing on to determine if there are any special configurations for the WAP such as limited or expanded authentication options (device authN, certAuthN only). The second session is simply the AD FS server presenting the authentication methods configured for Extranet users.
The third session we see a HTTP POST to the AD FS server with the same query parameters as our previous request but also providing a JSON object with a key of AuthMethod and the key value combination of AuthMethod=CertificateAuthentication in the body.
The next session is another HTTP POST with the same JSON object content and the key value pairs of AuthMethod=CertificateAuthentication and RetrieveCertificate=1 in the body. The AD FS server sends a 307 Temporary Redirect to the /adfs/backendproxytls/ endpoint on the AD FS server.
The WAP then performs a final HTTP GET back at the /adfs/ls/ endpoint including the previously described headers and query strings as well as provided the cookie it just received. The AD FS server responds by providing the assertion requested by Microsoft along with a MSISAuthenticated, MSISSignOut, and MSISLoopDetectionCookie cookies which are described in the link above.
In other words, AD FS separates the process of authentication and authorization. It does this by allowing account partners to authenticate users and send these authenticated requests to resource partners, which in turn, can control the actual use of resources.
No, AD FS cannot authenticate a user by itself. It requires a domain controller to authenticate it for Active Directory. Once this authentication is done, it verifies users and issues security tokens.
A domain controller holds the database of all users and computers that are connected to the domain whereas AD FS holds no such database. Instead, it acts as an intermediary between the given domain and an external one and requests authentication for users trying to log in from the external domain.
On the other hand, non-AD FS users get a public IP address for AD FS servers. This address helps users to navigate to the internal AD infrastructure of the application, and from there, they can access the application.
The easiest way to install AD FS is by using the AD FS Setup Wizard, as it takes care of running prerequisites and fixing dependencies. You can even do a quiet installation by using the command adfssetup.exe/quiet in the command line prompt.
The other common configuration is Federated Web SSO, typically used by two separate organizations that have a common agreement or are in a B2B relationship. This allows one organization to authenticate and send this information in the form of claims, and the second organization to authorize access based on this information.
Certificates are an essential part in any digital communication, and AD FS is no exception. Certificates help to secure communications between web proxies, web applications, federation servers, and cloud services, though the exact type would depend on your implementation.
SSL, which stands for Secure Socket Layer, is used for securing communication. AD FS requires a SSL for server-side authentication on every server in your federation server farm. You need both the certificate and the private key associated with it.
Token-signing certificate is a X.509 certificate used for securing all tokens issued by the federated server. AD FS generates a self-signed certificate for you by default, but you can change it through the AD FS management snap-in based on your implementation.
SIM401. Active Directory Federation Services 2.0 Deep Dive: Deploying a Highly Available Infrastructure. Brian Puhl Technology Architect Microsoft IT. Agenda. ADFS Roles/Functions Deployment Topologies Management Operations. Why Bother?. ADFS is your identity interface to the cloud
Load Balancing Internet Ability to shift or balance traffic between data centers Hardware load balancers enable quick response to server failures Internal load balancers provide high availability Geographic DNS DMZ Load Balanced Intranet Load Balanced
Deployment Topology MSIT.adfs.microsoft.com SQL Configuration Store Site2 Site1 SQL server ADFS service configuration Trust and claims rule storage SAML artifact storage Extranet Extranet Corpnet Corpnet Mirrored Clusters MSIT.adfs.microsoft.com
2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
7fc3f7cf58