Judging from the paucity of discussions on this subject, it appears that
few admins have taken advantage of IE's built-in functionality to
restrict the activex controls that IE is allowed to run. Yet this is
worth looking into. There are some initial hurdles to overcome, but
afterwards it becomes a very viable solution to guard against
activex-related security hazards.

First, a word on how this functionality works. To enable Admin-Approved
ActiveX controls, go to each security zone and enable "Run ActiveX
controls and plug-ins->Administrator approved" option. For applying
this setting en masse, use GPOs.

By default, all ActiveX controls are disabled, and you have to
explicitly enable controls one by one. To enable a control to run in
IE, find out its GUID, go to
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Int
ernet Settings\AllowedControls, create a DWORD value with the GUID as
the name, and 0 as the value. Note that 0 is the value which enables
the control, while a value of 1 explicitly disables it.

It is actually not recommended that you enter controls by hand, because
by default, the non-admin user is denied write-access to
HKEY_CURRENT_USER\Software\Policies. Rather, you should enable controls
via Administrative Templates in GPOs.

Windows 2000 comes with a template containing a few controls, not nearly
enough to satisfy the daily needs of an active user. Internet Explorer
Administration Kit contains axaa.adm, a template that inclues
specifications to enable a wider range of controls. However, this
latter template is broken out of the box, as the author mistakenly
specified a DWORD value of 1 on many of the entries which, as seen
above, actually disables controls. Hence while axaa.adm is a good place
to start, you can't use it without some modifications.

Even axaa.adm is not quite complete. The biggest omission perhaps is
the lack of support for ActiveX plugins, which are ActiveX controls that
act as viewers for documents specified using the <EMBED> tag. When IE
encounters an EMBED tag, it first uses the MIME type or the file
extention to determine the correct ActiveX control to view the file.
Then, IE launches a special ActiveX *container control*, which in turn
launches and encapsulates the ActiveX document viewer control. The
container control therefore must be enabled if ActiveX plugins are to
function. This container control is called, not surprisingly, "ActiveX
Plugin Control", and it has the GUID of
{06DD38D3-D187-11CF-A80D-00C04FD74AD8}.

Finding which ActiveX control to enable is the biggest headache in
implementing this feature. Sometimes it's not all that obvious,
especially when the controls are invoked by script, rather than a simple
<OBJECT> tag. For your convenience, here's the information on other
popular ActiveX controls that the typical user might need:

"Microsoft Shell UI Helper"
{64AB4BB7-111E-11d1-8F79-00C04FC2FBE1}--needed for Exchange 2000 OWA
"DHTML Richtext Edit Control"
{2D360201-FFF5-11d1-8D03-00A0C959BC0A}--needed for Exchange 2000 OWA
"XMLDOM" {2933BF90-7B36-11d2-B20E-00C04F983E60}--needed for Exchange
2000 OWA
"XML HTTP Request" {ED8C108E-4349-11D2-91A4-00C04F7969E8}--needed for
Exchange 2000 OWA
"Macromedia Shockwave Control" {166B1BCA-3F9C-11CF-8075-444553540000}
"Quicktime ActiveX Control" {02BF25D5-8C17-4B23-BC80-D3488ABDDC6B}
"RealPlayer G2 Control" {CFCDAA03-8BE4-11CF-B84B-0020AFBBCCFA}
"Adobe Acrobat ActiveX Control" {CA8A9780-280D-11CF-A24D-444553540000}
"DevdocCookie Class" {59CC0C20-679B-11D2-88BD-0800361A1803}--needed for
MSDN browser tree

I have uploaded my own copy of modified axaa.adm to a web server so that
those interested can be spared the trouble of figuring out the above.
I've been successfullying using this template for over half a year.

http://www.bol.ucla.edu/~everblue/axaa.adm

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]