Partager via

ActiveX Installer Service Discussion and Video

  • Article

This is Joel Yoker, Senior Consultant, and Rob Campbell, Technical Solutions Specialist, from the Microsoft Federal (Government) District. Many of the customers that we work with have locked-down desktop environments. One of the challenges that these customers face is how to deploy ActiveX controls in an environment where users are not administrators. ActiveX controls are designed to be installed interactively by the user, but standard users don’t have privileges to install ActiveX controls. The ActiveX Installer Service (AxIS) in Windows Vista is designed to solve this problem by giving IT a way to use Group Policy to determine which controls their users can install, even if they don’t have administrator privileges.

To illustrate AxIS in action, we have included a complete walkthrough of the installation and configuration of AxIS on Windows Vista RC1 in this video: Start video 100k | 300k

One of the biggest challenges with ActiveX controls is enabling the use of trusted objects while mitigating potential threats. In some customer segments, ActiveX and related technologies are labeled as “mobile code” and considered potential threats to the computing environment. The problem is that at the end of the day, depending on rights, the decision to install a particular ActiveX control (good or bad) is left up to an individual user. This means that in a 10,000-user environment, the decision to introduce spyware/malware into the environment could potentially be made by 10,000 different individuals within the organization. Let’s look at the problem for a moment, how previous versions of Windows mitigated this threat, and the innovative way Vista handles this with the ActiveX Installer Service (AxIS).

By default in Windows Vista (and in previous versions of Windows), only those with local Administrator rights have the ability to install ActiveX controls. Once installed, any user of the system can invoke a given ActiveX control. This is controlled by a series of registry and file system Access Control Lists (ACLs). While the default behavior is a good approach, it does not address the problem of allowing specific ActiveX controls that are in use with internal applications to be installed by end users. To address this gap, there are many different approaches, some of which are outlined below:

  • Pre-installation of ActiveX controls
  • Modifying URLActions (such as Install Signed ActiveX controls) on specific Internet Explorer Security Zones
  • Designating an internal Internet Component Download Server (by manipulating the CodeBaseSearchPath registry value)
  • Administrator Approved Controls (via Group Policy)
  • Blocking at the perimeter

Without diving into details on each of these methods, it is safe to say that they each have certain flaws. Each of the solutions addresses areas such as blocking where ActiveX controls come from, where they can be invoked from, and so on; however, these solutions do not mitigate the fundamental problem that users without Administrator rights cannot install ActiveX controls. In addition, each of the solutions listed above comes with a large administrative burden, particularly with the frequent changes found within the landscape of internal applications. What we have witnessed in some customer organizations are solutions ranging from end users being granted temporary/permanent administrative access on their workstations to the extreme of the default permissions in the operating system being modified to allow end users the ability to install ActiveX controls.

Enter Windows Vista and AxIS -- the solution to the problems outlined above. AxIS provides corporate administrators the ability to identify trusted sources of ActiveX controls, and provides standard users the ability to install controls from those trusted sources. The key benefit of this solution is that a non-administrative security posture is maintained on user workstations. A short explanation of the ActiveX Installer Service is provided by our good friend Chris Corio here (https://blogs.msdn.com/uac/archive/2006/06/14/631416.aspx). As described by Chris, this is enabled by identifying trusted locations where ActiveX controls are being installed from and having a service on Windows Vista install the ActiveX control on the user’s behalf (since any user can invoke a control once installed). If a control isn’t previously identified by Group Policy, the standard behavior will occur requiring administrative rights. However, an event will be logged in the Application event log (EventID 4097 from Source Microsoft-Windows-AxInstallService) outlining the attempted ActiveX control installation, along with the specific download path to the control. The data from this event log entry can then be used by the corporate administrator to modify Group Policy, allowing the control to be installed by AxIS on subsequent visits to the site. Furthermore, the ability to attach tasks to events in Windows Vista provides an easy way for anyone to receive a notification from the AxIS service (such as when the installation of an ActiveX control is blocked).

What does this mean practically? This means that through a simple Group Policy change and a service that can be enabled on Windows Vista, you can take control of which ActiveX controls are installed by end users across your entire organization. This also eliminates a common justification that end users cite when they request administrative rights on their systems. AxIS provides organizations with another tool to take a least-privilege approach to end-user rights on desktop systems. The choice of which ActiveX controls are “trusted” within the corporate environment are determined the organization, not the end user.

If you have Windows Vista RC1, we encourage you to give this feature a try. The next step for those planning Windows Vista deployments is to start a dialog with the developer community within your organization and identify all of the trusted locations where ActiveX controls could possibly come from.

-- Joel and Rob

Comments

  • Anonymous
    September 13, 2006
    Hello guys

    I have been trying to get the ActiveX Installer Service to run since Build 5472 of Vista. What I want is a silent install using the comma seperated values 2,2,2,0 but this does not seem to work. I have blogged about this on my blog:

    http://pointerx.net/blogs/glozano/archive/2006/09/13/Windows-Vista_3A00_-ActiveX-Installer-Service.aspx

    Could you please tell me what I am doing wrong here?

  • Anonymous
    September 13, 2006
    Thank Gabriel, we are investigating this. - Alex

  • Anonymous
    September 14, 2006
    You cannot define a policy of 2,2,2,0 because AxIS treats this as a malformed policy.  Unsigned controls policy (the x in the following comma separated policy value: 2,2,x,0) does not allow the installation silently.  This value can only be 1 or 0.  If you find that the policy does not work with 1 or 0 for unsigned controls please reply back and let us know.

  • Anonymous
    October 04, 2006
    To help you prepare for the IE7 release we’ve updated many of our tech articles on MSDN including those

  • Anonymous
    October 25, 2006
    The comment has been removed

  • Anonymous
    January 17, 2007
    If a user logs in as the Administrator, can install ActiveX as before?

  • Anonymous
    March 02, 2007
    PingBack from http://www.elka-install-instructions.info/blog/60/install-activex-why-you-are-unable/