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,
For certificate auth, you configure this at the ADFS server AND at the F5 proxy, as shown in the video above. The ADFS server must be configured for it because it controls the client's redirection to the certificate auth endpoint. The F5 must be configured for it because it performs the delegated certificate auth. It then passes the relevant details back to the ADFS server using MS-ADFSPIP, which is what makes it possible to delegate the certificate auth. This can be done without password. In the video above at 6:06 you see this happening. If you want it to be only certificate auth and happen automatically, no password option, then you have to change your extranet auth settings at the ADFS server.
For the second question, for other auth types, you just configure them at the ADFS server and select them there for extranet auth, and they should then show up when a user goes through the F5 ADFS Proxy the same as they would if there was a Microsoft WAP as ADFS Proxy. The proxy doesn't perform the auth (except for certificate), it just restricts access to ADFS to only the endpoints configured at ADFS. I haven't used the one you linked, but it should work fine.
Note that if you use an APM access profile, this overrides any authentication decisions made at ADFS. I don't advise this for your use case.
MarvinCirrocumulus
Hi Graham, that is great, so all the magic really happens by enabling the ADFS proxy checkbox on the virtual server level, I agree in this case without the APM access profile, thanks a lot!
- Graham_Alderso1
Exactly. Just remember though that APM is still required to be licensed and provisioned since it provides the ADFS Proxy functionality. You just don't use an access profile, which makes it very simple to deploy.
- Marvin
And I also need to provision LTM even though it is not licensed correct? But then I receive a provisioning warning...
- Graham_Alderso1
if you want to run the iApp, yes.
- Marvin
Hi Graham, we have deployed the solution accordingly, the ADFS proxy trust is established and we can see that on the virtual server. On the port 443 virtual server no cert authentication client SSL profile is being used currently but only the public certificate to do SSL offloading, however when we send a https request using the browser to /adfs/fs/federationserverservice.asmx directly to it the request is not being proxied towards the internal ADFS server.
For your information if we change the virtual server to performance layer 4 with ADFS proxy disabled the URL is accessible so there is no connectivity issue here.
How does the ADFS proxy work exactly? Does it need to receive a specific ADFS request before it proxies it to the internal ADFS server? Is there also a way to debug the ADFS proxy to have more details about what is going wrong?
Thanks,
Marvin
- Marvin
Strange enough /adfs/ls/IdpInitiatedSignon.aspx does work, where does the ADFS proxy look for exactly?
- Marvin
OK great, we also verified the client cert authentication and it is also working and looking good. I believe the real-time revocation check is not possible with LTM and we have to import the CRL list manually? For that I strongly recommend a RFE to include this feature in LTM. I know that with APM it is possible but we are not using the access policy for this setup and I wont recommend it either.
Is there a solution available to do (realtime) CRL check in the client SSL profile client authentication section or do I have to request a RFE? Perhaps OSCP is a good alternative for this in LTM?
Ps: Thanks for sharing all your information it is very useful and helped me a lot!
- Marvin
Hi Graham, my client is working for a while with this solution but seems they have an issue with version 15.1.x , using your iapp and only the ADFS proxy checkbox on the VS for one ADFS virtual server we see that the clientssl handshake is not being send to the ADFS server with the default setting SSL renegotiation disabled and we see this error in ltm logs
Self-initiated renegotiation attempted while renegotiation disabled: /Common/t-ADFS-proxy_client-ssl
When enabling renegotiation in clientssl profile it works.
We do have another virtual server with the renegotiation disabled and there the clientssl hello is being send normally to ADFS server, what are your thoughts on the ADFS and renegotiation settings required and do you have any idea what is happening here?
The iapp created the clientssl profile with clientssl-secure as parent and the renegotiation is disabled and in serverssl it is enabled