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.