IIS Security Default Settings

  • Article

This topic describes the state of IIS when installed or upgraded, and changes in the security features in IIS 6.0.

State of IIS when Upgraded

In most cases, IIS does not change configuration settings during an upgrade from one version to another. There is a case where a metabase property might be deprecated in a new version of IIS, or might behave differently; however these changes are the result of customer requests or interests.

For a list of metabase properties and which versions of IIS they apply to, see IIS Metabase Properties.

State of IIS during a Clean Installation

Starting with IIS 6.0, IIS includes a new security lockdown feature, which uses a manifest to specify the DLLs or EXEs that are allowed to run on an IIS server. By default, IIS serves only static content, which means that features like ASP, ASP.NET, Server-Side Includes, WebDAV publishing, ISAPI, and FrontPage Server Extensions do not work. You can serve dynamic content and "unlock" these features through the IIS Manager, or by using the iisext.vbs command-line tool.

Before IIS loads a DLL to handle a request, it checks the manifest for the file to load and determines whether that file is allowed to run. If it is, the request proceeds normally. If it is not, IIS returns an HTTP 404.2 custom error response to the client, indicating that the requested item does not exist. The HTML page for this response appears the same to the client as a standard 404 response, but the 404.2 error is logged (in W3C and binary-formatted logs)so that the administrator can determine what happened.

Generally, an upload directory on a server should not have execute permissions. If it does, it is possible for someone to upload executable code and run it on the server. In IIS 6.0, however, even if an executable DLL or EXE file is uploaded, it cannot be run unless the manifest indicates that it is allowed to.

The lockdown functionality of Web service extensions applies globally to the server, whether IIS is loading the code as a part of a script-mapped request or in response to an explicit client request for a DLL.

For information on how to work with this feature, see Enabling ASP, ASP.NET, CGI, and ISAPI Extensions and Installing and Uninstalling CGI and ISAPI Extensions.

Security Changes in IIS Features

IIS 6.0 includes the following security changes:

  • Many of the security features available in IIS 4.0 have been simplified. In IIS 5.0, IIS 5.1 and IIS 6.0, there are three new security task wizards:

    • Permissions Wizard

    • Web Server Certificate Wizard

    • CTL Wizard.

    With these three wizards, you can synchronize Web and NTFS security settings, obtain and install server certificates, and create and modify certificate trust lists. In IIS 5.1 and IIS 6.0, you can select a cryptographic service provider (CSP) for encrypting data with a certificate.

  • Index this resource is now enabled by default.

  • Script source access, which allows access to the source code of scripts in ASP pages and other scripts, is new and is disabled by default. It cannot be enabled unless Read or Write access is also enabled.

  • Sub-authentication is no longer enabled by default on a new installation of IIS 6.0. For more information, see AnonymousPasswordSync.

  • FrontPage Web, which allows administration of sites on your server by using FrontPage, is no longer set manually in IIS Manager. It is enabled by default.

  • Fortezza support has been removed.

  • There has been a change in the IIS WMI provider for Windows Server 2003 SP 1 and Windows XP SP2 that requires customers to update WMI-based scripts that operate over a remote connection. Network encryption for WMI is on by default. If you create an application or script that is intended to administer IIS on a remote computer running Windows Server 2003 SP1 or later, you must use the AuthenticationLevel property. WMI-based scripts that do not encrypt the connection when administering IIS remotely fail with an Access Denied error (WBEM_E_ACCESS_DENIED, 0x80041003). For information on how to configure encryption in WMI-based scripts, see Encrypting Data When Running WMI-Based Remote Administration Scripts in the IIS Administration Guide.

  • When using ADSI to configure IIS, ensure that the user account of the person running the script is a member of the administrators group. When you are using the WinNT provider, we recommend that you authenticate with the target server by logging onto a domain account with appropriate credentials or using the LogonUser function (which requires elevated privileges) prior to executing your ADSI code. For more information, see User authentication issues with the ADSI WinNT provider and INFO: Security Ramifications for IIS Applications.

The following articles might be of interest to customers who use ADSI and WMI to configure IIS: