RE: [ActiveDir] Using GPO to install an MSI package

[McClure David]

In my experience, a lot of developers DON'T KNOW in detail what their apps do and what permissions are required on what resources.  They develop with Admin accounts and make their service accounts Admins unless they're forced otherwise.  That's a sure way to keep security problems out of their way during testing so they can concentrate on code quality.  But then no one pays attention to security until implementation, and...you know the rest. -----Original Message----- From: Crawford, Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 15, 2005 4:29 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Using GPO to install an MSI package Envision my utopia – all apps, in order to get a “Designed for XP” logo need to meet some requirements: Come with an MSI installer or have one that’s easily extractable from an EXE. Come with an .ADM file for configuring options Run under a non-privileged user account.   How nice would that be?  Think about it, you spent several hours preparing your package, and tracking down the required permissions.  Multiply that by all the admins that would like to run in a secure environment and multiply that by all the apps that need special perms to run.  Add to that all the time spent making MSI’s of legacy installs.  Then you’ll get some idea of the YEARS of man hours wasted trying to make things manageable in a secure enterprise environment.  Compare this to the comparatively miniscule amount of additional time needed to build things right.   It would take relatively no time for developers to issue their installs as MSI’s in addition to EXEs.  It might take a bit of time to create an ADM file, but still relatively little since they have intimate knowledge of the app and where it reads settings from.  The biggest issue would be redesigning their apps to work as non-privileged users, but even that could be mitigated if they would at least publish a list of special perms needed or at the very least, every file and registry entry that’s part of their app so that we could give full control to Users over those objects.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason B Sent: Tuesday, February 15, 2005 3:00 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Using GPO to install an MSI package   I really appreciate everyone's input on my situation.   I did get it to work, in short, because of everyone's help here.  Thanks!    Here's what I did:   I contacted Intuit (maker of Quickbooks) and wasted 55 minutes on hold and another 10 minutes on hold after a rep answered the call only to find out absolutely nothing other than what a waste it is to have a "support" contract with Intuit.  Apparently the employees in product development are too busy improperly coding new programs to talk to those who actually [try to] use their stuff.   I determined that I needed to find out if the program explicitly looks for the user to be a local PU or Admin, since, if it did, as someone pointed out, we'd be SOL.  I created a test OU, created a test GPO and applied it to that OU.  I created a test group and a test user and put him in the group, and added the user (and test machine) to that OU.  I then gave the test group full permissions to the C:\ drive (FS) and \\classes_root \\machine \\user (registry) and logged in as the test user on the test box to see if it could run under the non-PU and non-Admin context.  It worked.  Now that that was known, it was time to filter down.  I removed the permissions for C:\ (FS), \\machine and \\user and tried again - it still worked, so now I have to figure out which keys were being written to in classes_root, so I ran regmon and after an hour of trying to decipher what it used and what it didn't, and making a long list in the test GPO permissions, I got it to work.  I think it took longer to enter the registry keys in the GPO than it did to find out what was needed as far as permissions go (sigh).  Did I mention how much I hate Intuit products?   ----- Original Message ----- From: Jason B To: ActiveDir@mail.activedir.org Sent: Tuesday, February 15, 2005 8:44 AM Subject: [ActiveDir] Using GPO to install an MSI package   Okay, our environment is that all our clients are running Windows XP SP2, and our servers are Windows 2003.  The situation is that our Accounting department uses Quickbooks, and about 70 of our employees need to use an application that comes with Quickbooks called "QB Timer".  It's free for use for our employees and it integrates with Quickbooks without requiring a Quickbooks install on each machine.  Now, the quandry:  according to Intuit/Quickbooks, the program requires at least Power User permissions to install and run.  Neither I, nor our CIO are willing to give local Power User permissions for these users, as that opens things up to too many potential problems, but our CFO and COO are REQUIRING the use of this application, or a similar one that integrates with Quickbooks.  Now, the QBTimer is free, which is good, so that's the *preferred* app to use.  It comes as an exe with a few other files, so I used WinInstall LE 2003 on a clean XP SP2 machine to package it into an MSI file.  That worked well, and I can install it/assign it through GPO - even if the user doesn't have local Power User privs.  However, true to form with Intuit products, it won't run if the logged on user doesn't have local admin or PU privs.  If I grant PU privs to the user, it runs fine.  I feel like I am --> <-- this close to getting this done, but I ran out of ideas to get this to work.  I tried looking at the reg file that was made when I ran WinInstall and gave the users full rights to the specific areas in the registry to see if that did anything; which it didn't.   Does anyone else have any siggestions, or am I stuck with Intuit's "users must have >= Power User privs" to run that app?   ANY help or suggestions are GREATLY appreciated!   --Jason ------------------------------------------------------------------------------- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you