Click here to Skip to main content
15,889,347 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I'm about to throw myself off a building over this.

I support a few hundred users of a particular application that is updated frequently - said updates involving nothing more than replacing the main .exe with a new version. I've written a dashboard for myself that allows me to stage the new version in advance, push it out on the night of the upgrade, rollback, etc. But I've always wanted to write a simple wrapper that sits on the users' desktops and allows them to swap out the .exe on their own.

Problem is that company policy forbids the users from having write rights to the application directory.

So I've tried various types and forms of impersonation in VB - console and form applications - and, though I think I've done everything exactly as instructed in various blogs and by Microsoft, and although stepping through the programs indicates that I have indeed impersonated a user with admin rights on all of the machines, when a regular user runs the code, it fails to copy the new file, throwing the error that "the user doesn't have rights to the directory."

The heart of the code, which anyone who's ever tried to do this will probably recognize, looks like this:
VB
Using safeTokenHandle
    Dim success As String
    If returnValue Then success = "Yes" Else success = "No"
    TextBox1.Text += "Did LogonUser succeed? " & success & vbCrLf
    TextBox1.Text += "Value of Windows NT token: " & safeTokenHandle.DangerousGetHandle().ToString() & vbCrLf

    ' Check the identity.
    TextBox1.Text = "Before impersonation: " & WindowsIdentity.GetCurrent().Name & vbCrLf

    ' Use the token handle returned by LogonUser.
    Using newId As New WindowsIdentity(safeTokenHandle.DangerousGetHandle())
        Using impersonatedUser As WindowsImpersonationContext = newId.Impersonate()

            ' Check the identity.
            TextBox1.Text += "After impersonation: " & WindowsIdentity.GetCurrent().Name & vbCrLf
            System.IO.File.Copy("\\MyServer\SourceFiles\TheProgram.exe", "c:\Program Files\AppDirectory\TheProgram.exe", True)

            ' Free the tokens.
        End Using
    End Using
End Using


The text box updates do indeed show that the file.copy code is being run under the newID, but the copy still fails with a rights issue.

What the heck am I missing?
Posted
Comments
Duncan Edwards Jones 18-Nov-15 9:02am    
I don't see where you are setting the current principal for the running thread (although this may be elsewhere in the code)...

See: https://msdn.microsoft.com/en-us/library/system.threading.thread.currentprincipal(v=vs.100).aspx
TheUFFP 18-Nov-15 10:33am    
I added the following lines to the interior Using block:

Dim wp As New WindowsPrincipal(WindowsIdentity.GetCurrent())
Thread.CurrentPrincipal = wp

Also added a text output to verify that the thread.currentprincipal was the impersonated user (the one with rights), and it shows that it is. Still getting the same rights issue, though. When run on a regular user's machine, it shows that the thread's currentprincipal is ME, but the copy fails.
Pascal-78 18-Nov-15 12:00pm    
Since Windows Vista, some operation needs "Elevated Privileges" even if done by the administrator account. Those operations usualy display a message asking for allowing the program to make changes to the system.
To check this, you may use the runas command to start a new cmd.exe with the new user Id and test if the copy is ok, and if not you can try to start a new cmd.exe with a right click and "run as administrator", it should prompt for a user with admin rights but it will also use elevated privileges... You may have more details by looking the UAC (User Account Control)

1 solution

Several years ago I had a similar problem. If I recall correctly I was able to change the permission problem by altering the Group Policy.
The setting I changed was Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - User Rights Assignment - Act as part of the operating system.
It might not be very safe, though...
 
Share this answer
 
Comments
TheUFFP 18-Nov-15 13:23pm    
I'd totally do that - except I'd probably get fired for it. ;)

Going to try opening a cmd process with runas, as suggested by Pascal, and see if I can get that to work. Seems logical enough to me.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900