RE: Impersonation / access rights for application

• Previous message: Frederic P.: "GetNamedSecurityInfo VS GetFileSecurity"
• In reply to: Matthew Townsend: "RE: Impersonation / access rights for application"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Sat, 25 Jun 2005 21:33:01 -0700

Try a COM+ component. The component is a basic COM but when properly setup in
COM+, it will be called like a DCOM and can be configured to run in the
account of your choice (including system account).

It's a cleaner approch since you keep control of what is going wrong. By
modifying Windows security, you are creating a breach. Also, it allows you to
use the standard API which have better chances to be portable.

Another plus is it allows you to create a clear separation between your
business logic and your GUI.

Fred.

"Matthew Townsend" wrote:

> Shortly after posting this I thought of another solution and it worked.
>
> All the microsoft power API really does is edit the registry.
>
> So I set the permissions to the power settings key in the registry via my
> service and then set them back when I am done with my power settings changes.
>
> Works great.
> --
> Matthew Townsend
>
>
> "Matthew Townsend" wrote:
>
> > 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

• Previous message: Frederic P.: "GetNamedSecurityInfo VS GetFileSecurity"
• In reply to: Matthew Townsend: "RE: Impersonation / access rights for application"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]