ADFS Proxy Replacement on F5 BIG-IP
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.
Published Mar 13, 2018
Version 1.0
Graham_Alderso1
Employee
EmployeeGraham_Alderso1Employee
Employee
Graham_Alderso1Marvin, This is normal. ADFS doesn’t publish federationservice.asmx on the proxy tier. The proxy receives a list of URLs to allow from the ADFS server farm.
Juerg_WiesmannNimbostratus
Where do I find ... v1.2.0rc6 it looks this v1.2.0rc7 is only the relase candidate ? Is it ok to use that and is it supported then ?
Juerg, v1.2.0rc6 was the latest at the time of publication. Graham's advice in the article here is to use rc6 as the minimum version.
- Graham_Alderso1
+1 - exactly. Anything after that version has the ADFS Proxy with MS-ADFSPIP support functionality built in. I recommend using the latest available.
Karthik_Krishn1Cirrostratus
I just finished configuring this and it works well as long as APM policies for Azure MFA are not enabled ( at least for me). When the APM policies are enabled, forms based SSO is not working, user name does not get pre-populated in the F5 logon page. Also, I am using the Azure Mobile app ( which requires the user to be enabled for 2FA in Azure). This presents a problem in that once the user has passed primary auth (AD) , secondary auth (Azure MFA) , SSO to ADFS, Azure presents the cloud 2FA again. When the F5 provides pre-authentication including Azure MFA, is the 2nd factor claim passed on to the ADFS server ( i have a relying party trust which will forward MFA claims to Azure thereby preventing the second MFA prompt from Azure)
Any help or suggestions on why SSO is failing would be greatly appreciated. I have configured exactly as per the deployment document.
- Graham_Alderso1
Karthik,
Perhaps look at the domain name setting regarding the forms SSO issues. Also ADFS by default is configured to require domain\username or username@domain.com format, so that is how the forms SSO works in APM works by default. Many environments modify the ADFS logon page to not require the domain, so you may need to adjust the forms SSO accordingly.
Regarding the Azure MFA, you would need to change your Azure MFA policy to implement the way you're requesting. If you have APM enforce the MFA requirement, then you do not need Azure to enforce it. ADFS (and thus Azure) is unaware that APM has already completed the MFA and that is why you are getting prompted twice.
If you want Azure MFA implemented the same way it would be when using WAP, do not select to deploy Azure MFA in the APM profile (or do not deploy an APM profile at all depending on your needs), and it will be implemented by ADFS and Azure in the same manner you are used to, but with APM replacing the WAP functionality.
- Karthik_Krishn1
Thanks Graham -- here's the error i am getting
- Graham_Alderso1
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.
- Karthik_Krishn1
Makes sense. Will try in a few minutes and let you know
- Karthik_Krishn1
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/)
