Elevate MSI install while allowing user based actions

Question

Yes, there are many articles related to elevating permissions when installing MSI packages. I have a twist on the issue that I can't find a good answer to. If I'm logged in as a user and I run my MSI elevation code (Below), the package installs but the current user actions are performed on the user I elevated the installer with.
For example, if the MSI adds a file to the CURRENT USER's desktop. The result of elevation (running as "Joe Admin") is the file gets put on Joe Admin's desktop -not the currently logged in user ("Sally User"). I have owned software that Elevates as Joe but puts the file on Sally's desktop as if she installed it. -I'd like to write my own. This is on a Windows 7 Machine, UAC is turned off.

Here is the non-working code. (Sally is logged in, Elevate as Joe -File goes to Joe's Desktop) (LoadUserProfile property was an attempt to solve this issue -didn't work).

    Process watchThis = ImpersonateInstaller(@"c:\temp\Test.msi", "SuperJoePassword");
    watchThis.WaitForExit();       

    private static Process ImpersonateInstaller(string msiPath, string Password)
    {
        Domain d = Domain.GetCurrentDomain();
        Process process = new Process();
        process.StartInfo.UseShellExecute = false;
        process.StartInfo.LoadUserProfile = true;
        process.StartInfo.FileName = @"C:\Windows\System32\msiexec.exe";
        process.StartInfo.Arguments = string.Format(@"/i {0} REBOOT=ReallySuppress /qb-", msiPath);
        process.StartInfo.WorkingDirectory = Environment.GetEnvironmentVariable("WINDIR");
        process.StartInfo.UserName = "JoeAdmin";
        process.StartInfo.Password = new SecureString();
        process.StartInfo.Domain = d.ToString();
        foreach (char c in Password.ToCharArray())
        {
            process.StartInfo.Password.AppendChar(c);
        }
        process.Start();
        return process;
    }

score 1 · Accepted Answer · answered Aug 29 '13 at 18:47

1

From an elevated process call msiexec /jm foo.msi to perform an advertisement. This blesses the package. From a standard user process call msiexec /I foo.msi REBOOT=R /qb and this will start the installation off as the user but elevate seamlessly as needed. Standard Actions and Custom Actions with No Impersonation will run as SYSTEM and Custom Actions with Impeornation will run as the user without privs as designed.

answered Aug 29 '13 at 18:47

Christopher Painter

54,556
6
63
100

Thanks. So, do I call with /jm instead of /i? – Fred B Aug 29 '13 at 18:59
It's a two step process. You call it once using the /jm from an elevated process and then you call it again using /i from a non-elevated process. Make sense? – Christopher Painter Aug 29 '13 at 19:00
Not particularly :) but I'm about to give it a shot. – Fred B Aug 29 '13 at 19:27
Ok.. So it "worked" but I'm using an MSI that I can install as the user without admin rights... I'm trying to dig up an MSI that does require admin rights now. – Fred B Aug 29 '13 at 19:54
That worked great! I don't have high enough reputation here to publish the answer until tomorrow but I will should someone else come looking. THANKS!!!! – Fred B Aug 29 '13 at 20:13
Some badly written MSI's require everything including the InstallUISequence to be elevated. A properly written MSI will work when advertised as managed and invoked with a standard user token. – Christopher Painter Aug 29 '13 at 20:28
I thought I knew a lot about MSIs until now... I've been using them for years, editing them with ORCA, etc. jeez – Fred B Aug 29 '13 at 20:48
Don't feel bad. Most people don't know these commands. If everyone back in the NT4/2K/XP days had tested their installs this way and ran their applications as a non-administrator the migration to Vista and UAC would have for the most part been a non-event. – Christopher Painter Aug 29 '13 at 20:59

score 1 · Answer 2 · answered Aug 30 '13 at 14:37

With Help from Christopher Painter, this appears to be the answer (THANKS CHRISTOPHER!!!) I've read the words "advertise" before and always assumed it had something to do with 'publishing in GPO' so I never follwoed through. Seems I'm wrong. Here's the trick should anyone else run across this.

First, advertise with elevated rights to "bless" the msi for end user installation. In my mind an adminstrator is saying, sure this msi is safe for Sally end user to install:

msiexec.exe /jm install.msi

Then, install as the end user as if they are admin:

msiexec.exe /i install.msi /your /typcial /installOption /switches /here

My code (surely could be better):

        Process advertise = advertiseMSI(@"c:\temp\test.msi", "JoeWhoHasAdminRights", "Joe'sSuperPassword");
        advertise.WaitForExit();
        Process install = installMSI(@"c:\temp\test.msi");
        install.WaitForExit();


    private static Process advertiseMSI(string msiPath, string userName, string Password)
    {
        Domain domain = Domain.GetCurrentDomain();
        Process process = new Process();
        process.StartInfo.UseShellExecute = false;
        process.StartInfo.FileName = @"C:\Windows\System32\msiexec.exe";
        process.StartInfo.Arguments = string.Format(@"/jm {0}", msiPath);
        process.StartInfo.WorkingDirectory = Environment.GetEnvironmentVariable("WINDIR");
        process.StartInfo.UserName = userName;
        process.StartInfo.Password = new SecureString();
        foreach (char c in Password.ToCharArray())
        {
            process.StartInfo.Password.AppendChar(c);
        }
        process.StartInfo.Domain = domain.ToString();            
        process.Start();
        return process;
    }

    private static Process installMSI(string msiPath)
    {
        Process process = new Process();
        process.StartInfo.FileName = @"C:\Windows\System32\msiexec.exe";
        process.StartInfo.Arguments = string.Format(@"/i {0} REBOOT=ReallySuppress /qb-", msiPath);
        process.StartInfo.WorkingDirectory = Environment.GetEnvironmentVariable("WINDIR");
        process.Start();
        return process;
    }

One note... be sure to maintain proper ACL's on the MSI file. If a non priv user can modify an advertised MSI and install / reinstall it, he can use it as an attack vector to get elevated permissions. — Christopher Painter, Mar 25 '15 at 00:19

Elevate MSI install while allowing user based actions

2 Answers2