BIG-IP Access Policy Manager can now replace the need for Web Application Proxy servers providing security for your modern AD FS deployment with MS-ADFSPIP support released in BIG-IP v13.1. This article will provide a one stop shop for you to gather information on the solution and leverage it in your environment.
What is an AD FS Proxy?
AD FS proxies are Windows servers that provide access to external users to the AD FS farm in the internal network. This is done on a server called a Web Application Proxy (WAP). More recent versions of Active Directory Federation Services require the proxy to support MS-ADFSPIP (ADFS Proxy Integration Protocol) which involves client certificate auth between proxy and AD FS, trust establishment, header injection, and more. As noted above, BIG-IP APM v13.1 has support for MS-ADFSPIP. You can see Microsoft’s notes on this and supported third party proxies here, noting that F5 is on the list.
Here’s a typical ADFS deployment:
So what does BIG-IP do for me?
Glad you asked! Here’s an example of the single tier deployment architecture. You can also split these roles into a two tier architecture.
As you can see, BIG-IP is taking the roles of both load balancer and the web application proxies protecting AD FS. In this diagram we’re adding additional security with Advanced WAF, DDoS, and Network Firewall services. You can see the F5/Microsoft announcement at Ignite here about this new feature.
If you want to understand more about the architecture, check out John Wagnon’s awesome lightboard lesson here.
How do I deploy it?
There are a few ways to do it. The simplest is with the latest iApp template to help you deploy everything, available from https://downloads.f5.com. Make sure you’re using at least v1.2.0rc6. You can also get the related deployment guide here.
If you want to deploy manually, there are instructions in the deployment guide. The support article here also covers basic deployment and how the pieces work. Who doesn’t love reading support articles?
For the admin the new feature comes down to this amazing simple checkbox:
Checking a box and entering credentials is WAY easier than deploying multiple Windows servers, configuring them as WAPs, establishing trust, then maintaining and securing them going forward. Access Policy Manager will maintain that trust, exchanging certificates automatically before they expire with AD FS.
Note that no access profile is assigned above. If you want one to add more security flexibility then the access profile is supported as well. Check the deployment guide for requirements. If you don’t use one, no access sessions are used.
Here’s a quick video explaining the solution and demoing deployment using the iApp.
What else can I do?
You can add more security using access profiles to add preauthentication, multifactor, etc. A basic access policy (with Azure MFA optional) is included in the iApp. Also included in the iApp is network firewall policy deployment. You can add Advanced WAF features like brute force, credential stuffing, bot protection, and more if desired too.
I looked at the APM profile the iApp creates when you select Azure MFA and it looks like there might be a minor mistake that breaks SSO (only when Azure MFA is selected). The current iApp puts the SSO Credential Mapping object after the RADIUS auth, which unfortunately overwrites the session.logon.last.password field, so the wrong password gets set for SSO. To fix this, you need to move the SSO Credential Mapping agent to immediately after the AD Auth (before RADIUS). I've included an image of what I'm describing below. Let me know if this solves your SSO issue, if so I will put in a request to have the iApp corrected as described.
That worked. Now only if you could tell me how to pre-populate the username-- please pretty please. I have included below the sequence of events prior to the logon page and after the logon page and was wondering if I could use the information "username=azure.token" in shown at the bottom of the first image to pre-populate the username field in the logon page. I was able to do this when I was using the F5 as the SAML iDP using an irule and check and variable assignments within the VPE (https://f5guru.com/2016/06/09/prepopulate-apm-username-from-o365-login/)
