Impersonating User Accounts


Impersonating User Accounts

When you requested pages with Classic Active Server Pages, the page executed with the permissions of the user making the request. In other words, in Classic Active Server Pages, each request impersonated a user account. For example, if you requested a page while logged in under the Administrator user account, the requested Active Server Page executed with the permissions of the Administrator account. If you requested an Active Server Page anonymously, the Active Server Page executed under the IUSER_ MachineName account.

By default, ASP.NET does not impersonate the user making a request. An ASP.NET page executes with the permissions of the ASPNET account. The ASPNET account was added to your server when you installed the .NET Framework.

This means that an anonymous user has the same permissions as the ASPNET account. If you grant the ASPNET account sufficient permissions to delete all the files on your hard drive, then an anonymous user can request a page that deletes all the files on your hard drive.

NOTE

A fresh install of the Windows 2003 operating system will use the NETWORK SERVICE account instead of the ASPNET account. If you configure IIS 6.0 (The version of IIS included with Windows 2003) to use IIS 5.0 Isolation mode, then Windows 2003 will use the ASPNET account.


You can modify this default behavior by enabling client impersonation. By default, this option is disabled in the Machine.Config file. You can modify the impersonation setting in the Machine.Config file, or you can override this setting in a Web.Config file located in an application root directory. For example, the Web.Config file in Listing 20.8 enables impersonation.

Listing 20.8 Impersonate\Web.Config
 <configuration>   <system.web>     <identity impersonate="true" />   </system.web> </configuration> 

The C# version of this code can be found on the CD-ROM.

NOTE

All the files in this section are located in the Impersonate directory on the CD that accompanies this book.


You can test the difference between enabling and disabling impersonation by using the file in Listing 20.9.

Listing 20.9 ReadDirectory.aspx
 <%@ Import Namespace="System.IO" %> <% Dim objDir As New DirectoryInfo( MapPath( "testDir" ) ) Dim objItem As FileInfo For Each objItem in objDir.GetFiles( "*.*" )   Response.Write( "<li>" & objItem.Name ) Next %> 

The C# version of this code can be found on the CD-ROM.

The ASP.NET page in Listing 20.9 displays all the files in a subdirectory named testDir . Imagine that the testDir directory can be accessed only by the ASPNET account. In that case, if you enable impersonation, you receive an error if you attempt to execute the ReadDirectory.aspx page. On the other hand, if you disable impersonation, the page executes just fine.

CAUTION

If you enable impersonation, the account being impersonated must have read and write permissions on (at least) the following two directories:

 
 \WINNT\Microsoft.NET\Framework\[  version  ]\Temporary ASP.NET Files\ \WINNT\Assembly 

The first directory contains compiled ASP.NET pages, and the second directory contains the global assembly cache.


Executing ASP.NET Pages under a User Account

As I discussed in the preceding section, by default, if request impersonation is disabled, an ASP.NET page executes using the ASPNET account. If you prefer, you can execute ASP.NET pages under a different user account by changing the account assigned to the ASP.NET process or by changing the account assigned to an individual ASP.NET application.

In order to change the ASP.NET worker process, you need to modify the Machine.Config file (located at /WINNT/Microsoft.NET/Framework/[ version ]/Config ). Open the Machine.Config file in Notepad and find the processModel section.

The processModel section includes the userName and password attributes. These attributes determine the account under which the ASP.NET worker process executes. By default, userName is assigned the value machine and password is assigned the value AutoGenerate . The special value machine indicates that the ASPNET user account is used for the ASP.NET worker process. You can also use the special value SYSTEM to indicate that the local system account should be used for the ASP.NET process.

The advantage of using the local system account for ASP.NET is that the local system account is very powerful. If you use local system for ASP.NET, then you never have to worry about granting such permissions as write permissions on a directory. The disadvantage , however, is evil code could wreak havoc on your server. There is nothing to prevent an ASP.NET page running under the security context of the local system account from deleting all the files from your hard drive.

NOTE

The Beta versions of ASP.NET all ran under the local system account by default. At the last moment, before releasing the final version of ASP.NET, Microsoft switched the default account to the ASPNET account.


Changing the account associated with the ASP.NET process modifies the account used by all ASP.NET applications on a machine. However, you might need to modify the security account associated with a particular application.

You might want to execute pages under a different account if you are hosting multiple ASP.NET applications on your Web server and you do not want one application to have access to the files in another application. You can configure the applications to run under distinct user accounts.

NOTE

You can lock down configuration settings in the Web.Config file. You need to do so when hosting untrusted applications to prevent users from modifying their security settings. For more information, see Chapter 15, "Creating ASP.NET Applications."


You specify a particular account for executing ASP.NET pages by modifying either the Machine.Config file or an application root Web.Config file. For example, the Web.Config file in Listing 20.10 would cause all ASP.NET pages to execute under the George user account. (This file is located in the ASPNETAccount directory on the CD that accompanies this book.)

Listing 20.10 Web.Config
 <configuration>   <system.web>     <identity       impersonate="true"       userName="YourDomain\George"       password="secret" />   </system.web> </configuration> 

The C# version of this code can be found on the CD-ROM.

The value of userName and password must correspond to a valid Windows user account. This Web.Config file causes ASP.NET pages to execute under the George user account regardless of the identity of the client who requests the page.

CAUTION

If you execute ASP.NET pages under a particular account, the account must have read and write permissions on the following two directories:

 
 \WINNT\Microsoft.NET\Framework\[version]\Temporary ASP.NET Files\ \WINNT\Assembly 

The first directory contains compiled ASP.NET pages, and the second directory contains the global assembly cache.


You can display the account that an ASP.NET page is executing by requesting the page in Listing 20.11.

Listing 20.11 ShowAccount.aspx
 <Script Runat="Server"> Sub Page_Load()   lblAccount.Text = System.Security.Principal.WindowsIdentity.GetCurrent().Name End Sub </Script> <asp:Label id="lblAccount" Runat="Server" /> 

The C# version of this code can be found on the CD-ROM.



ASP.NET Unleashed
ASP.NET 4 Unleashed
ISBN: 0672331128
EAN: 2147483647
Year: 2003
Pages: 263

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net