locked
best practices for elevating permissions in a C# win forms application RRS feed

  • Question

  • Hi,

    Here is the situation.  I am working to create a windows forms application which allows various help desk personnel to view active directory and powercampus (a sql db) data for users.  The program must also be able to reset users passwords.  It will be installed on multiple desktop machines on our network.

    This requires a certain level of permissions which we do not want to give to the Active Directory accounts of the personnel who will use it.

    My working solution in this case is to create an Active Directory account for the application, give that account the necessary permissions and then have the application impersonate this account when it needs elevated permissions.  I'm using advapi32.dll-LogonUser.  The username and password for the account are hard coded into the program.

    My question is, how do i do this better?  Is there some other way to give the application elevated permissions without giving those permissions to the users.  Is there a better way to impersonate an active directory account.  Last, i know that hard coding the username and password is not very secure.  I would prefer to encrypt the information somehow, but then the program must have the key to decrypt, which is only 1 step removed from what i have now.  how can i safely and simply encrypt the account password?

    Thanks

    Wednesday, October 20, 2010 4:03 PM

All replies

  • In general there's no good approach to protecting a hard-coded password, not least because it's rather hard to change if compromised.

    An alternative approach would be to create a service which runs under your special AD user account and is started automatically, which avoids having to store the password in the program at all. 

    The windows forms application your users use would then request this service to perform the privileged operations.

    The service would have to

    • perform only the specific operations requiring privilege;
    • authenticate and audit all requests for these operations.

    Where this service actually resides is for you to decide.

    This would be similar to the mechanism described in the section headed The Back-End Service Model in Windows Vista Application Development Requirements for User Account Control Compatibility (long).


    Answering policy: see profile.
    Friday, October 22, 2010 9:19 PM
  • Thanks for your reply.  I will take a look at the link you provided.  Maybe it will give me an idea.  I was sure that there had to be a way to simply implement this.  Though i guess simple problems don't always have simple solutions.  A service seems like a maintenance nightmare, introducing too many things that could go wrong.

    I do have one question for you right now.  How would you implement authentication in this scenario without ending up with the same issue:  some sort of hard coded or otherwise vulnerable piece of information held by the application. 

    Thanks again. 

    Friday, October 22, 2010 10:15 PM
  • Thanks for your reply.  I will take a look at the link you provided.  Maybe it will give me an idea.  I was sure that there had to be a way to simply implement this.  Though i guess simple problems don't always have simple solutions.  A service seems like a maintenance nightmare, introducing too many things that could go wrong.

    I do have one question for you right now.  How would you implement authentication in this scenario without ending up with the same issue:  some sort of hard coded or otherwise vulnerable piece of information held by the application. 

    Thanks again. 

    I'm assuming that by 'in this scenario' you mean your original scenario where the application somehow unlocks the credentials for the impersonation, not the service scenario.

    I think I'd consider encrypting the impersonation details on a per-user basis and store the data in the user's AD entry. This has the advantage of being able to revoke access very quickly (by deleting the data).

    The encryption could be performed either using a user-specific passphrase (although this would need additional tools to manage) or, if you have issued suitable PKI certs to the users, could use the user's public key for encryption, so that the user would need to use the corresponding private key.

    At the point where the application needs to perform the impersonation, it would retrive the encrypted impersonation data from the user's AD entry and either use the private key to decrypt it (which may require user interaction) or prompt the user to provide the necessary passphrase.

    This is a fairly broad-brush description.  In particular, I've avoided talking about specific algorithms.  If you need input on that, please ask again, giving the range of OS versions to be covered.


    Answering policy: see profile.
    Saturday, October 23, 2010 11:32 AM
  • I've given it some thought and i really like the idea of a service which would be deployed with the forms application.  But i'm unsure what is the best way to have the two communicate with each other?  How would i set that up securely?
    Tuesday, October 26, 2010 5:05 PM
  • You are likely to end up with some kind of RPC mechanism.

    The articles below .NET Remoting may help get you started, particularly .NET Remoting Authentication and Authorization Sample - Part I


    Answering policy: see profile.
    Tuesday, October 26, 2010 6:18 PM
  • Which of course means you need to take great care in designing your interface, such that it can't be used for evil, as you must assume evil RPC clients.
    Tuesday, October 26, 2010 8:37 PM