|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 Reliability Features
- Other New Features
New Security 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.
|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.
Selectable Cryptographic Service Provider (CSP)
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
File Authorization. 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.
URL Authorization: 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.
New Reliability Features
Microsoft has done a great job of re-architecting IIS to be more reliable and robust. Perhaps the most significant modification is the emphasis on the Worker Process Model, which affects reliability as well as security (see the section entitled “Configurable Worker Process Identity” on the preceding page). In IIS 4, this concept was initially known as “Running an application in a separate memory space“.
IIS separates all user code from its WWW service. The user application (different Web sites) functions as a separate Internet Server Application Programming Interface (ISAPI) application. The separate ISAPI work space is called a worker process. IIS 5.0 ran each Web site configured as a separate application in its own memory space (a separate instance of the inetinfo.exe application). In contrast, IIS 6.0 worker process Web sites don’t run within the inetinfo.exe (WWW services) memory space at all; therefore an error (or malicious attack) in one particular Web site will not cause the entire Web server to shut down. You can configure worker processes to run on a specified CPU. Each worker process model stores application-specific data in its own memory space, whereas IIS 5.0 stored all application-level data within the inetinfo.exe memory space. This separation, which makes application-level data independent of other Web sites running on the same machine also makes it feasible to not only to assign a Web site to run on a specific CPU, but also to dedicate more resources to popular Web sites than to those that generate less traffic.
|Author’s Note: IIS 6.0 runs in the worker process model by default. You can also configure IIS 6.0 to run in “IIS 5.0 isolation mode”.
Automatic health detection simplifies IIS Web site management. IIS performs health detection for all worker processes, which adds another level of reliability to the Web applications. The inetinfo.exe process (IIS) checks the availability of each worker process periodically. You can configure the check interval using the IIS manager applet (it’s 240 seconds by default). Therefore IIS will maintain a “heart beat” between its worker processes that’s similar to the ping facility. During each beat, the IIS server tries to communicate with worker processes to make sure that they are alive.
New Request-processing Architecture
In Windows 2003 server, the HTTP stack is implemented as a kernel mode device driver called HTTP.sys. All incoming HTTP traffic goes through this kernel process, which is independent of the application process. IIS 6.0 itself is an application process and is external to HTTP.sys. Application processes run in user mode and the operating system functions are run in kernel mode. HTTP.sys is responsible for:
- Connection management?managing the database connections from the ASP.NET pages to data bases
- Caching?reading from a static cache as opposed to recompiling the ASP.NET page
- Bandwidth throttling?limiting the size of the Web requests to a Web site
- Text based logging?writing IIS information into a text log file
In IIS 5.0, the HTTP request was handled by the IIS inetinfo.exe application. In IIS 6.0, HTTP.sys relieves IIS of request-handling responsibility. In doing so, it enhances IIS performance in the following ways.
- HTTP.sys enables caching (referred to as flexible caching) at kernel level so that static data can be cached for faster response time (independent of the user mode caching). You need to be careful with flexible caching. Since HTTP.sys is separate from IIS we may still cache old data after a IIS restart.
- HTTP.sys introduces a mapping concept called “application pool.” Application pooling allows Web sites to run together in one or more processes, as long as they share the same pool designation. Web sites assigned to different application pools never run in the same process. A central Web site (such as a credit card verification Web site) can be accessed by all the other miscellaneous sites (such as shopping cart E- Commerce sites) by using application pooling. By using the correct application pool information HTTP.sys can route the HTTP traffic to the correct Web site.
- The HTTP.sys application pool concept increases the number of Web sites you can host host on a single machine. It also increases performance and provides more control over access to valuable IIS resources.
Other New Features
Earlier versions of IIS (2.0 through 5.0) used a scripting host environment called Active Server Pages (ASP). IIS 6.0 uses ASP.NET language hosting instead. There are some significant advantages to the ASP.NET architecture compared to the older ASP architecture. Some of those advantages include:
- ASP.NET is based on the Microsoft.NET framework. You could write ASP code in VBScript, JScript, or any other scripting language that ran in the Microsoft Scripting Runtime host environment. You can code ASP.NET in any language compatible with the common language runtime (CLR). Currently, Microsoft’s CLR-compatible languages include Visual C#, VB.NET, Jscript.NET, and J#, but languages from many other vendors are either available or under development.
- You can have code in more than one language in the same ASP.NET page. In other words, you can call a VB.NET function from a C# ASP.NET page.
- ASP code is interpreted. The runtime engine compiles the code line by line at runtime, while ASP.NET code is completely compiled in advance?not line by line. ASP.NET compiled code runs significantly faster than ASP interpreted code.
- ASP.NET gives you three levels of caching. You can cache complete pages, selected parts of the pages (called fragment caching), or by using the Caching API. Developers can use the Caching API to exert fine-grained control over caching behavior, and thus increase performance.
Unicode Transformation Format-8 (UTF-8)
Earlier versions of IIS could write log files only in English. This was a major issue for multi-lingual Web sites. IIS 6.0 enables multi-lingual support by supporting the UCS Transformation Format (UTF) 8 character codes. You can instruct HTTP.sys to log details in a specific language format. Therefore IIS can maintain multiple log files in multiple languages.UTF-8 support is available for both URLs and file names in IIS 6.0. Active Server Pages (ASP) also gains UTF-8 support. The Unicode code is converted into UTF-8 in this instance. Note that IIS 6.0 doesn’t support this functionality for FTP sites. Some FTP sites may require you to enter login details?and those login details will not be in UTF?8 format.
IIS stores configuration settings in a hierarchical database referred to as the Metabase. Earlier IIS version stored Metabase data in binary format earlier IIS versions, making it difficult to edit the entries, or even to read them. The IIS 6.0 Metabase, on the other hand, is in Extensible Markup Language (XML) format. XML files are plain text. You can use any text editor to change the XML entries?even while ISS 6.0 is running, a process called “edit while running.” You do not need to restart IIS to reflect the changes unless you change the schema file?a separate XML file that controls the allowable content and order of the Metabase entries.
This design change has reduced the start-up and shutdown time of ISS considerably. Previously, IIS settings were stored in inetinfo.exe and in the system registry, which resulted in multiple reads from the registry and the necessity to load and access system resources at start-up time. Previous versions also needed to clear memory references at shutdown time. IIS 6.0 eliminates most of the overhead by storing all the settings in the XML Metabase.
The Metabase consists of the following two XML files:
- Metabase.xml. An XML document that contains ISS configuration values for the server, such as Web site details, and virtual directory details.
- MBSchema.xml. An XML document which holds the Metabase XML schema. The schema file acts as a validation tool to enforce correct Metabase values in the Metabase.xml file.
Both Metabase files are located in the SystemrootSystem32Inetsrv directory. You need administrator permission to view the contents of the Metabase entries. You can not edit the Metabase.xml file without admin access. You will not be able to edit the MBSchema.xml file directly even with Admin access. You make schema changes through the Active Directory Service Interface (ADSI). Editing a Metabase.xml file is a tedious task. A simple approach is to use the IIS Manager interface to make the changes. However editing the Metabase directly can save expert users some effort. It is possible to have simultaneous changes to the Metabase, for example, if one administrator changes the schema via ADSI and another administrator makes some changes to the Metabase.xml file. You can prevent this by using Access Control Lists (ACL) on the Metabase files to prevent XML file changes while schema changes are being made. The Metabase history feature stores a history of the Metabase.XML file changes. IIS uses this file to apply new Metabase changes if the configuration is lost. You can build up the Metabase with the help of the history and the backups of the Metabase..
You can back up the Metabase using the Backup/ Restore Configuration option on the All Tasks menu item by performing the following steps:
- Click Start | Programs | Admin Tools | Internet Information Services (IIS) Manager
- Right Click the server name in the left console pane
- Select All Tasks from the context menu
- Select Backup/ Restore Configuration
- Click the Create Backup button
- Type a name for the configuration backup
- Select whether to encrypt the backup with a password by checking or unchecking the Encrypt backup password option. If you elect to use a password, enter and confirm the password
- Your new backup will appear in the list of backups. Restoring IIS from a backup is done through the same interface. (When you select an existing backup from the list, the “Restore” button will be enabled on the interface.) Select the backup and click the Restore button if you wish to restore the backup
If the computer running IIS fails, you can restore the Metabase from this backup copy. You can also use the backup to create a duplicate setup on a new installation of Windows Server 2003 or even on a different computer (if you use secure backup). It’s possible to restore the Metabase using a copy of the Metabase files saved in the history folder; however, you can’t restore a backup from an earlier version of IIS, and if you restore from the history files, you can’t restore to a different IIS installation or to a different computer.
IIS automatically makes regular backups of the Metabase in addition to any manual backups made by administrators. It also creates history files automatically, as long as the history feature is enabled (by default, it is). You can use the IIS Manager to restore history files, as well as restoring from backup.