ADFS Proxy Replacement on F5 BIG-IP

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.

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.

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

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.

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.

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.

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.

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.

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.

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?