Managing Web Server Security in Windows Server 2008 R2

Lesson 2: Controlling Access to Web Services

Web servers are deployed in many configurations. Some servers provide content intended for the general public through the Internet. Others contain web application content intended only for a limited set of users. Web server administration must be able to define which users can connect to a web service and, after users have proven their identities, rules must be in place for determining which content is available to them.

In this lesson, you learn about how you can configure authentication and authorization for protecting web content in IIS. Due to the many security standards and approaches for web services, it is important to understand how to select the most appropriate one for a given scenario. You also learn how you can use features such as IP Address And Domain Restrictions and .NET trust levels to secure your web services further.

Managing IIS Authentication

Authentication refers to the process by which a user or computer proves its identity for security purposes. The most familiar method is through a logon or username and an associated password. When working with web servers such as IIS, authentication settings and options determine how users will provide their credentials to access content stored on the web server. IIS provides numerous methods for securing content. By default, content stored in new websites, web applications, and virtual directories will allow access to anonymous users. This means that users are not required to provide any authentication information to retrieve the data. In this section, you learn about the authentication modes supported by IIS and how you can configure them.

Understanding Anonymous Authentication

For many types of web servers, users should be able to access at least a default page or some content without being required to provide authentication information. When you enable the Web Server (IIS) role by using default options, anonymous authentication is enabled for the Default Web Site and its associated web content. Anonymous authentication is designed to provide access to content that should be available to all users who can connect to the web server. An example is the default IIS webpage for Default Web Site. When IIS receives a request for content, it automatically uses a specific identity to attempt to complete the request. By default, anonymous authentication uses the IUSR built-in account. (See Figure 6-20.) As long as this user account has permission to access the content (based on NTFS permissions), the request is processed automatically.

It is also possible to use the Set option to provide a username and password for a different account. This is useful when you plan to use different NTFS permissions for different web content. Finally, there is an option to use Application Pool Identity. This setting instructs IIS to use the same credentials that are applied to the application pool used by the website or web application.

If all the content on the web server should be available to all users, then no further authentication configuration is required. More commonly, however, you want to restrict access to at least some content on the server. For example, an intranet server might include a web application or virtual directory that is intended for only members of the Human Resources department. To restrict access to content, you can use NTFS permissions. If the credentials configured for the anonymous authentication option are insufficient to access the content, it will not be returned to the user automatically. Generally, you enable one of the other available authentication methods so that authorized users can access the content.

Understanding Forms Authentication

A common security approach web developers use is to use standard HTTP forms to transmit logon information. Forms authentication uses an HTTP 302 (Login/Redirect) response to redirect users to a logon page. Generally, the logon page provides users with locations to enter a logon name and password. When this information is submitted back to the logon page, it is validated. Assuming that the credentials are accepted, users are redirected to the content they originally requested. By default, form submissions send data in an unencrypted format. To secure the transmission of logon information, enable encryption through SSL or TLS.

Forms authentication is the most common approach used on the Internet because it does not have any specific web browser requirements. Web developers typically build their own logon pages. Logons are often validated against user account information stored in a relational database (for Internet sites) or against an Active Directory Domain Services (AD DS) domain.

The default settings for forms authentication are designed for use by ASP.NET web applications, and the Forms Authentication option appears only when you have added the ASP.NET role service to the Web Server (IIS) role. You can edit the settings of forms authentication to manage several settings. (See Figure 6-21.) The primary setting is the Login URL. This specifies the name of the webpage to which users are sent when they attempt to access protected content.

After the user has provided authentication information, cookies are sent from the web browser to the web server during each request. This enables the client to prove that it has authenticated with the web server, which is necessary because HTTP is a stateless protocol. The Cookie Settings section enables you to configure how cookies will be used by the site. The Mode options include:

• Do Not Use Cookies

• Use Cookies

• Auto Detect

• Use Device Profile

The most appropriate option will be based on web browser requirements (for example, whether your website requires users to enable support for cookies) and the requirements of the web application or web content.

Understanding Challenge-Based Authentication

Users who access secure websites on the Internet are familiar with the process of providing a username and password to access secured content or to perform actions such as placing online orders. IIS supports three methods of presenting a security challenge to users who are attempting to access web content that has been secured using file system permissions. Each of these methods relies on sending an HTTP 401 Challenge—a standard method that prompts users to provide logon information. These three authentication methods are:

• Basic authentication Presents an authentication challenge to web users through a standard method that is supported by all web browsers. The main drawback to this method is that information users provide is encoded but not encrypted. This means that, if the information is intercepted, the logon and password details can be obtained easily. To transfer basic authentication information securely, either ensure that your network connections are secure (for example, in a data center environment) or enable encryption using SSL or TLS.

• Digest authentication Relies on the HTTP 1.1 protocol to provide a secure method of transmitting logon credentials. It does this by using a Windows domain controller to authenticate the user. A potential drawback is that it requires clients’ web browsers to support HTTP 1.1. Current versions of most popular browsers support this method, so it is possible to use digest authentication for both Internet and intranet environments.

• Windows authentication Provides a secure and easy-to-administer authentication option. It relies on the use of either the NTLM or Kerberos authentication protocol to validate users’ credentials against a Windows domain or local security database. This method is designed primarily for use in intranet environments, where clients and web servers are members of the same domain. To simplify administration, administrators can use AD DS domain accounts to control access to content.

One important consideration about these challenge-based authentication methods is their interaction with anonymous authentication. If you want to require users to provide logon information before accessing web content, you must disable anonymous authentication. If anonymous authentication remains enabled, content that is not protected by using file system permissions is automatically made available to users without requiring authentication. Another requirement to note is that you cannot enable both forms authentication and challenge-based authentication for the same content.

Understanding ASP.NET Impersonation

Like form authentication, ASP.NET impersonation appears as an authentication option when you add the ASP.NET role service. Impersonation is a security method by which an IIS web request is processed by using the security information provided by a specific user account or by the user who is accessing the site. When ASP.NET impersonation is disabled (the default setting), the security context for processing requests is based on the account the web application uses. When you enable impersonation, you can specify a user account for determining the security context. (See Figure 6-22.) To provide the username and password information, click Set.

Another option is to configure ASP.NET impersonation to the Authenticated User option. This setting specifies that the security permissions of a user who has been authenticated (using one of the other authentication options) will be used to provide access to content. This setting is useful when you want to use file system permissions that use specific users and groups to decide which content should be protected. When used in this way, it is most appropriate for environments that support relatively small numbers of users, such as department-level intranet web servers.

Understanding Client Certificate Authentication

In addition to the other available authentication options, IIS provides support for using client certificates to validate the identity of a web user. This method requires users to have security certificates installed on their computers. When a request is made for protected content, IIS automatically validates the identity of the client by querying the certificate information. There are three main modes by which client certificates can be used:

• One-To-One mappings In this configuration, the web server must contain a copy of the client certificate used by every computer that will access restricted content. The server compares its copy of the certificate with the one presented by the client to validate requests.

• Many-To-One mappings It is often impractical to manage certificates for all possible web users on the server. Although this method is slightly less secure, many-to-one mappings are based on the web server performing authentication by using certain information found in the client certificate. A common example is validating the organization information in the certificate to ensure that the user is coming from a trusted company.

• Active Directory mappings Active Directory Certificate Services can simplify the creation and management of client certificates. To enable this method, organizations must first set up their own certificate-based infrastructure.

Because of the certificate requirements for client certificate authentication, this method is most often used in environments in which systems administrators have control over end users’ computers. It is impractical to require certificates for publicly accessible Internet websites and applications.

Understanding Authentication Requirements

Handlers and modules manage IIS authentication. The specific authentication options available for a web server are based on the Web Server (IIS) role services installed. The list of available role services includes:

• Basic Authentication

• Windows Authentication

• Digest Authentication

• Client Certificate Mapping Authentication

• IIS Client Certificate Mapping Authentication

• ASP.NET (for forms authentication and ASP.NET impersonation)

To add or remove a security-related role service, open Server Manager, expand the Roles section, right-click Web Server (IIS), and then select either Add Role Services or Remove Role Services. (See Figure 6-23.) Because role services affect the available authentication options for the entire web server, determine the requirements of all the web applications and web content on your server.

In addition to role service settings, each of the authentication methods has specific module requirements, as shown in Table 6-1. For more information about managing modules, see the "Managing Request Handlers" section earlier in this chapter.

Table 6-1 IIS Authentication Methods and Their Requirements

AUTHENTICATION METHODS	REQUIRED MODULE(S)
Anonymous	AnonymousAuthModule
ASP.NET Impersonation	ManagedEngine
Basic	BasicAuthModule TokenCacheModule
Client Certificates	iisClientCertificateMappingModule
Client Certificates (Active Directory Mapping)	CertificateMappingAuthenticationModule
Digest	DigestAuthModule
Forms	FormsAuthenticationModule
Windows	WindowsAuthenticationModule

Configuring Authentication Settings

IIS enables you to define configuration settings by using the web object hierarchy. Authentication settings can be configured for objects at the following levels:

• Web server

• Websites

• Web applications

• Virtual directories

• Physical folders and individual files

Authentication settings that are defined at higher levels (such as for a web application) apply automatically to lower-level objects. This method makes it easier to manage settings for multiple websites, web applications, and their related content.

To configure authentication settings by using IIS Manager, select the appropriate object in the left pane and then double-click Authentication in Features View. Figure 6-24 shows the default authentication options for the Default Web Site object.

The default display shows a complete list of the available authentication options, grouped by the response type used. Each method can be enabled or disabled by selecting the item and using the Enable or Disable commands in the Actions pane. In addition, some authentication options provide additional commands for managing settings. By default, when you enable or disable an authentication option, the setting applies to all lower-level objects and content in the IIS hierarchy. You can override this behavior by explicitly enabling or disabling authentication methods at lower levels.

To verify your authentication-related settings, you should always test access to content by using a web browser. In some cases, it might be necessary to use a second computer to ensure that authentication is working properly. For example, if you are already connected to a computer running Windows Server 2008 R2 as a member of the administrators group and you want to test Windows Authentication, you should attempt to connect from another computer in the environment to help prevent automatic authentication from affecting your test results.

Managing URL Authorization Rules

Authorization is a method by which systems administrators can determine which resources and content are available to specific users. Authorization relies on authentication to validate the identity of a user. After the identity has been proven, authorization rules determine which actions a user or computer can perform. IIS provides methods of securing different types of content by using URL-based authorization. Because web content is generally requested by using a URL that includes a full path to the content being requested, you can configure authorization settings easily by using IIS Manager.

Creating URL Authorization Rules

To enable URL authorization, the UrlAuthorizationModule must be enabled. Authorization rules can be configured at the level of the web server for specific websites, for specific web applications, and for specific files (based on a complete URL path). URL authorization rules use inheritance so that lower-level objects inherit authorization settings from their parent objects (unless they are specifically overridden).

To configure authorization settings, select the appropriate object in the left pane of IIS Manager and then select Authorization Rules in Features View. Figure 6-25 shows an example of multiple rules configured for a website.

There are two types of rules: Allow and Deny. You can create new rules by using the Add Allow Rule and Add Deny Rule commands in the Actions pane. The available options for both types of rules are the same, as shown in Figure 6-26. When creating a new rule, the main setting is determining the users to which the rule applies. The options are:

• All Users

• All Anonymous Users

• Specific Roles Or User Groups

• Specific Users

When you choose to specify users or groups to which the rule applies, you can type the appropriate names in a comma-separated list. The specific users and groups are defined using .NET role providers. This is a standard feature that is available to ASP.NET web developers. Developers can create their own roles and user accounts and can define permissions within their applications. Generally, information about users and roles is stored in a relational database or relies on a directory service such as Active Directory.

In addition to user and role selections, you can further configure an authorization rule based on specific HTTP verbs. For example, if you want to apply a rule only for POST commands (which typically send information from a web browser to a web server), add only the POST verb to the rule.

Managing Rule Inheritance

As mentioned earlier in this section, authorization rules are inherited automatically by lower-level objects. This is useful when your website and web content is organized hierarchically based on intended users or groups. The Entry Type column shows whether a rule has been inherited from a higher level or has been defined locally. IIS Manager automatically prevents you from creating duplicate rules. You can remove rules at any level, including both Inherited and Local entry types.

Configuring Server Certificates

One of the many challenges related to security is verifying the identity of a web server, and, after you are reasonably sure that the server can be trusted, you must protect communications between the web client and the web server. On many networks, and especially on the Internet, providing secure communications for sensitive data is a key concern. Server certificates are designed to provide added security for web services. IIS provides built-in support for creating and managing server certificates and for enabling encrypted communications. In this section, you learn how to configure and enable these options.

Understanding Server Certificates

Server certificates are a method by which a web server can prove its identity to the clients attempting to access it. The general approach to providing this functionality is by a hierarchy of trust authorities. The party that issues a server certificate is known as a certificate authority (CA). On the Internet, numerous third-party organizations are available for validating servers and generating certificates. Assuming that users trust these third parties, they should be able to extend the trust to validated websites. Organizations can also serve as their own CA for internal servers. This enables systems administrators to validate and approve new server deployments by using a secure mechanism.

The general process for obtaining a server certificate involves three major steps:

• Generating a certificate request The request is created on a web server, which produces a text file containing the information about the request in an encrypted format. The certificate request identifies the web server uniquely.

• Submitting the certificate request to a CA The certificate request is submitted to a CA (generally by using a secure website or email). The CA then verifies the information in the request and creates a trusted server certificate.

• Obtaining and installing a certificate on the web server The CA returns a certificate to the requester, usually in the form of a small text file. This file can then be imported into the web server configuration to enable secure communications.

Creating an Internet Certificate Request

Use IIS Manager to obtain a certificate for use on an IIS web server. To begin the process, connect to a web server running Windows Server 2008 or Windows Server 2008 R2 and double-click Server Certificates in Features View, as shown in Figure 6-27. Note that certificate requests are generated at the level of the web server and not for other objects, such as websites or web applications.

Depending on the configuration of the local server, some certificates might already be included in the default configuration. The Actions pane provides commands for creating new certificates.

To begin the certificate request process, click Create Certificate Request. As shown in Figure 6-28, you will be required to provide information about the requesting organization. The CA uses this information to determine whether to issue the certificate. Therefore, it is important for information to be exact. For example, the Organization field should include the complete legal name of the requesting company. The Common Name field generally defines the domain name that will be used with the certificate.

The second step of the certificate request process requires you to choose the cryptographic method to secure the certificate request. (See Figure 6-29.) The Cryptographic Service Provider setting should use a method accepted by the certificate authority. (The default option, Microsoft RSA SChannel Cryptographic Provider, is accepted by most third-party CAs.) The Bit Length setting indicates the strength of the encryption. Larger values take more time to process (due to computational overhead) but provide added security.

The final step of the process involves storing the certificate request to a file. Here you can provide a fully qualified path and file name into which the request will be stored. The request itself will be stored in a text file that contains encrypted information.

The next step of the process involves submitting the certificate request to a CA. Generally, the issuer’s website will request that you either upload the certificate request or copy and paste the contents into a secure website. The issuer will also require additional information, such as details about your organization and payment information.

Completing an Internet Certificate Request

The amount of time a public third-party CA can take to process a request varies. After the request has been processed and approved, the CA sends a response by email or through its website. You can then store this response in a text file and provide it to IIS to complete the process by selecting the appropriate request in the Server Certificates feature view and then clicking the Complete Certificate Request command in the Actions pane. You will be asked to specify the path and file name of the response along with a friendly name for administration purposes, as shown in Figure 6-30. The convention is to use a file name with a .cer extension for the response; however, any type of standard text file will work.

Assuming that the certificate request matches the response, the certificate is imported into the configuration of IIS and is ready for use.

Creating Other Certificate Types

In addition to the standard certificate request process, you can use two other commands to create certificates. These commands are also available in the Actions pane in the properties of the Server Certificates feature. The Create Domain Certificate option generates a request to an internal certificate authority. This is commonly used in organizations that have their own certificate services infrastructure. Instead of sending the request to a third-party CA, the request is designed to be sent to an internal server. Figure 6-31 shows the available options. The Specify Online Certificate Authority text box accepts the path and name of an internal CA server. The Friendly Name can identify the purpose of the certificate.

Creating a Self-Signed Certificate

The certificate creation and management process can require several steps, and usually requires an added cost for obtaining a certificate from a trusted third-party CA. Although these steps are necessary to ensure security in a production environment, an easier method is preferable for development and test environments. Self-signed certificates can test certificate functionality by creating a local certificate. By avoiding the CA process, it is easy to create these certificates by using the Create Self-Signed Certificate command in the Actions pane. Figure 6-32 shows the dialog box.

Unlike other certificate types, it is not necessary to provide organizational information for the certificate because the certificate itself is created immediately on the local computer. The primary drawback of self-signed certificates is that users who access the web server using a secure connection receive a warning that the certificate has not been issued by a third party. (See Figure 6-33.) Whereas this is generally not a problem in test environments, it prevents the use of self-signed certificates for production web servers.

Viewing Certificate Details

The contents of a server certificate include several details and properties. To view this information, double-click an item in the Server Certificates list for a web server. The Certificate dialog box, shown in Figure 6-34, provides information about the server certificate. The General tab displays details about the issuer of the certificate. For an Internet-based certificate, this is the name of the trusted third party that issued it. Additionally, certificates have a range of valid dates.

The Details tab displays additional properties of the certificate, including the encryption method. The Certification Path tab shows the entire trust hierarchy for the certificate. In environments that have multiple levels of CAs, this is useful for tracking all the trust relationships that are used. For the certificate to be considered valid, all the levels must be trusted. (See Figure 6-35.)

Importing and Exporting Certificates

After a certificate has been installed on a web server, you might need to export it to a file. You can use IIS Manager to do this by right-clicking the certificate and choosing the Export command. You can then provide an export location and file name for the file along with a password to protect the certificate from being installed by unauthorized users. (See Figure 6-36.) By default, exported certificate files use the .pfx extension. However, you can use any other extension. The contents of the exported certificate are encrypted and protected with the password you provide.

To import a certificate, click the Import command in the Actions pane. You are prompted to provide the file system location of the exported certificate file along with the password to open it. In addition, you can choose whether you want to allow the certificate to be exported in the future.

Enabling Secure Sockets Layer

After you have added a server certificate to an IIS web server, you can enable SSL-based connections. SSL-based connections rely on certificates to validate the identity of the web server. After the identity has been proven, users can create a secure connection by using the HTTP Secure (HTTPS) protocol. By default, HTTPS connections use TCP port 443 for communications. To modify the details or to enable HTTPS for a website, you must configure the site bindings for a website. (For complete details about configuring site bindings, see Chapter 5.)

You can also require SSL-enabled connections for specific websites by using IIS Manager. To do this, select a website, a web application, or a folder and then double-click SSL Settings in the Features view. In Windows Server 2008 R2, websites have only an HTTP binding by default, so you first must add an HTTPS binding before you can configure SSL. (Adding an HTTPS binding requires you to specify a server SSL certificate.) Figure 6-37 shows the available SSL settings after you have added an HTTPS binding to a website. The check boxes enable you to specify whether SSL is required to access this content. If the option is enabled, standard HTTP connections are not enabled. Optionally, you can specify whether client certificates will be ignored, accepted, or required.

Overall, server certificates and SSL provide a standard method of protecting web-based connections and web server content. Support for server certificates and SSL is often expected for all types of web servers that contain sensitive information.

Configuring IP Address and Domain Restrictions

Although some web servers are configured to provide public access to all content, it’s also common to need to restrict access to only specific groups of users. By default, IIS is configured to accept requests on all connections based on site binding settings such as IP address and TCP port. Systems administrators can further restrict access to websites by responding only to requests that originate from specific IP addresses or domains using IIS Manager.

The first step is to select the level at which you want to assign the restrictions. The IP Address and Domain Restrictions feature is available at the server, site, web application, virtual directory, and folder levels. In general, assign restrictions at the highest level for which the settings will apply. For example, if all the web applications in a particular site should respond to requests from a single domain only, configure the request settings at the site level. By default, IIS does not include any restrictions. To configure request settings, select the appropriate object in the left pane of IIS Manager and then double-click IP Address and Domain Restrictions in Features View. (This feature becomes available when you add the IP and Domain Restrictions component of the Security role service.) Figure 6-38 provides an example of the settings.

Adding Allow and Deny Entries

You can add two main types of entries to the IP Address and Domain Restrictions configuration. Allow entries specify which IP addresses can access web content; Deny entries define which addresses cannot access the content. When configuring IP address restrictions, you can specify either a single IP address or a range of IP addresses. (See Figure 6-39.) When specifying a range, you can enter the initial IP address and the subnet mask. This determines the range of addresses that will be allowed or denied. It is possible to exclude specific addresses or ranges by using additional allow or deny rules. Overall, however, try to keep the configuration simple to make administration and management as easy as possible.

The single address option is useful if only a few users require access to the site or if only a few other servers require access to the content. This is common in environments that support distributed server-side web applications that are not designed for direct user access. IP address ranges are more appropriate when groups of users and computers should have access to the environment. For example, if all the users in the Human Resources department are located on the same subnet, that subnet can be allowed while other subnets are denied.

When evaluating connection rules, IIS evaluates all allow and deny rules to determine whether an address has access. Deny rules take precedence over allow rules. If users are denied access to a site, they see a screen similar to the one shown in Figure 6-40.

An additional setting defines the default behavior for any IP addresses that are not explicitly added to either the Allow or Deny list. By default, IIS allows access automatically from these addresses. To change the setting, click Edit Feature Settings in the Actions pane and choose Deny for the Access For Unspecified Clients setting. (See Figure 6-41.)

Adding Domain Restrictions

Managing access to web services by using IP addresses is useful when the list of incoming clients is well known. This is typical of intranet and internal network environments in which network administrators can configure and manage IP address ranges. In other types of web server scenarios—such as public web servers or extranets—managing IP address ranges can be time consuming and impractical.

An alternative to using IP address-based restrictions is specifying allow and deny settings by using domain name restrictions. This method depends on a Domain Name System (DNS) reverse lookup operation. Whenever a user attempts to connect to IIS, the web server performs a reverse DNS lookup to resolve the requester’s IP address to a domain name. IIS then uses the domain name to determine whether the user should have access. Domain-based restrictions are disabled by default because this feature can decrease server performance significantly. Every incoming request must be resolved, adding overhead to request processing. In addition, this can place significant load on the DNS server infrastructure. From a management standpoint, however, this feature can sometimes be useful (especially in low-volume scenarios).

To enable domain name restrictions, double-click the IP Address And Domain Restrictions feature for a portion of the website and then click Edit Feature Settings in the Actions pane. As shown in Figure 6-41, you can select the Enable Domain Name Restrictions check box to enable this feature. Figure 6-42 shows the confirmation warning when you enable this feature.

After you have enabled domain name restrictions, you can use the Add Allow Entry and Add Deny Entry commands to configure the rules. As shown in Figure 6-43, the dialog boxes include a setting for Domain Name.

As mentioned earlier, the default behavior for allow and deny entries is for these restrictions to flow from parent objects to child objects. If you have made explicit changes to the settings for an object such as a web application, you can use the Revert To Parent command in the Actions pane to remove settings at that level. The effective settings are then based on the parent hierarchy.

Configuring .NET Trust Levels

The .NET Framework technology provides web developers with a strong set of features for implementing applications. The functionality includes web applications (based on the ASP.NET platform) and other managed code features. It is relatively simple to create .NET applications that can perform a wide array of operations on a computer. From a security standpoint, however, it is important to restrict the permissions that are granted to a .NET application. Malicious or defective code can cause problems ranging from unauthorized access to data to the accidental deletion of content.

To help systems administrators manage permissions on production servers better, IIS supports Code Access Security (CAS) policy. CAS policies can determine which operations are available to .NET-based application code. There are two main types of configuration. The full trust option provides ASP.NET application code with all permissions on the computer. For compatibility reasons, this is the default setting for applications that are based on.NET Framework 1.0, 1.1, and 2.0.

Understanding Partial Trust Levels

The other CAS policy option is partial trust, which limits the actions .NET applications can perform. These options are available to applications that are built using .NET Framework 1.1 and .NET Framework 2.0. The goal of partial trust is to enable only the permissions that are necessary for a specific web application.

Trust levels can be configured at different levels in the web server object hierarchy. These levels include:

• Web server

• Websites

• Web applications

• Virtual directories and physical folders

As with other security-related settings, trust levels that are defined at parent levels automatically apply to child objects unless they are specifically overridden. In general, define .NET trust level settings at the highest relevant setting. For example, if none of the web applications in a website should have full permissions, you can configure these settings at the site level. You can then manage exceptions by assigning the necessary .NET trust level settings for specific web applications or folders.

Understanding .NET Trust Levels

The .NET Framework contains many features and operations that can cause security issues on a web server. To provide a simpler method of configuring and applying trust settings, IIS includes five built-in levels that can be applied to IIS objects. The specific settings for each level are defined within various .config files. (For more information about using configuration files, see Chapter 5.) It is also possible to view and modify the settings in these files by using an XML editor or text editor. Table 6-2 lists the levels and their effects.

Table 6-2 .NET Trust Levels and Their Descriptions

.NET TRUST LEVEL	CONFIG FILE NAME	DESCRIPTION	RESTRICTED ACTIONS
Full (internal)	N/A	Provides full permissions to an ASP.NET application	N/A
High	Web_hightrust.config	Provides access to most actions on the server and is designed for well-trusted and well-tested web applications	Calling unmanaged code Calling serviced components Writing to the event log Accessing message queuing services Accessing ODBC, OLEDB, and Oracle data sources
Medium	Web_medium trust.config	Provides additional restrictions for web applications that should not need to access the file system or registry	Accessing files outside of the application’s directory Accessing the registry Making network or web service calls
Low	Web_lowtrust.config	Further restricts application capabilities	Writing to the file system Calling the Assert method (a method that is often used for testing application code)
Minimal	Web_minimal trust.config	Allows only Execute permissions and prevents access to other resources on the computer	Performing actions that require permissions greater than Execute

The default setting is Full (internal), which provides the best compatibility but also the greatest security risk. Whenever possible, lower the .NET trust levels to ensure that application code is being run with minimal permissions. Often, this involves interactions with web developers to determine requirements and perform complete testing at various security levels.

Configuring .NET Trust Levels

To configure .NET trust levels by using IIS Manager, select the object for which you want to assign the settings and then double-click .NET Trust Levels from Features View, as shown in Figure 6-44. To change the setting, select the appropriate level from the drop-down list and click Apply. After the trust level is set, it will apply to all ASP.NET applications running at the selected level and to any child objects unless the settings are explicitly overridden.

PRACTICE: Secure Web Servers and Web Content

In these exercises, you apply the information you learned about ways to add security to specific web content. The steps assume that you have installed the Web Server (IIS) role using the default settings and that you are familiar with the process of adding role services.

EXERCISE 1 Managing and Testing Authentication Settings

In this exercise, you configure and verify the effects of various authentication settings.

1. Log on to Contoso.local from Server2 as a domain administrator.

2. Using Server Manager, add the following role services to the Web Server (IIS) role. You can find these role services in the Security group.

   • Basic Authentication

   • Windows Authentication

   • Digest Authentication

   • URL Authorization

   • IP and Domain Restrictions

3. When you are finished, close Server Manager.

4. Open IIS Manager, browse to the Sites container, and select Default Web Site in the left pane. Double-click Authentication in Features View.

   The default settings specify that only anonymous authentication is enabled.

5. Click Default Web Site again and then click Browse *:80 (http) in the Actions pane. Verify that the default IIS start page is displayed. Keep the web browser open, but return to IIS Manager.

6. Again, double-click Authentication in Features View. Select Digest Authentication and then click Enable in the Actions pane.

7. Return to Internet Explorer and type http://server2 in the address box.

   Note that you are not prompted to provide authentication information. This is because anonymous authentication is still enabled for the site.

8. Return to IIS Manager, select anonymous authentication, and then click Disable in the Actions pane.

9. Return to Internet Explorer and refresh the page. This time, you are prompted to provide logon information to access the site. Enter your username and password and then click OK to verify that the site loads. Optionally, you can provide invalid logon information (such as a user account that does not exist) to see that you cannot access the site. When you are finished, close Internet Explorer.

10. To restore the original authentication settings, return to IIS Manager. Disable Digest Authentication and enable anonymous authentication.

11. When you are finished, close IIS Manager and log off Server2.

EXERCISE 2 Configuring Server Certificates

In this exercise, you create a self-signed security certificate for Server2.contoso.local and then require SSL to access Default Web Site and test the settings by using Internet Explorer.

1. Log on to Server2 as a user with Administrator permissions on the computer.

2. Open IIS Manager and select the server object in the left pane.

3. Double-click Server Certificates in the IIS section of Features View.

   Depending on which roles and role services have been installed on the local server, some certificates might already be available on the server.

4. Click Create Self-Signed Certificate in the Actions pane.

5. For the name of the certificate, type Test Local SSL Certificate and then click OK.

   You should now see the new certificate in the Server Certificates view of IIS Manager.

6. To view the properties of the new certificate, right-click it and select View.

   Note details such as the issuer (which is the name of the server) and the dates for which the certificate is valid. (New certificates expire in one year.) The Certification Path tab shows only the certificate itself and not a chain of trust, which signifies that it has not been issued by a trusted certificate authority (CA). For this reason, the certificate is not suited for access by users on public networks such as the Internet.

7. Click OK when you are finished.

8. In IIS Manager, right-click the Default Web Site object and select Edit Bindings.

9. In the Site Bindings dialog box, Click Add.

10. In the Add Site Bindings dialog box, in the Type drop-down list, select HTTPS.

11. In the SSL Certificate list, select Test Local SSL Certificate. Click OK to save the settings and then click Close. (If, after you click OK, a message box informs you that the binding is already being used, first click Yes and then click Close.)

12. In IIS Manager, ensure that the Default Web Site object is selected and then double-click SSL Settings in Features View. Enable the Require SSL option and then click Apply in the Actions pane.

13. Click Back to return to Features View for Default Web Site. In the Actions pane, choose Browse *:80 (http). This launches Internet Explorer and attempts to connect to the site by using a non-SSL (HTTP) connection. You receive an error stating, “The Page You Are Trying To Access Is Secure With Secure Sockets Layer (SSL).” Close Internet Explorer.

14. In IIS Manager, click Browse *:443 (https) in the Actions pane.

    This time, you receive a warning stating that there is a problem with the website’s security certificate. This is because a self-signed certificate was not issued by a trusted CA.

15. To access the site anyway, click Continue To This Website. In the Security Alert message box, click OK.

    The address bar turns red, and a Certificate Error message appears. The site content is, however, accessible.

16. When you are finished, close Internet Explorer.

17. In IIS Manager, double-click the SSL Settings feature for Default Web Site and disable the Require SSL option. Click Apply in the Actions pane to save the setting.

18. When you are finished, close IIS Manager.

Lesson Summary

• Anonymous authentication provides access to site content without requiring users to provide credentials.

• Forms authentication is useful for public websites and applications that manage their own security.

• URL authorization rules can determine which users or groups have access to which website content.

• Web server administrators can use Internet server certificates to enable encrypted connections through SSL over the Internet.

• Administrators can create self-signed server certificates for testing and development purposes.

• You can use IP Address And Domain Restrictions to restrict access to web content.

• .NET trust levels restrict the permissions that managed code has on a web server.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 2, "Controlling Access to Web Services. The questions are also available on the companion CD if you prefer to review them in electronic form.

1. You are an IIS web server administrator implementing authentication settings for a new Human Resources website. According to the requirements for the website, users should be prompted for authentication information when they attempt to access the site. The site will be accessed only by users who have accounts in your organization’s Active Directory domain. You have already configured the file system permissions for the content based on the appropriate settings. You also want to maximize security of the site. Which two actions should you take to meet these requirements? (Each correct answer presents part of a complete solution. Choose two.)

   1. Enable Windows authentication.

   2. Enable basic authentication.

   3. Disable anonymous authentication.

   4. Enable anonymous authentication.

2. You are a systems administrator troubleshooting a problem with accessing a web server running Windows Server 2008 R2. Previously, another administrator created and installed a server certificate on the computer. Users report that they are able to connect to the site using HTTP, but that they receive a warning in Internet Explorer when trying to connect by HTTPS. You want to enable users to connect using both HTTP and HTTPS. You attempt to access the site by using an instance of Internet Explorer on the server itself, and you receive the same warning message for HTTPS connections. How can you resolve this issue?

   1. Change the site binding for the website to enable connections on port 443.

   2. Change the SSL settings for the website to enable the Require SSL option.

   3. Obtain and install an Internet certificate on the web server.

   4. Export and reimport the existing security certificate.

   5. Reconfigure clients’ firewall settings to enable traffic on port 443.