0

I'm upgrading an ASP.NET 4.0 app from:

Windows Server 2003 and IIS 6

to:

Windows Server 2008 and IIS 7.5

This app is based on ASP.NET Web Forms and not MVC. I currently use SQL authentication, but I would like to follow best practices in the new environment.

Both the IIS 7.5 machine and the SQL Server 2008 machine will reside in a DMZ with its own domain controller. It would be nice if we could use similar connection strings for Dev, Test and Prod environments. What's the best practice for this situation? I've read about three options.

  1. ApplicationPoolIdentity
  2. Create your own service account on the domain
  3. SQL authentication

Here are links to questions that discussed related issues, but nothing seemed to answer my specific question.

User ASP.NET Runs Under

Assign Permissions to ApplicationPoolIdentity Account

Community
  • 1
  • 1
jtherkel
  • 139
  • 1
  • 1
  • 11

2 Answers2

1

I recommend AD account for running the app pool. Then, permissions can be created at SQL server for that same account. The conn string used by the app will then not have to contain account info at all (trusted connection), and you will have one less thing to worry about related to security. As additional precaution, remove that AD account from all user groups, and don't use it for anything else but for this one thing (the app pool). Give that user read access to website files, and write access only to folders that it needs to write to (e.g. to dump log files).

  • Thanks, I think this answers my question, but I still have a concern. Microsoft went to a lot of trouble to create the ApplicationPoolIdentity construct. Why would they bother if it makes sense to create an AD account for each app pool anyway? What are the trade-offs between the AD account and ApplicationPoolIdentity? – jtherkel Feb 02 '12 at 18:11
  • Not everybody has AD setup. Then, not every website will use network-shared folders and/or MS SQL server (etc). –  Feb 02 '12 at 18:24
  • I would assume that ApplicationPoolIdentity has less permissions on the system (the OS), compared to any other user (e.g. when one is created manually), and that this spawns further than accessing files on the disk (e.g. maybe it has access only to what matters to asp.net, on disk, registry, etc). –  Feb 02 '12 at 19:50
  • thanks; to make it as secure as it can be, when using AD account for this, remove it from all groups (by default, AD accounts are at least in "domain users" group), don't even add it to local guests group, and specifically allow permissions to folders on disk (on the web box) that matter to the app (website files, and any out-of-website-files-folder that the app reads or writes to). –  Feb 02 '12 at 21:36
  • Obviously, strong password. Although in closed environment it's less likely that somebody will hack your server/app by knowing the username and password, but if your app has a bug where that account can mess up things (e.g. delete unrelated files on the server), then it helps to not make it be a part of admin group (for example; I've seen that). –  Feb 02 '12 at 21:38
0

As far as best practices is concerned, I don't think any of the 3 options you listed is better over the other one; all of them can do the job securely and efficiently if used correctly. Your decision should be based on which of those offers advantages to you considering your particular environment, company policies, etc., but again, none of them are bad practice.

Icarus
  • 63,293
  • 14
  • 100
  • 115