- Purpose
- Description
- Demo
- Supported Mobile Devices
- Limitations
- Configuration
- End User Interface/User Experience
- Frequently Asked Questions
Brief Description
This feature provides secure remote access for Citrix Receiver application running on mobile devices to XenApp/XenDesktop VDI servers through ASA, eliminating the need for Citrix Access Gateway.
Purpose
Citrix Access Gateway (CAG) was traditionally the only way to provide secure remote access to virtualized Citrix resources (desktops and applications). In typical deployment such device would be located behind the firewall in DMZ zone. Current feature adds ASA functionality to support secure remote connection to virtual resources from mobile devices.
Traditional deployments require presence of CAG, typically located behind the Firewall:
With ASA, connections to internal Citrix resources is possible without presence of CAG:
Description
For ASA to proxy Citrix Receiver to a Citrix Server, ASA impersonates Citrix Access Gateway. When a user tries to connect to Citrix virtualized resource, instead of providing the Citrix Server’s address/credentials, users enter ASA’s SSL VPN IP address and credentials.
A new ASA handler is created to handle requests, including authentication requests from Citrix Receivers (HTTPS requests with agent string identifying itself as Citrix Receiver). After ASA has verified the credentials, the Receiver client starts to retrieve entitled applications through the ASA. The ASA rewrites and proxies to the XenApp or XenDesktop Server’s XML service interface (XML service is a service running on a Citrix server that service virtualization resource related requests).
ASA will connect and authenticate to VDI server using preconfigured credentials (see Configuration section). When sending credentials to back-end XenApp/XenDesktop server, ASA will always obfuscate user password using Citrix CTX1 encoding.
Demo
Supported Mobile Devices
- iPad --> Citrix Receiver version 4.x or later
- iPhone/iTouch --> Citrix Receiver version 4.x or later
- Android 2.x Phone --> Citrix Receiver version 2.x or later
- Android 3.x Tablet --> Citrix Receiver version 2.x or later
- Android 4.0/4.1 Phone/Tablet --> Citrix Receiver version 2.x or later
Limitations
- Certificate Limitations:
- Certificate/Smart Card authentication is not supported as means of auto sign-on since these forms of authentication do not allow the ASA in the middle.
- Client certificate verifications, tunnel group selection/group URL, double authentication, password expiration notification, internal passwords and CSD (everything in CSD, not just Vault) are not supported when standalone/mobile clients are used (because standalone/mobile virtualization infrastructure clients do not understand these concepts)
- Md5 signature in the certificates are not working due to security issue and is a problem on iOS: http://support.citrix.com/article/CTX132798
- SHA2 signature is not supported except windows: http://www.citrix.com/site/resources/dynamic/salesDocs/Citrix_ClientFeatureMatrix.pdf
- Key size >1024 is not supported as of now.
- Other Limitations:
- Citrix Receiver client accesses only one XenApp/XenDesktop Server at a time. As a result, the ASA proxies requests to one XenApp/XenDesktop per VPN session also. ASA picks the first XenApp/XenDesktop configured when a Citrix Receiver client connects.
- HTTP redirect is not supported since current version of Citrix Receiver application does not work with redirects.
- Only Default Tunnel Group is supported in phase 1.
- Only password based authentication is implemented in phase 1.
- Citrix Receiver mobile client to access web interface of Citrix servers is currently not supported.
- XML service must be installed and configured on the XenApp and XenDesktop servers
Configuration
CLI Commands
When a user uses Citrix Receiver mobile client to log on to the ASA, the ASA needs to connect it to a pre-defined Citrix XenApp or XenDesktop server. For this, the administrator configures the Citrix server’s address and logon credentials under Group Policy or username. In case both username and group-policy CLI are configured, username settings will take precedence over group-policy.
configure terminal group-policy DfltGrpPolicy attributes webvpn vdi type <citrix> url <url> domain <domain> username <username> password <password>
configure terminal username <username> attributes webvpn vdi type <citrix> url <url> domain <domain> username <username> password <password>
• type: type of VDI. For Citrix Receiver type must be citrix
• url : full url of the XenApp or XenDesktop server incluiding http or https, hostname, port number, as well as the path to the XML service.
Hostname and XML service path can contain a clientless macro. If XML service path is not provided, default path /Citrix/pnagent/ will be used
• username: username for logging into the virtualization infrastructure server, this can be a clientless macro
• password: password for logging into the virtualization infrastructure server, this can be a clientless macro
• domain: domain for logging into the virtualization infrastructure server, this can be a clientless macro
Example Configuration
The following are valid configuration examples:
vdi type citrix url http://192.168.1.2 domain domain1 username user1 password pass1
vdi type citrix url https://192.168.1.2/Citrix/pnagent1/ domain domain2 username username2 password password2
vdi type citrix url http://192.168.1.2:8080/Citrix/pnagent3 domain CSCO_WEBVPN_MACRO1 username CSCO_WEBVPN_USERNAME password CSCO_WEBVPN_PASSWORD
ASDM Configuration
Asdm -> Configuration -> Remote Access VPN -> Clientless SSL VPN Access - > Group Policy
Edit -> More Options-> VDI Access
Add VDI Server
Supported Modes
Single mode.
End User Interface/User Experience
Adding new account
The user experience of using Citrix Receiver to access virtual resources via the ASA is the same as when a Citrix Access Gateway is used.
If no servers are configured, user must configure a new virtual resource.
Users provide ASA's FQDN/IP address.
Users must check Access Gateway, Standard Edition, and enter credentials to connect to ASA.
When user profile is saved, application will automatically ask for credentials (ASA) and try to login.
When logged in, the application will display a list of published resources.
Users can navigate folders and click the corresponding resource to launch it.
Logging out WebVPN session
Citrix Receiver application does not provide means to terminate webvpn session with connected ASA or CAG at will. Typically such session will be terminated upon reaching configured timeout. Although newest version of Citrix Receiver have a new button "Logoff", such button does not terminate existing session with ASA. Instead it closes all open applications, and displays to user the list of configured servers. Therefore, if ASA is configured to use only 1 license per user, clients that use "Logoff" button will not be able to log back in until after session times out.
To allow end-users terminate webvpn session at will, and as a result release ASA license, new functionality has been added to injects Secure Logoff resource.
Such injection happens every time Citrix Receiver fetches the list of published resources.
When user clicks on Secure Logoff application, the session between ASA and Citrix Receiver is terminated. To properly release ASA license, Secure logoff resource must be used to terminate webvpn session instead of native Citrix Receiver Logoff button.
Different messages are displayed as a result of session termination based on the mobile devices and the version of the Citrix Receiver. Also, the difference in the way Citrix Application is written for different mobile platforms yields different user experience when logging off Android devices.
On iPad and iPhone, Citrix Receiver will display message Your access to Gateway session has expired, please log on again. When user clicks OK, Citrix receiver brings up the screen with configured servers.
Android devices also display injected Secure Logoff resource.
However, when user clicks Secure logoff application, network connection Error will be displayed.
Although by this time the webvpn session is terminated, Citrix Receiver application does not have embedded messages to properly inform the user of further actions. Note that this behavior is expected. When such "Error" message is displayed as a result of terminating session, users are expected to click "Cancel" button, then "Back" button on Android device to exit current account, and confirm "OK" when asked about leaving the account.
After exiting current account, the user will be presented with list of preconfigured servers.
ASA identity certificates and Certificate Authorities (CA)
- For Citrix Receiver to work with ASA, mobile devices must trust CA that issued ASA's identity certificate . ASA's certificate must be issued for a fully qualified domain name (e.g. clientlessvdi.cisco.com), and NOT an IP address of the ASA. If ASA's certificate has been issued by intermediate CA that is not present in the key-store of mobile device, such intermediate CA must also be trusted.
- Apple devices running ios can support self-signed ASA certificates, since they support straight-forward import of certificates and CAs ([1], page 54 ).
- On Apple mobile devices running ios, receiver will allow to connect to ASA and retrieve the list of applications, if certificate warnings are ignored. However, the user may not be able to start any of the published resources until valid ASA's certificate is installed.
- Some Android OS mobile device provide no legitimate way of importing third party certificates into the key store. Therefore, for Citrix Receiver on such Android devices to work with ASA/CAG, ASA must have an identity certificate issued by CA that has been embedded into the key store, e.g. Verisign, Godaddy, etc.
- On Android mobile devices, Citrix Receiver will not allow to connect to ASA if ASA's certificate is not present in the key store of the device.
- When Citrix Receiver connects to ASA with untrusted certificate, user will be prompt with pop-up warnings whether to continue or not.
Additional Information
For XenDesktop to work through the clientless, if there are any intermediate firewalls between the ASA (inside) and the XenDesktop server, make sure the ports 443, 1494, 2598 and 80 are open on that firewall. Also, ensure that the ports are open for both the XenDesktop Server and the pool of XenDesktops.
SSL Error 4: Error number: 183
This error is seen when the connection to the XML broker (XenDesktop server) is allowed, but the ports 1494 and 2598 to the actual XenDesktop pool is blocked. You can debug by enabling all ports and then narrow down the required ports.
Bugs and Enhancement Requests
CSCug45674 ASA : Citrix Receiver Proxy broken on enabling TCP-State-Bypass
CSCug18734 ENH: Citrix Receiver proxy on ASA support for backend Storefront server
Frequently Asked Questions
1. Does this new feature retain the granular controls configured on the XenServer? For example controls such as Client Drive Redirection, Client Printer Redirection, Client Clip board Redirection and Client USB devices redirection?
Answer: These parameters are defined on the XenServer and are part of the ICA file. The ASA does not modify these parameters. So, what ever setting you have on XenApp or XenDesktop will be reflected on the client.
2. Does the ASA have granular controls of the ICA connection such as prevent cut-n-paste, control Printer, Drive, Clip Board or USB redirection?
Answer: ASA doesn't modify the above settings. So, what ever setting you have on the XenApp or XenDesktop will be reflected on the receiver client.
