[Libreoffice-bugs] [Bug 94193] Installer forces AD domain users in Administrators group to run as Administrator, otherwise custom actions are disallowed during execution stage and not completed

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=94193

Xisco Faulí  changed:

   What|Removed |Added

   Priority|high|medium

--- Comment #16 from Xisco Faulí  ---
Changing priority back to 'medium' since the number of duplicates is lower than
5

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 94193] Installer forces AD domain users in Administrators group to run as Administrator, otherwise custom actions are disallowed during execution stage and not completed

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=94193

--- Comment #15 from Mike Kaganski  ---
(In reply to V Stuart Foote from comment #9)

It is a *good* and absolutely correct idea - and an easy hack - to add all the
user-configurable properties to the secure list. You are quite right!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 94193] Installer forces AD domain users in Administrators group to run as Administrator, otherwise custom actions are disallowed during execution stage and not completed

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=94193

V Stuart Foote  changed:

   What|Removed |Added

 CC||d.ostrov...@gmx.de,
   ||je...@softcatala.org
Summary|Installer ignores at least  |Installer forces AD domain
   |some options in Custom  |users in Administrators
   |mode, such as changes to|group to run as
   |the target directory|Administrator, otherwise
   ||custom actions are
   ||disallowed during execution
   ||stage and not completed
   Severity|normal  |enhancement

--- Comment #13 from V Stuart Foote  ---
@sebalis,

OK, thanks for another round.

So comparing the two installs--the first, AD Domain account in Administrators
group run from a command window, and the second, run from a command windows
"Run as Administrator", have different outcomes regards the MSI transition from
UI stage to Execute stage.

Public values are being disallowed for the first--even though the logs
recognize you as an admin in the UI stage. It shows a EnableUserControl
disabled but gets clobbered by a RestrictedUSerControl enabled. At line 5343 we
get "MSI (s) (B0:3C) [02:01:39:675]: Running product
'{A18CF6D8-7CE1-46F2-85B9-D87B7197B2F6}' with elevated privileges: All apps run
elevated."

In the latter, "Run as Administrator" at line 5044 we get:

MSI (s) (2C:0C) [16:58:54:988]: Product installation will be elevated because
user is admin and product is being installed per-machine.
MSI (s) (2C:0C) [16:58:54:988]: Running product
'{A18CF6D8-7CE1-46F2-85B9-D87B7197B2F6}' with elevated privileges: Product is
assigned. And the Execute stage and actions passed to the service assert as
expected.

So, problem solved... sort of ;-)

It is a work around--i.e. "Install from an elevated command prompt". Or one can
create and merge the following registry hack which will offer a "Run as
Administrator" from the Windows context menu--and accomplishes the same work
around.


Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Msi.Package\shell\runas]
@=""

[HKEY_CLASSES_ROOT\Msi.Package\shell\runas\command]
@="msiexec.exe /i \"%1\""

[HKEY_CLASSES_ROOT\Msi.Patch\shell\runas]
@=""

[HKEY_CLASSES_ROOT\Msi.Patch\shell\runas\command]
@="msiexec.exe /p \"%1\""



Despite work around(s) I continue to see this is a UAC issue with AD managed
user account, AD deployed GPO and interaction with the Windows Installer
package.

Suspect it is a manifestation of our legacy build scripts for Windows installer
packages.  Yes, we've added support for 64-bit flavors--but we are getting
further away from current Windows Installer Single Package Authoring. We have
been unable to do peruser installations beyond XP. We've now dropped Windows
XP, perhaps we should drop Windows Vista as well and refactor the MSI packaging
fully to Installer 5.0 including current ICE validation, and again support
peruser as well as permachine installs and I'd hope better handling of UAC for
AD "managed" machines and accounts.

@Andras, @DavidO, @Jesus how do you see this?  I beleive the work around should
hold for folks, but going forward, e.g. VS2015 etc. the Windows install
packaging may really need some attention. Restoring ability to install peruser
alone might justify refactoring.  

But as the work falls to you--I'm just opining... Stuart

=-ref-=
http://blogs.msdn.com/b/windows_installer_team/archive/2009/09/02/authoring-a-single-package-for-per-user-or-per-machine-installation-context-in-windows-7.aspx
https://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 94193] Installer forces AD domain users in Administrators group to run as Administrator, otherwise custom actions are disallowed during execution stage and not completed

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=94193

--- Comment #14 from sebalis  ---
I don't really have anything to add at this point, but I'd like to express my
gratitude to Stuart for the competent care he has given to my bug report.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs