ASP Security

This section describes how ASP security works and how you should set up Windows to support the type of security you want for your Web applications.

When IIS is first installed, it creates a Windows user account named IUSR_ computername , where computername corresponds to the current computer name . This account is assigned to the Guests account group , is given a random password, and is granted the right to log on locally. Whenever a user browses a Web page, this account attempts to access the page on behalf of the user. If the IUSR_ computername account does not have the proper permissions to access the page, the request is rejected with a "401 Access Denied" error message. The Web server then informs the Web browser which authentication methods the Web server will support ”either Basic authentication or Windows NT Challenge/Response authentication ”depending on the settings defined on your IIS server.

Basic Authentication

Basic authentication is supported across all Web browsers. When the Web server informs the client that it supports Basic authentication, the Web browser displays a message box asking the user for a user name and password. Once the user types this information in, the Web server tries to invoke the request using the credentials that the user supplied rather than the IIS anonymous account. It is a good idea to pass in your domain name as well as the user name in the authentication dialog box in the Web browser, using the syntax domain\username .

Basic authentication, if used over Internet connections, can present some security concerns because the user name and password typed into the authentication dialog box is transmitted to the server as clear text. If you do use Basic authentication over Internet connections, use it in conjunction with Secure Sockets Layer (SSL). SSL will encrypt the connection between the Web browser and the Web server so that any information passed between the two cannot be viewed by unauthorized individuals.

For the Web server to impersonate the user whose name is typed into the authentication dialog box, the Web server must log on as that user. By default, Windows does not give regular users the Log On Locally right on the server computer. For this reason, you must grant the right to Log On Locally on the Web server to all users who you expect will use your Web application with Basic authentication. You do this is by granting all your domain users the Log On Locally right in the group policies for your domain controllers.

Digest Authentication

IIS supports the standard Digest authentication. Digest authentication is similar to Basic authentication, but Digest authentication does not send the user's password over the wire. Instead, Digest authentication uses a hashing algorithm to form a hexadecimal representation of a combination of user name, password, the requested resource, and the HTTP method.

Windows NT Challenge/Response Authentication

Windows NT Challenge/Response, or NTLM authentication, is the most secure form of authentication because the user name and password are not sent from the Web browser to the Web server. Instead an encrypted challenge/response handshake mechanism is used. Unlike Basic authentication, NTLM typically does not prompt the user for a name and password. The Windows NT security credentials of the Web user currently logged on are sent to IIS and are used to access the requested resource. IIS then changes to the context of the specified user and attempts to access the resource. If this fails, the user will be prompted for a user name and password.

Note  

For Windows NT Challenge/Response to work correctly, the users you are trying to authenticate must have the Access This Computer From A Network right in the group policies for your domain. This is normally enabled for users by default.

A one-way encryption method is used, meaning the mechanism validates the user without sending the password to IIS. IIS doesn't know the user information and cannot use it to access other resources on other machines. Essentially, this is a problem of delegation. When IIS attempts to access a resource on another machine, the other machine will prompt IIS for user credentials. Since IIS does not have the password for the user, it cannot return the correct information to the other machine. For this reason, you cannot use the Windows NT Challenge/Response authentication method within a Web application that works with Exchange if the application is on a different server from your Exchange server. IIS cannot remotely send the authentication to the Exchange server when the Windows NT Challenge/Response method is used. You can solve this problem if you use the delegation features of Windows and IIS. However, delegation is quite powerful and should only be used if you understand the issues with it. Look at Microsoft Knowledge Base Article Q283201 for more information about delegation.

One more note about delegation is that Windows Server 2003 introduces a new type of delegation called constrained delegation . Constrained delegation allows you to delegate to only a certain application or service. Rather than allowing any type of delegation, constrained delegation lets you limit the service that the server can authenticate with on behalf of a user. You should look at these capabilities if you want your mid- tier application to authenticate a user against a back-end application and do not want to use basic authentication.

A second gotcha of the Windows NT Challenge/Response method is that you cannot use it over proxy connections for the same reasons just discussed. When setting up your Web server, consider NTLM's security advantages as well as its limitations.

A third gotcha for NTLM is that NTLM is supported only by Internet Explorer. This means that if you have a mixture of Web browser clients accessing your application, you might want to enable both Windows NT Challenge/Response and Basic authentication. If you enable only Windows NT Challenge/Response, when Netscape Navigator users attempt to access a secure resource or page, they'll receive a message denying them permission. With both security methods set up, if Windows NT Challenge/Response fails, Basic authentication will be used.

.NET Passport Authentication

Microsoft .NET Passport is a user-authentication service that permits single sign-in security, providing users with secure access to .NET Passport “enabled Web sites and services. Sites that support .NET Passport rely on the .NET Passport central server to authenticate users. However, the central server does not authorize or deny a specific user's access to individual .NET Passport sites. It is the responsibility of the Web site to control users' permissions. When you select this option, requests to IIS must contain valid .NET Passport credentials on either the query string or in the cookie. If IIS does not detect .NET Passport credentials, requests are redirected to the .NET Passport logon page.

ACLs

Another way to restrict access to your Web pages is by setting NTFS-level file permissions on your actual ASP files and directories. This will control which accounts have access to the files and the level of access they have. IIS respects the ACLs (Access Control Lists) on the files and will use the ACLs to attempt to verify users and their individual permissions on the files. Be careful when setting permissions on files, however, because if the permissions you set are too restrictive , users will not be able to use your application.