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.