Non-Admin ActiveX Controls
For many existing and future Microsoft ActiveX controls, Windows Internet Explorer 8 removes administrative involvement from the installation process. The solution addresses issues raised by enterprise customers who used previous versions of Windows Internet Explorer, where administration of controls was not optimal. Non-administrative ActiveX controls (or per-user ActiveX installation) is available on Windows Vista and later.
This topic contains the following sections:
- Overview
- Compatibility with Internet Explorer 7
- Feature Details
- Improvements in Internet Explorer 8
- Highlights of This Feature
- Developing Non-Admin Installation Packages
- AXIS-Dependent Installs
- Code Samples
- Sample .inf File for Non-Admin Install
- Determining Install Scope for AXIS-Dependent Controls
- Related topics
Overview
In Windows Vista, standard users are now able to install ActiveX controls to their own user profiles without administrative involvement. In the event that a user does install a malicious ActiveX control, the system itself will be unaffected. Because the installation affects only the user profiles, the risk and cost of compromise is lowered significantly. This feature relies on features found only in Windows Vista and is therefore not available on Windows XP. Benefits of non-admin ActiveX installations include:
- Most existing ActiveX controls will not need to be rewritten to benefit from this feature; the only change will be repackaging.
- This feature does not affect the installation behavior for legacy ActiveX controls.
Compatibility with Internet Explorer 7
Prior to Internet Explorer 8, extensions were deployed by using many different mechanisms, including .cab files (for example, in MSN Games) and MSI installation (such as in Microsoft Silverlight 1.0). These files contain an information (INF) file for registration instruction and the binary executable (DLL/EXE). The installation is handled by means of using an OBJECT tag in a Web page's HTML markup. Changes in Internet Explorer 8 do not affect the installation behavior for legacy ActiveX. Nothing has changed regarding the manner in which ActiveX are packaged; they are still an INF file and encased within a .cab file. The changes come in additional directives within the INF file, where developers can now specify whether to use new non-admin install features.
Feature Details
Improvements in Internet Explorer 8
Any ActiveX installation built for Windows Internet Explorer 7 and earlier requires users to have administrative privileges. On Windows Windows Vista, with user account control (UAC), this means that a UAC dialog will display when a control attempted to install. On both Windows XP and Windows Vista, non-administrators are prevented from installing any ActiveX on their own. But now an ActiveX registered under the HKEY_CURRENT_USER hive is now fully supported by Internet Explorer within the context of a user's privilege level.
Highlights of This Feature
User Experience
- Users logged on with Standard User privileges (or higher) are now able to install ActiveX controls from the Web.
- No UAC dialog is displayed in the common end-to-end ActiveX installation scenario when the installation is done in user mode.
- Users with administrative access can now choose between per-user and machine-wide ActiveX installation without experiencing unnecessary complexity during the installation experience.
IT Professional Experience
- IT Professionals can configure policies to manage which ActiveX controls are installed.
- IT Professionals can block Internet Explorer from installing ActiveX controls when ActiveX Installer Service (AXIS) is being used. This gives administrators complete control over ActiveX installations and prevents standard users from installing or tampering with already installed ActiveX controls.
Developer Experience
- Conforming to non-admin installation changes in Internet Explorer 8 will, in most cases, be as simple as repackaging a current control with a modified INF file.
Developing Non-Admin Installation Packages
By adding specific settings to the INF files contained within ActiveX installation .cab files, add-on developers can enable these new options. In a newly added section named [Deployment], users can add the following flag:
| Flag | Parameter |
|---|---|
| InstallScope | Optional. machine: [Default] The ActiveX control supports installation at machine scope (all users).user: The ActiveX control supports installation for the current user only. Both scopes can be supported. In that case, they need to be separated by a vertical bar (|). Example:
|
For each binary to be installed, developers can also specify the following flag:
| Flag | Parameter |
|---|---|
| RedirectToHKCU | Optional. This flag is set under the DLL sections scope. no: [Default] No need for registry redirection. yes: Enables HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE predefined key overrides when calling DllRegisterServer and DllUnregisterServer. This is a best-effort feature to help legacy ActiveX controls install correctly. |
This redirection will be available only to inproc-server DLLs, not to local-server executables. Internet Explorer 8 does not support ActiveX controls with custom registry settings. For example, if someone needs to write to HKLM\Software\Company Name, the control will fail at instantiation time because there will not be redirection at instantiation time.
For an example of this new INF file model, please refer to the following Code Samples section.
AXIS-Dependent Installs
If the AXIS service is present, ActiveX controls pass through it to be installed. Unfortunately, since AXIS runs with system privileges, it is not associated with the current user account. If an ActiveX control tries to register in the HKCU registry subtree, the registration will actually be written in the default node, and the current user will be unable to access those COM objects.
That means that in Internet Explorer 8, any ActiveX control that identifies itself as having user install scope only will be denied AXIS access. Then, depending on the system policies, users' control installation might succeed or might fail. Also, any ActiveX control that installs only as the current user will still go through AXIS, so that the installation will be broken in Internet Explorer 7.
To maintain compatibility with AXIS, no change was made to the IeAxiInstaller COM interface. Please refer to the Code Samples section for examples of accounting for install scope and avoiding failures due to user privilege levels.
Code Samples
Sample .inf File for Non-Admin Install
Developers can use the following INF file in their ActiveX packaging to allow Internet Explorer to install a specified ActiveX control under the HKEY_CURRENT_USER registry hive. The [Deployment] section allows user redirection.
[version]
signature="$CHICAGO$"
AdvancedINF=2.0
[Add.Code]
time.ocx=time.ocx
msvcrt.dll=msvcrt.dll
[Deployment]
InstallScope=user
[time.ocx]
file-win32-x86=thiscab
clsid={DCF0768D-BA7A-101A-B57A-0000C0C3ED5F}
FileVersion=1,0,0,0
RegisterServer=yes
[contoso.dll]
file-win32-x86=thiscab
clsid={ABC01234-BA7A-101A-B57A-0000C0C3EFF0}
FileVersion=4,20,0,6164
RegisterServer=yes
RedirectToHKCU=yes
Determining Install Scope for AXIS-Dependent Controls
Since ActiveX can support multiple installation scopes, the IEInstallScope function provides a way to let an ActiveX control know which scope to use. Urlmon.dll exports the function. The function signature is:
HRESULT IEInstallScope(LPDWORD pwdScope);