Understanding IIS 7.0 Authentication

Authentication is the process that helps a web server confirm the identity of the clients who request access to the server’s websites and applications. Authentication is a fundamental and crucial service—especially if the web server hosts private information or mission-critical applications. Microsoft Internet Information Services 7.0 (IIS)—the web server that’s bundled with Windows Vista and Windows Server 2008—includes several authentication options, both new options and updates to those in earlier IIS versions. We’ll look at how the new authentication features compare with those in previous IIS versions and how they can help you improve control of IIS authentication and your web server’s security. Table 1 compares the different IIS 7.0 authentication protocols. (To learn more about other security-related changes in IIS 7.0, see “Unleash the Power of Microsoft Internet Information Services 7.0's Security Features,” October 2007.)

IIS 7.0 Authentication Methods
Like its predecessors, IIS 7.0 supports the classic HTTP authentication protocols (basic and digest authentication), the typical Windows authentication protocols (NTLM and Kerberos), and client certificate–based authentication. Another long-standing authentication option that’s still around in IIS 7.0 is anonymous or unauthenticated access.

New in IIS 7.0 is support for a logon redirection–based authentication method called forms authentication. Also, in IIS 7.0 Microsoft removed the support for Microsoft Passport–based authentication. Passport, the former Microsoft cookie-based web single sign-on (SSO) solution for MSN and related Microsoft and partner websites, is the predecessor to Windows Live ID, the new Microsoft Web SSO solution for Windows Live and related websites (which IIS 7.0 doesn’t support, either).

A significant change in IIS 7.0 is that these authentication mechanisms aren’t automatically available on each IIS 7.0 installation, as they were in IIS 6.0 and IIS 5.0. Microsoft calls this feature componentization, and it’s a direct consequence of Microsoft’s efforts to further reduce the attack surface of its web server. Componentization means that when you do a fresh IIS 7.0 installation, Windows installs only a bare minimum of software modules, which enable the server to serve static web content to anonymous users. This means that none of the previously mentioned authentication options is available by default. You must explicitly add the authentication options you want during the IIS installation process.

You can select the authentication components you want to make available on your IIS 7.0 server from the Select Role Services page in the Add Roles Wizard during the web server installation, as Figure 1 shows. (See “Unleash the Power of Microsoft Internet Information Services 7.0’s Security Features” for more information about IIS 7.0’s componentization.)

Configuring IIS Authentication
All IIS 7.0 authentication methods—except for client certificate–based authentication—can be configured from the Authentication icon in the Microsoft Management Console (MMC) Internet Information Services (IIS) 7.0 Manager snap-in. You can find this icon in the IIS section in the middle frame, as Figure 2 shows.

If you double-click the Authentication icon, you’ll get a list of all available authentication methods, as you can see in Figure 3.

To set the client certificate–based authentication options for a web server or site, you must use the SSL Settings icon in the IIS pane, as in Figure 2.

IIS lets you enable one or more authentication methods per web server or site. For example, an administrator could allow anonymous access to most web server content and require authenticated access only to certain websites on the server. To do so, the admin would enable anonymous authentication at the web server level and enable, for example, only Windows authentication for the websites that host more important information or applications. To enable an authentication method in IIS 7.0 Manager, you select the authentication method, right-click it, and select Enable, or click the Enable action in the Actions pane.

On a fresh IIS 7.0 installation, only anonymous authentication is enabled by default. To actually authenticate a user to your web server, you must first disable Anonymous Authentication in IIS Manager, then enable one or more of the other authentication methods.

An important restriction that you should be aware of when enabling different authentication methods is that you can’t enable both a challenge-based and a logon redirection–based authentication method at the same time. In other words, you can’t enable forms authentication (which is redirection-based) while basic, digest, or Windows authentication (which are challenge-based) is also enabled.

An easy and powerful option for automating configuration of IIS 7.0 authentication methods is to use the Appcmd (appcmd.exe) command-line utility. For instance, you can use appcmd.exe in a batch file to configure the web servers of a web farm. The Appcmd tool is available on all IIS 7.0 installations. To disable anonymous access, you’d use an Appcmd command like this:

appcmd set config -section:anonymousAuthentication -enabled:false

The -section switch points Appcmd to the IIS anonymous authentication configuration section, and the -enabled:false switch disables anonymous authentication. Note that appcmd.exe is located in the %systemroot%system32inetsrv directory. Because this file system location isn’t automatically part of a Server 2008 or Vista system’s PATH environment variable, you must use the full path to the appcmd.exe executable when executing Appcmd commands. You can also manually add the Inetsrv directory to your machine’s PATH environment variable, so that you can access appcmd.exe directly from any file system location. (For more information about Appcmd, you can find a good introduction to using the tool at http://learn.iis.net/page.aspx/114/getting-started-with-appcmdexe.)

Two other options for configuring IIS 7.0 authentication are either to edit the IIS configuration files directly or to leverage Windows Management Instrumentation (WMI)–based scripting to configure IIS 7.0 authentication. The IIS configuration files are the ApplicationHost.config file, which is IIS 7.0’s main configuration file for storing web server configuration settings, and the Web.config files, which contain website- and application-specific configuration settings.

Anonymous Access
Web sites that host public information typically don’t care about a user’s identity. For these sites, authentication exchanges are just overhead that slow down the information access. This is why web servers include a mechanism to support unauthenticated, anonymous access.

When a user accesses an IIS server anonymously, Windows lets the user access the server’s web resources by using the permissions granted to a special account called the anonymous guest account. In IIS 7.0, this guest account is the IUSR account; it replaces the IUSR_computername account used in previous IIS versions.

IUSR is very different from IUSR_computername. First, IUSR is a built-in predefined account that doesn’t have a password. This means that it can’t be used to log on and will never expire or get locked out. This also means that you don’t have to do password maintenance for the IUSR account. If you open either the MMC Active Directory Users and Computers or Local Users and Groups snap-in, you won’t find the IUSR account; it’s a hidden account, similar to the NetworkService and LocalService accounts.

Second, IUSR is present and identical on all IIS 7.0 systems in your Windows environment. The IUSR account is a generic built-in account; it isn’t localized as is the IUSR_computername account. This means that if you set a file’s ACL to Deny for the IUSR account and copy that file and its ACL to another Vista or Server 2008 system, the ACL will still be valid on the target system (unless, of course, the file’s original ACL is overwritten on the target system by inherited permissions that are defined in a parent folder’s ACL). This helps web server replication and recovery (identical access control entries for the guest account can be leveraged on different systems, and no re-ACLing for the guest account is required during system recovery) and simplifies administration (you can leverage a single guest account on all IIS 7.0 web servers in your environment, no matter how many web servers you have).

You can change the anonymous access credentials to an account other than the default IUSR by using IIS 7.0 Manager’s Edit option for Anonymous Authentication. Remember, though, that if you do so you lose the advantages associated with the use of IUSR (e.g., no password maintenance, identical SIDs).

Basic Authentication
The basic authentication protocol is defined in the Internet Engineering Task Force (IETF) HTTP/1.0 and HTTP/1.1 specifications and is commonly supported by web browsers and servers. Basic authentication provides a simple mechanism to transmit user credentials (a user ID and password) to a web server.

An important security hole in the basic authentication exchange is that the credential information isn’t secured. When you enable basic authentication on pre–IIS 7.0 versions, IIS warns you about this potential security exposure. In IIS 7.0, Microsoft apparently considers this security hole common knowledge because it doesn’t warn you that the credential information is unsecured. (But then also remember IIS 7.0 componentization: A default IIS 7.0 installation doesn’t have the basic authentication bits installed.)

During a basic authentication exchange, the credentials are encoded using Base64, which can be decoded relatively easily. Base64 encoding stores every three eight-bit characters as four six-bit characters. To see how easy it is to decode Base64, you can use an online Base64-decoder tool, such as the one at http://base64-encoder-online.waraxe.us. To better protect your basic authentication-credential exchanges, you must secure them using the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocols. (For more information about configuring SSL/TLS on IIS 6.0—similar to the IIS 7.0 SSL/TLS configuration, see “Configuring SSL/TLS,” March 2006.)

When enabling basic authentication, you can configure a default domain and realm by using IIS 7.0 Manager’s Edit option for Basic Authentication. The default domain lets administrators set the Windows domain to which a user should be authenticated when the user doesn’t explicitly provide a domain during the basic authentication process.

You can enter a realm name to give the user a sense of what he or she is authenticating to—although I recommend that you don’t specify a realm in IIS 7.0. In previous IIS versions, the realm was used to restrict access to certain levels of the IIS metabase. But the metabase no longer exists in IIS 7.0, so specifying a realm is of little use—and I suggest you simply leave the realm field empty. In contrast to the default domain, the realm name is sent to the web browser as part of the basic authentication exchange and also appears in the basic authentication dialog box, as Figure 4 shows.

Digest Authentication
Digest authentication uses a challenge-response–based authentication method to ensure that user credentials aren’t sent over the network in clear text. As such, digest authentication doesn’t require the use of the SSL/TLS protocols. Digest authentication validates user authentication requests against an Active Directory (AD) user account and requires the web server to be an AD domain member.

Unlike basic authentication, digest authentication isn’t supported on all browser and web server types and versions; this is because digest authentication requires HTTP/1.1 support, and not all browsers and web servers support this HTTP version. On the Microsoft side, HTTP 1.1 is supported in Internet Explorer (IE) 5.0 and IIS 5.0 onward.

An important disadvantage of the digest authentication implementations of earlier IIS versions is that digest authentication requires the user password to be stored as clear-text storage in AD, which certainly isn’t a security best practice. You can control the use of clear-text password storage by using the Store password using reversible encryption AD user account property.

To work around this problem, Windows Server 2003 introduced advanced digest authentication, which doesn’t require clear-text password storage. Since advanced digest authentication has become the standard IIS 7.0 digest authentication implementation, the clear-text password-storage problem is no longer relevant in IIS 7.0. An important side-effect of the clear-text storage issue is that the IIS 7.0 digest authentication and IIS 6.0 advanced digest authentication protocols work against Windows 2003 or later domain controllers (DCs) only—because only these DC versions can properly handle the IIS 7.0 digest and Windows 2003 advanced digest authentication requests.

Forms Authentication
Forms authentication, which was available as an add-in option to earlier IIS versions, is now integrated in IIS 7.0. In contrast to the other authentication methods that IIS 7.0 supports, forms authentication lets web-application administrators and developers manage user registration and authentication at the application level, without needing to use the built-in Windows authentication mechanisms and identities.

Forms authentication uses a redirection mechanism to a logon page to determine the user’s identity. When a user connects to a document hosted on a site that’s protected using forms authentication, the user will enter his or her username and password at a logon screen, which then passes the user’s credentials to an authentication and credentials database, such as a Microsoft SQL Server database. The forms-based authentication mechanism then performs some sort of matching process to verify that the entered credentials match what’s in the forms-based authentication credential database.

The new out-of-the box support for forms authentication is possible because in IIS 7.0 Microsoft merged the IIS and ASP.NET authentication models, aka the IIS and ASP.NET authentication pipelines. In the pre–IIS 7.0 model, IIS examines a web request, performs its authentication routines, then passes the request to ASP.NET so that it can perform similar authentication tasks.

In IIS 7.0, Microsoft has produced a new unified authentication pipeline that incorporates the best aspects of the older models. IIS 7.0 still supports all the old authentication protocols as well as forms authentication. Prior to IIS 7.0, forms authentication could be configured only for ASP.NET web content, whereas in IIS 7.0 forms authentication can be used for all content types. Having only one IIS authentication model to deal with greatly simplifies the jobs of web administrators and .NET application development.

Windows Authentication
IIS Windows authentication (called Integrated Windows authentication in earlier IIS versions) consists of two authentication protocols: NTLM and Kerberos, which are typically supported only in Microsoft browsers. (Windows authentication never transmits the password in the clear and thus doesn’t require the use of SSL/TLS.)

Of all the web authentication protocols I’ve discussed so far, Windows authentication requires the least configuration and user intervention. Windows authentication doesn’t prompt the user to provide his or her credentials in a dialog box; instead, IE automatically retrieves the credentials from the user logon session’s credentials cache—unless Integrated Windows authentication has been disabled in the IE configuration settings. In IE, you can enable or disable Integrated Windows authentication support through the Enable Integrated Windows Authentication setting on the Internet Options Advanced tab. (You need to restart IE for this setting to take effect.)

Windows authentication also has some less-attractive features. For example, NTLM authentication doesn’t work across most HTTP proxies because it requires persistent point-to-point connections between the web browser and server. The IIS web server keeps the HTTP connection open for the duration of the NTLM challenge/response sequence. But web proxies typically close the HTTP authentication connection after they receive a 401 Access Denied HTTP error message (which is a part of the NTLM challenge/response sequence). Notable exceptions to this rule are the Squid proxy (www.squid-cache.org) and Microsoft ISA Server running in proxy (cache-only) mode: These proxies can deal with NTLM authentication traffic. A possible workaround for the NTLM proxy issue is to tunnel the HTTP traffic using, for example, an IPsec or L2TP tunnel. But then again, few organizations allow the creation of VPN tunnels that bypass their proxies and/or firewalls.

Kerberos authentication is available only on IE 5.0 or later browsers and IIS 5.0 or later web servers. For Kerberos authentication to work, the browser user and web server must be in the same or a trusted Windows 2000 or later domain, the browser must have permanent access to a DC (which means that you must open Kerberos TCP port 88 on your firewalls), and the web server must have a valid Service Principal Name (SPN) that’s registered in AD.

Given these limitations, Windows Authentication is best suited for intranet web authentication and is unsuitable for authentication in an extranet or Internet environment where web browsers and servers are separated by proxies and firewalls.

Client Certificate–Based Authentication
Client certificate–based authentication uses the SSL/TLS protocols to authenticate web users. To use this authentication method, your web server must have a server SSL certificate installed and you must deploy certificates to your clients. Although client certificate–based authentication is the most secure form of web server authentication, it includes the overhead of obtaining and managing client certificates. You can obtain client certificates either by buying them from commercial Certification Authorities (CAs) such as VeriSign or through your internal public key infrastructure (PKI).

IIS supports a mapping mechanism that lets administrators map client certificates to AD or SAM (the local security database on a standalone Windows machine) accounts. This mapping enables both strong authentication and authorization simultaneously: External users can authenticate to web content using certificates, and administrators can use an internal account for setting permissions on their resources and constraining what data external users can access.

As in previous IIS versions, IIS 7.0 still supports AD-level and IIS-level certificate mapping. AD-level mapping means that the certificate mappings are stored in one central AD that multiple IIS servers can leverage. IIS-level mapping means that the certificate mappings are defined in an IIS server’s configuration files.

Unlike in previous versions, the certificate-mapping configuration options are no longer available through the IIS Manager snap-in. But you can still configure certificate mapping either by directly editing the IIS XML configuration files or by using WMI, the appcmd.exe tool, or a Visual Basic (VB) script. You can find a useful sample VBScript script for setting up certificate mapping at http://blogs.iis.net/ulad/archive/2007/01/19/vbscript-to-configure-one-to-one-client-certificate-mapping-on-iis7.aspx. And you can get more information about configuring certificate mapping in IIS 7.0 at http://go.microsoft.com/fwlink/?LinkId=78498.

More Authentication Choices
IIS 7.0 offers a rich array of authentication options, to enable you to choose the level of authentication that will adequately secure your web server from unauthorized access. Unlike earlier versions of IIS, which enabled all authentication types by default, IIS 7.0 offers authentication options as separate components, requiring you to select and enable only those you really need. This gives you more control over IIS authentication and also might help you to give more thought to the type of web server authentication that’s optimal for your environment.