I'm working with a group of engineers doing .NET 4 / MVC 3 development, using Windows 7 Enterprise and IIS 7.5 locally, and connecting to MSSQL 2008+ dev/testing databases. The databases are remote but still within the same Active Directory environment.

Our current setup requires our local dev environments to connect to SQL as our individual accounts (e.g. DOMAIN\Paul), and we do that by setting the application pool's credentials to be the same as what we use to login to our workstations. On the database server we have configured a group (e.g. DOMAIN\EngineerGroup) that has the appropriate access to our dev/testing databases. This seems to work reasonably well, except for the inconvenience of having to update our credentials in IIS every time we change our passwords. (Our corporate/group policy enforces that we must change our passwords periodically.)

I was wondering if there are any security risks or other issues associated with using the built-in ApplicationPoolIdentity account instead. I have gotten this to work in an isolated environment by creating a new SQL login that corresponds to DOMAIN\MYMACHINE$ and granting it the same access we've given to DOMAIN\EngineerGroup. My proposal is to create a new Active Directory group, e.g. DOMAIN\EngineerWorkstationGroup, whose members are every engineer's workstation (rather than every engineer's user account), and grant the same access to the new group.

Ideally, I'm looking for some reasonably authoritative articles or documentation (presumably from Microsoft) that details how these MACHINENAME$ accounts are secured, how they might differ from user accounts, and what (if any) additional risks their use would expose us to. The best source I've found so far is an article on iis.net. I've tried numerous searches and haven't really found anything else that discusses trade-offs of using the different AD account types.

Thanks in advance!

P.S. We've also considered using a central domain account (e.g. create a single account like DOMAIN\EngineerAppPool and have everyone connect from IIS to SQL from that account), but I think that makes auditing and profiling more difficult.


I believe this is a strange solution to a common authentication scheme. What is normally done is to have the clients authenticate using their own user/pass and then use impersonation to access the database. To enable this you would have to use trust for delegation and double hop Kerberos authentication (NTLM is not supported)

This way, the application pool may run as a machine account or a service account. The user authenticates using their user/pass (single sign on). The machine account or service account of the app pool is then trusted to impersonate as the user when accessing the database.

You will however have to make changes to your application to get this working.

  • Thanks. My initial suspicion is our application's authentication scheme won't play well with this approach, but I will definitely investigate further. – Paul Karlin May 1 '12 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.