on 13-Jul-2020 10:47
Before I get started into discussing the solution in the title, I wanted to preface it with a little background. Prior to June 2020, I had never had any interaction or integration experience with Citrix StoreFront or any Citrix product for that matter. However, a few weeks ago my team was asked to help develop a solution providing smart card authentication and SSO. We approached this like any other web-based application that supported Windows Integrated Authentication. We would just simply provide the smart card auth portion and then use Kerberos Constrained Delegation as the SSO method. While we were right for the most part, there were definitely a few other Citrix requirements we missed.
Most of my experience in the past has been around VMware's Horizon View in which I have had an outstanding time working and collaborating with their engineering teams to provide and implement different solutions. With that, actually getting hands-on experience with StoreFront and the other Citrix services will help my team better understand and support these solutions in the future. Thanks to a few very bright engineers on the F5 side who have implemented this solution before, my team was finally able to get this working. This article is solely around smart card auth and SSO to StoreFront to display a set of applications a user is authorized to view. My goal is to follow this article with one on integrating FAS into the solution but we shall see. So with that, let's get started.
General Settings
The Citrix gateway URL is the external URL users will use to access the F5 BIG-IP virtual server.
I am unsure of what HDX routing is for but by selecting this option, it provided the Secure Ticket Authority option in which I would match to my APM policy.
Manage Beacons
Manage Authentication Methods
Manage Receiver for Web Sites
Note: Modifying this setting from On to OnUsingHttp did not affect the outcome but based on Citrix documentation when terminating SSL at a proxy, this setting should be used. We will be performing Bridged mode SSL so still delivering encrypted content to StoreFront but changed this setting anyway as I was still not clear. This did change the way I had to troubleshoot though. When using Wireshark, I had to enable the loopback network adapter to capture this traffic.
Configure Remote Access Settings
I think it is important to note that Citrix StoreFront allowed authentication without KCD or any SSO profile assigned but for reference, please follow my article on DevCentral on how this is configured.
Otherwise, you can skip this step as we will be passing session variables obtained from APM to StoreFront for authorization purposes.
General Properties
When returned to the previous page displaying all access profiles, select Edit from the newly created policy
set x509e_fields [split [mcget {session.ssl.cert.x509extension}] "\n"]; # For each element in the list: foreach field $x509e_fields { # If the element contains UPN: if { $field contains "othername:UPN" } { ## set start of UPN variable set start [expr {[string first "othername:UPN<" $field] +14}] # UPN format is <user@domain> # Return the UPN, by finding the index of opening and closing brackets, then use string range to get everything between. return [string range $field $start [expr { [string first ">" $field $start] - 1 } ] ]; } } # Otherwise return UPN Not Found: return "UPN-NOT-FOUND";
Note: If you decide to use KCD, this will need to be the fully qualified domain name and not the NetBIOS name. If not using KCD, expr {"ITC"} can be used.
Note: The sta server should be the same server defined in Citrix StoreFront earlier in this article
Once complete select Apply Access Policy and your VPE should look like the screenshot below
Note: X-Citrix-Via is the header name and withsf.itc.demo is the value. The value must match the external fqdn.
Note: This will be the IP address available to external users attempting to access Citrix resources
Note: This is an internally accessible only IP address that will be accessed by StoreFront
Note: You do not need to use the same client SSL profile but the certificates must match. In this example, I am using the same SSL profile.
when CLIENT_ACCEPTED { set citrix_logout 0 } when ACCESS_ACL_ALLOWED { set type [ACCESS::session data get session.client.type] if { !($type starts_with "citrix") } { set storeWebName "/Citrix/UDF_storeWeb/" set http_uri [HTTP::uri] if { $http_uri == "/" || ($citrix_logout eq 0 && $http_uri ends_with "login.aspx") } { # log local0. "For [HTTP::uri] Redirecting to $storeWebName" ACCESS::respond 302 Location "https://[HTTP::host]$storeWebName" } elseif { $http_uri contains "Logoff" } { set citrix_logout 1 } elseif { $citrix_logout eq 1 && $http_uri ends_with "login.aspx" } { set citrix_logout 0 ACCESS::respond 200 content "Logged out\r\n" Connection close ACCESS::session remove } } }
Now that you have hopefully authenticated to StoreFront, I wanted to say I am by no means a Citrix expert. If there are settings that should be changed per best practice, please shoot me a note and I would be more than happy to discuss. After the struggles I had deploying this over the past few weeks, I really hope this helps someone out there. Until next time!
Where in the Citrix configuration does it point to the "Internal Call Back Virtual Server"?
You can find this under the manage citrix gateway information. In my example, I used Callback URL: https://proxyauth.itc.demo. Search for this in the article and you will see the screenshot of exactly where it is. Let me know if you are still having issues identifying it.
Is it correct that the Callback-virtual server shouldn't have any default pool assigned?
That is correct. There will be no default pool assigned as the response will be sent back to storefront which is acting as the client in this request.
Ok, im not 100% sure how that can work! But i believe you! 🙂
Another question: In the callback-virtual server:
The ssl client profile in your setup is requering certificate as it is using the same ssl profile as the storefront vs.
Is that ok too?
Haha, yeah believe me it took a lot of digging through Citrix documentation. Based on that, for non-password authentication the Storefront sever simply needs to resolve the same gateway (F5 BIG-IP) that the user authenticated against. If your internal storefront servers have connectivity to the external facing gateway VS on the BIG-IP, then I believe you should be able to use that. However, I believe in my testing of that scenario I had issues with client-less requests from the Storefront server because you cannot enable clientliess mode with On Demand Cert Auth.
In my scenario my customer does not allow that communication to occur so we simply created a new VS accessible internally and a basic access policy I don't believe it is a Citrix requirement to use the same certificate/key pair that you use for the client-ssl profile used on the F5 VS publishing the citrix gateway URL but rather ensuring that the callback server url has a valid certificate.
If you are supporting smart card auth on the BIG-IP and you use a separate callback virtual server, I did find it necessary to have a connectivity and VDI profile.
Thank you. Impressive work and very kind of you to publish it!
Hopefully we get it to work here soon! 🙂
What my article does not include is the troubleshooting, network captures and more required to get this working. If you don't get this up and running right away and need to do packet captures with encrypted traffic, remember the two methods to do so. I personally find it easier to modify the SSL profile cipher string to support RSA only and use the private key in Wireshark but you can also use the RSA session secret using this solution article. https://support.f5.com/csp/article/K12783074
One other thing to note, under certain configuration circumstances Storefront will use its loopback IP to perform communication internally which I was not capturing because of my capture string was defining the BIG-P self IP and the routable Storefront IP.
In addition to this, if you are confused about the STA service, it was natively installed with the controller and required no configuration from me but I did have to define it in my access policy as a session variable.
If you are unsure who your F5 account team is, let me know and we can try to determine that so they can assist. If they are unable to do so, I still have my dev environment with this deployment functional so I may be able to provide more granular details if needed. Good luck and let me know how it goes.
Hi again.
It doesn't work and from the client I see these requests after a successful smartcard logon:
Client request to storefront-vs
POST /Citrix/VDIWeb/Authentication/GetAuthMethods HTTP/1.1
Server response from storefront-vs
HTTP/1.1 200 OK
eXtensible Markup Language
<?xml
<authMethods
xmlns="http://citrix.com/delivery-services/webAPI/2-6/authMethods">
<method
name="Certificate"
url="SmartcardAuth/Login"/>
<method
name="CitrixAGBasic"
url="GatewayAuth/Login"/>
<method
name="CitrixAuth"
url="CitrixAuth/Login"/>
</authMethods>
Client request to storefront-vs
POST /Citrix/VDIWeb/GatewayAuth/Login HTTP/1.1\r\n
This request never gets a response
The client retries 5 times and then gives up.
Is /Citrix/VDIWeb/GatewayAuth/Login the correct authmethod?
No worries. So auth is failing all together? Do you ever get to a client detection status? For me, Auth to the BIG-IP would succeed and I would get prompted on non-IE browsers to select detection status of the ICA client. Once I selected detect status I never received a status from Storefront. Do you even get to this point?
Yes, that was in the beginning of our labs. It seems like the browser knows the client detection state already.
In my world the authentication method proposed from the storefront server should be negotiate (kerberos) so that the kerberos delegation should kick in. But this is all very confusing.
I think we will take this with Citrix support and then contact F5 support for assistance
When initially deploying this I approached it as any other IIS based application that would support KCD for my external users who were non domain joined. You will notice in my guide, I completely removed all Kerberos configurations but provided it for reference only. As mentioned, I am no Citrix expert and still don't fully understand every aspect of their VDI solution but I have now had 2 customers follow this guide step by step with success. I just powered up my lab and will try and provide some more clarity. Unfortunately every time my customer who initially reached out for assistance on this contacted Citrix support, they were told to contact F5 when they learned of the integration. I am hoping you do not have this same experience but none the less, we will help you get this functional.
Great article. We finally got it working when the Citrix team starting to use the Federated Authentication Service (FAS) solution.
Storefront configured for CitrixAGbasic and SmartCard auth. The storefront server trusts the Bigip and no passwords needed, just username extracted from the upn on the smartcard. Thanks again Steve!