– Guest Blog from Julian Jakob (@jakob_davidson)
In a recent project I got the request for rolling out Citrix Push-OTP for about 4500 remote Users for HDX and SSLVPN Citrix Gateway (maybe I will share my experience with Push-OTP on another one here 😉 )
There was also the requirement for using user-certificate’s on corporate devices, instead of Push-OTP, to give these users some kind of comfort. A plain one for nFactor, sure. In this post I will share my discoveries and pains with the limitations of user-certificate authentication in combination with user-agent header filter possibilities on Citrix ADC.
I’m not going to be step-by-step on how to configure nFactor for certbased authentication usage, as there are detailed posts for example from Carl Stalhood (link to https://www.carlstalhood.com/nfactor-authentication-citrix-gateway-13/ )
User-certificate authentication is limited based on the client (Workspace App, Gateway Plugin) and operating system (Windows, MacOS, iOS, Android,…)
The feature matrix for workspace app also shows a hint „via Browser Only“
So the goal is to filter the user-certificate authentication policy based on „User-Agent“ Header on the ADC side.
- If the client / browser supports certbased auth and there is a matching certificate from the corporate pki, use it and prefill the username as the UPN from the cert
- If the client / browser doesn’t support certbased auth or there isn’t a matching one, switch to the next higher prioritized authentication policy (which is the MFA nFactor flow)
I was looking for such a listing of all mostly used User-Agent definitions and I created a Citrix support case asking for the same, too. Unhappy, more than this I wasn’t able to find, which is an old one and not containing the detailed differences between all these devices and operating systems https://docs.citrix.com/en-us/citrix-gateway/current-release/storefront-integration/ng-clg-session-policies-overview-con.html
Luckily, on Citrix ADC, there is the httpaccess.log located in /var/log, so I decided to make my own access tests with different clients / browsers / devices and analyzed the logfile.
These are my results, the goal is to use individual parts of the whole header, which is a unique one – so there is no mismatch between different clients or browsers. Green one’s are examples for that.
Workspace App (starting with 1809, CWAWEBVIEW is the browser engine’s header):
“Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko, CWAWEBVIEW/184.108.40.206534″
“Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; AGEE 8.0;) NAC/1.0 plugin 220.127.116.11″
Mozilla Firefox Browser:
“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0″
MS Edge Browser:
“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Edg/90.0.818.62″
Google Chrome Browser:
“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36″
Internet Explorer 11 Browser:
“Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko”
Workspace App iPhone:
“CitrixReceiver/21.5.1 iOS/14.5.1 CitrixReceiver-iPhone X1Class CWACapable 302RedirectionCapable CFNetwork Darwin”
Workspace App iPad:
“CitrixReceiver/21.5.1 iOS/14.5.1 CitrixReceiver-iPad X1Class CWACapable 302RedirectionCapable CFNetwork Darwin”
SSO App iPhone:
“Mozilla/5.0 (iPhone; CPU iPhone OS 14_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 CitrixSSO-1.3.7 VpnCapable NAC/1.0″
SSO App iPad:
“Mozilla/5.0 (iPad; CPU OS 14_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 CitrixSSO-1.3.7 VpnCapable NAC/1.0″
“CitrixReceiver/21.0.0 Android/9 PS7318 CWACapable“
“CitrixReceiver/CitrixVPN 2.4.16 (105) Android/9 VpnCapable AuthV3Capable NAC/1.0″
This is an example of an expression for supporting certbased auth on the following ways:
- Browser MS Edge
- Browser Google Chrome
- Browser Mozilla Firefox
- Workspace App for Windows and Mac at a minimum of Version 1809 and higher (as there comes the browser engine with)
I really hope this may help you, creating your own successful journey of user-certificate authentication with Citrix ADC.
- There is a powerful website containing lots of User-Agent headers for all kind of browsers / software / operating systems and so on, which helped me a lot, checkout https://developers.whatismybrowser.com/useragents/explore/
- With these User-Agent Headers, you are able to filter all kind of policies which are supporting the HTTP.REQ.HEADER(„User-Agent“).CONTAINS(„XXX“) expression – not only authentication policies. This can also extend your session policies architecture and flexibility, mostly. There is almost no limit!
- Set client authentication to „Optional“ in your ssl profile or ssl settings, otherwise the fallback will not work
- Enable client authentication only on your aaa vserver, otherwise you will get two certauth popups (one for login and the second one during starting an hdx / vpn session) if you’re not using aaa, you have to use a dummy gateway vserver, checkout https://support.citrix.com/article/CTX200193
- Citrix Gateway Plugin (native client connection way, not the browser one) for Windows / Mac / Linux is only working with mandatory certbased auth. If there is no cert, the user has to manual cancel the certbased auth process to begin with the fallback to the next nFactor flow – an auto fallback isn’t working.
- Citrix SSO App for Android isn’t supporting certbased auth, the fallback to the next MFA nFactor flow throws an error. It’s not possible to add the VPN account. I opened a Citrix feature request which is currently under investigation – you can refer to the case number 80505642
- Citrix Workspace App for Android isn’t supporting group extraction as the first nFactor flow in a login schema. It’s only possible to add an account with „Add Account as Webinterface“ option enabled. I opened a Citrix feature request which is currently under investigation – you can refer to the enhancement-ID NSHELP-27537 with your local Citrix sales engineer for helping to speed the process up