IIS Authentication Methods

IIS Authentication Methods

IIS plays a crucial part in online application security by serving as the first checkpoint on a request's path into your system. IIS tightly integrates with the Windows operating system and can authenticate user requests based on local machine or domain Windows accounts associated with the request.

You configure IIS authentication methods and other security- related parameters by using the IIS management plug-in located in Administrative Tools in the Control Panel. To view available IIS authentication methods, open the Properties dialog box for your web site using the IIS plug-in and click the Directory Security tab, as shown in Figure 6.2.

Figure 6.2. Configuring Site Security

IIS can authenticate user requests through one of five different approaches:

• Anonymous authentication

• Basic authentication

• Digest authentication

• Integrated Windows authentication

• Certificate authentication

The IIS dialog box shown in Figure 6.3 allows administrators to select and configure IIS authentication.

Figure 6.3. IIS Authentication Methods Dialog Box

If you disable Anonymous authentication and enable all other authentication methods, IIS will try to authenticate each incoming user request by using the most secure authentication methods. It will start with Integrated Windows authentication and, if that fails, will work its way up to Basic authentication.

Anonymous Authentication

If you select this mode (which is enabled by default), anyone can access your site. IIS can still restrict anonymous user access by filtering out certain IP addresses. If this mode is selected, user credentials are not requested and the same Windows account is used to execute on behalf of the connecting user. By default, this account, called IUSR_<MACHINE NAME>, is controlled by IIS. If you override the default settings by supplying a different account for anonymous access or by modifying the password used by IUSR_<MACHINE NAME >, be sure to enter the changes in the Authentication Methods dialog box shown in Figure 6.3. Otherwise, connections will fail.

Selection of the account used for an anonymous access is very important for your portal's security. The IUSR_<MACHINE NAME> account belongs to the GUESTS group and its access rights are fairly limited. If you select a different account, do not give it wide access. Using an account belonging to the Administrators group would be a poor choice security-wise for anonymous access.

Anonymous access does not provide any security restrictions and is recommended for public areas of web sites or portals. If you are trying to encourage casual visitors to access your content, you do not want to ask them to log in. Many users click the Back button when faced with a logon screen. There are no client browser limitations for this type of authentication, so all browsers are supported for anonymous access.

Basic Authentication

Basic authentication uses the browser logon features. When a user tries to connect to a site protected by Basic authentication, the user's browser opens a Login dialog box. IIS uses the credentials gathered from a login dialog box to match user information with an existing Windows domain account. If the account is found, IIS uses Windows security features to check the account privileges and access rights.

Because a Windows domain account list is used for user validation, using Basic as your authentication method means that each user of your site must have a valid Windows domain account. The general rule of thumb for granting rights to these Windows accounts is to be minimalist: Administrators should grant the smallest subset of privileges that would allow users to perform their tasks . Each account must be granted Log On Locally rights.

The Basic authentication method derives its name from the fact that both username and password are passed to IIS in base64-encoded form. Base64 encoding is not an encryption method and is easily decoded with simple code. Both username and password therefore are passed in the equivalent of plaintext ”a gigantic security risk. If the data stream were intercepted, the hacker would have little trouble cracking the username and password. In fact, IIS informs you that you are taking chances when you enable this form of authentication.

To alleviate this problem, you can use secure sockets layer ( SSL ) , a technology for encrypting and protecting the whole channel of communication. With SSL, all communication between the server and client is encrypted. Basic authentication with SSL is recommended for use on an intranet or when the usage of a portal is limited to a well-defined and relatively static group of users.

Digest Authentication

Digest authentication resembles Basic authentication, but it is augmented to make it significantly more secure. As with Basic authentication, the client browser prompts the user for a username and password. The browser then combines the user's responses and some other information available on the client (requested URL) to create a hash or digest of this information, which then is passed to the IIS. IIS takes this hash value and decrypts the password portion, which is then used to perform a network logon. For it to function, the server must store a copy of each such digest.

By default Windows does not store user passwords anywhere . Windows uses an ingenious technology that creates an encrypted value using both the username and password; this value and not the password is stored internally and used to validate user credentials. Windows is therefore a very secure system because even administrators do not have a way to obtain users' passwords. As a result, enabling Digest authentication would weaken Windows security by storing actual password values (albeit encrypted) on a server.

Another potential problem with Digest authentication is its susceptibility to replay attacks: If a hacker manages to snoop on a channel while a client browser and IIS are exchanging authentication data, he could record the user's digest and then use it to impersonate the user. While the chances of this kind of attack happening are very low, it is theoretically possible.

In spite of these issues, Digest authentication provides a reasonably high level of security. It also requires a valid Windows account for each user. Currently only Internet Explorer 5.0 or later supports Digest authentication, which is usable when access across proxy servers and a firewall are required.

Integrated Windows Authentication

Integrated Windows authentication uses Kerberos (an advanced authentication mechanism that appeared first in Windows 2000 and is used whenever both the client and server are running a Windows 2000 operating system or later). Pre “Windows 2000 systems use NTLM, an authentication mechanism used by NT4. While Integrated Windows authentication uses a hashing algorithm to pass and validate user credentials and is a very secure technology, it does have an important limitation: Many firewalls will block it so it is useful primarily on intranets . Like Digest authentication, Integrated Windows authentication requires each portal user to have a valid domain account.

Integrated Windows authentication has several attractive advantages: It provides a high degree of user identity protection while tightly integrating with the rest of the client/server pieces in the Microsoft world, thus requiring minimum additional effort to implement. It allows seamless hidden authentication: After users have been authenticated by NTLM or Kerberos as they log in to Windows, they can log in to sites protected by Windows authentication without being prompted to log in again. This single sign-on is a highly desirable portal feature.

Internet Explorer is the required browser for applications employing Integrated Windows authentication.

Certificate Authentication

Digital certificates form a part of the SSL implementation of IIS and work as a means of identifying the certificate owner. Certificates are used by both clients and servers to identify each other and contain encryption keys. Client certificate and server certificate encryption keys form a key pair used by SSL to facilitate data encryption and decryption and to establish a secure communication channel. Client certificates contain information required by the server to identify each client, and server certificates contain data allowing each client to verify the server's identity.

To enable Certificate authentication, you must obtain and install a valid server certificate on your web server. Generally, server certificates can be obtained from an accepted third-party certification authority (CA) such as Verisign. Such organizations are trusted to validate the identification information contained in a server certificate. If you are building an internal portal, you can use Microsoft Certificate Server to create and distribute certificates internally without using outside CA organizations.

You should use the IIS snap-in to install security certificates:

1. Open the Properties dialog box for your site.
   
   
2. Click the Directory Security tab.
   
   
3. Click Server Certificate to launch the Web Server Certificate wizard (see Figure 6.4).
   
   

   Figure 6.4. Request Server Certificate

   

   
   
4. Enter your organization parameters, select one of the CA organizations, and send the certificate request to the certification authority.
   
   

When the certificate authority gives you the file containing the server certificate, you use the same wizard to apply the certificate to your server.

Certificates let you create mappings between client certificates and user accounts. Certificate mapping is very flexible: You can map multiple user accounts to a single certificate or a single user account to multiple certificates using wildcard pattern matching; you can also create one-to-one mapping. For example, a many-to-one mapping strategy can be helpful in very large networks. For a network on which it is easier to allow each user to obtain a client certificate than to maintain separate Windows accounts, a portal administrator can set up special Windows accounts according to the roles established for the portal users and then set up several matching rules to establish a client certificates “Windows account connection.

Certificate authentication is a very secure authentication method. It works with both Internet Explorer and Netscape Navigator browsers and requires SSL. Certificate authentication is the widely accepted authentication mechanism for protecting online transactions. You can find more about client and server certificates on the MSDN site at www.microsoft.com/windows2000/en/advanced/iis/htm/ core /iicerts.htm?id=90.

IP Address and Domain Name Restrictions

Although IP Address and Domain Name Restrictions is not an authentication method, it often serves as the first barrier to prevent unauthorized traffic. This security mechanism uses rules to block traffic from certain originating IP addresses. These restrictions only allow access to users from a specified domain or network. For instance, you could block intranet access to anyone with an IP address that falls outside the range you specify.

To set up IP address restriction rules:

1. Using IIS Manager, open the Properties dialog box of your web site by right-clicking the web site name and selecting Properties .
   
   
2. Click the Directory Security tab.
   
   
3. Click Edit in the IP Address and Domain Name Restrictions section of the tab.
   
   
4. In the IP Address Restrictions dialog box, grant or deny site access based on incoming IP addresses or domain names . Figure 6.5 shows how to configure IIS to grant access to all callers except those coming from 192.168.0.1.
   
   

   Figure 6.5. IP Address and Domain Name Restrictions Dialog Box

   

   
   

IP address restrictions rules are available on Windows servers beginning with NT4 (NT4, Windows 2000, Windows XP, Windows 2003 server families) and are not available on the NT4 workstation, Windows 2000 Professional, or Windows XP Professional.