How to impersonate a Windows built-in Administrator role for a WinForms, C# App?

Question

It seems like the elevation of privileges is a common thing most developers fight with as most of the time they simply do not have it. I for one do but am fighting with a massive Background Worker routine and I'm trying to keep my code local to the class that will be employing it. Given the amount of code and references my background worker makes once it finishes inside the 'RunWorkerCompleted' handler method its proving diffcult to accept this as a viable alternative:

HOMEWORK 1:

HOMEWORK 2:

HOMEWORK 3:

There is simply too much dependence on my MainForm class by my Background Worker for me to consider shipping out the entire solution into a seperate process with 'Admin' privs. This involves far too much chopping and changing.

Omega Coder:

Having read into CAS for the 70-536 exam, I am aware of most of the terms in this above example but I failed to see how and why it works? Could someone please explain why the permission is granted to 'ManagersOnly' method? As once the PrincipalPolicy is changed to WindowsPrincipal, the next two steps look like ordinary object instantiation statements as posed to something like:

System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal, IPrincipal, IIdentity);

Obviously, no such overload exists, but its very clear in what that overload does.

Question 1: How does OmegaCoders example achieve this effect? Because it definately works as my user is part of the 'BUILTIN\Administrators' group. I'm looking for a literature based answer so go to as much detail as you feel.

UPDATE 1:

Question 2: How would I revert the PrincipalPolicy back to what it was before ... once the method returns I do not need the PrincipalPolicy still being set to 'WindowsPrincipal'??? So that application can carry on running as a lower privileged user as I intended.

Question 3: Once the 'ManagersOnly' method returns, is the permission discarded? Is it scoped to the life of the Method?

System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.NoPrincipal);

*UPDATE 2: *

This is proving difficult, as on my Win7 Pro dev machine I can test and run anything but when I tried testing out some code on a simple Win7 Home laptop I found out that permissions were being denied. Which begs the questions changing the PrincipalPolicy to 'WindowsPrincipal' does not work for all vista and Win7 users as many wont even be part of the admin user group. So this option is useless... Sitting on this small laptop its becoming pretty obvious that is not the solution I need.

IGNORE PREVIOUS Qs - with my own researh I have done they are not feasible.

Question 4: how does one go about impersonating an administrator programmatically and temporarilly in code?

Answer 1

The short answer is NO.

It seems like after all the digging round I have been doing there does not seem to be a progromattic way of elevating a method's permissions as CAS compliments RBS so if the user is not part of the right group. Then there is no point is even accessing for admin rights as rbs tells cas that the user is not part of the group so the request is bounced and permission is denied. Resulting in an exception.

If the user is part of the group you need i.e Administrators, then changing the Domains PrincipalPolicy will give you a temprary solution but it does not cater for users that are simply not part of the admin user groups. Thats where the above solution falls apart.

The long answer is, ship out the problem prone code into a small seperate .exe file and run it seperately.