When securing a small business network, whether it's based on Windows Small Business Server 2003 (SBS 2003) or Windows Server 2003, I like to suggest blocking ActiveX controls on the Windows XP Service Pack 2 (SP2) machines on the network and allowing only specified controls. By blocking most ActiveX controls—or, in recent Microsoft terminology: add-ons—you can substantially reduce the risk of users running code within Microsoft Internet Explorer (IE) and infecting their machines with malicious programs, spyware, and viruses.
In SBS 2003 and Windows 2003, Microsoft has given us new Group Policy tools to manage ActiveX controls in our domains. With these new Group Policy settings, administrators can add allowed ActiveX controls to a Group Policy "white list" and block any other add-ons from being loaded on client machines. Unfortunately, these tools don't make the process as easy as it could be. You must find the globally unique identifier (GUID), or Class ID, of the add-ons you want to allow and you must type in these long strings of letters and numbers, rather than copying and pasting them in. But the directions in this article should help you over these rough spots, and maybe improvements in Windows Vista and IE 7.0 will ease the process.
This article is aimed specifically at networks that use SBS 2003, which comes with Windows SharePoint Services, Microsoft Outlook Web Access (OWA), and other SBS 2003 features that use IE add-ons to function. However, you can take similar steps in an enterprise network if you're running these same features or products.
STEP 1: Find the GUID of the Add-ons That You Want to Allow
To put ActiveX controls on a Group Policy white list, you first must discover which controls your users need. Then, you must discover each control's Class ID so that you can type it into your Group Policy Object (GPO).
On a client machine that you think has the ActiveX controls that you want your users to have, start IE, then select Manage Add-ons from the Tools menu. In the Manage Add-ons dialog box, you can view two lists of ActiveX controls: a list of add-ons currently loaded and a list of add-ons that have been loaded at one time or another. Right-click the column headings of whichever list is currently visible and select Class ID to add the Class ID column to the dialog box, as Figure 1 shows.
Look through the two lists of ActiveX controls and write down the Class IDs of the ones you want to put on your GPO white list exactly as shown— with beginning and ending brackets and hyphens. Unfortunately, there's no way to copy the Class IDs from this list and paste them into the GPO. You're going to have to type in the Class IDs, so be careful to write them down correctly.
Unfortunately, the Manage Add-ons lists in IE 6.0 don't show all the ActiveX controls that run on a system—apparently because these add-ons are sitting behind another process. I've done a little detective work and have assembled a list of addons that SBS 2003 organizations need to allow to make various SBS 2003 features, such as Remote Web Workplace and OWA, work. Web Table 1 (http://www.windowsitpro.com, InstantDoc ID 48400) shows this list, which is updated as necessary in the Microsoft article "Outlook Web Access and Small Business Server Remote Web Workplace do not function if XP Service Pack 2 Add-on Blocking is enabled via group policy," http://support.microsoft.com/kbid?=555235. You'll need to type the Class IDs of the add-ons for the SBS 2003 features you use in your GPO allow list.
Depending on what other add-ons you require, you might need to do some additional sleuthing to discover other ActiveX controls that your client machines need to allow so that the Web sites your users need will work properly for them. It's great to do this discovery up front, before you block all ActiveX controls (except the ones you add to your white list) in Step 2 below. But keep in mind that you're likely to miss some ActiveX controls at this stage, so you'll probably need to add more Class IDs to your white list after you put ActiveX blocking into effect.
To discover the Class IDs that a Web site is loadingon a client system, first download and install the Debugging Tools for Windows from http://www.microsoft.com/whdc/devtools/debugging/default.mspx. Start the WinDbg tool, and configure the symbol path to point to the Microsoft public symbol server (http://msdl.microsoft.com/download/symbols).
Then attach to IE's process (IEXPLORE), which should already be running, and set the following breakpoint in the console window:
bp SHLWAPI!SHCoExtensionAllowed
"db poi(esp+4); g"
Press F5 to allow IE to run, and open the desired Web site in IE.
In the debugger window, you'll see output from the computer's memory that looks similar to the output in Figure 2. Each line represents an ActiveX control that requires operator approval before the control can run (some controls might appear more than once). The character strings that the debugger outputs aren't in Class ID format— they must be translated into that format.
For example, the first line in Figure 2 contains the string in the first line of Figure 3. If you reorder the first eight number/letter pairs, eliminate the spaces, and add brackets and hyphens, you end up with the Class ID for the JavaScript addon, which the second line in Figure 3 shows. Once you have the Class IDs, you just have to determine whether you want to add their associated controls to your allow list. (I never said this was easy.)
Alternatively, if you know you want to allow a particular add-on that doesn't appear on IE's Manage Add-ons lists, you can contact the add-on's vendor and request the Class ID.
Tracking down and manually writing down the GUIDs for all the ActiveX controls you want to allow can be a tedious process. The good news is that you only have to do it once if you use a GPO to apply the allow list.
Prev. page
[1]
2
next page 
