...
Horizon 6.2.1checkOrigin introduced and enabled by defaultHorizon 7.3.2enableCORS introduced, disabled by default.Horizon 8.3 (2106)enableCORS default changed to enabled (2106 Release Notes)Horizon 2206 and 2111.1allowUnexpectedHost introduced, enabled by default.Horizon 2111.2, 2209.1, 2212.1 and 2303 2306 2309allowUnexpectedHost default changed to disabled. BalancedHost can accept a List Horizon 2111.2, 2209.1, 2212.1 and 2303 2306 2309: Cross-Origin Resource Sharing (CORS) is enabled by default. See Cross-Origin Resource Sharing.Security configuration setting balancedHost can now accept a list for those with more than one load balancer. The syntax is exactly the same as portalHost. (Release Notes ) Security configuration setting allowUnexpectedHost has changed from true to false. This means that connections using the name or IP address of a proxy, gateway or load balancer that is not defined in locked.properties will fail, even if checkOrigin and enableCORS are both set to false. Please see Error 421 while connecting to Horizon via HTML Web Console after an upgrade to 2306,2111.1 or Later (93915) for additional details.For a step-by-step walkthrough of configuring Locked.properties, please see Horizon Server: Troubleshooting Configuration Issues with Locked.properties(94578) This Article's purpose is to outline some common questions seen as a result of these changes.Potential Symptoms seen as a result of the change: HTML access is stuck in the "Waiting" screen due to the lack of configuration in "locked.properties" An alert appears on an HTML5 access attempt "Failed to connect to the Horizon Connection Server"
Common Questions: 1.What is the purpose of this change?Any URL the user clicks on needs to be known to the connection server the request reaches.If they click on badguy.com, and that redirects them to Horizon, we need to reject the request. That’s the purpose of this. This is a W3 standard we comply with, see the documentation on this. CORS allows additional granularity through policy.2. Is this not just Origin Checking? Origin Checking has been a default in Horizon since Horizon 7.6 and this impacted admin page access in the past, please see KB2144768. Default origins include the connection servers' localhost and external URL (the external URL defaults to the server FQDN but is typically changed to an FDQN of a VIP used for external access). These are not impacted by the change. Origin checking is enabled by default. When it is enabled, a request is accepted only without an Origin, or with an Origin equal to the address that the External URL specifies, to the balancedHost address, to any portalHost address, to any chromeExtension hash, to null, or to localhost. If Origin is not one of these possibilities, an "Unexpected Origin" error is logged and a status of 404 is returned. Reference Link 3. I'm aware of origin checking, what do I need to consider?This enhancement can impact an environment in terms of HTML5 access when load balancers are in the equation.Origin Header: The origin header is the value that will pass through for validation by the connection server and can be defined as the URL that the user clicks on.Example: User opens htttps:/loadbalancer/ and logs into Horizon, hitting enter to authenticate.This request will be rejected if this load balancer URL does not match the aforementioned defaults.4. I'm experiencing issues with html5 page access after an update to 2106 and worked fine with previous release , what are my options?Essentially a configuration or design change is potentially needed based on your individual circumstances. UAG has a feature to rewrite the origin header coming from the client to match the URL it is using to forward requests to the connection server. (documentation - Re-Write Origin Header). This feature is off by default but can help to reduce the list of entries or even obviate the need for locked.properties entirely.If the URL that your users connect with will need to be added to the known origins list for each connection server behind the load balancer which is contained within locked.properties 4. How do I edit locked.properties? 1. Create or edit the locked.properties file. This is located on each connection server in c:\program files\vmware\VMware View\Server\sslgateway\conf. 2. This file can be edited with a standard text editor, like Notepad. 3. Please validate the extension of the file to ensure it is saved as .properties. If saved as a .txt extension, the edited values will not be read. 4. Restart each server to ensure the values take effect.5. What values do I need to change in locked.properties? There are two keywords for extending the known origins list, balancedHost and portalHost.Note 1: You don’t set a URL on these, just the hostname.Note 2: Both are designed to extend the list of known origins.For a hypothetical load balancer, we need to add this entry to all connection servers behind it:balancedHost = loadbalandedviewurl.company.com There can only be one entry for balancedHost and only https is allowed.The purpose of balanced host is primarily for the load balancer between connection servers and internal clients. There is no limit on the amount of portal host entriesThe purpose of portalHost is primarily for alternative routes and names.For example, let’s say that there are more routes into the environment, through originalname.com and newname.net and internally through originalname.int or hostname.You’ll need to add portalHost entries for these:portalHost.1 = originalname.comportalHost.2 = newname.net portalHost.3 = originalname.intportalHost.4 = originalnameportalHost.5 = hostnameIf all of these are load balancers too, You can reduce complexity and stop using balancedHost and list all routes with portalHost entries.5. Are these failures tracked in logs?Yes, If a request comes in with an origin header that is not in the list of known origins, you will get the error in the debug log of the connection server with a line: "Unexpected origin”.Log file Location: C:\ProgramData\VMware\VDM\logsLog file name: debug-datetime.txtIt you note the time of the failed attempt or check the debug log that most closely matches the time of the reported test.Sample Log Line : 2021-09-24T22:05:34.737-07:00 ERROR (1B08-1A58) <SimpleDeamonThread> [h] (ajp:admin:Request190) Unexpected Origin: https://newname.net 2021-09-24T22:05:34.738-07:00 DEBUG (1B08-1A58) <SimpleDeamonThread> [v] (ajp:admin:Request190) Response 404 Not Found [close] It then tells you what the origin header looks like, and if this should be accepted you can add yet another portalHost entry, for instance, with the above example - newname.net needs to be added as a portalhost entry.