locked
Installing Cab files or ActiveX in internet Explorer using non-admin user RRS feed

  • Question

  • Hi

     

    I need to install Cab files or ActiveX on workstation from IIS directory using Internet explorer using non-admin user login.

     

    How can i do it?

     

    Any help in this regard will be appreciated

     

    Thanks

    Friday, February 29, 2008 5:27 AM

Answers

  • There are two security issues involved. Firstly you need to set your browser settings to allow the installation of ActiveX controls. This is fairly trivial, and I suspect you already know how to do this. (If not I can post instructions).

     

    The second issue is likely the one you are concerned about. In the case of ActiveX controls, installation involves the browser loading the DLL into memory and calling the DllRegisterServer() entry point. This instructs the control to create the appropriate registry entries. Typically this involves touching registry keys which require administrator privileges. Unless you are willing to spend the time changing the registration code you are snookered.

     

    In recent years, Microsoft has come up with a registration procedure which allows the control to be registered on a per user basis, and this does not require administration privileges. Google for "Isolated COM" for details. 

     

    HTH

     

    Brian

     

    Friday, February 29, 2008 5:41 AM
  • As I have explained, unless you are willing to change each individual OCX to change the manner in which they enter their registry values, you must run with administrator privileges. Remember, you are essentially installing software, and installing software generally requires administrator privileges. This is important from a security standpoint since you don't want regular users installing software willy-nilly on any workstation.

     

    There are other ways of distributing your software. You can use SMS for example. Or you can use a group policy to install the software remotely. (http://support.microsoft.com/kb/314934)

     

    Brian

     

     

    Friday, February 29, 2008 4:43 PM
  • Addendum: In an earlier post in this thread I suggested reading up on "Isolated COM". I meant to say "Registration-free COM", but the two are related.

     

    http://msdn2.microsoft.com/en-ca/magazine/cc188708.aspx

    http://msdn2.microsoft.com/en-us/library/ms973913.aspx

     

     

    Saturday, March 1, 2008 4:35 AM

All replies

  • There are two security issues involved. Firstly you need to set your browser settings to allow the installation of ActiveX controls. This is fairly trivial, and I suspect you already know how to do this. (If not I can post instructions).

     

    The second issue is likely the one you are concerned about. In the case of ActiveX controls, installation involves the browser loading the DLL into memory and calling the DllRegisterServer() entry point. This instructs the control to create the appropriate registry entries. Typically this involves touching registry keys which require administrator privileges. Unless you are willing to spend the time changing the registration code you are snookered.

     

    In recent years, Microsoft has come up with a registration procedure which allows the control to be registered on a per user basis, and this does not require administration privileges. Google for "Isolated COM" for details. 

     

    HTH

     

    Brian

     

    Friday, February 29, 2008 5:41 AM
  • Thanks for reply.

     

    Let me tell u whole scenario in detail

     

    I have 6 Cab files containing Dlls or ocx with inf file. All these cab files are digitally signed.

    They are stored on IIS virtual directory running under administrative account.

     

    The problem is, on the workstation, user are not having admin rights so admin has to login on all the workstations to download and install them on browser.

     

    Is there a way to do that.

     

     

    Friday, February 29, 2008 10:14 AM
  • As I have explained, unless you are willing to change each individual OCX to change the manner in which they enter their registry values, you must run with administrator privileges. Remember, you are essentially installing software, and installing software generally requires administrator privileges. This is important from a security standpoint since you don't want regular users installing software willy-nilly on any workstation.

     

    There are other ways of distributing your software. You can use SMS for example. Or you can use a group policy to install the software remotely. (http://support.microsoft.com/kb/314934)

     

    Brian

     

     

    Friday, February 29, 2008 4:43 PM
  • Addendum: In an earlier post in this thread I suggested reading up on "Isolated COM". I meant to say "Registration-free COM", but the two are related.

     

    http://msdn2.microsoft.com/en-ca/magazine/cc188708.aspx

    http://msdn2.microsoft.com/en-us/library/ms973913.aspx

     

     

    Saturday, March 1, 2008 4:35 AM
  • Note the exceptional case  from the article you mentioned above:  http://msdn.microsoft.com/en-ca/magazine/cc188708.aspx

    "Not every component is a suitable candidate for use under Reg-Free COM. A component is not considered suitable if any of the following are true:

    • ...
    • The component is intended for use as an add-in or a snap-in, such as an Office add-in or a control in a Web browser. Such components typically require some kind of registration scheme defined by the hosting environment that is beyond the scope of the manifest itself. The other problem is an arbitrary application may not be designed to recognize isolated components, as it probably doesn't have a way to reference your component through a manifest."

    I've never seen any documentation from MS that Reg-Free COM works with IE. I've scowered for information about this and none is forthcoming.  ActiveX components are instantiated by ClassID not ProgId. (the script ActiveXObject() only takes a classid.)  I've tried it myself using the documentation from the walk through, and using the User Specific Redirection overrides putting ProgId info in the Current User hive, and I can't get it to work.

    From what I've seen, I believe you MUST register the ActiveX in HKLM before IE can see the classid. That means you MUST have admin rights to install an ActiveX. (The Active Directory push and SMS solutions don't get around this, they just require an Admin to push the install to the user's machine before the component is required.)

    If anyone has any different experience, please let us know. This is the SINGLEMOST PAINFUL aspects of using ActiveX components in IE. It doesn't match w/ the real world expectations since MOST enterprises do NOT allow user's admin rights to their machines.

    • Edited by ggianop Wednesday, August 27, 2008 4:15 PM left out a URL
    Wednesday, August 27, 2008 4:13 PM
  • I believe and please keep me honest here, as I'm about to try it out, that through GPO you can specify on a white list what controls can be installed by the user. 

    Adding these components to that list, will in turn allow the users to install them without admin rights.

    I'll try to get back to you after I attempt this, we'll see how successful I am.


    I need to deploy about 25 active-X controls for an application that a specific group of users will use.
    Wednesday, September 3, 2008 5:45 PM
  • did you mange to get the CAB files deployed and in witch way - even though it is a long time go, it would be helpful if you could point out the steps to solve this :)
    Wednesday, August 18, 2010 9:26 AM
  • Essentially, the white list will work perfect if you have add-ins for IE that are being hosted on a domain/webserver. You can specify in the whitelist that anything that comes from here has been given authority to run.

    For the installation of the OCX files, there is a seperate workaround that I was able to do.

    I created a batch file that runs the regsvr32 command for all the specific files, turns out i had more like 400 OCX files to deploy.

    The second step was to get these files to the user, in a directory where they had full permissions.  Once in that directory, the non-admin user account could execute the command. 

    However, should that still not satisfy your needs, perhaps your OCX files specifically require admin install because they are system rather than user specific, then once you have managed to get the files on the system, you can remotely use PSTOOLS or the likes to launch the batch file. 

    This way you don't have to be at the actual system.

    If you have SMS/SCCM, then there is no easier way to do this than creating the package with a selently executing batch or EXE.

    Wednesday, August 18, 2010 1:22 PM