ASP.NET, Coding

Using Trusted Connections & Impersonation in Web Applications

There are couple of steps that are involved which are outlined below.

Acquire a service account:
In an enterprise world if your application or department doesn’t already have a Service ID, you’ll need to acquire a service account through your Systems Administrator.

Configure the web app to run as this service account:
Open your web.config. Within , then create a new element that reads something like this:

Obviously switching out your real service account name and password. This tells the web server to run your application as that account. Meaning, when you do anything in your application (like access the file system or access a database with a trusted connection) – it will use those credentials instead of NetworkService or IUSR or IWAM, etc.
PLEASE NOTE: The domain name before the service account is needed, you may experience errors if it’s missing. In the example above, “DomainS123456” – “Domain” is needed. This only applies to an Enterprise application where Service ID’s can be used for database connections.

Security considerations to get your service account working:
There are a couple of things that you will likely need to do before your service account will work without issue:

  • Request machines for the lockdown list: all service accounts are now locked down to only work on specific machine names. If you try to use the service account from a machine that is not on the list, you will get a “unknown user or bad password” type message. To fix this, you will need to make a request to have your workstation/servers added to that lock down list.
    • Account lockout for your service account: if you use an incorrect password on any AETH account, it will “lock out”. For service accounts, the account will unlock automaticlaly after 20 minutes, so you need only wait for it to become available again.
    • Forgotten password for your service account: if the password is lost for your service account, the account owner should submit a request to have it reset..
  • Give access to file system: on your workstation, and on the web servers – make sure this service account has read privilege on the on web application directory and on the .NET runtime files under C:WinntMicrosoft.NET.
  • Access to Active Directory: if you service account will need to access users domain group membership, you will likely need to be added to the required network group.
  • Log on as batch: if you experience trouble with running your application, you may need to grant the service account access to log in as a batch process.

Specify to connect to your database with a trusted connection:
Presumably, you have a connection string in your web.config that specifies which server, database, etc to connect to. Instead of passing in credentials in this connection string, you should specify to use a “trusted connection”, which means use the credentials of the “current user”. Since we specified that the website should impersonate the service account, that means that the website will connect to the database server with the credentials of that service account.

You can use the following site to figure out what your specific connection string should be: http://www.connectionstrings.com/ but generally, it should look something like this:

when connecting to a standard SQL 2000 or 2005 server, assuming the server name was “myServerAddress” and the database name was “myDataBase”.

Applying Security:

Now that the application works and runs as this service account, the password needs to be encrypted. This MUST happen before going to production, however it is a good idea to do this in all of your environments as well.

Store the password in the registry on your machine:
Use the command-line utility aspnet_setreg.exe to create the registry key, encrypt the value of the password AND to tell you what you should put in your web.config.

IMPORTANT: the “MyApplicationName” that is specified below should match the same name as your virtual directory name. In other words, your web application sits off the root of a website, under a directory. That directory name, should be the same as the application name specified below.

For example:
aspnet_setreg.exe -k:SOFTWARECompanyNameMyApplicationName -p:#72d2@8273

That will output something like:
Please edit your configuration to contain the following:
 
        password="registry:HKLMSOFTWARECompanyNameMyApplicationNameASPNET_SETREG,password"
 
The DACL on the registry key grants Full Control to System, Administrators, and Creator Owner. If you have encrypted credentials for the  configuration section, or a connection string for the  configuration section, ensure that the process identity has Read access to the registry key. Furthermore, if you have configured IIS to access content on a UNC share, the account used to access the share will need Read access to the registry key.
Regedt32.exe may be used to view/modify registry key permissions. You may rename the registry subkey and registry value in order to prevent discovery.

So as per the section above, I should change my web.config to something like this:

What this does, is tell the ASP.NET run-time to look for the password in this specific registry key. There, the password is stored, encrypted with a key that specific to the current machine. Therefore, this command needs to be run once on every server where the application will live.

Have IIS Admin store the password in the registry on each web server:
In order to be able to push out your changes and have them work on a IIS server, the same command needs to be run on the server. The IIS Admin needs to run “aspnet_setreg.exe” for your website or web application: