What's New in IIS 6.0?
Many of the new features in IIS address technical and architectural issues in IIS 5.0. The new features can be divided into three broad categories:
New Security Features
- New Security Features
- New Reliability Features
- Other New Features
IIS was once considered one of the main security holes in Windows architecture. IIS 5.0 and earlier versions were constantly patched up by hot fixes from Microsoft. The security problems were a major deterrent to using IIS as a commercial Web server. In contrast, IIS 6.0 comes with an impressive list of new security features designed to win back commercial users.
Advanced Digest Authentication
Advanced Digest Authentication is an extension of Digest security. Digest security uses MD5 hashing to encrypt user credentials.(user name, password and user roles).
What's the purpose of MD5 hashing? Basic authentication sends the user name and password details over the network medium in base64 encoded format. These details can be easily "sniffed" (captured with a protocol analyzer) and decoded by an intruder, who could then use the credentials for nefarious purposes. Digest security's MD5 hash enhances security by applying cipher algorithms that are more sophisticated and more difficult to crack. An MD5 hash is binary data consisting of the encrypted user name, password and realm. The 'realm
' is the name of the domain that authenticates the user.
|Author's Note: The MD5 hash is embedded into an HTTP 1.1 header. This is only supported by HTTP 1.1-enabled browsers. Digest or Advanced Digest authentication mechanisms can not be enabled if the target browsers do not support HTTP 1.1. Internet Explorer 5.0 and above versions support HTTP 1.1, as well as recent versions of Netscape, Opera, Mozilla and other popular browsers.
Advanced Digest Security takes the Digest authentication model a bit further by storing the user credentials on a domain controller as an MD5 hash in the Active Directory database. Intruders would need to get access to the Active Directory to steal the credentials. This adds another layer of security to protect access to Windows 2003 Web sites. You do not need to modify application code to accommodate this security feature.
Both Digest and Advanced Digest Authentication only work on Web Distributed Authoring and Versioning (WebDAV) enabled directories. WebDAV (formerly called Web Folders) is a secure
file transfer protocol that lets people download, upload, and manage files on remote computers across the internet and intranets WebDAV is similar to the File Transfer Protocol (FTP) except that WebDAV always uses password security and data encryption on file transfers, whereas FTP doesn't support those features.
Text-based HTTP network transmissions between a server and client can easily be compromised; therefore, whenever you need to communicate privately you must encrypt all HTTP calls and responses. Secure Socket Layer (SSL) and Transport Layer Security (TLS) are the most common encryption mechanism used on Web sites. SSL/TLS enables secure communication by encrypting the communication channel with a cipher algorithm. TLS is a later (and more secure) version of the SSL protocol.
A further extension of SSL/TLS is Server-gated Cryptography (SGC) which has been available in a 40-bit version since version IIS 4. IIS 6.0 adds a strong 128 bit encryption mechanism to SGC. Adding SGC encryption to your applications does not require any special application code on the client machines; however, it requires a valid certificate
at the client Web browser, which can encode and decode the data. You need a special SGC certificate to enable the SGC support built into IIS 6.0, which you can obtain by contacting a certificate authority. You add the certificate to IIS just like you'd add any other certificate. IIS 6.0 supports both 40 bit and 128 bit encryption sessions, so your old 40 bit SGC certificates are still valid in IIS 6.0. So far, financial sector applications (such as banking and other financial institutions) are the most common users of SGC.
Selectable Cryptographic Service Provider (CSP)
|Author's Note: If you try to open an existing 40 bit SGC certificate in IIS 6.0, you may get an error message stating that "The certificate has failed to verify for all of its intended purposes" warning. These 40-bit certificates are targeted to Windows 2000 servers. Thus, you can have a valid certificate and can be mislead by this warning.
SSL/TLS offer a secure environment in which to exchange data, but they're both CPU intensive and have a negative performance impact. IIS 6.0 comes with a new feature called Selectable Cryptographic Service Provider (CSP) that lets an administrator or developer select from an optimized list of cryptography providers. A cryptographic provider provides you with an interface to encrypt communication between the server and the client. CSP is not specific to IIS and can be used to handle cryptography and certificate management.
Microsoft implements two default security providers. Those are the Microsoft DH SChannel Cryptographic provider and Microsoft RSA SChannel Cryptographic provider. The Microsoft implementations are optimized for IIS 6.0 to provide faster communications. Windows stores the private keys for these implementations in the registry.
The Microsoft Cryptographic API (Crypto API) for every provider contains an identical interface for all providers, so you can switch between providers to without modifying the code. Each provider creates a public and a private key to enable data communication. The private key is stored on hardware devices (such as PCI cards, Smart Cards etc.) or in the Registry. The other CSP keys can also be stored in the registry. It makes more sense to store private key as registry settings for computer access to the server. The private key is usually stored on Smart Cards and other portable devices for mobile distribution environments. (This is similar to Plug and Play
support for devices on Windows 2000 and Windows 2003 environments.) The CSP can be configured using the "Welcome to the Web Server Certificate Wizard." To reach the wizard, select the Directory Security tab from the site's Properties dialog, and then click the Server Certificate button.
Configurable Worker Process Identity
The World Wide Web Publishing Service (WWW) in previous IIS versions was unstable. If the WWW service failed it could shutdown the entire server. To help solve the problem, IIS 6.0 runs each Web site in an isolated process environment. This isolated process environment is called a Worker Process
. Using this scheme, Web site malfunctions are limited to one particular site's worker process, and will not lead to a generalized Web server shutdown. IIS 6.0 can also run sites in an IIS 5.0 compatible isolated environment. IIS system administrators can choose between a worker process model or the IIS 5.0 isolation model by selecting the correct option from the IIS Services tab in the Web Sites
properties dialog. Check the "Run WWW service in IIS 5.0 isolation mode" option to run IIS in IIS 5.0 isolation mode. If you don't check the box, IIS 6.0 runs on a worker process model by default. Note that IIS can run only one mode at a time; you can not run both worker process model Web sites and IIS 5.0 isolation mode Web sites simultaneously.
IIS typically runs worker process threads with a permission level lower than that of the system account. The worker process shuts down the application if the IIS server is targeted with malicious code. IIS 6.0 itself (which does
run as the local system account by default) is not affected because the worker process can be configured to run under a less privileged account.
Default Lock-down Status
The default installation of IIS 6.0 will result in a "light weight" Web server. By default, the only feature available is access to static content (for example, .htm files). This restricted
functionality is referred to as Default Locked Down
status, and forces system administrators to manually enable and disable those features that are necessary for their applications. They can do this through the Web services Extensions node of the IIS Manager.
New Authorization Framework
Authentication refers to identifying who a user is; authorization
is the process of confirming a users' access to a given resource. After authenticating a user you need to make sure whether that user is authorized to perform the required tasks on specific resource. There are two types of ASP.NET authorization options available for IIS 6.0
. The FileAuthorizationModule class is responsible for file authorization on Windows 2002 systems. The module is activated by enabling Windows Authentication on a Web site. This module does an access control list (ACL) check for the permissions a given user has to an ASP.NET file, which could be either an .asmx
file for an ASP.NET application or an .asmx
file for a Web service. The file is available to the user only if the ACL confirms the user has permission to access the file.
: The URLAuthorizationModule class is responsible for URL authorization on Windows 2003. This mechanism uses the URL namespace to store user details and access roles. The URL authorization is available for use at any time. You store authorization information in a special XML file in a directory. The file contains
tags to allow or deny access to the directory for specific users or groups. Unless specified, the
tags also apply to subdirectories. Here's a sample authorization file:
This file enables Chris
or anyone in the Admins group to access the content in the directory. In contrast, the user Kirby
is denied access. The wild card entry "?" means that no one else will be able to gain access to this directory.