Impersonation / access rights for application

From: Matthew Townsend (MatthewTownsend_at_discussions.microsoft.com)
Date: 06/22/05 

Date: Wed, 22 Jun 2005 10:09:03 -0700

We are developing a power management application. We want our customers to
be able to use it from a limited account if their IT department permits it.
To do this our application needs to have access rights to change power
management settings.

Solutions we have tried (and failed):
1) Write a service that runs as SYSTEM and have it start our application
when told to do so... This starts our app fine but it does not display on
the limited user's desktop. It does show up in the process viewer however so
we know it is running. Any idea how to get it to show up for the limited
user while still running under the SYSTEM user?

2) Write a service that runs as SYSTEM then passes a duplicate
WindowsIdentity.Token object to our application which then can impersonate
the higher level user. This does not work in two ways. First, the
WindowsIdentity.Token does not seem to work for a System user. Second, even
if I try it from another application when I pass the token to the other
process it is no longer valid. My guess is that acces tokens are processor
specific? Any idea if it is possible to pass an access token from one
process to another?

3) Using "run as" when running the application, this works however, you must
do this everytime you run it and it requires the limited user to know the
user name and password of an administrator account.

4) Using task scheduler and running it as an admin user, this runs the app
but has the same problem as 1 in that the limited user is not displayed the
GUI. Again, is there a way to get it to show up for the limited user but
still run with the permissions of an admin user?

5)Storing the user name as password of an administrator somewhere in our
application and then calling LogonUser to get token, duplicating said token,
and then impersonating the user. This works great but there are fundamental
issues: a) Our customers definitely would not want us putting an admin user
on their system and would delete it.
b) Given a, we would not know that admin username and password and thus our
customer's IT dept. would have to setup the user name and password in our
application (something which they would not like to do I would imaging).
c) Storing a user name and password of an admin user in our application
would require us to be much more rigid security wise which we would prefer to
avoid. 

-- 
Matthew Townsend