Managing Web Server Security in Windows Server 2008 R2
- 7/15/2011
- Before You Begin
- Lesson 1: Configuring IIS Security
- Lesson 2: Controlling Access to Web Services
- Chapter Review
- Suggested Practices
- Take a Practice Test
Lesson 1: Configuring IIS Security
In this lesson, you learn how to configure and manage security for the Web Server (IIS) server role and its associated components. You first learn how to determine the permissions administrators have on web servers. You learn ways to extend IIS administration capabilities to other users and web developers in your organization through remote management and delegation settings. You then learn how to increase security by configuring request handlers and their associated settings to minimize risks related to the execution of unwanted or malicious code or content.
Understanding IIS 7 Security Accounts
When you add the Web Server (IIS) role to a computer running Windows Server 2008 or Windows Server 2008 R2, as discussed in Chapter 5, the process makes numerous changes and additions to the configuration of the server. In earlier versions of IIS, each installation used service accounts that were based on the name of the server. Because the accounts and their security identifiers (SIDs) were different, copying web content and settings between web servers required multiple steps.
In IIS 7, a built-in, internal account named IUSR and a local security group called IIS_IUSRS are used on each computer running Windows Server 2008 and Windows Server 2008 R2 web server. Passwords for the accounts are managed internally, so administrators do not need to keep track of them.
Managing File System Permissions
To implement security, web server administrators must be able to define which content should be protected. They must also be able to specify which users or groups of users have access to protected content. Permissions settings for web content are managed through NTFS file system permissions. These permissions can be administered directly by using Windows Explorer or by right-clicking a specific object in the IIS Manager hierarchy and then clicking Edit Permissions. As shown in Figure 6-2, the permissions settings display which users or groups of users have access to the content and which permissions they have. IIS uses these permissions to determine whether credentials are required when attempting to complete a request from a web client.
Figure 6-2 Viewing permissions for a folder within the Engineering website.
Configuring IIS Administration Features
When you add the Web Server (IIS) role to a computer running Windows Server 2008 or Windows Server 2008 R2, the default configuration enables only local administration of the server. This enhances security because users of other computers are unable to use IIS Manager to make changes to the server’s configuration. Although this is appropriate for small, simple installations, often systems administrators benefit from the ability to use IIS Manager to configure the server remotely.
In many environments, multiple systems administrators manage websites and web applications. In large deployments, it is common for several administrators to be responsible for the same web server. For example, a single IIS server might host several important web applications, each of which is administered by a different individual or group. In hosting situations—when an organization provides IIS server access to subscribers—you must enable subscribers to control certain web content and features. In this case, subscribers act as remote administrators for certain portions of the servers. Remote administration is helpful for both multiple administrators and management performance from multiple locations.
To enable remote administrators to manage IIS, you must first enable remote management on the server. You can then define and configure IIS Manager users. Feature delegation enables you to specify which actions remote administrators can perform.
Enabling Remote Management
To enable remote management functionality, you first add the Management Service role service to the local server. You can do this by using Server Manager. Right-click the Web Server (IIS) role in the Roles folder and then select Add Role Services. Add Management Service, which is located in the Management Tools section of the available role services.
The Management Service role service is associated with the Web Management Service (WMSVC), which works by using a standard HTTP or HTTPS connection. Communications are configured to transmit over port 8172 by default. Assuming that traffic is allowed on this port through any firewalls or network security devices, this enables remote administrators to manage their IIS servers over a local network connection or over the Internet.
After you have added the Management Service role service to the Web Server (IIS) role, you can use IIS Manager to enable remote management. To do this, open IIS Manager and select the server object in the left pane. Double-click Management Service from the Management section in the Features view. (See Figure 6-3.)
Figure 6-3 Configuring Management Service using IIS Manager.
Initially, the Enable Remote Connections option will be cleared. To enable authorized users to connect to IIS over the network, select Enable Remote Connections. The Identity Credentials section enables you to specify whether you will allow authentication by using Windows credentials only (the default setting) or by using IIS Manager credentials as well.
The Connections portion of the settings enables you to specify the IP addresses and ports on which the management service will respond. The default setting is for the service to respond to all available IP addresses on port 8172. If your web server is configured with multiple network connections or IP addresses, you can increase security by restricting remote access connections to a specific address. The SSL Certificate section enables you to select one of the SSL certificates that has been configured on the local server. You can also configure the path into which remote management requests are logged. The default is %SystemDrive%\Inetpub\Logs\WMSvc.
Finally, the IPv4 Address Restrictions section enables you to increase security by restricting which computers can connect to IIS remotely. As shown in Figure 6-4, you can configure rules based on a specific IPv4 address or on an address range (which is defined by a combination of an IP address and subnet mask). The Access For Unspecified Clients drop-down list in the Management Service feature defines whether IP addresses without entries are allowed or denied. You can then create Allow or Deny entries to define which IP addresses can connect. These options are most useful when you have control over the groups of computers that will be used for administering web services.
Figure 6-4 Configuring IPv4 address restrictions for Management Service in IIS Manager.
Because WMSVC is stopped by default, you must click the Start command in the Actions pane to start allowing remote connections. You must stop the service to make changes to the configuration.
Understanding IIS Manager Users
To connect to a Windows Server 2008 or Windows Server 2008 R2 web server by using IIS Manager, users must have the necessary permissions. Users who are logged on to a computer running Windows Server 2008 or Windows Server 2008 R2 with administrator credentials have the necessary permissions to complete all the available tasks on the server. For other types of users, such as remote systems administrators, you must decide how you want to manage permissions.
By default, the Web Server (IIS) role enables permissions to be assigned using Windows authentication only. This means that all administrators who attempt to manage IIS must have Windows-based credentials and permissions. Windows authentication is most appropriate for environments in which all the web server administrators belong to the same domain. Users who are logged on to the domain will not have to supply credentials manually when they connect to a server using IIS Manager, assuming they have the necessary permissions. Windows authentication is also useful when you plan to create either local or domain accounts for all the administrators who need access to IIS Manager.
In some cases, it might be impractical to create local or domain accounts for each of the potential IIS administrators. For example, web service hosting companies can have hundreds of users who require the ability to manage their servers. In these environments, each user can generally modify specific settings for his or her own website. These users should not have access to other users’ websites and often will be restricted to changing only certain settings. To support these scenarios, you must enable the Windows Credentials Or IIS Manager Credentials option. When this option is enabled by using the Management Service described in the previous section, you can create username and password combinations solely for the purpose of managing IIS. These credentials can then be given to other users and administrators so they can connect to the web server without requiring individual Windows accounts for each of the users.
Creating IIS Manager Users
The IIS Manager utility enables you to define which users can connect to and administer websites and web services. To configure these settings:
Open IIS Manager and select a server in the left pane.
Click IIS Manager Users in the Management section of the features view. By default, the IIS installation will not contain any locally defined users.
To create a new user, first click Open Feature in the Actions pane and then click the Add User command in the Actions pane. You will be prompted to provide a username and to type and confirm a password. (See Figure 6-5.) These settings are defined locally in IIS, so it is not necessary to use a fully qualified username that is compatible with your domain design.
Figure 6-5 Adding an IIS Manager user.
In addition to configuring permission through IIS Manager users, you can use group membership settings to determine which users can connect remotely. Users who have permission to log on to the local computer and to use IIS Manager will be able to do so from a remote computer.
Defining IIS Management Permissions
So far, you have learned how to enable remote management and how to specify which users can use IIS Manager to administer a web server. Next, you must decide which permissions remote administrators will have after they connect. In some cases, you might want to enable a remote administrator to have full administrative access to the web server. In other cases, you will want to restrict access to only specific websites or web applications. You can configure IIS Manager Permissions at the website and application levels. However, you cannot configure permissions directly at the server level. This helps ensure that users are given permissions to modify the settings for only the specific websites and web applications to which they need access.
To manage permissions, select a website or web application and then click IIS Manager Permissions in the Management section of the Features View. By default, new IIS Manager users are not given permissions to connect to a specific website or web application. To enable a new user to connect at the selected level, first click Open Feature in the Actions pane and then click the Allow User command in the Actions pane. You are given the opportunity to specify a Windows user or an IIS Manager user (if IIS Manager credentials are accepted), as shown in Figure 6-6. If you are using the Windows option, you can select an existing user or group that is defined either in the domain (if the server is a member of a domain) or locally.
Figure 6-6 Allowing a user to administer a website.
When users connect to IIS remotely, they can access only those websites and web applications on which they have been allowed. By default, permissions from higher-level objects are inherited automatically by lower-level objects.
To simplify administration of many users, two commands are available when managing permissions for a website. Show All Users provides a list of all the users available on the IIS installation. Show Only Site Users restricts the display to only the users who have access to the site.
Configuring Feature Delegation
The ability to define users and permissions enables you to manage administration based on site content structure. However, it is also important to determine which features users can view and configure. For example, you might want a web server administrator to connect to the Default Web Site, but you do not want her to be able to change authentication settings. Delegation is the process by which an administrator can determine which features of IIS a user can view and change.
Default settings for feature delegation are defined initially at the server level in IIS. To access these settings by using IIS Manager, select the server object in the left pane and then double-click Feature Delegation in the Management section of Features View, as shown in Figure 6-7.
The list of items available for delegation includes all the features that have been added through the Web Server (IIS) server role and enabled role services. To change the setting for a feature, select it from the list and use the commands in the Set Feature Delegation section of the Actions pane. Most features have options of Read Only or Read/Write. In addition, some items have a Configuration Read/Write or Configuration Read Only setting. These settings enable web developers to specify settings in their configuration files or to manage them based on database settings. The Not Delegated setting means that the feature has not been enabled for delegation at lower levels and is not available for configuration. You can also use the Delegation option in the Group By drop-down list to determine quickly how all the settings have been configured, as shown in Figure 6-8.
Figure 6-7 Viewing Feature Delegation settings for an IIS web server.
Figure 6-8 Viewing Feature Delegation configuration grouped by the delegation setting.
The settings you define at the server level automatically apply to all child websites and applications by default. In some cases, you will want to restrict feature delegation at the site level. To do this, click the Custom Site Delegation command in the Actions pane. This brings up the Custom Site Delegation screen, as shown in Figure 6-9, and enables you to select specific sites to which you want delegation settings to apply.
Figure 6-9 Specifying Custom Site Delegation settings.
The Copy Delegation button enables you to copy the currently selected settings to one or more websites on the server. You can also use the Reset To Inherited and Reset All Delegation commands in the Actions pane to change groups of settings quickly to earlier values. (Reset To Inherited appears in the Actions pane only when you select a particular item or group of items for configuration within a site.) You use feature delegation settings to determine which parts of the system configuration will be available when remote users connect to the server by using IIS Manager.
Connecting to a Remote Server by Using IIS Manager
After you have enabled remote management and configured the appropriate permissions and settings, remote users will be able to connect to the server by using the IIS Manager console. To verify the configuration from either the local computer or from a remote computer that has the IIS Manager console installed, use Start Page in IIS Manager or the File menu to connect to IIS. As shown in Figure 6-10, remote users will be able to connect to the server at one of several levels. The available commands include:
Connect To A Server
Connect To A Site
Connect To An Application
Figure 6-10 Connecting to a remote installation of IIS.
Figure 6-11 shows the options available for connecting directly to a web application. Remote administrators will be prompted to provide credentials (including a username and password) to make the connection. If the connection is successful, remote administrators see a new object in the left pane of the IIS Manager. These administrators also can name or rename these connections to keep track of multiple connections.
Figure 6-11 Creating a connection to a web application.
The specific items available for management are based on feature delegation settings. Although the same icons might appear, remote administrators will be unable to make or save configuration changes for particular items. For most settings, they can access the configuration page that shows the details, but the controls themselves will be disabled. Figure 6-12 shows an example.
Figure 6-12 Viewing SSL options that are disabled due to feature delegation settings.
Managing Request Handlers
To provide support for various web application technologies, the architecture of IIS allows for enabling and disabling request handlers. Request handlers are programs that can process web requests and generate responses that are then returned to clients. Web servers and web applications can be configured with their own sets of request handlers, based on the types of content that must be supported. For example, a web application might be configured to support static content (such as HTML) as well as ASP.NET webpages.
The primary benefit is that web developers can choose the technologies most useful for their tasks. However, there is a drawback from a security standpoint. When IIS is configured with multiple request handlers, the security attack surface is increased. A vulnerability in any of the enabled request handlers can result in unauthorized access or related issues. Therefore, it is recommended that systems administrators enable only those request handlers they plan to use. In this section, you learn how to enable and disable request handlers.
Understanding Handler Mappings
When the web server receives a request, IIS uses the definition of handler mappings to determine which request handler to use. A handler mapping includes the following information:
Verb HTTP requests include verbs that define the type of request being made. The two most common verbs are GET, which obtains information from the web server, and POST, which can also include information sent from the client browser to the web server.
Request extension Web servers commonly return a wide array of content types. The most common types of information are standard HTML pages and images such as .jpg and .gif files. IIS can use the file extension information from the HTTP request to determine which type of content must be processed. For example, the default file extension for ASP.NET webpages is .aspx. Requests for .aspx pages are mapped automatically to the ASP.NET request handler. Most web development platforms have their own conventions for extensions. It is also possible to create new extensions and provide the appropriate mappings for them.
Handler information The handler mapping includes details related to the specific request handler IIS should call based on the verb and request extension. This information can be provided in different ways, including as a full path to an executable or as the name of a program designed to handle the request.
In addition to specific handler mappings based on these settings, IIS provides the ability to return content by using a default handler. The StaticFile handler mapping is configured to respond to requests that do not map to an existing file. The specific response is based on the settings for the web application. If a default document is specified for the web application or virtual directory, that document is returned if a file is not specified in the URL. For example, a request to http://Server1.contoso.local/TestSite results automatically in the return of the default.htm document (if one exists).
If a default document does not exist or the feature is disabled, the StaticFile handler checks whether directory browsing is enabled. If it is, a listing of the contents of the folder is returned to the requester. Finally, if neither of these methods is able to complete the request, the user receives an error stating that the request is forbidden. The complete error message is HTTP Error 403.14, The Web Server Is Configured To Not List The Contents Of This Directory. (See Figure 6-13.)
Figure 6-13 A detailed Request Not Found error page.
Configuring Handler Mappings
When you add the Web Server (IIS) role to Windows Server 2008 or Windows Server 2008 R2, a default set of handler mappings is defined for the web server and for the default website. New websites and web applications are also configured with a default set of handler mappings. In addition, when you add role services to the Web Server (IIS) role, additional handler mappings might be added automatically to the configuration.
You can use IIS Manager to configure handler mappings. After you have connected to an installation of IIS, you must choose the level at which you want to configure mappings. You can configure mappings at the following levels:
Web Server
Web Sites
Web Applications
Virtual Directories
Web Folders
Child items in the hierarchy automatically inherit handler mappings. For example, a child item automatically inherits the default handler mappings for a new web application from the configuration of the parent website. Settings made at lower levels override the settings from higher levels. This enables a specific web application to support a certain type of file content, such as ASP.NET pages, whereas other applications and the parent website might support only static content.
To view the handler mappings that are configured at a specific level, click the relevant object in the left pane of IIS Manager. Then, double-click Handler Mappings from the Features View in the center pane. Figure 6-14 shows the handler mappings that are defined for a website.
Figure 6-14 Viewing handler mappings for a website.
The display includes information about all the handler mappings defined at the selected level. The name specifies information about the request handler itself. Examples include StaticFile and ASPClassic. Built-in handler mappings have default names, but administrators can provide names for new mappings when they are created. The Path column shows the specific request extensions for which the handler will be used.
The State column specifies whether the handler is enabled or disabled. If the handler is disabled, requests that match the mapping will not be processed. The Handler column specifies details about the program to be called. Finally, the Entry Type specifies whether the handler mapping is inherited from a parent object or is Local (defined directly for this object).
You can use the Group By drop-down list to view handler mappings based on different criteria. These view options make it easy to determine the security attack surface for each component of the web server.
Removing Handler Mappings
To secure your web content, it is a good idea to remove any request handlers that you know will not be required when running in production. To remove a handler mapping, click it and then select the Remove command from the Actions pane. After a handler is removed, requests for the types of content that it handled will not be processed. For example, Figure 6-15 shows the result returned to a local web browser when the StaticFile request handler for the web application has been removed. In this case, the request file (default.htm) is present in the web application folder. However, because no request handler is available for the .htm file extension, the request cannot be processed. To the requester, it appears that the file does not exist.
Figure 6-15 A detailed request handler error page.
Managing Handler Inheritance
The inheritance feature of handler mapping settings can significantly simplify the administration of servers that host many websites and web applications. In general, configure handler mappings at the highest applicable level. For example, if you are sure that none of the web applications in a specific website must respond to the .soap file extension, you can remove this handler mapping at the level of the website. As mentioned earlier, to increase security, minimize the numbers and types of handlers that are enabled.
By default, it is possible for lower-level objects on the web server to override handler mapping settings from parent objects. In some cases, you might want to prevent some types of requests from being processed on the entire server, regardless of settings for websites and web applications. You do this by locking the configuration of the request handler. To lock the configuration, click the web server object in IIS Manager and then double-click Handler Mappings. Select the handler mapping you wish to lock and then click the Lock command in the Actions pane.
It is also possible to restore the handler mappings settings to their default values. To do this, click the Revert To Parent command in the Actions pane in IIS Manager. Performing this action restores mappings from the parent object, but it also results in the loss of any locally defined handler mappings.
Adding Handler Mappings
The architecture of IIS enables systems administrators to add new handler mappings based on specific needs. For example, if you want to provide support for a type of file that has a .mypage extension, you can add a handler for this path type. In addition, web developers can create their own programs to manage new types of requests.
To add a handler mapping, select the appropriate object and then double-click Handler Mappings in the Features View in IIS Manager. The Actions pane contains several options for adding new types of request handlers. They are:
Add Managed Handler A managed handler processes requests based on a .NET-based code library. The Type setting enables you to choose from the existing .NET code modules registered on the local server, as shown in Figure 6-16. These types of options all belong to the System.Web namespace.
Figure 6-16 Adding a managed handler for a website.
Add Script Map Scripting mappings send request processing to a dynamic link library (DLL) or executable (.exe) file type. These types of programs are designed to process request information and generate a response for IIS to send back to the end user.
Add Wildcard Script Map Wildcard script mappings specify a default handler for types of documents that are not managed by other handlers. The Executable path option points to either a .dll or an .exe file designed to handle requests.
Add Module Mapping Modules are programs designed to integrate with the IIS request processing pipeline. They can provide a wide range of functions and are included with the default and optional role services that are part of the Web Server (IIS) role. Examples include FastCGIModule, for processing scripts based on the Common Gateway Interface (CGI) specification, and StaticCompressionModule, which compresses static HTML content to reduce bandwidth usage. In addition to specifying the module to be used for processing, administrators can define an optional executable or .dll file to be used when processing requests, as shown in Figure 6-17.
Figure 6-17 Adding a module mapping to a web application.
When you add a new request handler, you are prompted to provide information about the request path. You can use wildcards, or you can specify a list of specific files. Examples include *.mypage (for responding to a request for any file with this extension) and Config.mypage (for responding to requests for this specific file name). You use the Name setting to help other developers and administrators identify the purpose of the handler mapping.
Configuring Request Restrictions
Besides specifying the paths and file names to which specific request handlers will be mapped, you can further secure IIS through request restrictions. To see the available options, click Request Restrictions in the dialog box when you are adding a mapping. Three tabs organize the request restrictions options: Mapping, Verbs, and Access.
You can use the Mapping tab to specify additional details related to whether files, folders, or both will be included in the mapping. The default setting is for the handler to handle requests automatically for both files and folders. You can choose either files or folders to limit whether the handler will respond to default documents or explicit file requests.
You can use the Verbs tab, shown in Figure 6-18, to specify the HTTP request verbs to which the handler will respond. Although the most common types of verbs are GET and POST, some applications might use other verbs (such as HEAD) to request other details from the web server. By default, all verb types are sent to the request handler. If you want to use different handlers for different verbs, or if you want the handler mapping to apply only to specific types of requests, you can specify this by using the One Of The Following Verbs option.
Figure 6-18 Viewing Verb Request Restrictions options for a handler mapping.
Finally, the Access tab specifies the access permissions that will be granted to the request handler. To improve security, minimize the types of access the handler will have. The default setting is Script, which is acceptable for most types of executable handlers. Other options include None, Read, Write, and Execute.
Configuring Feature Permissions
Feature permissions specify which types of actions a request handler can take. You can configure these options by double-clicking Handler Mappings and clicking Edit Feature Permissions in the Actions pane, as shown in Figure 6-19.
Figure 6-19 Configuring Feature Permissions for a request handler.
The three permission options are:
Read Enables the handler to read files stored within the file system.
Script Enables the handler to perform basic scripting-related tasks on the server.
Execute Enables the handler to run executable program code (such as .dll or .exe) files on the computer when processing a request. For Execute to be enabled, Script permissions must also be assigned.
By default, the Read and Script feature permissions are enabled for new handler mappings.
Understanding Request Filtering
In Windows Server 2008 R2, you can use the Request Filtering item in Features View of IIS Manager to restrict the kinds of HTTP requests your web server will process. Request Filtering is a security feature that helps you limit the attack surface of your web server.
The Request Filtering item in IIS 7.5 provides the following tabs to help you restrict HTTP requests.
File Name Extensions
With this tab, you can allow or deny access to web services according to a list of file name extensions specified in HTTP requests.
Rules
You can use the Rules tab to configure rules for allowing or denying web access according to various parameters, such as headers and deny strings.
Hidden Segments
This tab enables you to define a list of URL segments for which web access will be denied access and excluded from directory listings. (A segment is any part of a URL path between two slash [/] marks.)
URL
This tab enables you to allow specific URLs or to deny access to specific sequences within an URL. For example, if you specify “admin/config.xml” as a URL sequence, requests to http://contoso.com/application/admin/config.xml will be denied.
HTTP Verbs
Use this tab to create a list of HTTP verbs (such as GET, POST, or HEAD) whose access will be specifically allowed or denied.
Headers
Use this tab to create a list of HTTP headers whose access will be denied if a specified size limit is surpassed.
Query Strings
With this tab, you can create a list of query strings for which web access will be explicitly allowed or denied. An example of a query string is “%3b”, which represents HTTP URL encoding for the apostrophe character and is used in some SQL injection attacks.
Practice: Manage IIS Security Settings
This practice walks you through the steps required to manage security for a computer running Windows Server 2008 R2 that has the Web Server (IIS) role installed. Specifically, you learn how to enable remote administration and the effects of configuring handler mappings to increase security. The steps assume that you have already installed the Web Server (IIS) role by using the default options on Server2.contoso.local, and that you are familiar with the process of adding role services.
EXERCISE 1 Configuring and Managing Remote Administration
In this exercise, you use the IIS Management Service features to enable a user to connect to the computer. First, you must install the IIS Management Service role service, and then you create a new user based on IIS Manager credentials and configure permissions to access the Default Web Site. Finally, you connect to IIS, using the new user account to verify that the permissions and feature delegation settings are in effect. The final steps can be performed locally on Server2, or you can use another computer, running either Windows 7 or Windows Server 2008 R2, that has the IIS 7 Manager console installed. The steps assume that you perform the tasks locally on Server2.
Log on to Server2 as a user who has Administrator permissions.
Using Server Manager, add the Management Service role service to the web Server (IIS) server role. You can begin this process by right-clicking the Web Server (IIS) node and then selecting Add Role Services. On the Select Role Services page of the Add Role Services Wizard, you can find the Management Service role service within the Management Tools group.
After you have added the Management Service role service, open IIS Manager and connect to the local server (Server 2).
Click the server object in the left pane and then double-click the Management Service icon in Features View.
On the Management Service page, you should see a message stating that the Management Service (WMSVC) is stopped. This is necessary to make configuration changes. Select the Enable Remote Connections option.
In the Identity Credentials section, choose Windows Credentials Or IIS Manager Credentials. This enables you to create IIS Manager users later. Leave all other settings at their default values. Note that Management Service responds on port 8172 by default.
Start Management Service by clicking Start in the Actions pane. Note that you are unable to modify settings while the service is running.
If the Management Service message box appears, click Yes to save the settings before starting the service.
Return to Features View by clicking Back in the top toolbar.
Double-click IIS Manager Users to view a list of users who have been allowed to access the system. Note that, by default, there are no users in the list.
Click Add User in the Actions pane to create a new IIS Manager user. Use the WebAdmin01 username and the 1w3b!admin password. (Always use strong passwords.) Click OK to create the new user and verify that it appears in the list of IIS Manager Users.
In the left pane of IIS Manager, expand the Sites container and then click the Default Web Site object. Next, double-click IIS Manager Permissions in the Management section of Features View.
Click Allow User in the Actions pane. For the type of user, select IIS Manager and then type WebAdmin01 in the text box.
You can also click Select to select from all the users who have been defined on the server.
Click OK.
In IIS Manager, click the Server2 object and then double-click Feature Delegation in the Management section of Features View. In the Group By drop-down list, select Delegation. Note which features in the list are set to Read Only. In later steps, you attempt to change SSL Settings to verify that feature delegation is working.
In IIS Manager, click Start Page in the left pane. In the center pane, click the Connect To A Site link.
For Server Name, type server2.contoso.local. For Site Name, type Default Web Site. Click Next.
For Username, type WebAdmin01 and type 1w3b!admin for Password. Click Next.
For the name of the connection, change the name to Default Web Site – Test to specify that this is a test connection. Click Finish.
When the connection is complete, you see a new item called Default Web Site – Test in the left pane of IIS Manager. You can click this connection to administer the site, just as you would with the default local connection. However, note that the new connection shows only the contents of Default Web Site. You will have only the permissions that have been assigned to the WebAdmin01 user.
To verify the feature delegation settings, double-click SSL Settings in the IIS section of Features View.
Note the message in the Actions pane stating that the feature has been locked and set to read only. Verify that you are unable to make changes to these settings.
Remove the new connection in IIS Manager by right-clicking it and selecting Remove Connection.
When you are finished, close IIS Manager. You can click Yes to save the changes.
EXERCISE 2 Managing Handler Mappings
In this exercise, you learn how to configure and manage handler mappings for a web application. Initially, you verify that content is being presented correctly to web users. You then disable a request handler mapping and verify that the content is no longer accessible. Finally, you revert the handler mappings to their inherited settings to restore access to the content.
If you have not done so already, log on to Server2 as a user who has Administrator permissions.
Using Windows Explorer, navigate to the %SystemDrive%\Inetpub\Wwwroot folder.
From the Organize menu in Windows Explorer, select Folder And Search Options.
On the View tab of the Folder Options dialog box, clear the Hide Extensions For Known File Types check box and then click OK.
Make a copy of the Iisstart.htm file and name it Iisstart.test.
When you are finished, close Windows Explorer.
Open IIS Manager and connect to the local server.
In the left pane of IIS Manager, expand the Sites node and select Default Web Site. In the Actions pane, click Browse *:80 (http).
This launches Internet Explorer and connects to the default content for the site. Note that the default document (in this case, Iisstart.htm) is displayed and that the page contains a .png image type.
In Internet Explorer, modify the URL to request the iisstart.test page. An example of the full URL would be http://Server2/iisstart.test.
Although the file exists, you receive an HTTP Error 404.3. The error states that no handler is available to process the request.
When you are finished, close Internet Explorer.
In IIS Manager, with the Default Web Site still selected, double-click Handler Mappings in Features View.
You see a list of all the default handlers that have been registered on the system.
Click the Add Module Mapping link to create a new mapping. For Request Path, type *.test. For Module, select StaticFileModule. For Name, type Test Page Handler. Leave the other settings at their default values and then click OK to create the mappings.
This enables the web server to process files that have the .test extension.
Open Internet Explorer and navigate to the Iisstart.test page by using the same URL you used in step 9.
This time, you see a blank page, and no error message appears. This indicates that the new handler mapping you created is functioning properly. (By default, the HTML in the file with the .test extension cannot be read without coding a new custom handler. The default.png image does not appear in Iisstart.test for this reason.)
Close Internet Explorer.
In IIS Manager, return to the Handler Mappings section for Default Web Site and then click Revert To Parent in the Actions pane. Click Yes to confirm the changes.
This restores the default handler mappings and removes the Test Handler Mapping you created in a previous step.
When you are finished, close IIS Manager.
Lesson Summary
When implementing IIS security, consider the overall goals of implementing defense-in-depth best practices and reducing the server’s attack surface.
IIS 7 uses consistent built-in user and group accounts for managing security.
You can enable remote management of IIS by adding the Management Service role service.
You can manage remote management capabilities by creating users, assigning permissions, and configuring feature delegation.
Request handler mappings determine which types of content IIS will allow for a particular component in the hierarchy.
Lesson Review
You can use the following questions to test your knowledge of the information in Lesson 1, "Configuring IIS Security". The questions are also available on the companion CD if you prefer to review them in electronic form.
You are a systems administrator responsible for securing a Windows Server 2008 R2 web server. You have created a new website called Contoso Intranet that will contain seven web applications. One of the application developers has told you that her web application requires a new request handler that is processed by using a .NET library her team created. How can you meet these requirements while also maximizing security for the server?
Add a new managed handler to the Contoso Intranet website.
Add a new managed handler for the specific web application that requires it.
Add a new module mapping to the Contoso Intranet website.
Add a new module mapping for the specific web application that requires it.
You are a systems administrator responsible for managing a Windows Server 2008 R2 web server. Recently, your organization set up a new IIS website that users outside your organization will access. Consultants should be able to connect to this website by using IIS Manager. Your organization’s security policy prevents you from creating domain accounts or local user accounts for these users. You attempt to use the IIS Manager Permissions feature for the website. However, when you click Allow User, you are able to select only Windows users. How can you resolve this problem?
Verify that Management Service has been started.
Reconfigure the file system permissions for the root folder of the website.
Reconfigure Management Service to enable Windows and IIS Manager credentials.
Verify the authentication settings for the website.