SmartControl and SmartAccess

Both SmartAccess and SmartControl are similar in practice. One is implemented at the Delivery Controller level with the use of Citrix policies (SmartAccess) and the other is implemented at the NetScaler Gateway level (SmartControl). SmartControl was introduced in NetScaler v11, and is a Platinum feature.

SmartAccess and SmartControl can be used to block or allow certain components such as printer access, audio redirection, client device drive redirection and so on. SmartAccess policies can be applied based on the connecting user’s IP address, Delivery Group, Client Name, Delivery Group Type and many more conditions that can be found within Citrix Studio policies.

SmartAccess policies can be applied to internal connections through the use of Citrix policies that are enforced by DDCs when connecting to a resource. You can also use the “Access Control” object when assigning SmartAccess policies. Using this object allows you to enforce the policy to all connections coming through the NetScaler Gateway or certain vServers/Session Policies.

On the other hand, SmartControl is implemented directly on the NetScaler so that restrictions can be enforced at the network layer, before the user even gets to connect to a backend resource. SmartControl is implemented by using ICA policies and attaching them a NetScaler Gateway vServer, or globally.

Take for example a user has access to redirected printers when connecting to XenApp/XenDesktop resources within the corporate LAN however once they connect remotely through NetScaler Gateway printer redirection is blocked. This can be performed both by SmartAccess and SmartControl. A Citrix SmartAccess policy may be locally defined on DDCs that allows printer redirection from local client device to VDA. NetScaler may have SmartControl implemented via ICA Policy which restricts client printer redirection for anyone coming through the NetScaler.

Another example is client drive redirection is allowed when users route through NetScaler Gateway only if the machine has an approved anti-virus installed. EPA scans run before authentication takes place using pre-authentication policies which confirm if the machine has an appropriate anti-virus. If the machine does not, an ICA policy will be applied to the session which blocks client drive redirection.

What can be blocked with SmartControl on the NetScaler?

Connect Client LPT Ports – Not normally used these days however blocks LPT port redirection used for printers.

Client Audio Redirection – Redirect audio from VDA to client device.

Local Remote Data Sharing – Allows or disallows data sharing using Receiver HTML5.

Client Clipboard Redirection – Redirects client clipboard contents to VDA.

Client COM Port Redirection – Redirect COM (serial) ports from client to VDA.

Client Drive Redirection – Redirect client drives from client to VDA.

Client Printer Redirection – Redirects client printers from client to VDA.

Multistream – Allow or disable multistream.

Client USB Drive Redirection – Redirect USB drives from client to desktop VDA only.

Picture 1 (need picture from newer version which included client drives)

Configure ICA policy for SmartControl

Firstly take a look at my local client machine. I have a printer installed named HP OfficeJet Pro which by default does redirect to my Citrix session as shown by the from DESKTOP001.

Here’s the Citrix default policy allowing client printer redirection.

To use SmartControl we have to disable ICA Only on the vServer (NetScaler Gateway) we are using. In other words, the NetScaler Gateway vServer needs to be in SmartAccess mode. This allows us to make use of ICA policies. Universal licenses are used here. You cannot bind an ICA Policy to a NetScaler Gateway vServer until it is operating in SmartAccess mode.

Whilst the NetScaler Gateway vServer is in SmartAccess mode, the Session Policy I am using is configured for ICA proxy only, no client choices.

The Session Profile also has a simple ns_true expression to match all incoming connections.

To create an ICA Policy, Action and Profile, navigate to NetScaler Gateway -> Policies -> ICA -> Add.

Specify a name for your policy then click on the + sign beneath Action.

Specify a name for the action and then click the + sign beneath ICA Access Profile.

Configure the ICA Access Profile to block printer direction by specifying Disabled. Click Create.

Click Create.

Click on Expression Editor.

Here I am using the expression that this ICA Policy will apply if the connecting client IP matches 192.168.0.45. Click Done.

Click Create.The policy is ready to be applied to a resource. Next navigate to NetScaler Gateway -> Vitual Servers and edit the NS Gateway vServer.

Click on the + symbol beside Policies.

Choose ICA under Choose Policy.

Click Continue.

Click +.

Select the BlockPrinters_Policy and click Select.

Click Bind.

Click Done.

Now when a user logs in from that IP address, printer redirection is blocked even though by default Citrix policy allows redirection SmartControl is enforcing the restriction.

And back on the NetScaler you can see the ICA Policy has taken a hit.

Next unbind the ICA Policy.

Click Unbind.

Click Yes.

Click Done.

To use the Access control object for policy assignment within Citrix Studio you need to run the below command: Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true.

Once done, within Citrix Studio, navigate to Policies and click Create Policy.

Specify printer redirection as Prohibited and click OK.

Click Assign next to Access Control.

Here we can specify the NetScaler Gateway vServer and Session Policy that we want these policy settings to apply to. If you have multiple NS Gateways and Session Policies this is a way to achieve granularity. If you want this policy to apply to all NetScaler Gateway connections specify * both under NetScaler Gateway farm name and Access Condition. If not, use the names that are given within NetScaler for your NetScaler Gateway and Session Policy.

 

Click Next.

Click Finish.

At this stage when a user logs on from the NetScaler Gateway printer redirection will be prohibited as a result of SmartAccess and the Access control object.

The next example uses preauthentication policies to determine if a client has an appropriate anti-virus installed. If so, printer redirection is allowed. If not, printer redirection is disabled.

Navigate to NetScaler Gateway -> Policies -> Preauthentication -> Preauthentication Profiles -> Add.

Specify a name such as Antivirus_No, with action ALLOW and the Default EPA Group as NotTrusted. This profile will be used for non trusted computers. Click Create.

Create another profile however this time for trusted devices with a group name such as Trusted. Click Create.

Below are the two created profiles.

Click on the Preauthentication Policies tab -> Add.

Specify a name for computers holding anti-virus, select the Antivirus_Yes action and create an expression that matches the anti-virus you want to be present on the machine. Click Create.

Create another policy only this time for uncompliant computers. I am using an ns_true expression so all computers that do not have the desired anti-virus installed will match this policy. Click Create.

And now we have two policies ready to go. One for compliant computers and another for non-compliant Windows computers.

Navigate back to NetScaler Gateway -> Policies -> ICA -> Access Profiles -> Add.

The first profile we are creating is for compliant PCs. I am allowing client printer, drive and USB drive redirection by specifying a value of Default. Click Create.The second profile is for non-compliant computers that will receive no redirection. Click Create.

Two new profiles ready to go.

Click on ICA Action -> Add.

Specify a name for compliant computers and choose the compliant ICA Access Profile. Click Create.

Do the same for the non-compliant machines and choose the non-compliant ICA Access Profile. Click Create.

Now two ICA Actions are ready.

Click on the ICA Policies tab and click Add.

Speficy a name for the compliant policy. Choose the compliant Action and within the expression type HTTP.REQ.USER.IS_MEMBER_OF(“Trusted”). If you remember, the Trusted group name was specified within the Preauthentication profile we created earlier for compliant users. This means when a machine connects with anti-virus installed, it is processed by the compliant pre-authentication policy, the user is assigned to the Trusted EPA Group which in turn uses the compliant ICA Policy which looks for members of the Trusted group. Understand? Click Create.

Create a policy for non-compliant machines, choosing the non-compliant Action and an expression which triggers the ICA Policy when members are a member of group NotTrusted. Click Create.

The two ICA Policies are ready to be assigned to our NS Gateway vServer.

Edit the NetScaler Gateway vServer, click to add a policy, choose ICA as the policy type and click Continue.

Click the + symbol beneath Select Policy.Select the compliant ICA Policy and click Select.

Click Bind.

Do the same for the non-compliant ICA Policy and then click Close.

Click to add another policy and specify Preauthentication as the policy type. Click Continue.

Click the + symbol beneath Select Policy.

Choose the compliant pre-authentication policy first. We want this policy to have a lower priority so that it is always processed first on compliant and non-compliant machines. Click Select.

Click Bind.

Do the same for the non-compliant preauthentication policy. Notice I have altered the priorities slightly however the compliant policy has a lower priority meaning it will be processed first. Non-compliant machines will fail this policy then move on to the non-compliant policy where it will succeed. Click Close.

Click Save.

Using a non-compliant machines, I logged on, and the non-compliant ICA Policy was processed as you can see by looking at the hit counter.

No printer redirection has taken place.

Logging on with a compliant machine that has corporate approved anti-virus installed results in the compliant ICA Policy being applied.

And sure enough the printer has been redirected.