Article ID: 891031 - View products that this article applies to.
ASP .NET Support Voice Column: Common security issues when you access remote resources from ASP.NET applicationsTo customize this column to your needs, we want to invite you to submit your ideas about topics that interest you and issues that you want to see addressed in future Knowledge Base articles and Support Voice columns. You can submit your ideas and feedback using the Ask For It
(http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=)form. There's also a link to the form at the bottom of this column.
Hello again and welcome to the October '04 edition of the Support Voice Column. I would like to thank Mike Clay for his contributions. Mike has been a Developer Support Engineer with Microsoft for over five years. He is very experienced in Internet technologies as he started off supporting legacy ASP Scripting and Visual Studio 6, and currently supports ASP.NET. Mike also participated in the beta for the .NET 1.1 Framework (Everett). He doesn’t get too far from Microsoft products--in his free time, he plays lots of Xbox.
So pull up a chair, kick of your shoes, and read through our column all about common security issues when you access remote resources from ASP.NET applications. And remember, you can submit your ideas to us using the "ASK FOR IT" link included in every column we publish.
Common security issues when you access remote resources from ASP.NET applicationsIt is very common for developers to remotely access file shares, Web services, databases, or other resources from ASP.NET applications. This is typically a file server or database server separate from the Web server where the application is running. However, for this to work as expected, there are some very important security considerations to know about with regard to ASP.NET process identity, authentication, and permissions. We’ll explore some of these key concepts and possible resolutions. Which option will work best for a particular scenario will depend on your application architecture and security requirements.
The first and most important concept to consider is how the ASP.NET process and thread identity works. When the .NET Framework is installed on a Web server, it creates a low-privileged, local account named ASPNET, or on Microsoft Internet Information Services (IIS) 6.0, the NETWORK SERVICE account. By default, the ASP.NET worker process identity runs in the context of this account. Even more important is to understand that this is a local account. Let’s look at an example:
If we have a Web server (Server A) that runs an ASP.NET application that tries to access a file share on a second server (Server B), with default ASP.NET and IIS configurations, this will generate an
error. If you are trying to access a remote SQL server computer, you may get a
error. In either case, the root cause is the same--Server B cannot authenticate an account local to another server. By default, the thread identity trying to access Server B will run in the context of the local ASPNET account of Server A. This thread identity we are referring to is the WindowsIdentity.GetCurrent.Name property, which represents the Windows logon identity under which the current code is executing. Here are some common workarounds to this issue:
“Login failed for user 'MachineName\ASPNET”
(http://support.microsoft.com/kb/329290/ )How to use the ASP.NET utility to encrypt credentials and session state connection strings
For additional information on this topic, see the following resources: