CODEWITHSUNDEEP
asp.netvb.net
w0051977
w0051977

Reputation: 15787

Hiding passwords for impersonation

The following webpage talks about using impersonation in code (ASP.NET): http://support.microsoft.com/kb/306158. I am thinking about creating a class for the code, then the application can call impersonateValidUser and undoimpersonation.

I am concerned about putting usernames and passwords in my code as surely anyone will be able to see them using a tool like ILDASM. What is the best way to hide these passwords?

The article has a section titled: Impersonate the IIS Authenticated Account or User. I thought about creating an impersonated user in the Web.Config, but this would mean that the entire application is run as the inpersonated user. I only want a very small part of the application to run as the impersonated user - when it is necesary to access and update active directory.

Upvotes: 2

Views: 1169

Answers (1)

Anders Abel
Anders Abel

Reputation: 69260

I really like your intention to have have only the part of the application that does the AD updates running under a highly privileged account. I also share your concerns about storing the password in the web.config or in the code.

I can think of two options for you.

  1. Store the account details in the web.config and encrypt that part of the web.config. That will ensure that only an administrator of the web server can get hold of the password. Someone else getting hold of the web.config won't understand a thing of the password.

  2. Create a small, separate WCF service with the AD update code. Then run that WCF service in a separate application pool, with the app pool set to the identity of the user that has access to the active directory. Setup a restricted, localhost-only endpoint for the WCF. The WCF service should have access control to only allow access from a dedicated account. That account should be set as the identity of the app pool of the main web site.

Option 1 is easier to implement and protects the password rather well. Option 2 offers better protection for the passwords as they are not stored in the web.config at all - they are part of the IIS configuration. Option 2 also adds complete isolation between the privileged code and the rest of the system as it runs the AD update code in a separate process. With that isolation, it is much easier to make a code review for the AD code to check for security issues.

Upvotes: 1

Related Questions