ADFS Proxy Replacement on F5 BIG-IP

[Graham_Alderso1]

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.

[Juerg_Wiesmann]

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 ?

[BAMcHenry]

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_Krishn1]

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/)

[Graham_Alderso1]

You'll implement changes to the logon page object similar to this: https://devcentral.f5.com/s/articles/office-365-logon-enhancement-username-capture-27497

 

That article is using APM as SAML IdP instead of ADFS, but in both SAML and WS-Fed (ADFS) cases the username is sent along and you can extract it to insert into the APM logon page.

 

[Karthik_Krishn1]

Thanks Graham. I used the information from your link and from another to configure pre-population fr when F5 was the SAML iDP however it's not working for the ADFS implementation. The branch rule " expr { [mcget {session.logon.last.username}] ne "" }" fails, however it goes further when i use " expr { [mcget {session.logon.last.username}] } but then fails the AD query ( 'no matching user found with filter userPrincipalName='). I even tried changing it to sAMAccountName but no luck. I got rid of the Ad query and the logon page shows up with the username field blanked out.

I have this working for the F5 as SAML iDP and my thought was the same as what you suggested but I think there is some subtle change that is affecting the behaviour in this case.

[Karthik_Krishn1]

I was able to solve this issue and am able to pre-populate the user name

[raZorTT]

Hi,

Wondering if anyone has had an issue when selecting an existing Access Profile? We are running v11.4.1 (soon to be upgraded) but when we select an existing profile the F5 never returns the HTTP response to the client.

Looking in the logs, we can see the access policy completing, but the client just gets a connection error.

If we select do not provide secure authentication using APM, and then disable strict updates and manually assign our existing access profile it works.

Nothing obvious stands out in the ltm logs

Cheers, Simon

[Graham_Alderso1]

Hello Simon,

I have not seen this issue but recommend upgrading to 13.1 before spending any more time troubleshooting this use case since 13.1 is required for MS-ADFSPIP support, which is required by Microsoft to act as an ADFS Proxy.

[raZorTT]

Thanks Graham,

12.1.3 is as high as we can go in the short term due to hardware

Is MS-ADFSPIP required for ADFS 4.0? We currently only run ADFS 3.0, but handy to know the requirements when we look to update.

Cheers, Simon

[Graham_Alderso1]

Yes, unfortunately MS-ADFSPIP is required for full MS support from ADFS 3 (Windows 2012) on.

[a_basharat]

Hi Graham, I understand from the article and the user's comments, that any F5 image version above "v13.1" [i.e. v.14] will work, Can you confirm? Is there any field or visible option that you can see on the APM that corroborate the support for MS-ADFSPIP?

[Graham_Alderso1]

a.basharat you are correct regarding versions. Support for this feature can be verified on your BIG-IP by checking for the ADFS Proxy section shown in the screenshot under the "How do I deploy it" heading above.

[NPolitis_234832]

Hi,

Is there any easy way (meaning not deploying a second virtual server) to differentiate "inside" users from "outside" users when using the APM ADFS Proxy feature ?

Regards,

NPO

[Graham_Alderso1]

NPolitis, no, not a simple way. It may be possible with some iRules but the official supported method would continue to be two virtual servers. This also provides you with troubleshooting flexibility you probably don't want to lose.

You can deploy them at the same destination IP address however, and use the source IP constraint on the VS page for the internal load balancing only virtual server, though. You'd constrain it to your internal network, e.g.: 10.0.0.0/8 instead of the default 0.0.0.0/0. You would need to make this source address adjustment manually, outside the iApp with strictness disabled.

[Marvin]

Hi graham, I am looking into similar implementation F5 as ADFS proxy using Azure MFA, the first time a deploy the iApp sugin v1.2.0r8 I get the following message ADFS Trust Establishment Failed: Failed to establish ADFS trust relationship on the virtual server /UAT/testADFS.app/testADFS_adfs_vs_443: Can't connect to ADFS. What does it exactly need to do? Connect to the ADFS server, authenticate and establish a secure connection?

[Graham_Alderso1]

Marvin, the primary ADFS server must be online and reachable to establish trust from the BIG-IP.

[CEMIT2]

Hi Graham, we also are having Marvin's issue both with RC8 via Official Deployment instructions and Manual implementation via this article (https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-third-party-integration-13-1...). We are on 13.1.1. We validated communication is occurring between the VIP and ADFS server, but still fails to establish trust. Validated no drops on firewall. We also went through Microsoft's Analyzer tool to validate our ADFS configuration. All pass. https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-diagnostics-ana...

Are there any other troubleshooting steps you can provide? Are there any non-OOB configuration steps taken on the ADFS server itself?

[Graham_Alderso1]

No changes needed at the ADFS server. Are you entering your username in the correct format and is it an admin? It should be entered as: mydomain\myadminuser

[CEMIT2]

Graham, thanks for the feedback. Yep, validated this again. We decrypted the traffic traffic between the VIP's VLAN Self-IP and our ADFS server, and the only traffic we see is the health checks.

Any more information you can provide on how the Virtual Server builds trust would be helpful.

Is there any reason why building trust wouldn't work on a standby node?

Also, maybe you can suggest for future Release Candidates for this iApp template, they include an error for incorrect credentials apart from the connectivity, I'm sure what you just mentioned has gotten others before.

Thanks again.

[Marvin]

Ok Graham, I was just looking into the contents and how it is deployed and I currently dont have any connection to the ADFS server so that is normal. Is the Iapp compatible with BIg IP 14.1 and are there improvements of the ADFS integration with this new version or is version 13.1 still the recommended version?

[Graham_Alderso1]

CEMIT2, I'd suggest that you check the APM logs under /var/log/apm to see what the error message is. As far as building from a standby node, I haven't tried that. If you're trying that today, perhaps try from the active node. For more recent development of the template we've moved to the new Guided Configuration, which you'll see on your box under Access once upgraded to the latest release of 13.1 or later.

[Graham_Alderso1]

Marvin,

Yes, the iApp is compatible and you can continue using it. However, as noted in the comment directly above, new development is now focused on enhancing the Guided Configuration process for deploying ADFS Proxy instead of the iApp. You'll find that it asks similar questions, but in a more "guided" fashion.

As far as which version, you'll have the same set of capabilities for ADFS Proxy specifically on 13.1 or 14.1, but obviously other many features have advanced significantly in 14.1 and I'd highly recommend checking it out.

[Micha]

Hi Graham, i have an question about the "these are your claims page" is this an default page on the adfs server? or how can i created it?

[CEMIT2]

Hi Graham, We fixed it. It seems you cannot build ADFS proxy trust from a Standby node.

There was not any information in the logs or deployment documentation that indicated the trust must be built on the active node. No traffic apart from the health checks were triggered from the Standby Node. This is why I had asked the question specifically, if building trust would be impacted from Standby.

It would be fair to say many businesses work in the way of applying changes to a Standby Node, and making that node active, then syncing on success or returning back to Standby in failure.

If you could add specific errors for this scenario, or add this requirement to the documentation, I think this would resolve plenty of other client's issues.

[Graham_Alderso1]

CEMIT2, thanks for the feedback, I'll forward it on.

Micha, that page showing the claims is a webapp running on a different server, it is not default in ADFS. It is basically just a webapp that federates to ADFS and displays the claims it receives. If you search for "ADFS sample claims app" you'll find some examples and how to configure them.

[Marvin]

Hi Graham, I have a standalone F5 Big IP VE with only APM provisioned, when I deploy the Iapp I get the following error:

script did not successfully complete: (can't read "::basic__version": no such variable
while executing
"set adfs_version $::basic__version"
(procedure "configure_adfs_deployment" line 8)
invoked from within
"configure_adfs_deployment" line:983)

When I provision LTM additionally it does work properly, the problem however is the our client only has APM license, is the template compatible with only APM module or do we need both LTM+APM

Could you please confirm otherwise I will have to see for ways to add the license for LTM.

Thanks,

Marvin

[Micha]

Hi Marvin,

somewhere in de deployment guide there is an line that when you have an apm only license and you want to deploy the adfs iapp you only have to provision ltm. you don't need an ltm license but you must provision the ltm.

[Marvin]

Hi Micha ok thanks for confirming this, then it wont generate issues, by any chance do you also use certificate authentication on the virtual server? This Iapp is missing (I believe so) support for mobile devices, it would be good to include client identification (unmanaged vs managed devices) and apply different authentication methods. For managed certificate based authentication and for unmanaged devices without certificate based authentication. For both to work properly certificate authentication should be moved / applied to the access policy by using machine cert authentication and before that check the device type.

Something to take into consideration for designing this solution, please share if you have better ideas for mobile support.

[Marvin]

another thing is that the ADFS 2016 version uses port 443 for certificate authentication and device registration which in not 49443, when I try to configure that in the Iapp it fails, so I question myself if this is going to work properly when using port 443 for this. Maybe we have to modify the Irule to look into the specific URI for this purpose.

[Micha]

Hi Marvin, i did not use the certificate authentication. i think you need to check de adfs 2016 which port is used but i think for 2016 it is also 49443.

[Graham_Alderso1]

For certificate auth, ADFS performs this with the client on either port 49443 (alternate port), or on the same port but using the DNS name certauth.(myadfsfqdn) (alternate name). Alternate port is the more common and is what the iApp deploys. In order to use alternate name your ADFS environment has to be setup for it and you need a special SAN cert that contains that name deployed. You can modify the iApp deployment to do alternate name if needed.

It's very similar to the alternate port deployment, just with a client SSL profile doing the magic instead of a separate virtual server. You can deploy the iApp with cert auth set to yes and look at the client ssl profile it deploys for cert auth on port 49443, then you can go back and select "no" for cert auth since you'll add it manually. Make a client ssl profile just like the iApp made but add the name field set to "certauth.(myadfsfqdn)". Then attach that to the 443 virtual server in addition to the existing one. You need to setup your two client ssl profiles for SNI since you're attaching two to the same virtual server, so you'll also need to select the original one (the non-cert auth one) as the SNI default in its client ssl profile settings.

Note: This certificate authentication is delegated from the ADFS Server to the ADFS Proxy (your BIG-IP) using MS-ADFSPIP protocol. The communication from BIG-IP as ADFS Proxy to the ADFS server is on port 443 even if the client is doing cert auth to the BIG-IP on 49443.

[Marvin]

Hi graham, I got your point and I understand we can do this using the client SSL profile with the client cert authentication feature enabled. To understand the ADFS proxy in more detailed (the delegated cert authentication part), is it true that when the cert auth takes place on the F5 itself (using LTM client SSL profile) it is not needed to enable this feature on the ADFS server? Or does the F5 pass some authentication details / parameters (besides of the NTLM SSO) via PIP protocol to the ADFS farm (using its trust relationship)?

The reason I ask this is that my client is requiring a password-less solution using only client cert based authentication (pre-authenticate clients on the F5 using certs), so this basically means no logon page, no AD auth (because username and password cannot be gathered externally) and even no RADIUS MFA because of the same reason. Furthermore SSO NTLM wont work because of the missing username and password parameter values.

With this specific (password-less) requirement perhaps the best thing to do is simple use LTM, a virtual server with client SSL profile enabling client cert authentication and send the traffic to the ADFS pool without any APM functionality or ADFS trust enabled on it.

Have you ever heard about this particular setup and what would you suggest in this scenario?

Thanks again.

[Marvin]

Please refer to the following link for password-less authentication, question is how does F5 ADFS proxy integrates with this setup without logon page on the F5?

Link Microsoft password-less authentication

Probably a new use case for the ADFS Proxy iapp yet to be tested?

[Graham_Alderso1]

Marvin,

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.

[Marvin]

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?

[Graham_Alderso1]

Marvin, 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.

[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