How to Create USB Policy Rules

Default Policy

The following are the default policy configuration:

DENY: class=09 # Hub devicesDENY: class=03 subclass=01 # HID Boot device (keyboards and mice)DENY: class=0b # SmartcardDENY: class=e0 # Wireless ControllersDENY: class=02 # Communications and CDC ControlDENY: class=0a # CDC DataALLOW: # Ultimate fallback: allow everything else

How It Works

When a user plugs in a simple USB device, the host device checks it against each policy rule consecutively until a match is found. The first match for any device is considered definitive. If the first match is an Allow rule, the device is redirected to the virtual desktop. If the first match is a Deny rule, the device is available only to the local desktop (that is its not redirected). If no match is found, default rules are used.

User-added image
When a user plugs in a composite USB device (a device with multiple functions (interfaces) for example audio headset with speaker, mic and HID button) the host device checks for all functions (interfaces) against each policy rule. If the first match for any function(interface) is a Deny rule, the rule is considered definitive for the composite device and device is denied. If the first match for a function (interface) is an Allow rule, the host device continues to match the rules against next function (interface). The composite device is allowed if no function (interface) is denied by a policy rule. If definitive match for composite device is a Deny Rule, the device is available only to the local desktop otherwise the device is remoted to the virtual desktop. If no match is found, default rules are used.

User-added image

Creating New USB Policy Rules

Refer to the Citrix Receiver for Windows documentation for information on Updating the List of USB Devices Available for Remoting.

Tip: When creating new policy rules, refer to the USB Class Codes , available from the USB web site.

Policy rules take the format {Allow:|Deny:} followed by a set of tag=value expressions separated by whitespace. The following tags are supported:

Tag Description
VID Vendor ID from the device descriptor
PID Product ID from the device descriptor
REL Release ID from the device descriptor
Class Class from either the device descriptor or an interface descriptor
SubClass Subclass from either the device descriptor or an interface descriptor
Prot Protocol from either the device descriptor or an interface descriptor

When creating new policy rules, consider the following:

  • Rules are case-insensitive.

  • Rules might have an optional comment at the end, introduced by #. A delimiter is not required and the comment is ignored for matching purposes.

  • Blank and pure comment lines are ignored.

  • Whitespace is used as a separator, but cannot appear in the middle of a number or identifier, for example, Deny: Class = 08 SubClass=05 is a valid rule; Deny: Class=0 Sub Class=05 is not.

  • Tags must use the matching operator =. For example, VID=1230.

  • Each rule must start on a new line or form part of a semicolon separated list.

Important! If you are using the Administrative (ADM) template, you must create rules on a single line, as a semicolon-separated list.

For example a set of administrator-defined USB policy rules:

Allow: VID=1230 PID=0007 # ANOther Industries, ANOther Flash Drive

Deny: Class=08 SubClass=05 # Mass Storage

Related:

  • No Related Posts

XenApp 7.15- after scheduled reboot VDA remains shutdown

This usually happens when the Server VDAs does not shutdown gracefully in the stipulated amount of time.

When a reboot action is initiated via Reboot Schedule, Delivery Controller sends a shutdown signal to the VDA but before that, it waits for the all user sessions to get logged off and services to shutdown.

If all the user sessions on the VDA are not logged off within 10 minutes and machine is not shutdown gracefully, then the Delivery Controller sends a force shutdown of the VDA and machine does not power on.

Related:

  • No Related Posts

How to Configure NetScaler Gateway Preauthentication EPA Scan for Domain Check

NetScaler GUI

Complete the following steps to configure NetScaler Gateway preauthentication EPA scan for domain check:

  1. Log on to NetScaler Gateway and navigate to NetScaler Gateway > Policies > Preauthentication > Preauthentication Profiles (tab) > Add. Assign a Name for the new profile and choose Create.

    User-added image

  2. Switch to the Policies tab and choose Add to add a new policy.

    Provide a Name and under Request Action choose the previously created domain-scan-profile.

    User-added image

  3. A pop-up window will appear. Use the expression editor to select Windows to scan Windows based systems, then choose Domain Check.

    User-added image

  4. Select + to the right of the Domain Check option. In this case the check will be to see if ‘example.com’ is the domain suffix. Enter the Domain suffix and comment as shown in the following screen shot and click OK.

  5. Now select Create to create the new policy.

  6. To enable the policy it will now need to be bound to the virtual server. This is done by editing the virtual server itself.

    Navigate to the NetScaler Gateway > Virtual Servers section and select the virtual server and then choose the Edit option. Allow the HTML page to load and towards the bottom of the resulting web page there will be section called Policies.

  7. Choose the + symbol in the top right of the Policies section.

  8. A selection box will appear. Change the Policy type under Choose Policy to Preauthentication and choose Continue.

    User-added image

  9. In the Choose Type section, select the policy created for domain scan under Select Policy and then click Bind button.

    User-added image

  10. Click OK and it should show the other policies as well as the new preauthentication policy bound to the virtual server.

  11. Once the scan has been enabled, test it with a suitable client that has domain membership matching the setting in the policy. Then repeat with a non-confirming client to verify the functionality of the new policy.

NetScaler CLI

To enable preauthentication policy for domain check, run the following command from CLI:

add aaa preauthenticationpolicy <policy name> “CLIENT.SYSTEM(DOMAIN_SUFFIX_anyof_<domain>[COMMENT: Domain check]) EXISTS” <Action Name>

Related:

  • No Related Posts

“Unable to connect to the server. Contact your system administrator with the following error” When Launching Desktop

Adaptive transport is a new data transport mechanism for XenApp and XenDesktop and available in Citrix policies.

When set to Preferred, data transport over EDT is used as primary and fallback to TCP. By default, adaptive transport is disabled (Off) and TCP is always used. For testing purposes, you can set Diagnostic mode, in which case only EDT is used, and fallback to TCP is disabled.

First Test with policy set to Preferred. [No UDP Ports are opened]

  1. Launch the Desktop.
  2. From command prompt browse to “C:Program Files (x86)CitrixSystem32”
  3. Run ‘CtxSession’


You can see that TCP is being used with CGP (Session Reliability) and Session Reliability encapsulates the ICA protocol.

User-added image

Run CtxSession /v for a verbose output. Here you can see the port 2598 being used on the VDA.

User-added image

Now set the policy to ‘Diagnostic mode’.

Ensure UDP 1494 and 2598 ports open on the VDA I connect back to the Citrix desktop, run CtxSession /v and receive confirmation that we are now using UDP 2598. This means that HDX Enlightened Data Transport is being used with Session Reliability. You can also check Director and note the protocol will be set as UDP.

User-added image

Related:

  • No Related Posts

Excessive Syn Drops on Citrix ADC in Dynamic Service Scenario

The issue was resolved by shutting down the client sending this very high volume of syn packets. Further, analysis was done into why ADC was dropping the packets.

Given that this is RNAT with “tcpproxy enabled” (USEPROXYPORT) scenario, ADC probes the server when SYN for a given server IP is received for the first time..(i.e. this is dynamically learnt server/service scenario) and later NS caches that learnt info for some time and later times out if there is no activity. There is a rate limiting that it applied to “how many such dynamic server probes that can be sent in a given time”, this is controlled by the setting “System >> Change TCP Parameters >> Maximum Server probes in 10ms”, The default value is 7. (This is a Global limit not per client / server) and maximum is 65535 In this case as you can see in the counters, when the issue starts, we see TCP_TOT_SYN go up to 38059 per second = ~380 per 10ms which is far higher than the 7 per 10 ms default limit. So, the excess SYN requests were dropped – this is confirmed by the fact that (tcp_err_syn_drop= tcp_tot_probe_limit_exceeded) therefore all the drops were due to this rate limit.

Related:

  • No Related Posts