on 08-Mar-2012 20:18
So let’s talk Application Delivery Controllers, (ADC). In part one of this series we deployed both an internal ADFS farm as well as a perimeter ADFS proxy farm using the Big-IP’s exceptional load balancing capabilities to provide HA and scalability. But there’s much more the Big-IP can provide to the application delivery experience. Here in part 2 we’ll utilize the Access Policy Manager, (APM) module as a replacement for the ADFS Proxy layer. To illustrate this approach, we’ll address one of the most common use cases; ADFS deployment to federate with and enable single sign-on to Microsoft Office 365 web-based applications.
The purpose of the ADFS Proxy server is to receive and forward requests to ADFS servers that are not accessible from the Internet. As noted in part one, for high availability this typically requires a minimum of two proxy servers as well as an additional load balancing solution, (F5 Big-IPs of course). By implementing APM on the F5 appliance(s) we not only eliminate the need for these additional servers but, by implementing pre-authentication at the perimeter and advanced features such as client-side checks, (antivirus validation, firewall verification, etc.), arguably provide for a more secure deployment.
Assumptions and Product Deployment Documentation - This deployment scenario assumes the reader is assumed to have general administrative knowledge of the BIG-IP LTM module and basic understanding of the APM module. If you want more information or guidance please check out F5’s support site, ASKF5. The following diagram shows a typical internal and external client access AD FS to Office 365 Process Flow, (used for passive-protocol, “web-based” access).
Virtual Servers and Member Pool – Although all users, (both internal and external) will access the ADFS server farm via the same Big-IP(s), the requirements and subsequent user experience differ. While internal authenticated users are load balanced directly to the ADFS farm, external users must first be pre-authenticated, (via APM) prior to be allowed access to an ADFS farm member. To accomplish this two, (2) virtual servers are used; one for the internal access and another dedicated for external access. Both the internal and external virtual servers are associated with the same internal ADFS server farm pool.
INTERNAL VIRTUAL SERVER – Refer to Part 1 of this guidance for configuration settings for the internal ADFS farm virtual server.
EXTERNAL VIRTUAL SERVER – The configuration for the external virtual server is similar to that of the virtual server described in Part 1 of this guidance. In addition an APM Access Profile, (see highlighted section and settings below) is assigned to the virtual server.
APM Configuration – The following Access Policy Manager, (APM) configuration is created and associated with the external virtual server to provide for pre-authentication of external users prior to being granted access to the internal ADFS farm. As I mentioned earlier, the APM module provides advanced features such as client-side checks and single sign-on, (SSO) in addition to pre-authentication. Of course this is just the tip of the iceberg. Take a deeper look at client-side checks at AskF5.
AAA SERVER - The ADFS access profile utilizes an Active Directory AAA server.
ACCESS POLICY - The following access policy is associated with the ADFS access profile.
SSO CONFIGURATION - The ADFS access portal uses an NTLM v1 SSO profile with multiple authentication domains, (see below). By utilizing multiple SSO domains, clients are required to authenticate only once to gain access to both hosted applications such as Exchange Online and SharePoint Online as well as on-premise hosted applications. To facilitate this we deploy multiple virtual servers, (ADFS, Exchange, SharePoint) utilizing the same SSO configuration.
CONNECTIVITY PROFILE – A connectivity profile based upon the default connectivity profile is associated with the external virtual server.
Whoa! That’s a lot to digest. But if nothing else, I hope this inspires you to further investigate APM and some of the cool things you can do with the Big-IP beyond load balancing.
Additional Links:
Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”
Big-IP and ADFS Part 3 - “ADFS, APM, and the Office 365 Thick Clients”
BIG-IP Access Policy Manager (APM) Wiki Home - DevCentral Wiki
Firstly thanks for these articles, they've been a great resource in my recent Exchange/APM work.
I've implemented F5 APM federated Office 365 for students in our university, and we're so happy with how it's working that we're keen to investigate the hybridisation of our on premises exchange org (used exclusively for staff) with a new office 365 tenancy, again using F5 for the federation/ saml aspects of the architecture. So far I've been focussing on getting to grips with the ADFS method of implementation (4 ADFS servers? Overkill much?) and I think I can see where F5 is going to be able to take over those roles. All my reading is leaving me a little confusd though, can i competely remove the need for ADFS servers in a Exchange 2010/office 365 hybrid deployment? Or is there still going to be a requirement for internal ADFS servers? It would be great to hear about that particular topology, and if it's possible? Cheers - Gavin Connell-Otten - Victoria University, NZ
It seems as you are using the BigIP to front end your ADFS environment where ADFS is acting as the IdP in order for users on your LAN to authenticate to Office 365, the SP. What I am trying to do is retrofit this concept to the opposite, where I need to accept inbound assertions from an external IdP and allow access to an internal resource on my LAN. I have ADFS built and I am ingesting assertions from the external IdP but I would like to use the BigIP as the reverse proxy for not only the connection between the IdP and my ADFS server, but to also provide a secure front end that mirrors that of the default STS logon page on ADFS, ultimately allowing an external user to auth against their IdP, ADFS process the claims, issue a new token for my internal sharepoint site to that client and then redirect them to the VS that will be front ending my sharepoint site. Are these concepts you discuss in this series still applicable or is this a completely different scenario requiring another solution? I would love to see this laid out if you have gone through this scenario as well.