New Administration Features
Like the previous version, IIS 6.0 offers two graphical interfaces for managing Web servers — via Internet Information Services Manager MMC snap-in and via IIS Administration Web site. The first one is available as soon as the World Wide Web Service component is installed; the second one requires the installation of the Remote Administration (HTML) item listed as one of the subcomponents of World Wide Web Service in the Windows Components Wizard (which is invoked by running the Add or Remove Programs Control Panel applet). Once the installation is completed, you can administer the Web server remotely by connecting from a Web browser to https://servername:8098.
In version 6.0 the connection uses the HTTPS protocol, which is secured with pre-configured, automatically generated certificates. Unfortunately, several vulnerabilities were discovered in recent months, so in general this utility should be avoided.
More significant from, an administrative point of view, is the ability to control the installation of the IIS component with Windows 2003 Group policies. The relevant setting is located in the Computer Configuration -> Administrative Templates -> Windows Components -> Internet Information Services container.
New Authentication Methods
In addition to the authentication methods available in the previous versions (anonymous, basic, integrated, certificate based — using client certificate mapping, and digest), IIS 6.0 offers two new types:
- .NET passport authentication uses the Microsoft-managed .NET Passport Web service. Although acceptance of this technology has been rather lukewarm in corporate environments, the ability to use it for Web authentication has been implemented in IIS 6.0. .NET Passport authentication improves user experience, since it limits the number of user names and passwords to be remembered and makes Web site administration more challenging.
First, you must register your Web server with .NET Passport servers (this procedure includes signing formal agreements that result in obtaining a site ID) and ensure both sides are communicating properly. Testing procedures (performed with designated by Microsoft .NET Passport preproduction servers) are described in the “Setting Up .NET Passport in the IIS topic of the online Help included with Windows Server 2003 . The task is even more challenging if you must set permissions on the Web site, since .NET passport provides only the authentication mechanism, but it is not used for authorization (i.e., controlling what a user can or cannot access). To accomplish this, map .NET Passport users to Active Directory accounts. This process is called provisioning, and it is also described in the same On-Line Help topic.
- Advanced Digest authentication is similar in many respects to digest authentication, which became available with IIS 5.0. It uses Windows domain accounts, and can be used across firewalls and proxies (unlike integrated authentication). However, while digest authentication requires user passwords be stored on domain controllers using reversible encryption, which has obvious security implications, with advanced method, passwords are stored in the form of one-way MD5 hash. At the beginning of authenticated connection, a Web server informs the client’s browser to prompt user for user name, domain name, and password. The browser applies MD5 hash algorithm to user credentials and submits them to Web server as part of HTTP 1.1 request. The Web server then forwards the hash to the Windows 2003 domain controller for verification. Once this is successful, the user is allowed to connect.
Note that use of Advanced Digest Authentication places additional requirements on both the server and client sides:
- Users’ computers must have HTTP-1.1-compliant browser installed (IE 5.0 or later)
- Web server must be running IIS 6.0 (this requires Windows Server 2003)
- Users’ accounts must reside in the same domain as the Web server or a domain trusted by the domain where Web server resides
In addition, you must also enable Advanced Digest Authentication on the Windows Server 2003 running IIS 6.0 component. This requires performing the following two steps:
- Modify the setting on the Directory or File security tab (depending on the level on which authentication will be applied) of a Web site, directory, or file Properties dialog box in the IIS Manager MMC snap-in. Click the Edit button in the Authentication and access control section, and select the Digest authentication for Windows domain servers checkbox. This will enable the Realm text box, in which you can type (or select after clicking on Browse button) the domain where users accounts reside.
- The previous step enables digest authentication. To switch to the advanced version, you must also set the UseDigestSSP metabase key to TRUE (leaving this key empty or setting it to FALSE defaults to legacy setting). You can configure this setting on the top W3SVC level, which will be automatically inherited by lower-level keys. For the new setting to take effect, restart the IIS service, unless the Enable Direct Metabase Edit setting on the Computer Properties dialog box in IIS Manager MMC snap-in is selected.
On a side note, IIS Metabase is no longer stored in the binary format, but instead consists of two XML files (Metabase.xml and MBSchema.XML), which simplifies edits, backups, and restores.
Secure Sockets Layer 3.0
Secure Sockets Layer is commonly used to secure the exchange of information between Web clients and Web servers over the HTTP protocol. The mechanism employed in this exchange is based on certificates, which not only provide encryption, but also ensure message integrity and allow mutual identification of both parties involved in communication (thus preventing eavesdropping and message tampering). Typically, certificates are installed on the server; however, you can authenticate clients based on their certificates as well. With IIS 6.0, Microsoft supports SSL version 3.0, which includes fixes for some well publicized security holes present in the SSL 2.0.
Customizable Selection of Cryptographic Service Provider
IIS 6.0 offers the choice between Microsoft and third-party CryptoAPI providers when requesting certificates for securing Web communication with Secure Sockets Layer. This is set when running Web Server Certificate Wizard, which is launched from the Directory Security tab of the Web site to be secured. On the Name and Security Setting page of the Wizard, you can specify whether to select a cryptographic service provider for the certificate requested. Once this option is selected, you will be presented with a list of providers installed on the Web server. This is important because calculations performed by SSL encryption algorithms place a significant load on the Web server processors. To alleviate this problem, install specialized devices that can offload processing from the server, with their own set of keys and CryptoAPI providers. The providers must be installed as part of the encryption mechanism. Web Server Certificate Wizard makes this option easy to implement.
ASP.NET as the Primary Development Platform
Introduction of ASP.NET as a new Web development platform brought significant changes to the way applications are written. Even though ASP.NET is not limited to Windows Server 2003 platform (since it is the feature provided by .NET framework, available for every 32-bit versions of Windows), it works best when combined with the new version of the Internet Information Server. For example, ASP.NET applications operate by default in the worker process isolation mode (described earlier in this article) when installed on a Windows 2003 server and can be easily configured to take advantage of Web Gardens on multiprocessor computers (which increases scalability by allowing a single application pool to spread processing across several worker processes).
ASP.NET, like other .NET-framework-based development platform, has built-in support for a number of features that make Web applications more stable and secure. Automatic garbage collection, code access security, and role-based administration are just a few described in previous articles of this series. In addition, ASP.NET offers the ability to maintain state across the farm without the need for cookie support on the client side, which also simplifies maintaining the proper security level.
One of the features made available by combining functionality included in ASP.NET, IIS 6.0, and Windows Server 2003 is URL Authorization. Just as you can control access to applications by configuring role-based security with Authorization Manager (as described in our previous article), you can also control access to specific URLs on a Web server. This mechanism, referred to as URL Authorization, takes effect when when a Web client requests access to a URL configured with Authorization Manager. User identity is matched against a set of defined roles (LDAP queries and Authorization Manager scripts known as BizRules can also be used), which, in turn, determines a user’s access rights to the resources available via requested URL.
URL Authorization is implemented in the form of ISAPI interceptor, which monitors all incoming authenticated HTTP request and communicates with Authorization Manager to determine whether access to a particular URL should be granted. Conditions are evaluated dynamically and can be matched against current conditions, such as time of day. If the response is positive, the interceptor forwards the client’s request for further processing.