IIS Authentication
When a client machine connects to an IIS server, it will almost always connect as either an anonymous user (i.e., no user credentials supplied) or with supplied user account credentials. In IIS, user credentials can be stored in Active Directory or the local SAM, handled by an application, or stored in an external authentication database source. IIS allows seven different kinds of default authentication:
Authentication methods can be configured in the IIS Admin tool by choosing the Authentication icon under the IIS pane (see Figure 1). One or more authentication methods can be selected per Web site, per folder, or per file (see Figure 2). For example, an administrator can allow anonymous connections to most of their Web site content, but require authenticated access to a particular folder or file. Disable or remove unused authentication methods.
| Note |
If anonymous and other authenticated methods are allowed at the same time, most browsers will try the anonymous connection first.
|
Anonymous Authentication
When a browser connects to IIS without supplying user credentials, which is often the case when a browser connects to a public Web site, IIS allows the user to access the Web site with the permissions assigned to the related IIS anonymous user account. Any account intended to be used as an IIS anonymous account should be in the IIS_IUSRS group.
Membership in the IIS_IUSRS group gives contained accounts Read and Execute permissions to \Inetpub\wwwroot, the default Web site location. If the referenced Web site is not located there, the anonymous account or the IIS_IUSRS group will need to be given the necessary permissions to the referenced content locations.
A new important change in IIS 7 is that anonymous web content can now be more easily run in the context of the site's application pool identity instead of the anonymous user. This could be accomplished in IIS 6 as well, but required more steps. Figure 3 shows the application pool and its identity being used instead of the defined anonymous user account.
ASP.NET Impersonation
ASP.NET Impersonation allows a developer to run their ASP.NET application in the security context of an authenticated Active Directory or local account user, or as another specific user (see Figure 4). ASP.NET Impersonation is disabled by default, and if enabled, defaults to the authenticated user option.
Basic Authentication
Basic Authentication is an older but widely supported HTTP standard that allows the user to log on using a SAM or Active Directory account. The user is prompted to input his or her logon name and password, and the browser encodes the information using Base64 encoding and transmits it to the server. Although Base64 encoding is not plain-text, it is near enough, and extremely easy to decode back to its plain-text original. Basic Authentication should not be used except in cases where backward compatibility is needed. You can enable Basic Authentication for compatibility reasons and use SSL/TLS (or another protective tunnel such as IPsec) to strongly protect the authentication stream.
Digest Authentication
Digest Authentication allows remote clients to use Active Directory user accounts to authenticate if the web server is a member of an Active Directory domain. The server must use Windows 2000 and IIS 5 or above and the client must be IE 5.0 or above. The user's account must also have the "Store passwords using reversible encryption" option enabled. When enabled, clients can authenticate using their normal user account, and the authentication transaction does not transmit the users in plain-text (unlike Basic Authentication).
| Note |
If Digest Authentication is used on a Windows Server 2003 web server running in a Windows 2003 domain, Digest Authentication can become Advanced Digest Authentication (using more secure MD5 hashes).
|
Forms Authentication
Forms authentication is a new IIS 7 logon feature that can be installed on a web page by including a file called Login.aspx or its related code into an existing web page. When a user connects to a referenced document, it presents them with a login name and password prompt screen that will then pass the credentials from IIS to an external authentication database, such as Microsoft SQL or Oracle, or to any installed security provider. You can do this with ASP.NET applications prior to IIS 6. However, in IIS 6, it works for ASP.NET content only. In IIS 7, it will work for all content.
Windows Authentication
Windows Authentication (formerly called Window Integrated Authentication or Integrated Windows Authentication) allows a client to connect using one of the normal Windows logon authentication methods (LM, NTLM, NTLMv2, or Kerberos). This method requires that the client and IIS server reside in the same domain, and for that reason Windows Authentication does not normally work over the Internet. NTLM and NTLMv2 can get past a firewall but are generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.
Windows Authentication is intended for internal intranet sites, where the user should not be bothered by being asked to re-authenticate when they connect to the intranet server. Any Web site in the user's intranet sites zone using Windows Authentication will not prompt the user for logon credentials unless the logon credentials are valid. The default option of whether to always be prompted or not is set under each security zone's settings in Internet Explorer . The remaining authentication methods will always prompt the user for logon credentials and pass them to the web server.
Client Side Mapping
SSL/TLS Client Side Mapping is another potential default IIS authentication method. If SSL/TLS is enabled on a Web site, the Web site can also require that the client provide an authenticated SSL certificate, as well. The client's SSL/TLS certificate can be stored in Active Directory (i.e., mapped), so that when the Web site requests it, it can be retrieved from the user's Active Directory user object and handed to the server for validation. This is a very secure form of authentication but requires heavy initial and ongoing administrative use of a PKI infrastructure.
In previous versions of IIS, all of the authentication methods came as one default package. If IIS was installed, then all of these methods could be used. Only the anonymous user was enabled by default on the Default Web Site, but any authentication method could be turned on with a simple mouse click. In IIS 7, each individual authentication method can be enabled or disabled on a per module basis. For example, if the Web site doesn't use Basic Authentication, the administrator can remove the Basic Authentication module, and the code will not even be available in IIS for use or exploitation.
Table 1 summarizes the basics of each IIS authentication method.
Table 1: IIS Authentication Method Summary
 Open table as spreadsheet
|
METHOD
|
SECURITY LEVEL
|
HOW PASSWORDS ARE SENT
|
CROSSES PROXY SERVERS AND FIREWALLS
|
CLIENT REQUIREMENTS
|
|
Anonymous authentication
|
None
|
N/A
|
Yes
|
Any browser
|
|
ASP.NET Impersonation
|
Medium
|
Obscured
|
Yes
|
.NET
|
|
Basic authentication
|
Low
|
Base64 encoded clear text
|
Yes, but sending passwords across proxy server or firewall in clear text is a security risk because Base64 encoded clear text is not encrypted.
|
Most browsers
|
|
Digest authentication
|
Medium
|
Hashed
|
Yes
|
Internet Explorer 5 or later
|
|
FORMS Authentication
|
None
|
Plain-text
|
Yes
|
.NET
|
|
Windows authentication
|
High
|
Hashed when LM or NTLM is used; Kerberos ticket when Kerberos is used.
|
No, unless used over a VPN connection
|
Internet Explorer 2.0 or later for NTLM; Windows 2000 or later with Internet Explorer 5 or later for Kerberos
|
|
Certificate authentication
|
High
|
N/A
|
Yes, using an SSL connection
|
Internet Explorer and Netscape
|
| Note |
Windows Authentication provides significant protection as compared to Basic and Digest Authentication methods. However, like regular Windows logons, Windows Authentication can use either LM or NT password hashes and LM, NTLM, NTLMv2, or Kerberos authentication protocols. As discussed in previous chapters, LM password hashes and LM and NTLM authentication protocols, if used, can be cracked fairly easily. If Windows Authentication is going to be used, ensure that only NT password hashes are used, and that only NTLMv2 or Kerberos authentication protocols are used in the process.
|
Table 2 discusses the various advantages and disadvantages of the authentication protocols requiring logon credentials.
Table 2: Comparison of Authentication Methods Requiring Credentials
Open table as spreadsheet
|
AUTHENTICATION METHOD
|
ADVANTAGES
|
DISADVANTAGES
|
|
Basic Authentication
|
Doesn't require IE or Active Directory. Supports authentication through firewalls and proxies. Can be used to authenticate local accounts. Stores hash of the user credentials in Active Directory.
|
Plain-text transmission of credentials. Low security. Consider using adjunct security tunnel, such as SSL, TLS, or IPsec if Basic Authentication is desired.
|
|
Windows Authentication
|
Protects user credentials. Provides high security. Requires IE 2.0 or later (5.0 and later for NTLMv2 and Kerberos authentication).
|
Requires Microsoft clients. Will not work across a proxy server. May use low-level encryption for LM depending on the specifics.
|
|
Digest Authentication
|
Protects user credentials. Provides medium security.
|
Requires Internet Explorer 5 or later.
|
|
Forms Authentication
|
Easy to set up logon authentication on any Web site; can be hooked to external authentication source.
|
Logon credentials not protected by default, should be used with SSL/TLS.
|
|
Client Certificates
|
For server authentication (certificates stored on the server), your organization obtains certificates from a trusted certification authority. For client authentication, map certificates to users' accounts stored in Active Directory running on Windows 2000 Server or later. Provides high security.
|
For client authentication (certificates stored on the clients), your organization has, or is willing to deploy, a public key infrastructure (PKI). For client authentication, you have a method of securely distributing the certificates to the clients.
|
It's also important to remember that most of the IIS logon authentication methods are more concerned with transmitting authentication credentials between the remote client to the server and are not as concerned with integrity and confidentiality issues. To ensure those latter points, use an adjunction protection tunnel such as SSL/TLS or IPsec.
|
