User Impersonation on Win XP SP2

[JaredHite1]

I agree that the problem he's having right now is not related to the
solution I posted...Your advice of getting the process info before
impersonating is sound. What I'm saying is that even if he fixes his
current issue, a much larger one looms...Once the process is started,
it will be happily running under the process' permissions, not the
impersonated thread's, so he needs to consider another approach
altogether.

Jared

 

[Willy Denoyette [MVP]]

|I agree that the problem he's having right now is not related to the
| solution I posted...Your advice of getting the process info before
| impersonating is sound. What I'm saying is that even if he fixes his
| current issue, a much larger one looms...Once the process is started,
| it will be happily running under the process' permissions, not the
| impersonated thread's, so he needs to consider another approach
| altogether.
|
| Jared
|

That's true, that's why I'm a bit scared when people start to impersonate an
admin, I always wonder why they need it, and most of the time they don't.
The same, here, now I see what the OP is trying to achieve, the only
solution, is or calling "runas.exe" through Process.Start or trying to use
System.Management and WMI, which is not guaranteed to be succesfull because
of a security issue in v1.1.

Willy.

 

[vipleo]

Interesting points, codefealls..
The reason I want to impersonate the admin is that app user doesn't
have write permission on app install dir and app uses auto-update
mechanism to get latest files from network share on start-up. Xcopy of
latest dlls is being done within app; so If exe itself need to be
updated, another copier exe will be launched to finish auto-update.

I didn't get chance to try your suggestion, willy.

I will try it today and post results.

Thanks for your help guys...

~ViPuL

 

[vipleo]

Interesting points, codefealls..
The reason I want to impersonate the admin is that app user doesn't
have write permission on app install dir and app uses auto-update
mechanism to get latest files from network share on start-up. Xcopy of
latest dlls is being done within app; so If exe itself need to be
updated, another copier exe will be launched to finish auto-update.

I didn't get chance to try your suggestion, willy.

I will try it today and post results.

Thanks for your help guys...

~ViPuL

 

[vipleo]

Good news & bad news..

Good news first, anothe exe is being launched with willy's suggestion
to get process info before doing impersonation.
But....(bad news begins), exe is getting following exception:

System.TypeInitializationException: The type initializer for
"System.Runtime.Remoting.Identity" threw an exception. --->
System.Security.Cryptography.CryptographicException: CryptoAPI
cryptographic service provider (CSP) for this implementation could not
be acquired.
at
System.Security.Cryptography.RNGCryptoServiceProvider..ctor(CspParameters
cspParams)
at System.Security.Cryptography.RNGCryptoServiceProvider..ctor()
at System.Runtime.Remoting.Identity..cctor()
--- End of inner exception stack trace ---
at
FHEG.Framework.AppUpdater.CopyFilesDelegate.BeginInvoke(AsyncCallback
callback, Object object)
at FHEG.Framework.AppUpdater.ProgressForm.BeginCopy()
at
FHEG.Framework.AppUpdater.ProgressForm.ProgressForm_Activated(Object
sender, EventArgs e)
at System.Windows.Forms.Form.OnActivated(EventArgs e)
at System.Windows.Forms.Form.set_Active(Boolean value)
at System.Windows.Forms.Form.WmActivate(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32
msg, IntPtr wparam, IntPtr lparam)

 

[Willy Denoyette [MVP]]

| Good news & bad news..
|
| Good news first, anothe exe is being launched with willy's suggestion
| to get process info before doing impersonation.
| But....(bad news begins), exe is getting following exception:
|
| System.TypeInitializationException: The type initializer for
| "System.Runtime.Remoting.Identity" threw an exception. --->
| System.Security.Cryptography.CryptographicException: CryptoAPI
| cryptographic service provider (CSP) for this implementation could not
| be acquired.
| at
| System.Security.Cryptography.RNGCryptoServiceProvider..ctor(CspParameters
| cspParams)
| at System.Security.Cryptography.RNGCryptoServiceProvider..ctor()
| at System.Runtime.Remoting.Identity..cctor()
| --- End of inner exception stack trace ---
| at
| FHEG.Framework.AppUpdater.CopyFilesDelegate.BeginInvoke(AsyncCallback
| callback, Object object)
| at FHEG.Framework.AppUpdater.ProgressForm.BeginCopy()
| at
| FHEG.Framework.AppUpdater.ProgressForm.ProgressForm_Activated(Object
| sender, EventArgs e)
| at System.Windows.Forms.Form.OnActivated(EventArgs e)
| at System.Windows.Forms.Form.set_Active(Boolean value)
| at System.Windows.Forms.Form.WmActivate(Message& m)
| at System.Windows.Forms.Form.WndProc(Message& m)
| at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
| at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
| at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32
| msg, IntPtr wparam, IntPtr lparam)
|

As was said before, when impersonating, you are only running the thread in
the impersonated context, not the process that you spawn from this thread,
that's exactly why I asked why you were impersonating.
The result is that:
1. won't be able to copy to the .exe directory, and
2. apparently the application you start this way needs to access the crypto
store of the administrator, which is impossible because, the store (assumed
it's registry based) is not loaded and if it was you won't be able to access
it anyway.

Really, the only thing you can do (on v1.1) it create the process to run as
an administrator by calling CreateProcessAs through PInvoke, or better
integrate the "update" into your application (while impersonating). But
honestly, do you really want to take all this overhead when starting a
client application, just because you do not want to grant write access to
the .exe directory?
Do you think, this is a real security measure? I would say it's not, think
of what can happen when the process crashes when impersonating an
administrator!

Willy.

 

[vipleo]

I was able to launch another exe successsfully using CreateProcessAUser
but ran into other issue. So I gave up.

Thanks a lot for your help guys. I really appreciate it.

~ViPuL

 

[JaredHite1]

I remember trying createprocessasuser and not having any success
either...

I still think your best bet is to do File.Copy operations while
impersonating. In my case, I didn't have the option of granting the
user write rights to the folder since it was in an enterprise
environment where all that stuff was way out of my control.

Good luck,
Jared