Mombu the Microsoft Forum sponsored links

Go Back   Mombu the Microsoft Forum > Microsoft > AdminUser vs. Privileged Installs
User Name
Password
REGISTER NOW! Mark Forums Read

sponsored links


Reply
 
1 15th July 21:03
michael hlavinka
External User
 
Posts: 1
Default AdminUser vs. Privileged Installs



I have a merge module that I'm trying to use in my msi
package that requires the administrator to install. Can
someone speculate why this fails for privileged installs
that are done with machine and user policies set to
AlwaysInstallElevated to true for non-administrator
users? Does this not give you administrative
privileges? Is there a difference between AdminUser
installs and Privileged installs?

Thanks,

Michael
  Reply With Quote


  sponsored links


2 23rd July 19:29
chris gouge [msft]
External User
 
Posts: 1
Default AdminUser vs. Privileged Installs



AlwaysInstallElevated is NOT a recommended solution for running elevated
installs. Since these policies are machine-wide, they create significant
security issues. Once set, the machine can never truly be secured again as it is
impossible to tell whether a bad user took advantage of the policy to install
dangerous software on the machine.

With regards to your specific question: Yes, there is a difference between an
AdminUser and Privileged install. When the AdminUser property is set, the user
invoking the install is a member of the Administrators group. When a non-admin
user performs an installation for a product which has been set to run elevated,
the AdminUser property is NOT set.

The Privileged property indicates that the user performing the install is a
member of theAdministrators group OR that the user performing the install is NOT
a member of the Administrators group but the product has been set to run with
elevated privileges. When the Privileged property is set, it does NOT change the
rights of the user - the user DOES NOT become an Admin may still only perform
actions that fall under his or her assigned security restrictions. This includes
custom actions that are marked to run using the user's identity. When the
product is set to run elevated it enables custom actions to run using the
LocalSystem identity if so marked, and also enables MSI performing actions on
the user's behalf using elevated rights through standard MSI tables.

The recommended (and secure) method of enabling elevated installs by non admins
is to pre-advertise the product in the appropriate context. This may be done
through Intellimirror (Software Deployment) or a similar software distribution
or software management infrastructure.

It is not possible for a package to elevate itself. Granting specific elevated
software rights to non-admin users is a decision made by the system
administrator, not the package author. However the package author can block the
install if the Privileged property is not set. (It is not recommended that MSM
authors block the install, but that is a separate issue.)

-Chris Gouge
Microsoft Windows Installer Team

This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.asp>
  Reply With Quote
Reply


Thread Tools
Display Modes




Copyright © 2006 SmartyDevil.com - Dies Mies Jeschet Boenedoesef Douvema Enitemaus -
666