Tài liệu Module 4: Internet Information Services Authentication docx

Module 4: Internet
Information Services
Authentication
Contents
Overview

1

Lesson: Introduction to Web Client
Authentication

3

Lesson: Configuring Access Permissions
for a Web Server

16

Lesson: Selecting a Secure Client
Authentication Method

25

Lesson: Running Services As an
Authenticated User

45

Review

54

Lab 4: Authentication and Access Control

56


Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property..
 2002 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, ActiveX, Active Directory, Authenticode, Hotmail,
JScript, Microsoft Press, MSDN, PowerPoint, Visual Basic, Visual C++, Visual Studio, and
Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.


Module 4: Internet Information Services Authentication

iii

Instructor Notes
Presentation:
75 minutes
Lab:
30 minutes

This module provides students with information about the Web client
authentication methods that are supported by Internet Information Services
(IIS) and Microsoft® Windows® 2000 Server. Initial Web client authentication
and the flow of user identities through the Web application are the focus of this
module. After completing this module, students will be able to select the best
IIS authentication method for a given set of requirements.
After completing this module, students will be able to:
!

!

Use Information Protocol (IP) address and domain name restrictions, and
IIS Web-based permissions, to effectively control who can access the
resources on a Web server.

!

List and explain all of the authentication methods that are supported by IIS
and select the best method for a given set of requirements.

!

Required materials

Explain how Web client authentication is used to pass user identity through
a Web application.

Explain how the identity of an authenticated Web client is mapped to a
Windows 2000 user identity and passed to Web applications and COM+
components.

To teach this module, you need the following materials:
!
!

Preparation tasks

Microsoft PowerPoint® file 2300A_04.ppt
Hypertext Markup Language (HTML) and Flash animation files:
2300A_04_A05_1570.htm, 2300A_04_A05_1570.swf

To prepare for this module:
!

Read all of the materials for this module.

!

Complete the demonstrations and lab.

!

Read Module 5, “Implementing Security on a Web Server,” in Course 2295,
Implementing and Supporting Microsoft Internet Information Services 5.0.

!

Read Module 12, “Configuring a Web Server,” in Course 2153,
Implementing a Microsoft Windows 2000 Network Infrastructure.

!

Read the article “Principal and Identity Objects” in the Microsoft .NET
Framework documentation.

!

For background information on COM+ and role-based security, see Course
2557, Building COM+ Applications Using Microsoft .NET Enterprise
Services.

!

Read the Microsoft MSDN® Magazine article, “An Introductory Guide to
Building and Deploying More Secure Sites with ASP.NET and IIS,” which
is available at />ASPSec/ASPSec.asp.


iv

Module 4: Internet Information Services Authentication
!

Read the MSDN Magazine article, “Web Security: Part 2: Introducing the
Web Application Manager, Client Authentication Options, and Process
Isolation,” which is available at />issues/0700/websecure2/websecure2.asp.

!

Read the MSDN article, “Securing Your Web Application,” which is
available at />veconsecuringyourwebapplication.asp.

!

Read the MSDN article, “Implementing a Secure Site with ASP,” which is
available at />msdn_implement.asp.

!

Read the MSDN article, “Untangling Web Security: Getting the Most from
IIS Security,” which is available at />dnsecure/html/WebsecIISsec.asp.


Module 4: Internet Information Services Authentication

v

How to Teach This Module
This section contains information that will help you to teach this module.

Lesson: Introduction to Web Client Authentication
This section describes the instructional methods for teaching each topic in this

lesson.
Why Web Servers Are
Attacked

Explain the ways and reasons why a Web server is the target of so many
attacks.

Authentication and
Authorization

Define authentication and authorization. This module is about authentication.
Module 5, “Securing Web Pages,” in Course 2300, Developing Secure Web
Applications, is about authentication and authorization. These terms will be
revisited many times throughout Course 2300, Developing Secure Web
Applications.

Impersonation and
Delagation

The primary difference between impersonation and delegation is that
impersonation occurs on the Web server, while delegation occurs across
computer boundaries.

User Identities and
Permissions

Introduce the user and group accounts listed on the slide.
IWAM_computername will be covered at the end of this module. The ASPNET
account is new in Microsoft .NET, and it secures the Microsoft ASP.NET pages
by limiting the rights of the account that the pages run as.

How IIS Impersonates a
Windows User Account

Expand on the subject of impersonation by explaining how IIS performs work
on behalf of an authenticated client. The identity under which IIS performs this
work varies, based on the type of authentication that is used and the platform
that you use to develop the Web application (Active Server Pages (ASP) or
ASP.NET).

Programmatically
Accessing User Identity

In ASP.NET, you use the code User.Identity.Name to discover the name of the
authenticated user. In this code, User is a Principal object and User.Identity is
an Identity object.
This property uses the User property of the HttpContext object to determine
where the request has originated from. The HttpContext object provides access
to the intrinsic Request, Response, and Server objects for the request.
This topic also introduces how to enable impersonation in an ASP.NET Web
application by setting an attribute in the Web.config file. This may be the first
time some students have heard about the Web.config configuration file. Quickly
explain its purpose and use. Web.config will be covered again in Modules 5,
“Securing Web Pages,” and Module 6, “Securing File System Data,” in Course
2300, Developing Secure Web Applications.

Demonstration:
Programmatically
Accessing User Identity

This demonstration is performed with the Web site configured to allow
Anonymous access. Therefore, the code will not show a name for the user. The
same page will be demonstrated in the next lesson to show how the page
changes based on the authentication method selected for IIS.


vi

Module 4: Internet Information Services Authentication

Lesson: Configuring Access Permissions for a Web Server
Using IP Address and
Domain Name
Restrictions

One reason to use IP address restriction is that if there is a known proxy server
that is waging attacks, you can restrict access to your Web site for that IP
address. The Web site has a list of servers that
known hackers use.

Using Web-Based
Permissions

Web-based permissions are one way to protect files that are not handled “by
default” by the Web server, such as .inc files.

Practice: Using WebBased Permissions

This practice reinforces the point that some of the default permissions settings
in IIS can expose Web application implementation files to users. It is important

to understand what the default permission settings are and how to modify these
settings to best protect Web application files.

Using the Permissions
Wizard

Quickly demonstrate the Permissions Wizard. Many of the settings in the
Permissions Wizard are beyond the scope of this course, but the wizard does
provide a quick way to configure Web-based permissions for common
scenarios, such as a public Web site or a secure Web site. The students do not
run the Permission Wizard in this course because they will manually implement
the same settings.

Lesson: Selecting a Secure Client Authentication Method
Overview of IIS Web
Client Authentication

The term “identified access” may be new to students. Explain the difference
between identified access, which is typically used for the personalization of a
Web site, and authenticated access.

Demonstration: Setting
IIS Authentication
Methods

The demonstration should set the different authentication methods on the
Mod04 subfolder of the 2300Demos Web application. Discuss the results after
each authentication method is applied.

Using Anonymous

Authentication

You might want to mention that Anonymous access plays an important role in
forms-based authentication, which is the topic of Module 5, “Securing Web
Pages,” in Course 2300, Developing Secure Web Applications.

Using Basic
Authentication

Basic authentication is not a secure way of adding authentication to your Web
application because the password that is entered by the user is sent to the Web
server in Base64 encoding. In Module 8, “Protecting Communication Privacy
and Data Integrity,” in Course 2300, Developing Secure Web Applications, you
will explain Secure Sockets Layer (SSL) and show how the students can secure
the Basic authentication method by securing the Basic-protected folder by using
SSL. Then, the user name and password (in addition to all of the other data on
the secured pages) will be sent to the Web server by using SSL.

Using Digest
Authentication

Digest authentication is included for a complete look at authentication, but you
do not need to discuss this authentication method in detail. Digest
authentication requires the Active Directory® directory service, which is beyond
the scope of this course.

Using Integrated
Windows Authentication

Although Integrated Windows authentication is a very secure authentication

method because it takes advantage of the security features that are built into the
Windows operating system, it is important to note its limitations and why is it
not appropriate in most Web applications that are designed for use on the
Internet.


Module 4: Internet Information Services Authentication

vii

Using the Kerberos V5
Protocol vs. NTLM

The most important difference between the Kerberos V5 protocol and NTLM is
that NTLM is limited to impersonation on the Web server, whereas Kerberos
can use delegation to access resources across the network. It is also important to
note that you do not have control over which protocol is used. IIS will always
attempt to use Kerberos first and will use NTLM only if Kerberos is not
available.

Using Multiple
Authentication Methods

Review the guidelines for using multiple authentication methods so that the
students will understand how IIS determines which authentication method to
use when multiple authentication methods are specified.

Practice: Selecting a
Web Client
Authentication Method

In this practice, students will review some common scenarios and decide which
authentication method or methods to use in each scenario. You can add value to
this practice by asking students to determine the order in which IIS will try each
of the authentication methods to find a valid one.

Lesson: Running Services As an Authenticated User
Multimedia: User
Identity Flow in a Web
Application

This animation explains how the identity flow can be passed either by using
application parameters or the Windows operating system. The animation shows
all parts of the process; however, only the client authentication in IIS and
COM+ pieces are discussed here. Microsoft SQL Server™ is covered in Module
7, “Securing Microsoft SQL Server,” in Course 2300, Developing Secure Web
Applications. COM+ is beyond the scope of this course.
If students do not know what a COM+ component is, start out with a brief
description:
COM+ was introduced by Microsoft in 2000. COM+ builds on the integrated
services and features of the Component Object Model (COM), making it easier
for developers to create and use software components in any language, by using
any tool.
For more information about COM+, see the article “COM+ Programming
Overview,” which is available at />cossdk/htm/pgintro_programmingoverview_9kjb.asp.

Selecting an IIS
Application Protection
Level

Note that the application protection setting applies only to ASP Web
applications.
Demonstrate where you configure this setting in IIS, which is in the Properties
dialog box, on the Directory tab, of a Web application.
Describe the process in which ASP.NET Web applications are run,
ASPNet_wp.exe. Explain that IIS always runs ASP.NET Web applications in a
single instance of the ASPNet_wp.exe process and that developers do not have
control over this.


viii

Module 4: Internet Information Services Authentication

Configuring COM+
Applications to Run
Under a Specific User
Identity

Demonstrate the Component Services dialog box to show where the students
can set the identity of a COM+ application:
1. On the Start menu, point to Programs, point to Administrative Tools, and
then click Component Services.
2. In the Component Services dialog box, expand Component Services,
expand Computers, expand My Computer, and then expand COM+
Applications.
3. Right-click a COM+ application, such as IIS Out-Of-Process Pooled
Applications, and then click Properties.
4. In the Properties dialog box, on the Identity tab, show how the IIS Out-OfProcess Pooled applications are configured to run as the
IWAM_computername user.

5. Click Cancel to close the Properties dialog box.

Configuring Role-Based
Security for COM+
Applications

This topic is beyond the scope of this course. Direct students to Course 2557,
Building COM+ Applications Using Microsoft .NET Enterprise Services, to
learn more about this topic.

Lab 4: Authentication and Access Control
Introduce the lab with a group brainstorming session about which users need to
have access to the TailspinToys and TailpsinToysAdmin Web applications, and
therefore, what authentication method should be applied to each Web
application:
!

The TailspinToys Web application must be available to everyone; therefore,
it will be configured to allow Anonymous access.

!

The TailspinToysAdmin Web application must be available only to the
employees of Tailspin Toys; therefore, it will be configured to use
Integrated Windows authentication.

At the end of the lab, reiterate which authentication methods were applied to the
two Web applications and why.

Module 4: Internet Information Services Authentication

ix

Customization Information
This section identifies the lab setup requirements for a module and the
configuration changes that occur on student computers during the labs. This
information is provided to assist you in replicating or customizing Microsoft
Official Curriculum (MOC) courseware.

Lab Setup
To complete this lab, students can continue working in the Tailspin Toys
Microsoft Visual Studio® .NET projects that they used in previous labs, or they
can start with new files.
To start with new files, students must complete the following steps.

! Create the Web applications for the ASP exercises
1. Copy all of the contents of the ASP starter folder install_folder\Labfiles\
Lab04\ASP\Starter\TailspinToys to the TailspinToys IIS virtual directory at
C:\Inetpub\wwwroot\TailspinToys.
2. Copy all of the contents of the ASP starter folder install_folder\Labfiles\
Lab04\ASP\Starter\TailspinToysAdmin to the TailspinToys IIS virtual
directory at C:\Inetpub\wwwroot\TailspinToysAdmin.

! Create the Web applications for the ASP.NET exercises
1. Copy all of the contents of the ASP.NET folder install_folder\Labfiles\
Lab04\ASPXVB\Starter\TailspinToys.NET to the TailspinToys.NET IIS
virtual directory at C:\Inetpub\wwwroot\TailspinToys.NET.
2. Copy all of the contents of the ASP.NET folder, install_folder\Labfiles\
Lab04\ASPXVB\Starter\TailspinToysAdmin.NET, to the

TailspinToysAdmin.NET IIS virtual directory at
C:\Inetpub\wwwroot\TailspinToysAdmin.NET.

Lab Results
Performing the lab in this module introduces the following configuration
change:
!

The TailspinToys and TailspinToys.NET Web applications should be
configured in IIS to only allow Anonymous access.

!

The TailspinToysAdmin and TailspinToysAmin.NET Web applications
should be configured in IIS to allow only Integrated Windows
authentication.



Module 4: Internet Information Services Authentication

1

Overview
!

Introduction to Web Client Authentication

!

Configuring Access Permissions for a Web Server

!

Selecting a Secure Client Authentication Method

!

Running Services As an Authenticated User

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction

Implementing the correct security settings on your Web servers can safeguard
your Web application against security threats, such as unauthorized individuals
trying to gain access to restricted information, along with protecting against
well-intentioned users who might accidentally alter important files.
Security in Internet Information Services (IIS) version 5.0 consists of an
interaction of permissions, policies, authentication methods, and secure
communications protocols. By configuring security correctly on your Web
server, you can ensure that your servers are protected from unauthorized access.
This module provides insight into the Web client authentication methods that
are supported by IIS and Microsoft® Windows® 2000 Server. After the Web
client user is identified, that identity is then mapped to a Windows 2000 user
identity. Servicing a Web page request can involve several processes that have
different security identities. The initial authentication and the flow of those
identities are the focus of this module.
Note The code samples in this module are provided in both Microsoft
Visual Basic® .NET and C#.

2

Module 4: Internet Information Services Authentication

Objectives

After completing this module, you will be able to:
!

Explain how Web client authentication is used to pass user identity through
a Web application.

!

Use Information Protocol (IP) address and domain name restrictions, and
IIS Web-based permissions, to effectively control who can access the
resources on a Web server.

!

List and explain all of the authentication methods that are supported by IIS
and select the best method for a given set of requirements.

!

Explain how the identity of an authenticated Web client is mapped to a
Windows 2000 user identity and passed to Web applications and COM+
components.

Module 4: Internet Information Services Authentication

3

Lesson: Introduction to Web Client Authentication
!

Why Web Servers Are Attacked

!

Authentication and Authorization

!

Impersonation and Delegation

!

User Identities and Permissions

!

How IIS Impersonates a Windows User Account

!

Programmatically Accessing User Identity

!

Demonstration: Programmatically Accessing User
Identity

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction

IIS serves as the gatekeeper to the resources that are on your Web server by
authenticating clients as they attempt to access your Web application. In this
lesson, you will learn how IIS authenticates clients and passes user identity
through a Web application.

Lesson objectives

After completing this lesson, you will be able to:
!

Describe why and how Web servers are attacked.

!

Describe the difference between authentication and authorization in a Web
application.

!

Explain the difference between impersonation and delegation.

!

List and explain the standard user identities that are on an IIS server.

!

Explain how a Web client identity is translated into the process identity or a
series of identities that are used by processes that fulfill the Web application
request.

!

Use code to determine the identity of the user of the currently running Web
application.


4

Module 4: Internet Information Services Authentication

Why Web Servers Are Attacked
!

Reasons for an attack
"

!

Easy public access to a company's network

Weaknesses that might lead to an attack

"

Unpatched IIS server

"

Unprotected Web application files

"

Web application not secured against anonymous
access

"

Incorrect Web-based permissions set on Web
application pages

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction

Web servers are an easily reached gateway to a company’s network because
they are often available for all Internet users to browse. Therefore, Web servers
pose a very public arena for attack.
Some files on the Web server need to be available for read access, but must not
be available for write access or execute access. Some pages on the Web server
should be accessible only to the Web server itself (such as include files or codebehind pages in a Microsoft ASP.NET Web application).
The files on the Web server contain useful information for attackers. Server
script files, such as .asp and .aspx files, contain implementation source code
that can be useful for determining a Web site’s architecture. This

implementation source code may also describe database structures. Source code
may also contain database connection strings, trusted user names and
passwords, and other configuration data that can be useful to an attacker.


Module 4: Internet Information Services Authentication

Accessing a Web server

5

A Web server can become available to an attacker through a variety of
mechanisms. Some of these mechanisms are the results of the weakness in a
system. You can prevent most of the attacks on the Web server by ensuring that
certain weaknesses are addressed. Specific weaknesses are described in the
following table.
Weakness

Use

IIS server not current with
patches

Staying current with IIS patches helps to ensure a secure
server. Historically, there have been IIS holes that permit
access to the implementation file source. For example,
appending ::$DATA to an .asp file Uniform Resource
Locator (URL) allows an attacker to access the .asp file
source code.

Alternate routes to the file

Running more applications on the Web server than
required makes the Web application vulnerable to attack
because it provides alternate routes to attackers to access
the Web application data. For example, Web application
implementation files can also be accessed through
applications, such as File Transfer Protocol (FTP) and
Web Distributed Authoring and Versioning (WebDAV).
If a Web server is running these applications and they
have a weakness or security hole, Web application
implementation files may be accessible to external users.
You should disable all of the applications that are not
required on the server.

Unprotected configuration
files

File types that are not explicitly disallowed are by
default accessible through IIS. If you add any new file
types (for example, .inc files) to your Web application,
you must ensure that those files are secured.

Securing private portions of
Web sites

Ensure that anonymous users are allowed only to visit
public Web sites and secure all private sites for
authenticated users.

Incorrect Web-based
permissions on files

Ensure that the pages of your Web application are
available for read access and possibly available for
execution. Do not apply write, directory browsing, or
execute permission to files and folders unless it is needed
by the Web application.


6

Module 4: Internet Information Services Authentication

Authentication and Authorization
!

Authentication
"

!

The process of verifying the identity of a principal by
accepting credentials and validating those credentials

Authorization
"

The process of confirming that an authenticated
principal is allowed access to one or more resources

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction

The ability to authenticate Web application users and authorize them to use
Web application resources is one of the foundations of Web security.

What is authentication?

Authentication is the process of obtaining user identification credentials, such
as a name and a password, and then validating those credentials against some
authority, such as a database. If the identification credentials are valid, the user
that submitted the credentials is considered an authenticated user.
For example, all users must provide a user name and password every time that
they log on to a network. These credentials are then authenticated by an
authority, such as a database or a Windows-based domain controller.

What is authorization?

After an identity has been authenticated, the authorization process determines
whether that identity has access to a specified resource. The authorization
process limits access rights by granting or denying specific permissions to an
already authenticated identity.
For example, you can authorize user Robert Brown to access the color printer,
but deny access to user Bob Hohman. Similarly, you can authorize only the
users of a company’s Media group to be able to access the color printer and
deny access to the rest of the company’s users.
The user of a Web application should always execute code with just enough
access privilege to accomplish the intended task, and no more. This is referred
to as running with least privileges. By limiting access to resources to only those

users who are authorized, you can help prevent accidental or malicious damage
to Web application and system resources.


Module 4: Internet Information Services Authentication

7

Impersonation and Delegation
SQL Server

Code
Code
IIS
IIS

Client
Client

!

Authenticated
User

Impersonation
"

Code executes
in the context of
an authenticated

client

Authenticated
User
Network Server
Network
!

Delegation
"

Enables the
server to
access remote
resources while
acting as the
client

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction

Impersonation and delegation are used to control the flow of user identity
through a Web application.

What is impersonation?

The pages in your Web application are run by either the Active Server Pages
(ASP) process or the ASP.NET process. These processes run in many threads
on the computer running Windows 2000 Server.
Impersonation is the ability of a thread to execute by using different security

information than the process that owns the thread. Typically, a thread in a
server application impersonates a client. Impersonation allows the thread to act
on behalf of that client to access objects on the server or to validate access to
the client’s own objects.
The primary reason for impersonation is to cause access checks to be performed
against the client’s identity. Access checks identify the user when a thread
interacts with a securable object or tries to perform a system task that requires
access privileges. Using the client’s identity for access checks can cause access
to be either restricted or expanded, depending on what the client has permission
to do. For example, assume that a file server has files containing confidential
information and that each of these files is protected by an Access Control List
(ACL). To prevent a client from obtaining unauthorized access to the
information in these files, the server can impersonate the client before accessing
the files.

What is delegation?

Delegation, which is a more powerful form of impersonation, enables the server
to access remote resources over the network while acting as the client;
impersonation is limited to accessing resources on the server computer.


8

Module 4: Internet Information Services Authentication

User Identities and Permissions
!

Windows 2000 and IIS create special accounts for Web

applications that help you to control user access to
resources
"

Interactive group

"

Network group

"

IUSR_computername account

"

IWAM_computername account

"

ASPNET account

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction

Windows 2000 includes several built-in group accounts that assist you in
granting the minimum permissions possible. These group accounts include the
Interactive and Network groups. Additionally, when IIS is installed, the
IUSR_computername and IWAM_computername user accounts are created for
use, by IIS, when IIS is running ASP Web applications. When you install the

Microsoft .NET Framework, an account called ASPNET is also created. The
aspnet_wp.exe process (which runs all ASP.NET Web applications) runs as the
ASPNET account.
Note You will learn more about the different authentication methods that are
supported by IIS in the lesson “Selecting a Secure Client Authentication
Method” in this module.

Interactive group

The Interactive group is a built-in, automatically maintained group in
Windows 2000 that consists of all of the users who are logged on locally to the
server computer. A local log on is one that appears to the server to have
occurred on the server itself, instead of occurring remotely. Before a user or
group can perform a local log on, he or she must have the Log on Locally user
right. You can use the Interactive group to restrict or permit access to all of the
users that are authenticated by Basic authentication.

Network group

The Network group is a built-in, automatically maintained group in
Windows 2000 that consists of all of the users who are logged on to the server
over the network. Before a user or group can perform a network log on, they
must have the Access This Computer from the Network user right. You can use
the Network group to control access for all of the users that are authenticated by
Digest or Integrated Windows authentication.


Module 4: Internet Information Services Authentication

IUSR_computername

account

The Internet Guest Account is named IUSR_computername (where
computername is the name of the computer on which IIS is running), and this
account is used to provide Anonymous access to a Web application, a folder, or
a file.
Managing NTFS file system permissions for the Internet Guest Account is
critical to the security of your Web server and network. The Internet Guest
Account should be permitted only the minimum permissions that are necessary
to gain access to the Web server.

IWAM_computername
account

The IWAM_computername account is also created by IIS, and it is used solely
for Web applications that run in Medium or High application protection. In
some situations, you will need to provide the appropriate permissions to server
resources for this account. For example, if there is a program gaining access to
a database on behalf of a user, and that program is running in Medium or High
application protection, you will need to provide appropriate database
permissions to this account.
Note You will learn more about IIS application protection levels in the topic
“Selecting an IIS Application Protection Level” in this module.

ASPNET account

The ASPNET account is created by the .NET Framework, and it is used solely
for ASP.NET Web applications. In some situations, you will need to provide
the appropriate permissions to server resources for this account. For example, if
a Web application needs to write to a file, you will have to give the ASPNET

user write permission to access the folder where the file is located.

9


10

Module 4: Internet Information Services Authentication

How IIS Impersonates a Windows User Account
LocalSystem
1 Takes client request
1
2 Impersonates the
2
Internet
Internet
Information
Information
Services
Services

user by mapping the
request to a Windows
user account

3
3

Performs the

appropriate tasks

4
4

Reverts to the
process identity,
LocalSystem

IUSR_computername
IWAM_computername
Windows users
and groups

Windows
Windows
user
user
accounts
accounts

ASPNET

LocalSystem

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction

When IIS receives a request from a Web client, it authenticates the client and
then performs the work under the identity of the authenticated client by using a

Windows user or group account. IIS impersonates the client by using the
IUSR_computername or IWAM_computername account for ASP Web
applications or the ASPNET or IUSR_computername account for ASP.NET
Web applications.

ASP and impersonation

Whereas IIS impersonates the client, IIS operates within the confines of the
authenticated user’s security context. This security context may change during
the various stages of request processing, depending on the nature of the client
request and what resources are required to service that request.
The security context of the IIS process (Inetinfo.exe) is known as LocalSystem.
However, when IIS is processing a client request, it will impersonate the
context of the client that originally generated the request. The Windows user
account that is used depends on the authentication method, as described in the
following table.
Authentication method

Windows user account

Anonymous

IUSR_computername for in-process Web
applications and IWAM_computername for Web
applications running in an isolated process.

Basic, Digest, and Integrated
Windows (NTLM)

The Windows user account for which the client

supplied the user name and password.

Integrated Windows (Kerberos)

The Windows user account for which the client
supplied the user name and password.
Kerberos also supports delegation, which allows
access to the resources of another system, under the
client’s identity.


Module 4: Internet Information Services Authentication

11

After IIS has performed the tasks that are required to complete the client
request, IIS reverts to the security context of the IIS process, LocalSystem.
Note You will learn more about IIS application protection levels in the topic
“Selecting an IIS Application Protection Level” in this module.
ASP.NET and
impersonation

ASP.NET does not impersonate by default. ASP.NET executes all code by
using the same user account as the ASP.NET process (aspnet_wp.exe), which is
typically the ASPNET account. You can change the account that the ASP.NET
process runs as by setting the userName and password attributes of the
tag in the Machine.config or Web.config file. You can enable
impersonation in ASP.NET Web applications by setting the impersonate
attribute of the <identity> tag in the Web.config file.
The following example enables impersonation, thereby causing the ASP.NET

process to run as either the authenticated user or the Internet Guest Account
IUSR_computername:
<identity impersonate="true" />

You can also enable impersonation and specify a specific impersonation
identity, as shown in the following example:
password="password" />


12

Module 4: Internet Information Services Authentication

Programmatically Accessing User Identity
!

ASP

<%= Request.ServerVariables("AUTH_USER") %>
<%= Request.ServerVariables("AUTH_USER") %>
<%= Request.ServerVariables("AUTH_PASSWORD") %>
<%= Request.ServerVariables("AUTH_PASSWORD") %>
!

ASP.NET

If (User.Identity.IsAuthenticated) Then
If (User.Identity.IsAuthenticated) Then
Response.Write(User.Identity.Name)

Response.Write(User.Identity.Name)
Response.Write(User.Identity.AuthenticationType)
Response.Write(User.Identity.AuthenticationType)
End If
End If
!

Impersonation in ASP.NET Web applications

<identity impersonate="true"/>
<identity impersonate="true"/>

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction

After a user has accessed your Web application through whichever
authentication mechanism you have enabled, the Web pages can then access the
user name of the user through code.

Accessing user
information from ASP

In ASP, you use the ServerVariables collection of the Request object to obtain
the identity information about the user. The variables that contain the user
information are AUTH_TYPE, AUTH_USER, AUTH_PASSWORD, and
LOGON_USER.
The following example shows the use of the AUTH_USER and
AUTH_PASSWORD variables:
<%= Request.ServerVariables("AUTH_USER") %>
<%= Request.ServerVariables("AUTH_PASSWORD") %>

If the user is authenticated with Anonymous authentication, the AUTH_USER
variable will contain an empty string. The LOGON_USER variable will be
different from the AUTH_USER variable, if the remote user is mapped to a
local Windows account.
Note For more information about the ServerVariables collection, search for
“ServerVariables” in the Microsoft MSDN® online documentation.


Module 4: Internet Information Services Authentication

Accessing user
information from
ASP.NET

13

In ASP.NET, you use the User.Identity object to obtain identity information
about the authenticated user.
The following example uses the User.Identity object to write user information
to a Web page:
[Visual Basic .NET]
Imports System.Security.Principal
Sub Page_Load(...)
If User.Identity.IsAuthenticated Then
Response.Write(User.Identity.Name)
Response.Write(User.Identity.AuthenticationType)
Else
Response.Write("Anonymous access")
End If

Response.Write("Windows identity: " & _
WindowsIdentity.GetCurrent().Name)
End Sub
[C#]
using System.Security.Principal;
private void Page_Load(...)
{
if (User.Identity.IsAuthenticated) {
Response.Write(User.Identity.Name);
Response.Write(User.Identity.AuthenticationType);
}
else {
Response.Write("Anonymous access");
}
Response.Write("Windows identity: " +
WindowsIdentity.GetCurrent().Name);
}

The Name and AuthenticationType properties return "", if Anonymous
authentication is used.
Note For more information about the User.Identity object, search for “Identity
object” in the .NET Framework documentation.


14

Module 4: Internet Information Services Authentication

Impersonation in
ASP.NET Web

applications

When impersonation is not enabled for your ASP.NET Web application, it runs
under the identity of the ASPNET account, rather than as the authenticated user.
The WindowsIdentity class is the Windows user account that is running the
Web page. The User.Identity object contains the authenticated user (User is a
Principal object that contains security information).
When impersonation is not enabled, the User.Identity.Name property displays
the authenticated user, but the code still runs as the ASPNET account;
therefore, access to resources is limited to those available to that account. The
WindowsIdentity.GetCurrent().Name property displays the name of the
account that is running the Web application (the WindowsIdentity class is in
the System.Security.Principal namespace).
If you are using Integrated Windows authentication or Basic authentication, and
impersonation is enabled, the code runs as the authenticated user, and
User.Identity.Name and the WindowsIdentity.GetCurrent().Name are the
same. If impersonation in not enabled, WindowsIdentity displays ASPNET
and User.Identity displays the authenticated user.


Module 4: Internet Information Services Authentication

15

Demonstration: Programmatically Accessing User Identity
1. Display user information on an ASP page
2. Display user information on an ASP.NET
page

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Introduction

In this demonstration, you will see how to display the user identity of the
currently running Web application.

! To run the demonstration
1. In Microsoft Internet Explorer, open the http://localhost/2300Demos/
Mod04/WhoAmI.asp page.
The user is allowed access to the Web application as an anonymous user.
2. In Microsoft Visual Studio® .NET, open 2300Demos solution.
3. Open the WhoAmI.asp page in the Mod04 folder of the 2300Demos project.
Show the code that displays the AUTH_USER and AUTH_PASSWORD
variables.
4. In Internet Explorer, display the http://localhost/2300Demos/Mod04/
WhoAmI.aspx page.
You are allowed access to the page as an anonymous user, but the identity
of the account is ASPNET.
5. In Visual Studio .NET, open the WhoAmI.aspx.vb code-behind page in the
Mod04 folder of the 2300Demos project.
Show the code that displays the name of the authenticated user and the name
of the Windows account.