Who ate my Cookie?

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

In this article, I’m going to cover an interesting troubleshooting exercise undertaken by the Solution Engineering team while investigating a DataNow issue whereby the Windows Client would intermittently lose its connection to the server and prompt the user to re-enter their credentials.

To set the scene, AppSense DataNow is designed to be inherently scalable; providing mechanisms that allow clusters of servers to work together and provide a highly available service to a large number of clients. Customers scaling their deployment up to support large numbers of clients often supplement DataNow’s built-in clustering support with 3^rd party load balancers to allow client load to be evenly distributed.

When using a load balancer, a persistence method has to be configured to ensure that DataNow client sessions remain “sticky”, with all client communication for a single user session being handled by the same server. This is required so that the DataNow server handling a user’s request can verify that the user is authenticated by the presence of a session token, supplied by the client and cached by the appliance, in each request.

To implement this “session stickiness” it’s common to use a persistence type called “Cookie Insert”, allowing the load balancer to track which clients are talking to which servers by marking all correspondence from the server to the client with a special persistence cookie. When the client responds to this correspondence, it adds the same cookie into the outbound packet, thereby ensuring that the load balancer can determine which server to send this response to.

Upon configuring their Citrix NetScaler load balancer in this manner, one of our customers reported that, during testing on Windows 7 machines, their users were intermittently being prompted for DataNow login credentials.

Troubleshooting the Issue

We set to work troubleshooting this issue by first collecting a set of DataNow Windows client logs. These logs showed that the client was communicating with the server normally for a time, then suddenly the server would respond with a BAD SESSION message, indicating that the client’s communication had been sent to a server with no record of the client’s current session token. This immediately indicated that the load balancer’s persistence mechanism wasn’t working as expected.

Further analysis of these logs highlighted that the BAD SESSION response was always received following an upload attempt of a filename beginning with a dot.

We set about reproducing the behaviour in house in order to investigate further, using a load balancer configured for cookie persistence and a DataNow Windows client on Windows 7, as per the customer’s setup. We found that we could recreate the issue; attempting to upload a file with a leading dot in the name caused the client’s response to be sent to the wrong server in some cases, resulting in the BAD SESSION response and the client prompting for credentials.

We captured a network packet trace on our affected test client to investigate the behaviour further. This capture confirmed the following:

• The NetScaler load balancer was correctly adding the persistence cookie to the incoming packets. This can be seen in the following response to a login request (the NSC_ item being a Citrix NetScaler inserted persistence cookie):

• The upload of normal files (no leading dot in the name) resulted in the persistence cookie being added to the request. Note the presence of the same NSC_ cookie when uploading a file called “test.txt”:

• Inspecting the upload of a file containing a leading dot in the name shows that the persistence cookie is omitted. The file being uploaded in the following screenshot is “.test.txt”, note the absence of the NSC_ persistence cookie:

Further testing led us to establish this issue only affected Windows 7 clients, not Windows 8 or 8.1 clients.

The handling of the persistence cookie is done by Windows’ WinHTTP subsystem, which should read the values specified in Set-Cookie headers in the incoming packets and ensure that these cookies are added to any outgoing packets destined for the same remote address. Microsoft provides an article on this topic which explains the mechanism in greater detail:

Cookie Handling in WinHTTP

We approached Microsoft to demonstrate the behaviour and they’ve identified an issue in WinHTTP on Windows 7 which causes it. They have also confirmed that the issue is not present on XP, Vista, 8 or 8.1 and are currently investigating it further.

Working Around the Issue

Thankfully, the issue is a lot more straightforward to work around that it is to diagnose; there are two main options, each with minor caveats:

1. Exclude files beginning with a dot from being uploaded by the DataNow Windows client. This can be implemented easily using DataNow’s upload sync exclusions mechanism by configuring the relevant registry settings explained in the following article:

How do I exclude files / folders from being synced up by the DataNow Windows client?

This will only be an option if files beginning with dots are genuinely not required, which will often be the case, as not many well-known applications create files on Windows with a leading dot in the name (iTunes being one of very few that we’re aware of).

2. Reconfigure the load balancer to use an alternative persistence mechanism such as Citrix NetScaler’s “Source-IP Destination-IP Hash” which uses a mathematically derived routing system based on the addresses of the clients and servers to guide traffic.

Changing the persistence type should always be carefully considered as it may have an impact on the efficiency of load distribution across a DataNow cluster.

If you think you might be seeing this issue in your DataNow deployment, or would like to discuss our findings in more detail please don’t hesitate to get in touch with Support who will be glad to assist.

Keep an eye out for more DataNow and network related troubleshooting articles coming soon to the AppSense Blog.