March 25, 2005

Deploying ASP.NET Apps with Integrated Security

At work we're in the midst of deploying an ASP.NET application using Integrated security (using impersonation - <identity impersonate ="true"\> is the tag, btw). This allows us to develop the application securely using Windows accounts, and make use of the security features of the Operating system, including integration with SQL Server 2000 and the Active Directory groups, etc... In deploying it to a new server, I was locking down the application directories to ensure that only the people who needed to access the application could get to it, and I found out something when I locked it down too far. and why are you using a domain controller as a web server, you naughty geek?!?
You see, ASP.NET needs to recompile the application into a DLL before it starts executing the code (it checks for things like changes to the aspx files before starting up). But if you're using Imersonation, the ASPNET account is not the account being used for this compile operation. Instead, it's the 'NETWORK SERVICE' account, which will need access to the entire application for checking for changed files, and write access to the binaries directory for writing out the .dll. The error you'll get if this problem applies to you is something along the lines of "Access Denied to .[your app path]\ web.config'. Failed to start monitoring file changes.". The fix is to permit 'NETWORK SERVICE' account (local account except on domain controllers - and why are you using a domain controller as a web server, you naughty geek?!?) read access to your entire web site, and write access to where the compiled code is.
Using Integrated Security for your web applications is a good way to build security deep into the site when using SQL Server or other integrated database product. It allows security to pervade the very core of your code, rather than provide only an entry mechanism to your web site. You can and should lock users out of things that they shouldn't have access to, even if your code doesn't allow them to execute code. New bugs, buffer overflows, viruses, and the law of unintended consequences will come back to bite you in the ass if you're not careful, and it's better to apply security at all levels of your design.

No comments: