Multi-Stores Citrix environment BIG-IP APM
Introduction In this article we are going to discuss a use case, where we have multiple stores URIs hosted at the same Citrix StoreFront. Following Citrix deployment guide , we end up with the below policy configurations, The created Form Based Single Sign-On look like the below, Note, Make sure to validate the strart URI and form action if any customization done at store front side. Additional configurations In order to adjust the configurations to match our multi-store setup, we will follow the below, As a start we will need to replicate the SSO settings to match the number of hosted stores, below example for additional two stores (StoreB, StoreC) StoreB StoreC Then we create an iRule similar to the below and attach it to XML HTTPS virtual server created by the iapp. when ACCESS_ACL_ALLOWED { switch -glob -- [string tolower [HTTP::uri]] { /citrix/storea/explicitauth/login* { WEBSSO::select Citrix_storea_sso_form_based } /citrix/storeb/explicitauth/login* { WEBSSO::select Citrix_storeb_sso_form_based } /citrix/storec/explicitauth/login* { WEBSSO::select Citrix_storec_sso_form_based } } } At the end, we remove the SSO settings under the access policy to allow our iRule to control the SSO selection. References Citrix XenApp or XenDesktop deployment guide
Horizon View "This Page is Not Secure"
I have a connection to my VDI desktops via F5 (build using the iApp) and it essentially works i.e. I can get a virtual desktop although with a slight issue. To start with I enter the URL e.g. https://myvdi.mydomain.com Then after authenticating on the connection server and making my choice of desktop, the URL in the address bar changes to an IP in the range of the private LAN for the virtual desktops e.g. https://10.180.0.80:22443/d/DE841123-FE72-4C6D-A9F3-2E6B7072D7E1/certAccept.html?numPages=3 This results in a typical "this site is not secure" page in IE which I have to manually press on "go on to the webpage." Once I manually continue everything is fine as the URL is then https://myvdi.mydomain.com/portal/webclient/index.html/desktop and I get my authenticated, secure desktop. Does anyone know how I can stop this behaviour?
VMware Horizon View iAPP VDI + HTML5
Greetings! This is my first post and I am not an F5 guru but I am wondering if anyone has gotten all the ports working for VMware Horizon View and the latest iApp for Horizon View. I am specifically wondering if anyone has gotten HTML5 to the desktop working in their environment. We have 4 brokers all running View 5.2. Accessing the individual servers works fine using HTML5. When trying to add 8443 it appears like it will work but it looks like it failing on the connection to the Broker after Authentication. From a Network trace it appears we connect on 443 (authentication) to one broker and then when we try to connect to 8443 (HTML 5 access to the desktop) it fails. If I disable 3 of the 4 pool members it works every time. If I enable 2 of the 4 pool members if fails 50% of the time.... Any advice? Thanks!VMware Horizon and F5 iAPP Deployments Backed by Ansible Automation
The Intro: A little over a year ago I knew barely anything about automation, zero about ansible, and didn't even think it would be something so tied to my life like it is now. I spend all my moments trying to think about how I can make Automation easier in my life, and being in Business Development I spend a lot of time testing F5 solutions and integrations between vendors (specifically between F5 and VMware as well as F5 and RedHat Ansible). I figured why not bring them a little closer together? It takes forever to build Labs and setup environments, and with automation I can do this in mere minutes compared to the hours it use to take (we are talking fresh builds, clean environments). I plan on sharing more about more of my VMware and Ansible automation integrations down the chain (like Horizon labs that can be built from scratch and ready to test in 30 minutes or less). But I wanted to start out with something that I get a lot of questions about:is it possible to automate iApp Deployments? Specifically the VMware Horizon iApp? The answer is YOU CAN NOW! grant you this like all automation is a work in progress. My suggestion is if you have a use case you want to build using what I have started with I encourage it!! TAKE, FORK and Expand!!!! The Code: All of the code I am using is completely accessible via the F5 DevCentral Git Repository and feel free to use it! What does it do? Well, if you are an F5 Guru then you might think it looks similar to how our AS3 code works, if you aren't a Guru its basically taking one set of variables and sending off a single command to the F5 to build the Application (I tell it the things that make it work, and how I want it deployed and it does all the work for me). Keep in mind this isn't using F5 AS3 code, it just mimics the same methods bytaking a JSON declaration of how I want things to be and the F5 does all of the imperative commands for me. --- - name: Build JSON payload ansible.builtin.template: src=f5.horizon.{{deployment_type |lower }}.j2 dest=/tmp/f5.horizon.json - name: Deploy F5 Horizon iApp f5networks.f5_modules.bigip_iapp_service: #Using Collections if not use - bigip_iapp_service: name: "VMware-Horizon" template: "{{iapp_template_name}}" parameters: "{{ lookup('template', '/tmp/f5.horizon.json') }}" provider: server: "{{f5_ip}}" user: "{{f5_user}}" password: "{{f5_pass}}" validate_certs: no delegate_to: localhost All of this code can be found at - https://github.com/f5devcentral/f5-bd-horizon-iapp-deploy/ Deployments: Using the F5 iApp for Horizon provided many options of deployment but they were all categorized into 3 buckets F5 APM with VMware Horizon - Where the F5 acts as the Gateway for all VMware Horizon Connections (Proxying PCoIP/Blast) F5 LTM with VMware Horizon - Internal Connections to an environment from a LAN and being able to secure and load balance Connection Servers F5 LTM with VMware Unified Access Gateway - Using the F5 to load balance the VMware Unified Access Gateways (UAGs) and letting the UAGs proxy the connections. The deployments offer the ability to utilize pre-imported certificates, set the Virtual IP, add additional Connection Servers, Create the iRule for internal connections (origin header check) and much more. All of this is dependent on your deployment and the way you need it setup. The current code doesn't import in the iApp Template nor the certificates, this could be done with other code but currently is not part of this code. All three of these deployment models are considered and part of the code and how its deployed is based on the variables file "{{code_directory}}/vars/horizon_iapp_vars.yml" as shown below. Keep in mind this is using clear text (i.e. username/password for AD) for some variables you can add other ways of securing your passwords like an Ansible VAULT. #F5 Authentication f5_ip: 192.168.1.10 f5_user: admin f5_pass: "my_password" f5_admin_port: 443 #All Deployment Types deployment_type: "apm" #option can be APM, LTM or UAG #iApp Variables iapp_vip_address: "172.16.192.100" iapp_template_name: "f5.vmware_view.v1.5.9" #SSL Info iapp_ssl_cert: "/Common/Wildcard-2022" # If want to use F5 Default Cert for Testing use "/Common/default.crt" iapp_ssl_key: "/Common/Wildcard-2022" # If want to use F5 Default Cert for Testing use "/Common/default.key" iapp_ssl_chain: "/#do_not_use#" #Horizon Info iapp_horizon_fqdn: "horizon.mycorp.com" iapp_horizon_netbios: "My-Corp" iapp_horizon_domainname: "My-Corp.com" iapp_horizon_nat_addresss: "" #enter NAT address or leave empty for none # LTM Deployment Type iapp_irule_origin: - "/Common/Horizon-Origin-Header" # APM and LTM Deployment Types iapp_horizon_connection_servers: - { ip: "192.168.1.50", port: "443" } # to add Connection Servers just add additional line - { ip: "192.168.1.51", port: "443" } #APM Deployment Type iapp_active_directory_username: "my_ad_user" iapp_active_directory_password: "my_ad_password" iapp_active_directory_password_encrypted: "no" # This is still being validated but requires the encrypted password from the BIG-IP iapp_active_directory_servers: - { name: "ad_server_1.mycorp.com", ip: "192.168.1.20" } # to add Active Directory Servers just add additional lines - { name: "ad_server_2.mycorp.com", ip: "192.168.1.21" } # UAG Deployment Type iapp_horizon_uag_servers: - { ip: "192.168.199.50", port: "443" } # to add UAG Servers Just add additional lines - { ip: "192.168.199.51", port: "443" } How do the Variables integrate with the Templates? The templates are JSON based code which Ansible will inject the variables into them depending on the deployment method called. This makes it easier to templates to specific deployments because we don't hard code specific values that aren't necessary or are part of the default deployments. Advanced Deployments would require modification of the JSON code to apply specialized settings that aren't apart of the default. If you want to see more about the templates for each operation (APM/LTM/UAG) check out the JSON Code at the link below: https://github.com/f5devcentral/f5-bd-horizon-iapp-deploy/tree/main/roles/ansible-deploy-iapp/templates The Results: Within seconds I can deploy, configure and make changes to my deployments or even change my deployment type. Could I do this in the GUI? Absolutely but the point is to Automate ALL THE THINGS, and being able to integrate this with solutions like Lab in a box (built from scratch including the F5) saves massive amounts of time. Example of a VMware Horizon iApp Deployment with F5 APM done in ~12 Seconds [root@Elysium f5-bd-horizon-iapp-deploy]# time ansible-playbook horizon_iapp_deploy.yaml PLAY [localhost] ******************************************************************************************************************************************************************** TASK [bypass-variables : ansible.builtin.stat] ************************************************************************************************************************************** ok: [localhost] TASK [bypass-variables : ansible.builtin.include_vars] ****************************************************************************************************************************** ok: [localhost] TASK [create-irule : Create F5 iRule] *********************************************************************************************************************************************** skipping: [localhost] TASK [ansible-deploy-iapp : Build JSON payload] ************************************************************************************************************************************* ok: [localhost] TASK [ansible-deploy-iapp : Deploy F5 Horizon iApp] ********************************************************************************************************************************* changed: [localhost] PLAY RECAP ************************************************************************************************************************************************************************** localhost : ok=4 changed=1 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0 real 0m11.954s user 0m6.114s sys 0m0.542s Links: All of this code can be found at - https://github.com/f5devcentral/f5-bd-horizon-iapp-deploy/What is Virtual Desktop Infrastructure (VDI)
tl;dr - Virtual Desktop Infrastructure (VDI) hosts virtualized desktop environments for users in a centralized system. What is VDI? Imagine not having to carry around a laptop or be sitting in a cubicle to access your work desktop applications. Virtual desktop infrastructure (VDI) is appealing to many different constituencies because it combines the benefits of anywhere access with desktop support improvements. Employees typically use a wide range of mobile devices from laptops to tablets and from desktops to smartphones are being used. The diversity of these mobile devices and the sheer number of them in the workplace can overwhelm IT and strain your resources. Desktop Virtualization centralizes sets of desktops, usually in a data center or cloud environment, and then provide access to your employees whether they are in the office, at home or mobile. VDI deployments virtualize user desktops by delivering them to distinctive endpoint devices over the network from a central location. There are many reasons why organizations deploy VDI solutions – it’s easier for IT to manage, it can reduce capital expenditures, improve security and helps companies run a ‘greener’ business. Since users’ primary work tools are now located in a data center rather than on their own local machines, VDI can strain network resources, and the user experience can be negatively affected. Desktop virtualization is a bit more complex than server virtualization since it requires more network infrastructure, servers, server administrators, authentication systems, and storage. VDI’s effect on the network is significant; it may necessitate infrastructure changes to accommodate the large volume of client information that will be traversing the network. When a user’s desktop moves from a physical machine under the desk to the data center, the user experience becomes paramount; a poor VDI deployment will result in IT being flooded with “My desktop is too slow” calls. Why VDI? Mobile devices and bring your own computing are popular drivers for VDI deployments. It enables employees to work from anywhere and simplifies/unifies desktop management, especially updating operating systems and applications. It can lower costs, provide flexible remote access; improve security and compliance along with potentially offering organizations disaster recovery options. It also enables employee flexibility and reduced IT risk of employee owned devices. VDI allows employees work with a wide range of devices from laptops to tablets to smartphones. Employees can sign on from wherever they are, whenever they like and with whichever device they choose. Deploying virtual desktops can also increase IT efficiency and reduce IT workload since the desktops are centralized. It also benefits IT with greater access and compliance control, while at the same time, allowing employees the freedom to use their mobile device of choice. IT departments can remove obsolete versions of application software or perhaps enhance the security policy. Either way, the employee always has the most up to date desktop image. Things to Consider Desktop virtualization is no longer about the desktop, it’s about allowing employees desktop access from wherever they are. So things like availability, access, security, DR, authentication, storage, network latency and SSO are all areas to keep in mind when deploying a VDI solution. VDI Providers Some VDI solutions include VMware Horizon View, Citrix XenDesktop, and Microsoft RDS. Next Steps If you'd like to learn more or dig deeper into VDI, here are some additional resources: VDI the F5 Way Lightboard Lessons: Secure & Optimize VDI Citrix VDI iApp template VMware Horizon View iApp Also, here are some other articles from the #Basics Series.F5 Remote Desktop Gateway and MS Azure Multifactor Authentication
With Microsofts own Remote Desktop Gateway (2012r2) it is now possible to require 2-factor authentication for RDP clients. It is done by configuring the RD Gateway to use a NPS/Radius server which in turn uses MS Azure Multifactor Authentication server (MFA) to add the second factor. The configuration is described here: http://www.rdsgurus.com/step-by-step-using-windows-server-2012-r2-rd-gateway-with-azure-multifactor-authentication/ 2-factor authentication for RDP clients is a long-awaited feature, and I hoped and believed that it was possible to make this work also with the F5 RD Gateway. After hours and hours trying I have realized that its not straight forward, if possible at all. The challenge/problem seems to be that the only place to put in a NPS/Radius server in the F5 solution is in the access profile (VPE), but if you do the NPS/Radius responds with access_reject (unknown username or password). I suspect this is because the access profile doesn't really participate in the NTLM authentication (challenge/response), that part is handled before the access profile - in the vdi profile. So the access profile doesn't have any valid "password" to send to the NPS/Radius server. I guess this might have worked if Radius was an option in the vdi profile, but the only option there is a NTLM Auth Configuration (Big IP Machine Account in a Windows domain). My questions are: Has anyone had better luck than me setting up F5 RD Gateway with Azure MFA? Is it possible, via tmsh maybe, to make a vdi profile use Radius instead of a NTLM Auth Configuration?VDI Gateway Federation with BIG-IP
Today let’s look at how F5 BIGIP APM can consolidate, secure and federate all the core VDI gateways technology. For instance, if an organization decides move from one VDI technology to another or if you’re consolidating VDI technologies, BIG-IP can help. On the BIG-IP we’ve set up three VDI environments. Microsoft RDS/RDP with a broker authentication server, VMware Horizon and Citrix XenApp. With only a corporate account, a user can authenticate to all of them as needed and access all available desktop content. In this example, we connect to the BIG-IP APM. This is the default view. And here we’ve put some advanced security fields like OTP or multifactor authentication for instance. So here we’d use our username and password and for additional security we'll choose a secondary grid. By default, a grid is not generally available from any of the VDI vendors. When we select grid, BIG-IP APM will present a grid for a PIN entry. This is provided through a partnership with Gemalto. BIG-IP is connecting to Gemalto servers to present the grid to the user. We then enter our confidential PIN. Upon auth, we’re presented with our BIG-IP APM Webtop and BIG-IP did the necessary single sign on for all the VDI technologies and environments assigned to us. With a single, multifactor authentication we’re able to gain access to our federated BIG-IP Webtop and select the specific VDI resource we need. From an administrative view, here is the full Visual Policy Editor (VPE) for the overall solution. This also shows where the OTP/Grid is if you follow the Host FQDN path. And here are the specific inspections and criteria for the VDI scenario. You can see a path for each VDI vendor along with specific inspections and actions depending on the situation. Special thanks to F5 Sr. Security SE Matthieu Dierick for the explanation and you can watch the demo video. psChange Webtop Remote Desktop Icon
I have an access policy for VMware VDI and I can't seem to change the icons for my webtop/remote desktop links. The default icon is "terminal_service.png" located in /var/sam/www/webtop/public/images/full_wt I have changed this to an icon with the same dimensions (32px) in Access Policy>Customization>Basic>Remote Desktop and General>Branding>Remote Desktops but still the old icon is dispayed. Any ideas?Lightboard Lessons: Secure & Optimize VDI
Virtualization continues to impact the enterprise and how IT delivers services to meet business needs. Desktop Virtualization (VDI) offers employees anywhere, anytime, flexible access to their desktops whether they are at home, on the road, in the office or on a mobile device. In this edition of Lightboard Lessons, I show how BIG-IP can secure, optimize and consolidate your VMware Horizon View environment, providing a secure front end access layer for VMware’s VDI infrastructure. ps Related: Simplify VMware View Deployments
