Zone rules

  • Rules based on Active Directory Site allow you to create zones based on the Active Directory site from which users can start a Workspace Control session. This can be useful for sites with multiple Active Directory sites, divided by different domain controllers.
  • Rules based on Active Directory Group membership allow you to set access on items, based on computer group membership. This rule supports Active Directory groups.
  • Rules based on Active Directory OU membership allow you to set access on items, based on computer OU membership. When you select Inheritance, the rule also applies if a computer is a member of a child-OU.
  • Rules based on Active Directory Computer property allow you to set access on items, based on computer property. For example, you can assign access to an application based on the Computer's name as stored in Active Directory. For this Zone rule, wildcards can be used in the Value field.
  • Rules based on Active Directory User property are useful to create Zones for applications and/or settings that should only be available in sessions that match the value of the specified user property. For example, when an application should only be available to users in a specific company department, you can create a Zone rule based on the user property "department" and a value that specifies this company department.
  • Rules based on Computer Hardware are useful for applications that need specific minimum system requirements (for example, AutoCAD).
    • Rules based on Number of processors and Processor architecture (under Computer > Hardware) are also supported for Linux and Apple Mac OS X Agents.
    • Rules based on Processor architecture are useful for applications that need specific processor type (x86/x64).
  • Rules based on IP address, IP address range or Computer Name (under Computer, Network and Remote Desktop) are useful to link the Zone to a range of IP addresses or to a specific server, for example when configuring a printer server. When adding a Rule based on the Computer name for a Zone, the Computer (FQDN) can be used to apply the Rule to one or several Zones.
  • On the Rules tab of a zone based on Computer name, you can manually add the relevant computer names.
    Specifically for this type of zone, computer names can also be added to an existing zone using the command line. This can be used, for example, for scripting. The Administrator who runs this command must have access to the Console and to Zones.
  • Rules based on Operating system (Bit) version (under Computer and Configuration) are useful for applications that need a specific (bit) version of a Microsoft Windows OS or one of the following Linux and Apple Mac OS X versions (64-bit only):
    • CentOS Linux 5.11, 7.2.1511, 7.1.1503, 7.0.1406
    • RHEL 5.11, 7.2-7.0, 6.8-6.6
    • Apple Mac OS X 10.8-10.12.
  • Rules based on Vendor ID, Product ID or Serial number of USB storage devices (under Computer and Configuration > Hardware token) allow you to create advanced scenarios in which, for example, an application is only available or a laptop can only be accessed if a specific USB storage device is present. For examples of how to use this rule, see Example: Use a USB device for authentication purposes.
  • Rules based on Environment variable (under Configuration) allow you to set access on items, based on the value of a specific environment variable. This rule applies to existing environment variables only; not to environment variables that are set by the Workspace Composer when the user starts a session.
  • Rules based on File version (under Configuration > Files and folders) are useful if the version of a specific file should be the reason why a setting or application should be available or unavailable. For example, access to a database can be made to depend on the version of the database client; or the availability of an application can be made to depend on the version of a DLL file. In this way, you can hide an application from a user if the application cannot function properly due to the absence of a required version of a specific file. This saves the user from opening the application and then being confronted with error messages and other problems.
  • Rules based on File or folder exists (under Configuration > Files and folders) are useful if the existence of a specific file, folder or drive at the start of a session should be the reason why an action should be carried out or not. For example, you may want to perform a folder synchronization action with a network drive. This action is only useful if this drive mapping exists. The Zone rule File or folder exists can be used to check this.
  • Rules based on Federal Information Processing Standard (FIPS)compliancy (under Configuration) allow you to set access to resources based on a FIPS-compliant Windows Operating System. The rule evaluates whether the Windows GPO for FIPS has been set on the Agent.
  • Rules based on Operating system (under Configuration) are also supported for the following Linux and Apple Mac OS X versions (64-bit only):
    • CentOS Linux 5.11, 7.2.1511, 7.1.1503, 7.0.1406
    • RHEL 5.11, 7.2-7.0, 6.8-6.6
    • Apple Mac OS X 10.8-10.12.
  • Rules based on Registry setting (under Configuration) offer a huge range of possibilities, because much information is stored in the Registry. Each piece of information in the Registry can serve to determine the user's workspace, from printers to environment variables to applications to Data Sources. For example, the availability of Word 2013 can be made to depend on a Zone that checks for the Registry key HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Word; and the availability of Word 2010 can depend on the absence of this key. Similarly, different language versions of an application can be made available to users depending on their Active Directory site, which is stored in the Registry. Or access to the plotter printer can be granted only to users who use an AutoCAD application, as information about this is also stored in the Registry.
    • With the option Registry redirection selected, a 64-bit Operating System will redirect registry values specified for HKEY_LOCAL_MACHINE\SOFTWARE to their corresponding locations under the Wow6432Node. Please take the following into consideration when selecting this option:
      • In the Workspace Control Console, when browsing the registry to configure a Zone rule, the Wow6432Node will NOT be visible.
      • In a user session, applying a Zone will be based on the redirected location under the Wow6432Node.
    • With the option Registry redirection not selected, no redirection will be done and the following should be taken into consideration:
      • In the Workspace Control Console, when browsing the registry to configure a Zone rule, the Wow6432Node will be visible on 64-bit Operating Systems.
        Please note that 32-bit and 64-bit applications store information in different locations in the Registry. Therefore, separate rules may need to be configured for HKEY_LOCAL_MACHINE\SOFTWARE and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node.
      • In a user session, applying a Zone will be based on the original location in the registry.
        Zone rules containing registry values in the Wow6432Node will not be applied on 32-bit Operating Systems that do not have a Wow6432Node.
  • Rules based on Computer name, IP address, and IP address range (under Network) are also supported for Linux and Apple Mac OS X Agents.
  • Rules based on Remote host/URL (under Network) allow you to verify whether a specific IP address or URL is reachable to define an Access Control mechanism. This may be useful, for instance if a specific URL is only available from within the company network. Setting Access Control on an application to a Zone based on Remote host/URL prevents the application to be started from another location.
  • Rules based on Connected network (SSID), allow you to configure features (e.g. printers) that are available if a session is running on a device connected to a specific wireless network.
    • Rules based on the Security option Must connect through a trusted access point apply if the Agent's connection to a wireless network with the specified SSID uses a trusted access point. This makes it possible to disregard connections to other wireless networks with the same SSID, because they will not be accessible through your trusted access points.
      Please note, an access point is trusted if an enabled Nearest access point (BSSID) zone rule exists for it in your Workspace Control Console. Please be sure to define a full set of relevant access points.
    • Rules based on the Security option May connect through any access point apply if the Agent is connected to any wireless network with the specified SSID. This may or may not be your organization's wireless network, because wireless network SSIDs are not globally unique.
      This option may be sufficient if you have not defined a full set of trusted access points, and/or if security is less important.
  • Rules based on Nearest access point (BSSID), allow you to configure features to be available if a session detects that a specific access point is the nearest, based on it having the greatest signal strength of all detected access points.
    Please note that each access point for which a zone rule is specified will become a trusted access point for the purpose of zone rules based on wireless networks.
    • Rules based on the Signal detection option Limit to trusted access points will only evaluate trusted access points when determining which detected access point has the greatest signal strength.
      Please note, an access point is trusted if an enabled Nearest access point (BSSID) zone rule exists for it in your Workspace Control Console. Please be sure to define a full set of relevant access points.
    • Rules based on the Signal detection option Do not limit to trusted access points will evaluate all detected access points from networks with the specified SSID when determining which detected access point is the nearest. Detected access points may include mobile access points to other networks with the same SSID, because wireless network SSIDs are not globally unique.
      This option may be sufficient if you have not defined a full set of trusted access points, and/or if security is less important.
  • Rules based on Client type (Citrix Receiver only) (under Remote Desktop) allow you to create zones based on the client type detected through the Citrix Receiver on Citrix XenApp and Citrix XenDesktop. This leverages the support that Citrix Receiver provides for different devices in order to distinguish the various operating systems.
  • Rules based on Session type (under Remote Desktop) allow you, for instance to easily distinguish various desktop types. By specifying a session type, protocol and/or platform, access to a Zone may be set accordingly. A zone specifically for XenDesktop machines, for instance, would comply to: Session type: Remote Desktop; Protocol: Citrix ICA; Platform: Desktop. Other supported protocols are: Microsoft RDP, VMware PCoIP, VMware Blast, and VMware Blast Extreme.
  • Rules based on Terminal Server (TS) listener name (under Remote Desktop) allow you to create Zones that can differentiate between network connections from inside and outside the company network. This is useful for applications that should be highly secured, such as financial applications.
  • Rules based on the presence (or absence) of a VDX/Workspace Extender (under Remote Desktop) are useful to create Zones for applications that should only be available when there is (or is no) active VDX or Workspace Extender Client. These rules also apply to the RES Subscriber for VDX Agent and RES Subscriber for VDX Client.
  • It is also possible to add a rule based on a computer name to an existing Zone, using a command line. In the Workspace Control Console this would be done at User Context > Locations and Devices, New/Edit Zone and then selecting the Rules tab and adding a Computer Name. This option is also available in combination with the command line, which can be used, for example, for scripting.
  • When adding rules based on the value of a specific Computer property in Active Directory, please note that the following symbols will give unexpected results when they are used both in entries in Active Directory and as wildcards in the Value field in Workspace Control:
    • asterisk (*)
    • square brackets ([ ])
    • semicolon (;)
  • If an access point is configured to hide its SSID, Workspace Control will detect it as an empty SSID (i.e. empty string). If there are multiple access points with a hidden SSID, Workspace Control is not able to distinguish between the networks they belong to. In this case, a rule for the nearest access point, specified for an access point with a hidden SSID, will check the nearest access point of ALL access points that hide their SSID (even if they belong to different networks).
  • The use of environment variables is not supported for SSID and BSSID names.
  • Due to privacy constraints, detected wireless networks and access points are not logged in the Workspace Control Console. However, during a user session they are shown to the end user on the Diagnostics tab of the Workspace Preferences tool, so end users can provide their administrator with this information upon request.