Re: Running a program with elevated priveleges

From: Valery Pryamikov (valery_at_harper.no)
Date: 04/12/05

  • Next message: jblo: "Re: Cannot open log for source {0}. You may not have write access. (Access right wanish after a while)" 
    Date: Tue, 12 Apr 2005 08:10:16 +0200

    "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote
    > "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote
    >>I need to create a program that will run under a common user profile but
    >> which will need to be able to perform some file IO tasks that the user
    >> doesn't have the rights to perform. I can get this done with
    >> impersonation
    >> but I can't figure out how to avoid storing the password in plain text
    >> inside
    >> the executable, which is not acceptable.
    >
    > A few other options:
    >
    > 1. Ask the user.
    > 2. Store the password elsewhere.
    > 3. Call into another component (e.g.: COM+ application) running under
    > another user context.
    >
    > My own general preference is for #3, but the best choice for your
    > application will depend on quite a few details like target OS version(s),
    > tolerable user experience, etc. Storing the password anywhere (encrypted
    > or not) is usually the riskiest option and should probably be avoided if
    > at all possible.

    The thing that you should be aware about with #3 is that COM+ stores
    passwords unencrypted in LSA secrets. Administrators can simply read clear
    text password from LSA secret associated with your COM+ application. So, for
    COM+ - the recommendation would be to use some account that has logon as
    batch job right (or logon as service if you run your COM+ application as
    service) and no logon locally rights for being sure that nobody uses it as
    his/her normal logon account.

    -Valery.
    http://www.harper.no/valery

  • Next message: jblo: "Re: Cannot open log for source {0}. You may not have write access. (Access right wanish after a while)"