Citrix XenApp 5 Feature Pack 2 for Windows Server 2003 has a very cool feature called Secure Clipboard Control. The technical folks may know this feature as "Read-Only Client Drive Mapping and Clipboard", but the end results are the same: it further mitigates risks of data leakage.

Granting remote users CDM access is great because they can open local files with server published apps. But they also have the ability to save server documents locally thereby increasing the probability that confidential data leaks out beyond the enterprise. Some customers have tried to tackle this problem by disabling CDM and clipboard altogether, but that does not offer users flexibility - what if administrators want to only let users save documents back on the server? This is where the new Secure Clipboard Control setting can help. It is a really simple feature for administrators to configure, yet provides an added level of flexibility (users can save documents to the server, but cannot save documents to the local device) administrators didn't have before.

To enable the feature in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cdm\Parameters, create a DWORD value with value name ReadOnlyMappedDrive and value data 1.

To enable one way clipboard In registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\Virtual Clipboard, create a DWORD value with value name ReadOnly and value data 1.

After rebooting the server all users that connect will only be able to read documents from their mapped drives and will only be able to copy and paste text into a published application. Data that is copied into the published application clipboard (via CTRL-C) will not show up in the client's clipboard paste buffer. Whenever the user tries to save a file to a mapped drive they will get an error saying they don't have permission to write to the location because XenApp has the drive open in read-only mode.

For now both settings are server wide so remote users will have to be confined to specific machines where the settings are enabled. You can find out more about this feature at CTX123002 and in Citrix eDocs here.

Learn more about Citrix XenApp 5 Feature Pack 2

• Official Press Release - http://citrix.com/English/NE/news/news.asp?newsID=1857726
• XenApp 5 Feature Pack 2 release Web Site - http://citrix.com/xenapp/featurepack2
• XenApp 5 Feature Pack 2 Executive Video - http://citrix.com/xenapp/fp2/video
• XenApp 5 Feature Pack 2 Release Webinar - http://citrix.com/xenapp/fp2/techtalk
• XenApp feature matrix by platform, version and edition - http://citrix.com/xenapp/comparativematrix
• XenApp Expert Series videos for this release - http://citrix.com/xenapp/fp2/expertseries
• XenApp 5 Feature Pack 2 Blogs- http://community.citrix.com/blogs/tag/xa5fp2
• Download XenApp technology previews - http://citrix.com/xenapp/techpreviews
• XenApp Product Page - http://citrix.com/xenapp/

Follow XenApp on | | |

Mac users out there have long been asking for and waiting for a rich and secure remote access experience with Access Gateway solutions. Now the wait is over. Mac users can now download the Access Gateway plug-in for Mac from MyCitrix.

Access Gateway team has made available Mac OX X plug-in for Access Gateway 4.6 Standard Edition and Access Gateway 9.1 Enterprise Edition:

- The user experience of the plug-in conforms to the native Mac experience, providing rich user experience.

- Mac users can securely connect to their remote applications, leveraging pre- and post-authentication endpoint scans to confirm to their corporate security policies. For stronger security, when the remote Mac user logs off,  the plug-in also destroys any session data (cache, cookies, etc) on the client.

- With globalization features, the plug-in brings this new experience to English, French, German, Spanish and Japanese users.

If you are a Mac user, I encourage you to go to the downloads section on MyCitrix and select Citrix Access Gateway from the drop-down menu of 'Search Downloads by Product", then find "Access Gateway Plug-in for Mac OS X, Version 1.0.2.23" under the Clients section.

If you are using this new plug-in, please share your experience with me and what you would like to see next.

Sai

Ever got frustrated with how long it takes to email a large report or presentation after incorporating your manager's feedback? Or found yourself in a plane wishing the email downloaded faster when the flight attendant asks you to turn off your 3G-equipped laptop? Or wished for a solution that could deliver email 50 times faster?

Did you know our WAN optimization solution, Citrix Branch Repeater, delivers superior user experience and application performance not only for branch office users but also for remote and teleworkers?

No one feels the need for speed more than a remote user or a teleworker with a low-bandwidth or a high- latency network connection. These users typically use an SSL VPN, such as Citrix Access Gateway, to connect to their corporate network and access email, intranet portals, other applications and data. When your IT augments secure remote access (Access Gateway) infrastructure with Branch Repeater, you can benefit from both secure and accelerated remote access.

Well, now we have two reports that demonstrate ways to use Branch Repeater to augment your Access Gateway infrastructure and the resulting benefits of accelerating secure remote access.

You can download the Turbocharge Access Gateway Performance Report - CTX121034 from the Citrix Knowledge Center. The report explores the benefits of using Access Gateway and Repeater plug-ins for Citrix Receiver together:
• 50x faster Microsoft Outlook and Exchange (MAPI) workflows
• 50x faster Microsoft SharePoint (HTTP) workflows
• 30x faster Windows File Shares (CIFS) workflows

I think you will want to try out the benefits of turbocharged remote access. Check out the Turbocharge Access Gateway Deployment Guide and Reference Architecture - CTX121035 if you want to conduct a POC (proof of concept) or a demo to convince your IT or other decision makers. You will be your end-users hero for providing them with an accelerated yet secure remote access.

HTTP Callouts

New in NetScaler 9.0 is the ability to perform a callout using HTTP to an external server. An HTTP Callout is a means to process incoming packets on the NetScaler using an external service that can be a virtual server on the NetScaler itself, a back-end server, or an third party service.

Traditionally, the NetScaler used to verify these packets internally using in-built policies but with specialized services being available for validation, they can be integrated with the NetScaler using this feature.

An HTTP callout will consist of a NetScaler policy expression that can send a simple HTTP request to an external service, wait for the response and then parse the response to produce a simple result. The result will then be used like any other policy expression evaluation result.

The HTTP callout expression:

SYS.HTTP_CALLOUT(<name of HTTP Callout>)

To define the HTTP callout:

set policy httpCallout <name>
	[-IPAddress < ip_addr|ipv6_addr>]
	[-port <port>]
      	[-vServer <string>]
	[-returnType <returnType>]
	[-httpMethod ( GET | POST )]
	[-hostExpr <string>]
	[-urlStemExpr <string>]
	[-headers <name(value)> ...]
	[-parameters <name(value)> ...]
	[-fullReqExpr <string>]
	[-resultExpr <string>]

Where:

-returnType must be one of TEXT, NUM or BOOL.

-IPAddress IP address of the server to which callout is made

-port Port of the server to which callout is made

-vserver must be one of the vservers added using the "add lb/cs/cr vserver" command. The service type of the vserver must be HTTP.

-httpMethod could be GET or POST.

-hostExpr Complex PI string expression for value of the Host header.

-urlStemExpr Complex PI string expression for generating the URL stem.

-headers Every header name must have a corresponding value. These headers will be inserted in the request. Header name is string. Header values are Complex PI Expressions.

-parameters Every parameter name must have a corresponding value. These parameter names are put in the URL query if the request has a GET method or they are put in the body if the request has a POST method. One must not rely on the order in which the parameters are inserted. Parameter name is a string. The parameter values can be computed using Complex PI String expressions. The parameter values will be URL encoded.

-fullReqExpr A complex PI String expressions computes the entire request. It is the user's responsibility to provide a well formed and sane HTTP request. The system will not do any sanity checking. If full request is specified then none of the other arguments can be specified.

HTTP callouts are available with HTTP or TCP Content Switching, Responder and Rewrite functionality.

The basic communication flow for HTTP callout is:

1. User sends request
2. Policy sends HTTP request to an external service
3. Result used like any other policy evaluation result
4. Available for multiple features

HTTP Callout Deployment Scenarios

The examples in this section illustrate how to use HTTP callouts to perform various tasks. In all cases, the NetScaler performs a callout to an external server where a callout agent is configured to respond to the request from the NetScaler based on the data that is present on the external server.

This section describes how to configure HTTP callouts in the following scenarios:

1. Filter clients based on an IP blacklist.
2. Fetch and update content on the fly using Edge Side Includes (ESI) markup language.
3. Authenticate users and control access to resources.
4. Filter Outlook Web Access (OWA) spam.

Filtering clients based on an IP blacklist

HTTP callouts can be used to block requests from clients that are blacklisted by the administrator. This list of clients can either be a publicly known blacklist or one that is maintained specifically by the administrator or a combination of both.

The source IP address of the incoming client request is checked against the external pre-configured blacklist and based on whether the IP address has been blacklisted or not, the transaction is either blocked by the NetScaler or the NetScaler continues to process the transaction normally.

The HTTP callout feature facilitates this by allowing the NetScaler to communicate with the external server that maintains a database of such blacklisted IP addresses.

The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.

ESI support for fetching and updating content dynamically

Edge Side Includes (ESI) is a markup language for edge-level dynamic Web content assembly. It helps in accelerating dynamic Web-based applications by defining a simple markup language to describe cacheable and non-cacheable Web page components that can be aggregated, assembled, and delivered at the network edge.

Using HTTP callouts on the NetScaler, you can read through the ESI constructs and aggregate or assemble content dynamically.

The following outlines the requirements to implement this configuration:
1. Enable Rewrite on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Rewrite action to replace the ESI content with the callout response body.
4. Bind the Rewrite action to a Rewrite policy.
5. Bind the Rewrite policy globally on the NetScaler.

Access Control and Authentication

In high security environments, it may be mandatory to externally authenticate a user before a resource is accessed by clients. On the NetScaler, you can use HTTP callouts to externally authenticate a user based on supplied credentials. There are different ways that authentication credentials might be supplied; the client could be sending the user name and password in HTTP headers in the request, or, the credentials could be fetched from the URL or the HTTP body.

The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.

OWA-based spam filtering

Spam filtering is the ability to dynamically block emails that are not from a known or trusted source or has inappropriate content. Spam filtering requires business logic that indicates a particular kind of message is a spam.

Using HTTP callouts, you can take out any portion of the incoming message and check with the configured external callout server that has the rules to detect if the message is a legitimate email or spam. In case of a spam email, the sender will not be notified that the email is marked as spam because it will only alert spammers to modify their messages.

The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.

Read about the Citrix Application Switch with Version 9.0 here.

Try the Citrix Application Switch with Version 9.0 here.

Tap into the power of AppExpert!