6.2 Introducing IIS authentication

Microsoft’s Web server supports the classical HTTP authentication methods—basic and digest authentication—and certificate-based authentication based on the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. These three authentication methods are discussed extensively in this chapter. Besides these three, IIS also includes support for the typical Windows authentication methods—NTLM and Kerberos authentication—and Microsoft’s Internet Single Sign-On authentication protocol—MS Passport. NTLM and Kerberos authentication were explained in great detail in the previous chapters. In this chapter we will look at how the Kerberos and NTLM protocols fit into the IIS authentication exchange and configuration. The built-in support for MS Passport authentication is new to IIS 6.0. It will be explained in greater detail in Chapter 7.

The IIS authentication options can be set from the properties of an IIS Web site, directory, or file (as illustrated in Figure 6.2) in the ISM: Go to the Directory Security tab, then click the Edit… pushbutton in the “Authentication and access control” section. To set SSL authentication options for a Web site, directory, or file, click one of the buttons in the secure communications section of the Directory Security tab. You can also set the authentication options globally for the complete Web server using the master Web site properties. The latter are accessible from the properties of the Web sites container in the ISM.

Figure 6.2: Configuring IIS authentication options.

By default, every Web resource has both anonymous access and integrated Windows authentication enabled. This means that IIS will always first attempt to give a user access using anonymous (or unauthenticated) access. If this does not succeed, IIS will try to give the user access using integrated Windows authentication and the user’s Windows credentials. If you have enabled the integrated Windows, digest, and basic authentication options, IIS will first try to give users access using the integrated Windows and digest authentication protocols—only after trying these two methods and failing will it try with the basic authentication protocol.

These authentication options are not the only authentication options that can be made available to an IIS user. Web site administrators and application developers can also build their custom authentication methods or rely on authentication solutions provided by other software vendors. A good example of an IIS authentication solution from another vendor is the SecurID authentication plug-in from RSA Security^[3] (illustrated in Figure 6.3; more information can be found at http://www.rsasecurity.com/products/securid/techspecs/windows.html). A good example of a custom authentication method is forms-based authentication.

Figure 6.3: SecurID-based IIS authentication.

In a forms-based authentication scenario, a user enters his or her authentication credentials on a Web page and then the Web page’s code logic validates the credentials against a credential database. The credential database can be any kind of repository (an LDAP-accessible directory, an SQL database, and so forth). Some of these custom authentication methods do not rely on the built-in Windows security mechanisms and services such as security principals, accounts, and credential databases (like the AD and the SAM). Custom IIS authentication methods are not explained in this book. A good example of a custom authentication method is explained in the IIS 6.0 Resource Kit; the example is named CustomAuth Version1.0. Another example is Exchange Outlook Web Access (OWA) formsbased authentication.

^[3]At the time of writing, no SecurID agent was available for IIS 6.0. More info is available at the following URL: http:// www.rsasecurity.com/products/securid/techspecs/windows.html..