Microsoft has recently changed its licensing to help organizations adopt virtualization technologies. The new Windows Virtual Desktop Access (VDA) licenses are a Software Assurance benefit, or can be purchased for $100 per desktop a year. VDAs provide users of Windows PCs the right to install Windows XP, Vista or 7 in up to 4 VMs. If you’re the primary user of a device covered by VDA, Extended Roaming Rights (ERR) allow you to access a VM from devices not licensed under Software Assurance or VDA, providing that they’re located offsite and don’t belong to the company.

To further help the take-up rate for virtualization, Microsoft has 2 licensing suites that package licences for accessing remote desktop servers, the Microsoft Desktop Optimization Pack (MDOP), System Center Configuration Manager (SCCM), Operation Manager (SCOM) and Virtual Machine Manager.

With the flexibility that VDIs provide, licenses for your line-of-business applications need to be monitored more carefully. While Microsoft’s AppLocker application whitelisting technology for Windows 7 is a security feature, preventing users launching untrusted applications and executables, Privilege Guard’s application control not only provides a unified administration interface for Windows 7, Vista and XP, but is also more flexible than AppLocker. Moving beyond security, Privilege Guard application control can also whitelist or blacklist applications by device, using a hostname or IP address.

Privilege Guard allows organizations to add a whitelist of device names to application control policies to prevent users launching programs installed on VMs or physical PCs, which is especially pertinent for VDIs where devices may greatly outnumber users, and organizations can quickly fall out of compliance with a shortfall of licences.

As licensing can be one of the biggest costs for Windows shops, ensuring that you procure only the number necessary is crucial to keep costs low. Virtualization technologies promise to reduce costs by allowing organizations to dynamically provision desktops to users without the high total cost of ownership traditionally associated with desktop PCs. But your efforts to reduce costs could be in vain if software licensing is not kept in check, and this is where Privilege Guard’s superior application control technology can help.

Citrix has engineered GoToMeeting so that it doesn’t require any special privileges to install. That may come as a surprise to some system administrators, as it’s often assumed that admin rights are required to install and update the software. One exception is that administrative privileges are needed to install GoToMeeting’s recording codec, but if you don’t need to record a meeting, you’re good to go without it.

If you’ve configured application whitelisting to provide an extra layer of defence, you’ll need to make the necessary exceptions so users can install and update GoToMeeting. Creating rules for Windows 7 AppLocker to allow GoToMeeting to run needs a little preparation because of the slightly convoluted nature in which GoToMeeting installs and runs.

Table 1 - GoToMeeting Executables and AppLocker Rules

Rules will be required for 5 executables as shown in Table 1. Assuming you’ve already enabled AppLocker in Windows 7, I won’t explain here how to create rules, as no doubt that’s something you already know how to do. A good primer can be found at http://technet.microsoft.com/en-us/windows/dd320283. Suffice to say that following best practice, you should configure publisher rules for the GoToMeeting runtimes wherever possible. Figure 1 shows how the file name on disk and the file name displayed in the AppLocker wizard differ, adding some confusion to the process.

For the purposes of adding the GoToMeeting runtimes to AppLocker, you’ll find most of the executables located in the logged in user’s TEMP directory (%username%\appdata\local\temp). You can either enable AppLocker and add a rule for each executable as it’s blocked or install GoToMeeting with AppLocker disabled and then run the Automatically Generate Rules wizard and allow AppLocker to discover the necessary runtimes. The appcore executable isn’t signed, so you’ll need to create a file hash or path file rule to prevent AppLocker from blocking it.

Figure 1 - An AppLocker publisher rule for g2m_download.exe

Once rules to allow the 5 executables listed in Table 1 are added to AppLocker, you should find that users can join and host meetings. If you’re using a mix of Windows versions, Privilege Guard can manage application privileges and implement whitelisting in XP and later so that one set of rules are applied to all your Windows systems.

Use Virtualization to Solve Problems of Privilege

If a user is required to host meetings on a regular basis, with GoToMeeting or a different service, make sure the software is set up in advance and works on their local desktop. For users that might need to join meetings at short notice using unknown services, consider deploying Windows 7 XP Mode – or other virtualized desktop – so that if necessary, client software can be quickly installed without any intervention from IT.

AppLocker can ensure that users are only allowed to run authorized executables, installer packages and scripts. It provides a good selection of rules, including filename, publisher and file hash. In addition, it is possible to identify applications based on their file properties, such as product name and version, although this capability is restricted to signed applications.

The lack of support for management consoles and control panel applets, introduces a slight security concern, as unauthorized snap-ins and applets may be launched by the user. Other areas of Group Policy can be configured to hide control panel applets, but this does not stop a rogue control panel applet from actually running. Management console snap-ins can also be controlled through Group Policy settings, and although this does go further than superficial hiding of snap-ins, the whitelisting of third party snap-ins could prove challenging, so it’s a shame that AppLocker can’t control snap-ins through the restriction of msc files.

Although AppLocker can handle software installation packages, a high proportion of software installers will require local admin rights to install. Granting local admin rights to a user will make any attempt to control application execution a futile undertaking, as the user will effectively have complete control over their desktop, and so the white listing of software packages with AppLocker is severely limited.

Where AppLocker really disappoints is in its end user experience. The end user message that is displayed when an application is blocked can’t be configured, and so the IT department are not able to convey a meaningful message to their user base when an application is blocked. This is further compounded by the lack of any method for a user to request access to an unauthorized application. It’s highly unlikely that the IT department will get application control policies configured correctly first time, and so the lack of informative messaging and a user feedback mechanism will make the ongoing fine tuning and maintenance of policies more challenging.

The application of AppLocker to more advanced users, such as technical users or laptop users, could prove problematic, as applications can only be blocked, which may prove too restrictive and lead to productivity issues. The ability to warn and audit, as opposed to blocking, would have made it possible to apply AppLocker policies to a much broader range of users, but this capability is sadly lacking.

As with most of Microsoft’s built-in system management tools, AppLocker provides no reporting capabilities, which could make it difficult to fully assess the impact of the applied policies.

There is no doubting that AppLocker is a big improvement over Software Restriction Policies, but it still falls short in a number of areas, which may restrict its adoption to smaller implementations of task based workers, where users require little flexibility in their job role. As a user’s requirements become more complex, AppLocker could prove difficult to apply without severely compromising an end user’s productivity and creating a burden on the IT department to constantly update policies.