citrix storefront + smart access + apm
Does anyone have this working? I'm trying to get smart access policies to work with StoreFront 2.6 using the v2.2 of the citrix iApp...and every possible configuration I've tried does NOT work. I've followed the guide step by step. F5 support has not responded to me for weeks. I've verified this configuration works with Netscaler and the smart access also works from the same F5 device utilizing the webtop instead of storefront...I've also verified the variables are being set by APM...it's just not passing through to storefront...
Solution for Citrix Optimal Gateway Routing
Introduction On the heels of a very well written DevCentral article by Steve Lyons, Smart Card Authentication to Citrix StoreFront Using F5 Access Policy Manager, where he documented how to configure F5 BIG-IP APM to provide SSO Smart Card Authentication to Citrix StoreFront I figured it was time to publish another APM/Citrix related article for the community. A customer of mine was going to be replacing Citrix ADCs (NetScalers) with F5 APM throughout their enterprise to provide SSO SmartCard authentication to StoreFront along with ICA traffic proxying. There is a freely available iApp available for your APM that will help with this configuration. However, this iApp solution is only appliable if you are authenticating to StoreFront AND proxying your ICA traffic through the same F5 APM. And of course, this was not the configuration my customer was looking to implement. The existing Citrix ADC based implementation was configured to take advantage of something Citrix calls Optimal Gateway Routing (OGR); sometimes referred to as Optimal HDX Routing. Table of Contents What is OGR The F5 Problem The F5 Solution Configuration Steps F5 APM SF-GW Configuration iRule - Create STA Resolution Halt iRule - Create Citrix Logged Out F5 APM ICA-GW Configuration iRule - ExtractCitrix STA iRule - Resolve Citrix STA What is OGR? OGR for Citrix Storefront is a design whereby a Citrix web client is directed to an ICA Proxy Gateway (ICA-GW) anywhere in the world that is closest to the app/desktop hosting environment (XenApp and XenDesktop servers) which may not be on the same Citrix StoreFront ADC (NetScaler) Gateway (SF-GW) which has authenticated the user. This is in contrast to being directed to a single ADC Gateway device that hosts SF-GW and ICA-GW. In a Citrix ADC deployment, the ICA-GW (not the SF-GW) is responsible for validating/resolving the STA ticket provided by a Secure Ticket Authority (STA) server. Since the ICA-GW is responsible for this validation, it allows OGR to function and send ICA traffic to a different ICA-GW than what was used to download the ICA file from StoreFront. Figure 1: Suboptimal Gateway Routing Figure 2: Optimal Gateway Routing The F5 Problem(link back to Top of page) The F5 Access Policy Manager (APM) can be used to simultaneously replace a Citrix ADC for both the StoreFront Authentication process as well as the ICA Proxy process. In contrast to how Citrix ADC processes a downloaded ICA file, the F5 APM Citrix VDI plugin is designed to validate/resolve the STA ticket with the STA server upon download of the ICA proxy file from the StoreFront server.The validation details are stored locally in the APM SF-GW access session table. This session table is not shared amongst APM devices in the enterprise. So, if the ICA file then directs the client to a different APM device (ICA-GW) by virtue of the ICA file entry: SSLProxyHost=[ICA-Proxy-FQDN]:443 than what was used to download the ICA file (APM SF-GW), the APM ICA-GW will NOT have knowledge of the already validated/resolved STA ticket. The APM Citrix VDI plugin does not perform validation/resolution of the STA ticket upon launching the ICA file. The APM ICA-GW will then terminate the app/desktop session. The F5 Solution(link back to Top of page) In order to support Citrix Optimal Gateway Routing in a distributed gateway environment, the following configuration can be used. The APM SF-GW is responsible for authentication, proxying StoreFront application/desktop enumeration, and app/desktop ICA file retrieval. When a client requests an app, StoreFront will create an ICA file based on information it has retrieved from the DDCs and STA servers, send it to the APM SF-GW, which will then send the ICA file to the client. An iRule attached to the virtual server on the APM SF-GW will prevent STA validation upon download. The client can then launch the ICA file which contains a line: SSLProxyHost=[ICA-Proxy-FQDN]:443 directing the connection to an APM ICA-GW. The APM reads the ICA request, pulls out the STA server shortname referenced in the payload: Address=;40;STA12345678;0123456789ABCDEF0123456789ABCD which is the same STA server that StoreFront connected to, and matches that to a URL for the STA server using a pre-configured datagroup. Then APM ICA-GW connects to the STA server in order to validate the STA ticket included in the ICA payload. STA validation variables are stored in an APM access session table. Now that the STA ticket has been validated, the APM will proxy the ICA traffic to the app server. Configuration Steps(link back to Top of page) Assumptions: 1.Citrix StoreFront and DDCs are configured for external client access utilizing HDX routing which requires the configuration of Secure Ticket Authority (STA) servers similar to the following: Figure 3: StoreFront server, “Citrix StoreFront” applet -> Stores -> “Manage Netscaler Gateways” -> Edit Figure 4: StoreFront server, “Citrix StoreFront” -> “Configure Store Settings” -> “Optimal HDX routing” F5 APM SF-GW Configuration(link back to Top of page) Creating a StoreFront AD Authentication Access Policy Navigate to Access››Profiles / Policies : Access Profiles (Per-Session Policies) and click Create General Properties Name: sta_resolver_ap Profile Type: All Customization Type: Modern Configurations Logout URI Include: /Citrix/UDF_storeWeb/Authentication/Logoff Note: replace UDF_storeWeb with the appropriate StoreFront related Store name for your Storefront environment Language Settings Configure your desired Language settings and click Finished When you are returned to the previous page displaying all access profiles, select Edit from the newly created policy to open the Visual Policy Editor (VPE) Between Start and Deny, select the + From the Logon tab, click the “Logon Page” radio button and click Add Item. Accept the Logon Page Agent default settings. Click Save Click the “+” (plus sign) to the right of the Logon Page object From the Authentication tab, select your preferred method of authentication. This should match up with the authentication method the StoreFront is expecting to consume.For the purpose of this article, we are using “AD Auth”. The configuration of the AD server is beyond the scope of this article. Click Add Item. Complete the Authentication configuration per AAA guidelines. Click Save. Click the “+” (plus sign) to the right of the Authentication object Select the Assignment tab. Select the SSO Credential Mapping radio button and click Add Item. Leave the defaults and click Save Change the ending for the SSO Credential Mapping fallback to Allow Click Apply Access Policy at the top left Once complete select Apply Access Policy and your VPE should look like the screenshot below Creating a VDI Profile Navigate to Access››Connectivity / VPN : VDI / RDP : VDI Profiles and click Create New Profile Profile name: citrix_vdi Parent Profile: /Common/vdi Click OK Create STA Resolution Halt iRule Navigate to Local Traffic››iRules : iRule Listand click Create Name: STA_STOP Definition: when RULE_INIT { set static::debug_sta_fwd 0 } when HTTP_RESPONSE { if { [HTTP::has_responded] } { log local0. "http has responded" return } if { $tmm_apm_client_type != "citrix-launch" } { #log local0. "apm client type is NOT citrix launch" return } set content_type [string tolower [HTTP::header Content-Type]] if { $content_type contains "application/x-ica" || $content_type contains "application/vnd.citrix.launchdata+xml" } { log local0. "content type is ica or citrix" set ica_file_response 1 set contentLength [HTTP::header "Content-Length"] HTTP::collect [HTTP::header Content-Length] } else { log local0. "content is not citrix" } } when HTTP_RESPONSE_DATA { if { [info exists ica_file_response] } { log local0. "ica_file_response exists" # set session.user.access_mode to local ACCESS::session data set "session.user.access_mode" "local" if { ![info exists target_apm] } { return } } } Create Citrix Logged Out iRule Navigate to Local Traffic››iRules : iRule Listand click Create Name: storefront_logged_out Definition: 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 } } } Note: The storeWebName variable value in the iRule must be changed to match your Citrix store name Configuring an HTTP Profile Navigate to Local Traffic››Profiles : Services : HTTP and click Create Name: storefront_http Parent Profile: http Request Header Erase: Accept-Encoding Request Header Insert: X-Citrix-Via:storefront.itc.demo Note: X-Citrix-Via is the header name and storefront.itc.demo is the value. The value must match the external FQDN in your environment. Redirect Rewrite: All Insert X-Forwarded-For: Enabled Click Finished Creating a VDI Profile Navigate to Access››Connectivity / VPN : VDI / RDP : VDI Profiles and click Create New Profile Profile name: citrix_vdi Parent Profile: /Common/vdi Click OK Creating a Client SSL Profile for Storefront Client Access Navigate to Local Traffic››Profiles : SSL : Client and click Create Name: storefront_clientssl Parent Profile: clientssl Certificate Key Chain: Select the External Cert and Key that will be used for this website Configuring a Storefront Pool Navigate to Local Traffic››Pools : Pool List Name: storefront_pool Health Monitors: tcp Load Balancing Method: Least Connections (member) Address: 10.1.20.6 Service Port 443 Click Add and Finished NOTE: add as many StoreFront servers in your environment to the pool member list Creating a Virtual Server for Storefront Access Navigate to Local Traffic››Virtual Servers : Virtual Server Listand click Create Name: storefront_vs Type: Standard Destination Address/Mask: 10.1.10.101 Service Port: 443 Protocol Profile: tcp HTTP Profile (Client): storefront_http SSL Profile (Client): storefront_clientssl SSL Profile (Server): serverssl Source Address Translation: Auto Map (or whatever is appropriate for your environment) Access Profile: storefront_ap Click the + next to Connectivity Profile to create a new profile. Profile Name: proxy_conn Parent Profile: /Common/connectivity Click Ok VDI Profile: citrix_vdi iRules Highlight “STA_STOP” and “storefront_logged_out” and click the double left arrow button to move the iRule to the Enabled box Default Pool: storefront_pool Default Persistence Profile: cookie Fallback Persistence Profile: dest_addr Click Finished This concludes the configuration of the F5 APM SF-GW There is a minimum requirement of 2 virtual servers on the ICA-GW. The first VS (proxy-vs) will be the listener that client ICA proxy requests are sent to. An iRule attached to this VS will pull out the payload of the ICA proxy request and make a sideband call to another VS (sta-resolver-vs) on the same APM. The sta-resolver-vs VS, via an iRule, will take the payload sent by the proxy-vs sideband call and use the STA server “shortname” in the payload to reference a Datagroup to find the STA server URL. This URL is then populated in the APM session table. The VDI profile will use this URL to contact the STA server to validate the STA ticket. Information received back from the STA server populates the session table. The ICA-GW now has the information it needs to proxy the ICA traffic. F5 APM ICA-GW Configuration(link back to Top of page) Creating a STA Ticket Resolver Access Policy Navigate to Access››Profiles / Policies : Access Profiles (Per-Session Policies) and click Create General Properties Name: sta_resolver_ap Profile Type: All Customization Type: Modern Configure your desired Language settings and click Finished When returned to the previous page displaying all access profiles, select Edit from the newly created policy Between Start and Deny, select the + and then the “General Purpose” tab Select “Empty” and click Add Item Name: sessionexternal_sta_ticket Click the Branch Rulestab Click the Add Branch Rulebutton Name: External STA Ticket Click changenext to Expression: Empty Click the Advancedtab In the advanced field enter: expr {[mcget {session.external_sta_ticket}] == 1} Click Finished Click Save Click Apply Access Policy at the top left Once complete select Apply Access Policy and your VPE should look like the screenshot below Create a client SSL profile that contains the appropriate certificate, key, and chain. This configuration is beyond the scope of this article. A server SSL profile is not required as traffic between the ICA-GW and DDC does not use TLS. Creating a VDI Profile Navigate to Access››Connectivity / VPN : VDI / RDP : VDI Profiles and click Create New Profile Profile name: citrix_vdi Parent Profile: /Common/vdi Click OK Create STA ticket Extractor iRule Navigate to Local Traffic››iRules : iRule Listand click Create Name: StaTicketExtractor Definition: See iRule here: https://devcentral.f5.com/s/articles/Extract-Citrix-Secure-Ticket-Authority-STA Note: A Virtual Server name (sta-resolver-vs) is referenced in the command ‘set conn [connect "sta-resolver-vs"]’.This VS will be created further in the article. If the VS is created with another name, then the command in this iRule must be changed to match the name of the VS. Creating a Virtual Server for ICA Proxy Navigate to Local Traffic››Virtual Servers : Virtual Server Listand click Create Name: proxy-vs Type: Standard Destination Address/Mask: 10.1.10.115 Note: This will be the IP address available to external users attempting to access Citrix resources Service Port: 443 Protocol Profile: tcp HTTP Profile (Client): http SSL Profile (Client): citrix_client_ssl SSL Profile (Server): leave blank Source Address Translation: Auto Map Access Profile: sta_resolv_ap Click the + next to Connectivity Profile to create a new profile. Profile Name: proxy_conn Parent Profile: /Common/connectivity Click Ok VDI Profile:citrix_vdi iRules Highlight “StaTicketExtractor” and click the double left arrow button to move the iRule to the Enabled box Do not select a Default Pool or Persistence Profile Click Finished Create STA Ticket Resolver iRule Navigate to Local Traffic››iRules : iRule Listand click Create Name: StaTicketResolver Definition: See iRule here: https://devcentral.f5.com/s/articles/Resolve-Citrix-Secure-Ticket-Authority-STA Create a DataGroup to map STA server shortnames to the URL of the STA server Navigate to Local Traffic››iRules : Data Group Listand click Create Name: sta_dg Type: string Enter as many pairs of String:Value necessary for your environment. The String will be the STA server shortname; typically in the STA12345678 format although this is customizable in the Windows registry. The value is the URL of the STA server in the format: https://[FQDN]/scripts/ctxsta.dll. Check with the Citrix system administrator if the STA servers should be contacted via http or https. This guide was written for HTTPS Click Finished Creating a Virtual Server for STA ticket Resolution Navigate to Local Traffic››Virtual Servers : Virtual Server Listand click Create Name: sta-resolver-vs Note: This name must match the name referenced in the ‘set conn [connect "sta-resolver-vs"]’ command in the previously created “StaTicketExtractor” iRule Type: Standard Destination Address/Mask: 1.2.3.4 Note: This can be any dummy IP address Service Port: 80 Protocol Profile: tcp HTTP Profile (Client): http SSL Profile (Client): leave blank SSL Profile (Server): serverssl Source Address Translation: Auto Map Access Profile: sta_resolv_ap Connectivity Profile: proxy_conn VDI Profile:citrix_vdi iRules Highlight “StaTicketResolver” and click the double left arrow button to move the iRule to the Enabled box Do not select a Default Pool or Persistence Profile Click Finished This concludes the configuration of the F5 APM SF-GW Conclusion(link back to Top of page) And that’s it. When you connect to your StoreFront virtual server on the F5 APM SF-GW, you will be presented with an F5 APM login screen.Login with your AD (or other) credentials.This should SSO you into Storefront where you will be presented with applications assigned to your AD account or groups. When you click on an app or desktop, an ICA file is downloaded and automatically launched by the Citrix Connection Manager (Receiver).The SSLProxyHost line in the ICA file directs your client to the F5 APM ICA-GW defined in the StoreFront configuration. The ICA-GW reads the payload in the request and contacts the STA server for validation, and then your app/desktop should load.Resolve Citrix Secure Ticket Authority (STA)
Problem this snippet solves: Optimal Gateway Routing (OGR)for Citrix Storefront is a design whereby a Citrix web client is directed to an ICA Proxy Gateway (ICA-GW) anywhere in the world that is closest to the app/desktop hosting environment (XenApp and XenDesktop servers) which may not be on the same Citrix StoreFront ADC (NetScaler) Gateway (SF-GW) which has authenticated the user. This is in contrast to being directed to a single ADC Gateway device that hosts SF-GW and ICA-GW. In a Citrix ADC deployment, the ICA-GW (not the SF-GW) is responsible for validating/resolving the STA ticket provided by a Secure Ticket Authority (STA) server. Since the ICA-GW is responsible for this validation, it allows OGR to function and send ICA traffic to a different ICA-GW than what was used to download the ICA file from StoreFront. This iRule will be used to resolve/validate the STA ticket which has already been extracted from the client's ICA proxy request. How to use this snippet: See DC Article "Solution for Citrix Optimal Gateway Routing" for implementation. Code : ## ## Resolver iRule ## To enable detailed iRule debugging, set the static::debug_sta_rslv variable in the RULE_INIT event to 1 ## Updated July 14, 2021 by b.otlin@f5.com ## when RULE_INIT { set static::debug_sta_rslv 0 } when HTTP_REQUEST { if { [HTTP::has_responded] } { if { $static::debug_sta_rslv } { log local0. "HTTP::has_responded" } return } else { if { $static::debug_sta_rslv } { log local0. "HTTP::has NOT responded" } } set sta_request [expr {[HTTP::path] == "/f5apm/ctx-sta"}] if { $static::debug_sta_rslv } { log local0. "req is [HTTP::uri]" } if { $static::debug_sta_rslv } { log local0. "sta req is $sta_request" } if {!$sta_request} { # exit event if the request was not a STA request if { $static::debug_sta_rslv } { log local0. "sta_request does NOT exist, exit event" } return } else { if { $static::debug_sta_rslv } { log local0. "sta_request does exist, continue" } } sharedvar internal_ica_file_request if { [info exists internal_ica_file_request] } { if { $static::debug_sta_rslv } { log local0. "internal_ica_file_request exists...return 200 ok to SF APM with mod ICA info" } HTTP::respond 200 content \ "\[ApplicationServers\]\nApp=\n\[App\]\nAddress=;[HTTP::query]" \ "Content-Type" "application/x-ica" if { $static::debug_sta_rslv } { log local0. "unset internal_ica_file_request and exit event" } unset internal_ica_file_request return } else { if { $static::debug_sta_rslv } { log local0. "internal_ica_file_request does NOT exist, continue" } } if { [info exists sta_request_sid] } { if { $static::debug_sta_rslv } { log local0. "sta_request_sid is $sta_request_sid" } if { $static::debug_sta_rslv } { log local0. "insert MRHSession cookie = $sta_request_sid and X-F5-Client header" } HTTP::header insert \ "Cookie" "MRHSession=$sta_request_sid" \ "X-F5-Client" "citrix-launch" VDI::enable if { $static::debug_sta_rslv } { log local0. "enable VDI" } set internal_ica_file_request 1 if { $static::debug_sta_rslv } { log local0. "internal_ica_file_request set to 1" } SSL::disable serverside if { $static::debug_sta_rslv } { log local0. "disable SSL serverside" } virtual [virtual name] if { $static::debug_sta_rslv } { log local0. "go back to same VS" } } else { if { $static::debug_sta_rslv } { log local0. "sta_request_sid does NOT exist" } HTTP::header insert "clientless-mode" "1" if { $static::debug_sta_rslv } { log local0. "insert clientless-mode header" } } } when HTTP_RESPONSE { if { [HTTP::payload] contains "Address=;" } { if { $static::debug_sta_rslv } { log local0. "Response payload contains Address=; which denotes an ICA File" } set sta_address [HTTP::payload] regexp -line {^(?:[^;]*;){2}([^;]*)} $sta_address -> sta1 regexp -line {^(?:[^;]*;){4}([^;]*)} $sta_address -> sta2 set STA1 [class match -value -- $sta1 equals sta_dg] if { [info exists sta2] } { set STA2 [class match -value -- $sta2 equals sta_dg] ACCESS::session data set session.citrix.sta_servers "$STA1;$STA2" if { $static::debug_sta_rslv } { log local0. "STA from SF is $sta1 and $sta2 resolved to FQDN: $STA1 and $STA2 and adding to access session table" } } else { if { $static::debug_sta_rslv } { log local0. "STA from SF is $sta1 resolved to FQDN: $STA1 and adding to access session table" } ACCESS::session data set session.citrix.sta_servers "$STA1" } } else { if { $static::debug_sta_rslv } { log local0. "not an ICA" } } } when HTTP_RESPONSE_RELEASE { if { [HTTP::has_responded] } { if { $static::debug_sta_rslv } { log local0. "HTTP has_responded...exit event" } return } if {!$sta_request} { if { $static::debug_sta_rslv } { log local0. "sta_request does NOT exist...exit event" } return } if { [HTTP::status] == 200 } { if { $static::debug_sta_rslv } { log local0. "HTTP status is 200, remove Set-Cookie header" } # There is no need to expose this SID HTTP::header remove Set-Cookie } else { if { $static::debug_sta_rslv } { log local0. " HTTP status is NOT 200, remove access session" } # Remove session on failed STA resolution ACCESS::session remove } } when ACCESS_SESSION_STARTED { if { !$sta_request } { if { $static::debug_sta_rslv } { log local0. "sta_request does NOT exist...exit event" } return } else { if { $static::debug_sta_rslv } { log local0. "sta_request exists...continue" } } if { $static::debug_sta_rslv } { log local0. "sta_request exists so set 'session.external_sta_ticket' to 1" } ACCESS::session data set "session.external_sta_ticket" "1" } when ACCESS_POLICY_COMPLETED { if { !$sta_request } { if { $static::debug_sta_rslv } { log local0. "sta_request does NOT exist...exit event" } return } else { if { $static::debug_sta_rslv } { log local0. "sta_request exists...continue" } } set sta_request_sid [ACCESS::session sid] if { $static::debug_sta_rslv } { log local0. "sta_request_sid is $sta_request_sid" } } Tested this on version: 15.1Extract Citrix Secure Ticket Authority (STA)
Problem this snippet solves: Optimal Gateway Routing (OGR) for Citrix Storefront is a design whereby a Citrix web client is directed to an ICA Proxy Gateway (ICA-GW) anywhere in the world that is closest to the app/desktop hosting environment (XenApp and XenDesktop servers) which may not be on the same Citrix StoreFront ADC (NetScaler) Gateway (SF-GW) which has authenticated the user. This is in contrast to being directed to a single ADC Gateway device that hosts SF-GW and ICA-GW. In a Citrix ADC deployment, the ICA-GW (not the SF-GW) is responsible for validating/resolving the STA ticket provided by a Secure Ticket Authority (STA) server. Since the ICA-GW is responsible for this validation, it allows OGR to function and send ICA traffic to a different ICA-GW than what was used to download the ICA file from StoreFront. This iRule will be used to extract the STA ticekt information from the client's ICA proxy request. the iRule will then force a sideband call to a local virtual server which is responsible for validating the STA ticket with the STA server. How to use this snippet: See DC Article "Solution for Citrix Optimal Gateway Routing" for implementation. Code : ## ## Extractor iRule ## To enable detailed iRule debugging, set the static::debug_sta_extr variable in the RULE_INIT event to 1 ## Updated July 14, 2021 by b.otlin@f5.com ## when RULE_INIT { set static::debug_sta_extr 0 } #collect TLS data for evaluation when CLIENTSSL_HANDSHAKE { SSL::collect } when CLIENTSSL_DATA { set data [SSL::payload] # Look for specific Session Reliability CGP payload; Pre-amble is hex 1A followed by ASCII encoded CGP/01 # Look for specific non-Session Reliability ICA Payload; Pre-amble is hex 05 01 00 03 # ICA ticket info follows these pre-ambles if { $data starts_with "\x1ACGP/01" || $data starts_with "\x05\x01\x00\x03"} { regexp -line {;([\d\w;]*)} $data -> ticket if { $static::debug_sta_extr && $data starts_with "\x1ACGP/01" } { log local0. "CGP with SR ticket is $ticket" } if { $static::debug_sta_extr && $data starts_with "\x05\x01\x00\x03" } { log local0. "ICA without SR ticket is $ticket" } if { [string length $ticket] > 0 } { # create ticket variable from CGP or ICA payload set ticket [string trimleft $ticket ";"] # make sideband call to resolver VS # resolver VS gets a synthetic ICA download and then performs STA validation set conn [connect "sta-resolver-vs"] send $conn "GET /f5apm/ctx-sta?$ticket HTTP/1.0\r\nHost: APM\r\n\r\n" recv -eol $conn close $conn } } SSL::release SSL::collect } Tested this on version: 15.1
Smart Card Authentication to Citrix StoreFront Using F5 Access Policy Manager
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. Configuring Storefront to Support Gateway Passthrough Launch the Citrix StoreFront Management Console Rightclick Stores and select Manage Citrix Gateways Click Edit in order to modify an existing store or Add and use the following settings General Settings Display name: APM Citrix Gateway URL: https://withsf.itc.demo/ The Citrix gateway URL is the external URL users will use to access the F5 BIG-IP virtual server. Usage or role: Authentication and HDX routing 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. Select Security Ticket Authority and click Add Type the host of the DDC hosting the STA service Select Authentication Settings Logon type: Domain Callback URL: https://proxyauth.itc.demo Click OK Manage Beacons Define a beacon address that is only accessible by internal users. For External beacons, define 2 addresses that are only accessible to external users Manage Authentication Methods Select Pass-through from Citrix Gateway Click the drop-down to the right and select Configure Delegated Authentication Check the box to Fully delegate credential validation to Citrix Gateway Click the drop-down to the right and select Configure Password Validation From the drop-down select Validate Passwords via Delivery Controllers and select a delivery controller. Manage Receiver for Web Sites Select configure and Authentication Methods Select Pass-through from Citrix Gateway Select Advanced Settings and modify the Enable loopback communication to OnUsingHttp 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 Check the box to Enable Remote Access and allow users to access only resources delivered through StoreFront (No VPNN tunnel) Select APM from the given options Enabling Kerberos Constrained Delegation in AD and the F5 BIG-IP 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. https://devcentral.f5.com/s/articles/configuring-certificate-based-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm-31571 Creating an Active Directory AAA Object Navigate to Access››Authenticationand click Create Name: ad-aaa Domain Name: ITC.DEMO Server Connection: You can use a pool or select direct to use a single AD source IP: 10.1.20.8 and click Add Admin Name: define a user that has the ability to bind to AD Admin Password: password Click Finished Creating a Smart Card Authentication Access Policy Navigate to Access››Profiles / Policies : Access Profiles (Per-Session Policies) and click Create General Properties Name: SC Profile Type: All Customization Type: Modern Configure your desired Language settings and click Finished When returned to the previous page displaying all access profiles, select Edit from the newly created policy Between Start and Deny, select the + and then the Authentication tab From the authentication list, select On-Demand Cert Auth and click Add Item From the Auth Mode menu, select require from the drop-down and Save Following the Successful branch, click the + and then the Assignment tab From the assignment list, select Variable Assign and Add Item Select Add new entry In the 1st assignment field, select change In the Custom Variable field type session.logon.last.upn In the Custom Expression box add the following expression 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"; Click Finished Select Add new entry and change In the Custom Variable field type session.logon.last.domain In the Custom Expression field type expr {"ITC.DEMO"} Click Finished 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. Select Add new entry and change In the Custom Variable field type session.citrix.sta_servers In the Custom Expression field, type expr{http://xenapp1.itc.demo/scripts/ctxsta.dll"} Click Finished Note: The sta server should be the same server defined in Citrix StoreFront earlier in this article You should now see three variable assignments, click Save Following the fallback branch, select the + and select the Authentication tab From the authentication list, select AD Query and Add Item From the Server drop-down, select the AD AAA object created earlier in this article SearchFilter: userPrincipalName=%{session.logon.last.upn} Select the Branch Rules tab and click change Remove the AD User's Primary Group ID is and click Add Expression Context: AD Query Condition AD Query Passed Active Directory Query has Passed Click Add Expression and Finished Change the branch name to AD Query Passed and click Save Following the AD Query Passed branch, select the + and click the Assignment tab From the assignment list, select Variable Assign and Add Item Click Add new entry In the Custom Variable field type session.logon.last.username In the Custom Expression field, select AAA Atribute from the drop down Agent Type: AD Attribute Type: Use user's attribute AD attribute name: sAMAccountName Click Finished and Save Following the fallback branch, select the Deny ending and change to Allow Once complete select Apply Access Policy and your VPE should look like the screenshot below Creating an Access Policy for the Citrix Call Back Function Navigate to Access››Profiles / Policies : Access Profiles (Per-Session Policies)and click Create Name: citrix-callback Profile Type: All Select the supported languages and click Finish. When returned to the list of access policies, select the Edit option as you did in the previous steps Change the fallback action to Allow and Apply the Access Policy Configuring a Storefront Pool Navigate to Local Traffic››Pools : Pool List Health Monitors: https Load Balancing Method: Least Connections (member) Address: 10.1.20.6 Service Port 443 Click Add and Finished Configuring an HTTP Profile Navigate to Local Traffic››Profiles : Services : HTTP and click Create Name: smart-card-http Parent Profile: http Request Header Erase: Accept-Encoding Request Header Insert: X-Citrix-Via:withsf.itc.demo Note: X-Citrix-Via is the header name and withsf.itc.demo is the value. The value must match the external fqdn. Redirect Rewrite: All Insert X-Forwarded-For: Enabled Click Finished Create a Client SSL Profile to Support Smart Card Logon Navigate to Local Traffic››Profiles : SSL : Client and click Create Name:smartcard Parent Profile: clientssl Certificate Key Chain: Select the External Cert and Key that will be used for this website Trusted Certificate Authorities: Select the CA certificate or bundle that was used to issue the client certificates Advertised Certificate Authorities: Select the CA certificate or bundle that was used to issue the client certificates Click Finished Creating a Virtual Server for Smart Card Authentication Navigate to Local Traffic››Virtual Servers : Virtual Server Listand click Create Name: smart-card-WSF Type: Standard Destination Address/Mask: 10.1.1.103 Note: This will be the IP address available to external users attempting to access Citrix resources Service Port: 443 Protocol Profile: f5-tcp-wan HTTP Profile (Client): smart-card-http SSL Profile (Client): smartcard SSL Profile (Server): serverssl Source Address Translation: Auto Map Access Profile: SC Click the + next to Connectivity Profile to create a new profile. Profile Name: WithStoreFront_Connectivity Parent Profile: Connectivity Click Ok VDI Profile: vdi Default Pool: storefront Default Persistence Profile: cookie Fallback Persistence Profile: source_addr Click Finished Create an Internal Call Back Virtual Server Navigate to Local Traffic››Virtual Servers : Virtual Server Listand click Create Name: internal_callback Destination Address/Mask: 10.1.20.101 Note: This is an internally accessible only IP address that will be accessed by StoreFront Service Port: 443 Protocol Profile (Client): f5-tcp-lan HTTP Profile (Client): http SSL Profile (Client): smartcard 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. SSL Profile (Server): serverssl Access Profile: citrix-callback Connectivity Profile: WithStoreFront_connect VDI Profile: vdi Click Finished Configure Log Out iRule for StoreFront Navigate to Local Traffic››iRules : iRule Listand click Create Name: sf-loggedout Deffinition: Use the tcl content below and modify the storeWebName to reflect your environment 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 } } } Click Finished Assign Log Out iRule to External Virtual Server Navigate to Local Traffic››Virtual Servers : Virtual Server List and select the external virtual server created in the previous steps (Not the callback) Select the resources tab Manage next to iRules and move sf-loggedout from Available to Enabled Cick Finished Validate Access to StoreFront Access From your external client, browse to your external URL where you should be prompted for a certificate After clicking OK, if you are using Chrome or Firefox, you will be prompted to Detect Receiver, click Detect Receiver Click Open Citrix Receiver Launcher If you are not automatically redirected, select Already Installed If all configuration steps were followed, you should then be presented with your apps and desktops 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!
Storefront logout and re-authenticate with no prompt for credentials
Hi, We've integrated citrix storefront with F5 (11.6.2) recently by using iApp . Everything works great but we have an issue with the authentication to the storefront once user logs off from the citrix, Users are able to logon without prompting for username and password when clicked on logon. We are using Imprivata for Radius and its MFA. Any help would be much appreciated. FYI: no user sessions should be terminated after logout is enabled.
Support for 2 different Citrix farms on one Virtual Server
Hi All, We are currently using a BIG-IP APM device to allow external access to our XenApp 6.0 farm with Web Interface. Basically, we are using the BIG-IP as a NetScaler replacement. We are in the process of trying to roll out a XenDesktop 7.8 implementation using Store Front. My problem comes with trying to support both environments using a single Virtual Server. Right now, we have an SSO form and a iRule in place for the 6.0/Web Interface farm. The SSO Configuration is applied to the Access Policy and the iRule is applied to the Virtual Server. This is problematic, since I can't think of a way to provide support for both environments at the same time. I can either support one or the other by changing the SSO Configuration and the iRule, but applying the set for the 6.0 Farm breaks the 7.8 farm and vice-versa. What I am trying to determine is if there is any other way to apply the SSO Configuration and the iRule based on a user's role, rather than at the VS and Access Policy level. In my access policy I do a AD group membership check for a group called "XEN 7 Users". If my user is in that group, I can then assign them some SSO credentials and the StoreFront Pool. If they are not in the "XEN 7 Users" group, they get assigned SSO credentials and the Web Interface pool. However, if they are in the "XEN 7 Users" group, but the SSO config and IRule for the Web Interface are in place they can't access the Store Front servers. Is there some way I could assign SSO configurations and iRules based on the user's role, rather than to the Access Policy and Virtual Server? I am looking to get a little more granular. Thanks, I hope this was clear. -John
Citrix APM 11.5.1 HF8 Citrix Client download Bundle not working
I experience something weird while implementing APM with Citrix Storefront is that when I try to Access the F5 APM published page and the client does not contain the Citrix Receiver client the APM should redirect the client to the location where to download the client. Everything else is working correctly. This is Spanish for not having received any data (Empty response) First we tried to change the Citrix Client Bundle to the internal installation package and it shows the before mentioned error. When trying to change it to an external link it does not change the download location, in other words the problem persists. One thing I dont have clear is how exactly is this object linked to the APM Access policy or webtop? Something similar is explained in this article https://devcentral.f5.com/questions/issue-citrix-client-bundle-configuration-apmCitrix XenApp iApp APM with Storefront - Cross Access Profile SSO
We've deployed the XenApp iApp in the configuration using APM to send traffic to Storefront. When deploying the iApp, I allowed it to create the APM access profile. I have since noticed that SSO between our Webtop AP and our Citrix AP doesn't appear to be working. The Access Profile SSO Domain Cookie has the same value across both Access Profiles (ex. company.com), but when clicking the Storefront link (Webtop Link - Application URI ex. storefront.company.com) from the webtop, you are redirected to the F5 login page for the Storefront Access Profile. Has anyone else seen this behavior? Any ideas how to get SSO from the webtop into the Storefront AP working? I've also noticed that if I log into Storefront first, and open a new browser tab to the webtop, I immediately get a Connection Reset message.
APM Citrix tidy session termination
Hi, I have used the f5.citrix_xenapp_xendesktop.2012_06_27 iApp to migrate remote access to our Citrix Xenapp and Xendesktop environment through F5's running APM and 11.3 HF6. We have kept the Citrix Web Interface in place as the business had already invested in the Storefront upgrade (I initally was connecting to web interface but the Storefront upgrade has now been rolled out). I am confused about how the iApp achieves a tidy close down of a remote session. Obviously there is an iRule that looks for a URI to be passed back from the web interface \ Storefront that contains "loggedout". I am fine with the mechanics of how this works but what I am confused about is that this doesnt seem the most intuitive way of doing things. Also Storefront does not redirect to a URI that contains "loggedout" it just dynamically changes the web page to say "logged out" in the body of the page. The reason i think this is not intuitive is that we had a 20 minute timeout on our Web Interface - ie. you get redirected to the "loggedout" URI after 20 minutes....so if you had a remote desktop session running but idle you get thrown off after 20 minutes. Our citrix session idle timeout is 3 hours......so ok fine change the timeout on Web Interface to be 3 hours.....but isnt this a bit of a security risk?....somebody could be working on a public machine and close down their remote session but forget to logoff from Web Interface. The imperfect workaround I have in place at the moment is to reduce the inactivity timeout under the access policy to 60 seconds. This gives users enough time to select a remote session upon logon, the timeout gets constantly reset during their session, it also gives them enough time to logoff from a session and select another one and also is sufficently low so that it doesnt matter whether they click logoff from Web-UI \ Storefront or close the browser...after 60 seconds the session is dead. The downside of this is that test users have noticed that they can click logoff but then immediately re-target the URL and get straight back in without authenticating which obviously isnt great. I am happy to hear if I am missing the point or something obvious it just seems that the iRule to check for a URI that contains "loggedout" will not work for us. Also, as mentioned, I do not think this will work at all with Storefront. Any advice greatly appreciated!
