July 28, 2019

More adventures in RADIUS!

PingID provides one of the most prevalent multi-factor authentication (MFA) solutions on the market today and as with many of them such as Azure MFA (which I touch on in a previous article), Okta, Duo, etc. can handle one-time passwords (OTP) via SMS, mobile app, or email, as well as “pushes” to a their mobile app (preferred method) which tends to be the norm these days. More and more organizations are seeking to move away from OTPs and obnoxious token codes.

PSA while on topic: MFA via SMS is arguably the least secure option and N IST ceased recommending it around 2016 and thus organizations should seriously consider looking at removing it as an enabled option for users in their MFA solution to improve security.

PingID’s solution is often implemented as a SAML IdP via PingFederate and this is well documented. However, not everyone wishes to integrate with an MFA solution via SAML. In the case of Citrix, the use of SAML as the authenticating factor being sent over to StoreFront necessitates Citrix FAS (which I touched on in my multi-datacentre article) to federate authentication between a non-LDAP source and LDAP using certificates. When a recent customer who had on-prem PingFederate servers which were RADIUS capable alongside SAML, RADIUS was the logical choice due to the current lifecycle of their Citrix platform and timelines for service activation. The only challenge was essentially no documentation being available for this configuration from PingID.

To complicate things a bit more, we had two goals to meet:

Ensure mobile ReceiverWorkspace App clients could authenticate to the platform with PingID.
Ensure the second password field was hidden.

When dealing with multi-factor authentication with these requirements, things can get a tad tricky when it comes to supporting both native app alongside browser authentication. Duo solves this elegantly by using two distinct RADIUS configurations that get applied based on the client header detected. We didn’t appear to have such options with PingID so what worked for one solution, didn’t work for another.

Citrix has a few articles that deal with this including CTX215611, CTX232026, and CTX222547 time cite a few.

To merely hide the second password field on my customized X1 theme, the following did the trick, bound to the vServer:

add rewrite action rw_act_insert_var_PING_ENABLED insert_before_all "HTTP.RES.BODY(120000).SET_TEXT_MODE(IGNORECASE)" ""var PING_ENABLED = true;"" -pattern "if (pwc ==2"
add rewrite action rw_act_insert_PING_ENABLED insert_after_all "HTTP.RES.BODY(120000).SET_TEXT_MODE(IGNORECASE)" "" && !PING_ENABLED"" -pattern "if (pwc ==2"
add rewrite policy rw_pol_insert_var_PING_ENABLED "HTTP.REQ.URL.CONTAINS("gateway_login_form_view.js")" rw_act_insert_var_PING_ENABLED
add rewrite policy rw_pol_insert_PING_ENABLED "HTTP.REQ.URL.CONTAINS("gateway_login_form_view.js")" rw_act_insert_PING_ENABLED

This works fine for browsers, but as CTX215611 notes, it doesn’t work for Receiver. Moving on to CTX203775, we get a little more information on means to hide the second password field from the native client, but alas, this does not work for mobile Citrix clients. This article does a better job than CTX215611 however on elaborating on how the workaround suggested functions.

The workaround? (And before anyone asks, no, not nFactor… 6 months ago we tried that but nFactor just couldn’t handle sending some clients through EPA and others not, based on client headers, at least as of 12.1 b50.31 when we last tried).

Essentially it is to uncheck the “Authentication” checkbox on your LDAP server. This has the effect of authenticating the user at the Citrix Gateway, which should also permit password changes (so long as you’re using LDAPS or LDAP over TLS) if you have it enabled, and sends the authenticated credentials through to the RADIUS server to finish the job. In our case, this results in a single password field for browser and native Citrix clients (mobile and desktop) and achieved our desired outcome. In case you’re wondering, in this configuration we were able to leave the ReceiverWorkspace App session policy as using primary authentication vs. making it secondary as is commonplace.

And the result? Log in with AD creds, receive a push to the mobile app. On all access methods. Here’s some shots from iOS Workspace App being that it was the key challenge I was trying to solve.

Now you may wonder if that’s where we ended up, why not do away with LDAP altogether and delegate that to RADIUS? I mean, all one needs to do is set RADIUS as the primary authentication method and have no need for secondary. The password sent to RADIUS would be encrypted using the shared secret. While this is true, it presents the following requirements or limitations:

Unable to perform group policy extraction as authentication is delegated to RADIUS (useful for all sorts of things)
Assumes RADIUS server is configured to also handle LDAP authentication and not just RADIUS
Relies on RADIUS server to also allow for password changes (if it can even facilitate it) vs. Citrix Gateway
Reduces visibility for the Citrix admin on LDAP authentication events as RADIUS servers are often managed by a different team
Reduces consistency (in our case the Citrix ADCs services numerous untrusted ingress networks, some which did not require 2FA)

All in all, this post is more of a walkthrough on a thought process than it is a “how-to” guide of some kind. Hope in some way shape or form it becomes helpful to someone.

Subscribe