A highly interesting and practical use case was submitted to us recently: that of a nomad user accessing different shared encrypted zones on a number of geographic sites.

Let us thus consider several distinct geographic sites with shared encrypted zones on file servers. Access to these zones is defined in 'group' access files managed locally on each site, and available for the ZoneCentral workstations in a shared zone defined as the main path in the Policies.

A user has a laptop running ZoneCentral. He travels frequently and is required to work on every site using certain encrypted zones which he is authorized to access. Each local site has added his access in certain lists of local groups.

Problem: his laptop can only belong to one domain, and it is this domain that defines his policies, and therefore the main path for the access files. When the user connects his machine to another network, he is unable to obtain the local policies, and cannot therefore know where to find the local group access files, which are essential for opening the site's encrypted zones.

Example: on site A, the main path is in \\Blue\AccessFiles, and on site B, it is in \\Red\AccessFiles. The user belongs to site A, and his policies are thus configured for \\Blue\AccessFiles.

The ZoneCentral policies can use environment variables, such as %LOGONSERVER% and others like it. However, no variables of this type correspond to this specific case (localizing the workstation with a path to a given shared zone).

Solution: 

• in each site's policies, define the main path as \\dummyserver.mydomaine.com\AccessFiles, where dummyserver.mydomaine.com is a virtual server name (i.e., that does not actually exist), expressed as a DNS name, not a NETBIOS name.
• in each site's DNS, configure the dummyserver.mydomaine.com alias so that it returns the IP address of the real server (e.g.: ‘Blue’ address on site A and ‘Red’ address on site B).
• Logically, the user's laptop is configured in DHCP so that it can easily connect to any site network. The DHCP server will thus assign it an IP address and, more importantly, the DNS server to use for resolving names and addresses. Thus, depending on the site the laptop is connected to, the \\dummyserver.mydomaine.com\AccessFiles virtual location will be resolved to the right access files server. This is all done in complete transparency for the user.

Try it out: using Windows Explorer, browse a \\server\share server by keying in \\IP\share or \\serverdnsname\share in the address field.

Note that the problem does not arise if access is defined directly in the zones, since there is no resolution of access files to be done. However, it is always best to use access files as they allow for unique group management.

Thanks to the Microsoft partnership, last December the Lab received applied, thorough training from Microsoft and Intel experts on 64-bit architectures, and we have established and approved a software architecture plan for ZoneCentral.

The presence of drivers on the one hand, and the interaction of third party DLLs on the other hand mean that ZoneCentral is ‘sensitive’ to the 64-bit architecture, and imply a dedicated version.

In short, a driver must be compiled in 64 bits. This is mandatory, and may involve some minor code tweaks. Using 'mixed' drivers or an emulation system is not possible.

To a certain extent, matters with ‘user mode’ components are less restrictive, since a 64-bit system can run a 32-bit component through emulation (wow64). However… in a given execution context (64-bit or 32-bit emulation), all the components used (DLLs, among others) must be of the same kind. Consequently, for third party DLLs (invoked in another uncontrolled context, such as the Windows Explorer) or when using a third party DLL (e.g.: PKCS#11), this aspect must have been considered beforehand…

The "64-bit" project is thus underway, with the result scheduled for the last quarter of 2006. This is all the more important given that Windows Vista is planned to be released in 32 and 64-bit versions.

[Note that the specific 64-bit Itanium processor, primarily server-oriented, will not be immediately supported since ZoneCentral is a client machine application].

It is quite natural (and wise!) to be suspicious and cautious when trying out a new product, especially when this product invites you to encrypt your Windows profile or your Workstation…

Generally speaking, a tester-evaluator will first give the product a try on some dummy folders to get to grips with it, before moving on to tests on real data, but still with caution, using backup data… Testers will sometimes be able to use a test PC for more exhaustive tests.

Consequently, it is worth pointing out that ZoneCentral operates perfectly well in virtual environments such as VMWare, Virtual PC or Virtual Server. The fact that ZoneCentral is integrated in the Windows kernel, that it uses drivers, etc. does not pose a problem (it was qualified in this type of environment). Moreover, a number of virtual machines can be run in different operating systems (2000, XP, 2003), thus allowing you to test the deployment scenario (remote installation, distribution of policies, nomad profiles, shared access, etc.).

Here are some specific points to bear in mind: 

• Unfortunately, Virtual PC does not remap the host's USB peripherals on the virtual machines, which is a nuisance when testing ZoneCentral with memory cards or RSA USB tokens.
  
  Tip (which works!): on the host, use the ‘Remote Desktop Connection’ on the virtual machine that is running. This Windows service can remap its host's memory cards. As a result, the memory card is visible on the virtual machine and can be used! Obviously, you must have installed the card manufacturer's software on the virtual machine. Also, don't be surprised if the card is not particularly fast…
  
  Note: to establish this type of connection, you must retrieve the IP address assigned to the virtual machine, which itself must be in the host's addressing plan.
  
  
• In VMWare, dragging & dropping files between the host and the virtual machine can pose problems when the source or target are encrypted zones. We are looking into this problem, however it is fairly understandable, since it is an operating mode normally associated with a network operation (copying files from machine to machine), but that does not work in the same way as a network operation: it is a 'private' emulator mechanism.

In December and January, the Lab carried out a complete, detailed qualification of ZoneCentral in a multi-session Terminal Server environment on Windows 2000 and 2003 servers.

Besides checking the product's smooth functioning in this type of environment, the underlying objective was to check that an opened zone for a session A was not opened for another session, and that the accessible files – already read and decrypted in the system's cache – remain inaccessible (and encrypted) for another session.

In some cases, certain anomalies were observed. In particular, the open zone request would sometimes succeed not in the session at the origin of the request (after opening a file in a zone, for example), but in the so-called "zero" session, which corresponds to the Terminal Server administration console. These few faults have been corrected, and a fully qualified "Terminal Server" version will be released very soon.

The software is also undergoing qualification for Citrix environment operation.

… This is because we slipped up slightly; nothing serious, but one of the changes made in 286 at the end of December brought about the risk of a bug. The chances of it occurring were slim, but we wanted to correct it immediately, resulting in patch 287 which ‘replaces’ 286. Customers concerned have been informed.

Despite our attention to quality, we are not immune to this kind of error, especially since our policy is to offer a highly reactive support service.

We have no one but ourselves to blame, so please accept our apologies; we will do our best to prevent it from happening again.

Generally speaking, this operation is performed with ZCEDIT.EXE [Zone Management], however it can also be done using the Windows Explorer.

When you want to create a new file, you generally right-click on the Desktop or on a folder, select 'New' and choose from among the various file types, among which there is no ‘ZoneCentral access file’! …

This is deliberate, because if each application installed all its little private files here, this Windows feature would quickly become unusable. In fact, creating access files is not usually a frequent operation.

There is another much easier way of obtaining the same result: create a new text document and, when defining its name, apply the ‘.zaf’ extension, i.e., the one used for ZoneCentral access files. Now accept the Windows warning displayed.

Then proceed as usual: right-click the file, choose Properties, click on the ‘Access’ tab: ZoneCentral detects that it is an access file not yet initialized, initializes it, and prompts you to manage its access as usual.

In fact, the important thing is for the file created via "New Text Document" (or other) to have an initial size of 0 bytes; this enables ZoneCentral to ascertain that it can initialize it. If it contained a few bytes that are non-recognizable or inconsistent with an access file, ZoneCentral would not do anything, to avoid the risk of assigning these bytes which do not belong to it.
Example: "New Word Document" does not create an entirely empty file; once renamed ‘mylist.zaf’, the ZoneCentral properties will display an error message.