Implementing Access Control

Web applications require the ability to restrict access to their content, to protect sensitive resources, or to authorize access to resources to specific users. IIS 7.0 provides an extensive set of features that you can use to control the access to application content. These features are logically divided into two categories, based on the role they play in the process of determining access to the request resource:

• Authentication Authentication features serve to determine the identity of the client making the request, which can be used in determining whether this client should be granted access.
• Authorization Authorization features use the authenticated identity on the request or other applicable information to determine whether or not the client should be granted access to the requested resource. Authorization features typically depend on the presence of authentication features to determine the authenticated identity. However, some authorization features determine access based on other aspects of the request or the resource being requested, such as Request Filtering.

IIS 7.0 supports most of the authentication and authorization features available in IIS 6.0, and it introduces several additional features. These features (role services) are listed here in the order in which they apply during the processing of the request:

1. IP and Domain Restrictions. Used to restrict access to requests clients make from specific IP address ranges or domain names. The default install does not use this feature.
2. Request Filtering. Similar to UrlScan in previous versions of IIS, request filtering is used to restrict access to requests that meet established limits and do not contain known malicious patterns. In addition, Request Filtering is used to restrict access to known application content that is not meant to be served to remote clients. Request filtering is part of the default IIS 7.0 install and is configured to filter requests by default.
3. Authentication features. IIS 7.0 offers multiple authentication features that you can use to determine the identity of the client making the request. These include Basic Authentication, Digest Authentication, Windows Authentication (NTLM and Kerberos), and many others. The Anonymous Authentication feature is part of the default IIS install and is enabled by default.
4. Authorization features. IIS 7.0 provides a new URL Authorization feature that you can use to create declarative access control rules in configuration to grant access to specific users or roles. In addition, it continues to support NTFS ACL-based authorization for authentication schemes that yield Windows user identities. IIS uses NTFS ACL-based authorization by default.

Note In IIS 7.0, all of these role services are available as Web server modules that can be individually installed and uninstalled and optionally disabled and enabled for each application. Be careful when removing authentication, authorization, and other access control modules, because you may unintentionally open access to unauthorized users or make your application vulnerable to malicious requests. To review the list of security-sensitive modules that ship with IIS 7.0, and considerations when removing them, see the section titled "Securing Web Server Modules" in Chapter 12.

You should leverage access control features to ensure that only users with the right to access those resources can access them. To do this, you need to configure the right authentication and authorization features for your application.

In addition, you should take advantage of Request Filtering to limit usage of the application as much as is possible, by creating restrictions on content types, URLs, and other request parameters. Doing so enables you to preemptively protect the application from unexpected usage and unknown exploits in the future.

IP and Domain Restrictions

The IP and Domain Restrictions role service enables you to restrict access to your application to clients making requests from a specific IP address range or to clients associated with a specific domain name. This feature is largely unchanged from IIS 6.0.

Note The IP and Domain Restrictions role service is not part of the default IIS install. You can manually install it from the IIS \ Security feature category in Windows Setup on Windows Vista, or from the Security category of the Web Server (IIS) role in Server Manager on Windows Server 2008. See Chapter 12 for more information about installing and enabling modules.

You can use this feature to allow or deny access to a specific range of IP addresses, or to a specific domain name. The IP and Domain Restrictions role service will attempt to match the source IP address of each incoming request to the configured rules, in the order in which rules are specified in configuration. If a matching rule is found, and the rule is denied access to the request, the request will be rejected with a 403.6 HTTP error code. If the rule allows access, the request will continue processing (all additional rules will be ignored).

You can specify any number of allow or deny rules and indicate whether access should be granted or denied if no rules match. The common strategies for using IP Address and Domain Restrictions rules include:

• Denying access by default and creating an Allow rule to grant access only to a specific IPv4 address range, such as the local subnet. You can do this to grant access only to clients on the local network or to a specific remote IP address.
• Allowing access by default and creating a Deny rule to deny access to a specific IP address or IPv4 address range. You can do this to deny access to a specific IP address that you know is malicious.

Caution Allowing access by default and denying access for specific IP address ranges is not a secure technique, because attackers can and often will use different IP addresses to access your application. Also, clients that use IPv6 addresses instead of the IP addresses will not match a Deny rule that uses an IPv4 address range.

If you are looking to restrict access to your application to clients on the local network, you may be able to implement an additional defense measure by specifying that your site binding should listen only on the IP address associated with the private network. For servers that have both private and public IP addresses, this can restrict requests to your site to the private network only. You should use this in conjunction with IP and Domain Restrictions where possible. For more information on creating Web site bindings, see Chapter 9.

Though you can create rules that use a domain name instead of specifying an IP address, we don't recommend that you do so. This is because domain name-based restrictions require a reverse Domain Name System (DNS) lookup of the client IP address for each request, which can have a significant negative performance impact on your server. By default, the feature does not enable the use of domain name–based rules.

To configure the IP and Domain Restrictions rules, you will need to perform the following steps:

1. Use IIS Manager to configure the rules by selecting the Server node, a Site node, or any node under the site in the tree view. Then double-click the IP Address And Domain Restrictions feature, which is shown in Figure 14-4.
2. Use the Add Allow Entry or the Add Deny Entry command in the Actions pane to create allow or deny rules.
3. You can also use the Edit Feature Settings command to configure the default access (allow or deny) and whether or not domain name–based rules are allowed.

Figure 14-4 Configuring IP and Domain Restrictions using IIS Manager.

Note Although the IP and Domain Restrictions feature enables you to use IPv6 addresses, you cannot configure addresses that use IPv6 rules using IIS Manager. Also, requests that are made over IPv6 connections do not match rules using IPv4 addresses. Likewise, requests made over IPv4 connections do not match rules that specify IPv6 addresses.

Note By default, the ipSecurity configuration section is locked at the server level. You can unlock this section by using the Appcmd Unlock Config command to specify IP and Domain Restriction rules in web.config files at the site, application, or URL level.

You can also configure the IP and Domain Restrictions configuration by using Appcmd or configuration APIs to edit the system.webServer/security/ipSecurity configuration section.

Request Filtering

The Request Filtering feature is an improved version of the UrlScan tool available for previous versions of IIS. The Request Filtering feature enforces limitations on the format of the request URL and its contents to protect the application from possible exploits that may arise from exceeding these limits. With IIS 6.0 and previous versions of IIS, these limits have thwarted the majority of known Web application exploits, such as application-specific buffer overruns resulting from long malicious URLs and query strings. Though the Web server itself, starting with IIS 6.0, has been engineered to not be vulnerable to these attacks, these limits remain valuable in preventing both known and unknown future exploits for the Web server and applications running on it.

In addition to enforcing request limits, the Request Filtering feature also serves to deny access to certain application resources that are not meant to be served to Web clients, but are located in the servable namespace for an application. These files include the web.config configuration files for IIS and ASP.NET, as well as contents of the /BIN and /App_Code directories for ASP.NET applications.

You can use Request Filtering to do the following:

• Set request limits Configure limits on the length and encoding of the URL, the length of the query string, the length of the request POST entity body, allowed request verbs, and maximum lengths of individual request headers.
• Configure allowed extensions Configure which file extensions are allowed or rejected, regardless of the selected handler mapping.
• Configure hidden URL segments Configure which URL segments are not served, to hide parts of your URL hierarchy.
• Configure denied URL sequences Configure which URL patterns are not allowed, possibly to prevent known exploits that use specific URL patterns.

IIS 7.0 depends on request filtering by default to reject requests that may contain malicious payloads and to protect certain content from being served by the Web server. You can also use it to further restrict the input to your application, or to protect additional URLs, directories, and files or file extensions from being served by the Web server.

Caution Request filtering is a critical security component and should not be removed unless it is absolutely clear that it is not needed. Always prefer to relax request filtering limits by setting the configuration rather than uninstalling or removing the Request Filtering module.

The request filtering configuration does not have an associated IIS Manager page, so these settings cannot be set through IIS Manager. To set them, you can configure the system.webServer/security/requestFiltering configuration section directly at the command line by using Appcmd.exe or other configuration APIs. The requestFiltering section is unlocked by default, so you can set request filtering configuration in web.config files at the site, application, or URL level.

The remainder of this section will illustrate how to modify common request filtering configuration tasks.

Setting Request Limits

You can use Request Filtering to configure even tighter request limits if allowable in your application's usage to further reduce attackers' ability to exploit your application with malicious input. At other times, you may need to relax the default request limits to allow your application to function correctly, for example, if your application uses long query strings that may exceed the default limit of 2048 characters.

You may need to modify request limits applied by request filtering if any of the default limits interfere with your application usage.

You can use Appcmd to set request filtering limits as follows.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/requestFiltering 
[/allowDoubleEscaping:bool] [/allowHighBitCharacters:bool] 
[/requestLimits.maxAllowedContentLength:uint] [/requestLimits.maxUrl:uint] 
[/requestLimits.maxQueryString:uint]

This command uses the parameters in Table 14-7.

Table 14-7 Parameters for Requesting Filtering Limits

Note You can also configure the request header length limits for each header by adding header limits in the headerLimits collection in the system.webServer/security/requestFiltering section. If the request exceeds a configured header limit, it will be rejected with a 404.10 response status code. Additionally, you can configure which verbs are allowed by adding those verbs to the verbs collection. If the request specifies a verb that is not allowed, it is rejected with a 404.6 response status code.

Configuring Allowed Extensions

By default, the Web server will process only extensions for which a handler mapping exists. By default, StaticFileModule processes all unmapped extensions. StaticFileModule serves only extensions listed in the system.webServer/staticContent configuration section (known as Mimemaps in IIS 6.0 and previous versions of IIS). Therefore, the handler mapping configuration and the static content configuration serves as the two-level mechanism for controlling which extensions can be served for a particular URL.

However, as a defense in depth measure, you may still want to use Request Filtering to deny requests to a particular extension, after making sure that it is not configured in the IIS handler mappings and the static content list. This makes sure that requests to this extension are rejected very early in the request processing pipeline, much before they otherwise would be rejected by the configuration mentioned earlier.

To add a prohibited or explicitly allowed extension by using Appcmd, use the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/requestFiltering 
/+fileExtensions.[fileExtension='string',allowed='bool']

The fileExtension string is in the format of .extension.

To delete a prohibited extension by using Appcmd, use the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/requestFiltering 
/-fileExtensions.[fileExtension='string']

These commands use the parameters in Table 14-8.

Table 14-8 Parameters for Deleting Prohibited Extension

You can set this configuration for a particular site, application, or URL by specifying the configuration path with commands shown earlier in this section.

Note Alternatively, you can configure the fileExtensions collection to deny all unlisted extensions, explicitly enabling the extensions that are allowed. This may be a more effective practice for reducing surface area than prohibiting specific extensions. However, it requires you to know and maintain the exhaustive list of all allowed extensions necessary for your application. To do this, set the allowUnlisted attribute on the fileExtensions collection at the desired configuration path to false.

Configuring Hidden URL Segments

You may also want to prohibit a URL segment from being servable. ASP.NET uses this technique to prohibit requests to the /BIN, /App_Code, and other special /App_xxx directories that contain ASP.NET application resources that the application is not to serve. You can create your own special directories that contain nonservable content and protect them with URL segments. For example, to prevent content from being served from all directories named data, you can create a hidden segment named data.

Direct from the Source: Protecting ASP.NET Special Directories

The debate on how to protect special directories containing application content not meant to be served directly, such as the ASP.NET /BIN directory, dates back to IIS 5.0 days. The ASP.NET team has gone through multiple attempts at achieving this, starting with the explicit removal of Read permissions from the /BIN directory on IIS 5.0 during ASP.NET application startup, to adding the code that prohibited requests containing the /BIN segment to the ASP.NET ISAPI filter. During the development of ASP.NET 2.0, I had the opportunity to guide the solution to this problem for the several new directories introduced by ASP.NET 2.0, such as the new App_Code directory. Unfortunately, removing the Read permissions from these directories was no longer an option, because on IIS 6.0, ASP.NET no longer had Write access to the IIS metabase. In the absence of a general Web server feature to protect special directories, we had no better option than to add blocking support for all new directories to the ISAPI filter. Arguably, the most painful part of the project was the decision to ask the community for the preferred naming of these special directories, which resulted in much debate and the changing of the directory names from Application_Code, to App$_Code, and finally to App_Code. At the end, we were so fed up with changing the names that the development manager ordered hats for all of us that were printed with "App$."IIS 7.0 finally provides a general solution for protecting special directories, a solution that ASP.NET leverages to protect its special directories when installed. Therefore, it no longer relies on the ISAPI filter for this support. Additionally, hidden URL segments provide a general mechanism for anyone to configure protected directories as appropriate for their applications, without writing special code to perform the blocking.Mike VolodarskyIIS Core Program Manager, Microsoft

To add a hidden URL segment by using Appcmd, use the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/requestFiltering 
/+hiddenSegments.[segment='string']

The segment string is the segment to protect.

To delete a hidden URL segment by using Appcmd, use the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/requestFiltering 
/-hiddenSegments.[segment='string']

Note Unlike file extensions, there is no way to prohibit all segments other than the ones configured. You can only deny specific segments by adding them using the preceding command.

You can target configuration for a particular site, application, or URL by specifying the configuration path with the preceding commands.

Configuring Denied URL Sequences

In some cases, you may want to reject requests that contain specific sequences in the URL, whether or not they are a complete segment. If it is not possible to fix the application itself, this may be an effective way to protect an application from certain URL patterns that are known to cause issues.

To add a denied URL sequence by using Appcmd, use the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/requestFiltering 
/+denyURLSequences.[sequence='string']

The sequence string is the sequence to reject.

To delete a denied URL sequence by using Appcmd, use the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/requestFiltering 
/-denyURLSequences.[sequence='string']

Note Unlike file extensions, there is no way to prohibit all URL sequences other than the ones configured. You can only deny specific sequences by adding them using the preceding command.

You can set this configuration for a particular site, application, or URL by specifying the configuration path with the preceding commands.

Authorization

As mentioned earlier, authorization is the second phase in the process of determining whether or not a client has the right to issue a particular request. Authorization refers to determining if the user identity determined during the authentication phase is allowed to access the requested resource.

IIS 7.0 provides several authorization mechanisms that can be leveraged to control access to resources:

• NTFS ACL-based authorization By default, IIS 7.0 verifies that the authenticated user identity has the right to access the physical file or folder corresponding to the requested URL. This check is performed only for requests that map to physical files or directories and use authentication methods that produce Windows tokens. This authorization mechanism has multiple usage limitations that are discussed in detail later in this section.
• URL Authorization The new IIS 7.0 URL Authorization role service enables applications to create declarative configuration-based rules to determine which authenticated users and/or roles have the right to access the Web site or specific URLs therein. This feature replaces the IIS 6.0 URL Authorization feature, which is no longer supported.
• ASP.NET URL Authorization The ASP.NET URL Authorization feature, available since ASP.NET 1.0, is similar to IIS URL Authorization, with a slightly different configuration syntax and rule processing behavior. ASP.NET applications that use this feature today can configure it to control access to all Web site content when they run using ASP.NET integrated mode.

In addition, developers can provide custom authorization features by developing modules by using the IIS 7.0 native module APIs or the ASP.NET APIs for applications using ASP.NET Integrated mode. In fact, you can use most existing ASP.NET authorization modules immediately in applications that are using ASP.NET Integrated mode. This makes it significantly easier to develop custom authorization features that implement business authorization rules and can leverage the powerful ASP.NET membership and role infrastructures. For more information on installing and leveraging custom modules, see Chapter 12.

Caution Exercise extreme caution when configuring or removing authorization modules. If you remove an authorization module that is used to restrict access to the application, parts of the application may become exposed to unauthorized users. See the section titled "Securing Web Server Modules" in Chapter 12 for more information about removing security-sensitive modules.

In the remainder of this section, we will review the authorization features in detail.

NTFS ACL-based Authorization

The IIS 7.0 server engine (rather than a module) automatically performs NTFS ACL-based authorization. During this authorization, the Web server checks that the authenticated user identity has the rights to access the physical file or folder being requested.

Note NTFS ACL-based Authorization is part of the IIS Web server core and therefore is always installed when the Web server is installed. Though it cannot be uninstalled or disabled, you can remove one of the requirements in the following list to configure your application to not use it.

This authorization occurs automatically when all of the following conditions are met:

• The authenticated user identity must have a Windows token. If the request is authenticated using an authentication method that does not provide Windows tokens, for example Forms Authentication, this authorization is not performed.

• The selected handler mapping for the request specifies a resource type of File, Directory, or Either. Some mappings use the resource type of Unspecified to enable requests to virtual URLs that do not have a corresponding physical resource on disk. For these handler mappings, this authorization is not performed. Note Most ASP.NET handler mappings are marked as Unspecified by default. However, ASP.NET includes additional functionality that ensures that if the URL maps to a physical file or folder, the access check is performed (with the exception of content located in a virtual directory that stores its files on a UNC path).

• The request URL maps to a physical file or folder that exists on disk. If the file or directory does not exist, IIS does not perform the check.

• The virtual directory corresponding to the request being made does not specify fixed access credentials. If the virtual directory specifies fixed credentials, they will be used to access all content for the virtual directory, and therefore IIS does not use the authenticated user to check access.

In addition, for you to successfully use NTFS ACL-based authorization, the following conditions must also be true:

• The physical resources have ACLs configured to properly grant or deny access to each authenticated user. This is typically done by placing all of the allowed users in a group, and granting this group access to the content.
• If the virtual directory corresponding to the request refers to a remote UNC share and does not specify fixed UNC credentials, the authenticated user identity must be able to delegate to the remote server. This requires basic authentication, or requires Constrained Delegation or Protocol Transition to be configured. For more information, see the section titled "UNC Authentication" later in this chapter.

Because of the aforementioned limitations and the overhead of managing NTFS ACL permissions for multiple users, NTFS ACL-based authorization is not recommended as a generic mechanism for restricting access to IIS resources. Use it only if your application meets the preceding requirements and you would like to use ACLs as an authorization mechanism (for example, if you are sharing static resources for users with domain or local machine accounts, and the resources already have the right permissions configured).

Because this authorization happens automatically for physical resources, you must configure all required resources to grant access to the authenticated identities that need to use your application. See the section titled "Set NTFS Permissions to Grant Minimal Access" in this chapter for more information on properly configuring NTFS ACLs for use with NTFS ACL authorization.

URL Authorization

The IIS 7.0 URL Authorization feature is new in IIS 7.0. It provides a way to configure declarative access control rules that grant or deny access to resources based on the authenticated user and its role membership.

Note URL Authentication is not part of the default IIS install. You can manually install it from the Windows Features IIS feature category through Windows Features on Windows Vista or from the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008. See Chapter 12 for more information about installing and enabling modules.

Unlike NTFS ACL-based authorization, URL Authorization has the following advantages:

• It is not tied to authentication schemes that produce Windows identities. It can be used with any authentication schemes, including Forms Authentication, which produces custom authenticated user identities.
• It enables rules to be configured for specific URLs, not underlying files or directories. Therefore, it is not tied to specific resource types and does not require files or directories to exist.
• It stores authorization rules in the configuration, instead of NTFS ACLs. These rules are easier to create and manage, and they can be specified in distributed web.config files that travel with the application when it is deployed or copied between servers.
• It integrates with the ASP.NET Membership and Roles services, which enables custom authentication and role management modules to provide the authenticated users and their roles. You can use ASP.NET Forms Authentication with Membership and Roles to quickly deploy a data-driven user and roles credential store for your application.

Note The IIS 7.0 URL Authorization feature is new. It is not related to the similarly named IIS 6.0 URL Authorization feature, which is overly complex, difficult to configure, and not widely used. The IIS 6.0 URL Authorization feature is not included with IIS 7.0.

The ASP.NET URL Authorization feature inspired the new URL Authorization feature, which implements similar functionality. However, some key differences exist in how rules are configured and processed. We'll discuss these differences later in this section.

Using URL Authorization to Restrict Access

To use URL Authorization to restrict access to your application, you need to configure one or more URL Authorization rules. These rules can be configured at the Web server level. Alternatively, you can configure them for a specific Web site, application, or URL. This makes it very easy to use URL Authorization to quickly restrict access to any part of your Web site to a specific set of users or roles.

These rules can be one of the following types:

• Allow An allow rule grants access to the resource being requested and allows request processing to proceed.
• Deny A deny rule denies access to the resource being requested, rejecting the request.

Both types of rules can specify a set of users, roles, and/or verbs that URL Authorization uses to match each rule to the request. As soon as a rule matches, the corresponding action (Allow or Deny) is taken. If the request is denied, URL Authorization will abort request processing with a 401 unauthorized response status code. If no rules matched, the request will also be denied.

Unlike ASP.NET URL Authorization, the deny rules are always processed before allow rules. This means that the relative order between deny and allow rules does not matter. In addition, the order between rules defined by parent configuration levels and the current configuration level does not matter, because all deny rules from all levels are always processed first, followed by all allow rules. Finally, the default behavior when no rules match is to deny the request.

By default, URL Authorization has a single rule configured at the Web server level that provides access to all users. You can restrict access to your Web site or a part of it by creating authorization rules by using the following techniques:

• Remove the default allow rule for all users and create explicit allow rules only for users and roles that should have access to the current URL level. This way, by default, all requests will be denied unless the authenticated user or role matches the configured allow rule. This is the recommended practice, because it ensures that only the configured users and roles have access to the resource, and it denies access to everyone else.
• Create explicit deny rules for users and roles that should not have access to the current URL level. This may be appropriate to prevent access for only the specific users and roles. However, it is not generally a secure practice, because the set of users and roles is typically unbounded. The exception to this rule is the technique of creating a deny all anonymous users rule to restrict access only to authenticated users.

Note When designing the access control rules for your application, prefer to grant access to roles instead of specific users. This makes it easier to manage authorization rules as more users are added.

See the following section titled "Creating URL Authorization Rules" for information on configuring URL Authorization rules.

Creating URL Authorization Rules

You can use IIS Manager to configure URL Authorization rules by selecting the desired node in the tree view and double-clicking Authorization Rules. In the resulting window shown in Figure 14-5, you can see the list of rules currently in effect at the level you selected, which will include both the rules configured at higher configuration levels and the rules configured at the current configuration level.

Figure 14-5 Configuring URL authorization rules.

You can remove existing authorization rules (including parent authorization rules that are not locked) by selecting them in the list and clicking Remove in the Actions pane. You can add an allow or deny rule by clicking Add Allow Rule or Add Deny Rule in the Actions pane. Figure 14-6 shows an allow rule that can be used to allow access to all users or specific users or roles.

Figure 14-6 Adding an Allow URL authorization rule.

You can also edit URL Authorization rules by configuring them directly in the system.webServer/security/authorization configuration section, by using Appcmd from the command line, or by using configuration APIs. This configuration section is unlocked by default to facilitate storing URL authorization rules in your application's web.config files, which enables them to travel with the corresponding application content when deploying the application to another Web server.

To add a URL authorization rule with Appcmd, you can use the following syntax.

%systemroot%\system32\inetsrv\Appcmd.exe set config [ConfigurationPath] 
/section:system.webServer/security/authorization 
"/+[users='string',roles='string',verbs='string',accessType='enum']"

To delete a URL authorization rule with Appcmd, you can use the following syntax.

%systemroot%\system32\inetsrv\Appcmd.exe set config [ConfigurationPath] 
/section:system.webServer/security/authorization 
"/-[users='string',roles='string',verbs='string']"

The parameters to these commands are shown in Table 14-9.

Table 14-9 Parameters for Adding URL Authorization Rule

Using ASP.NET Roles with URL Authorization

In applications using the ASP.NET Integrated mode, it is possible to configure the ASP.NET Roles feature to provide application-specific roles for each authenticated user. IIS 7.0 URL Authorization rules can specify access rules that use roles provided by the .NET Roles feature or another ASP.NET module to implement application-specific authorization schemes, much like the original ASP.NET URL Authorization feature. You can learn about setting up the ASP.NET Roles feature at https://msdn2.microsoft.com/en-us/library/9ab2fxh0.aspx.

When the .NET Roles feature is enabled, and a role provider is configured for your application, you can begin configuring URL Authorization rules that rely on these roles in your application. To make sure that the roles are available for requests to non-ASP.NET content types, be sure to remove the managedHandler precondition from the RoleManager module. For information about enabling managed modules to run for all requests by removing the managedHandler precondition, see the section titled "Enabling Managed Modules to Run for All Requests" in Chapter 12.

You can also create roles directly using IIS Manager by selecting the application node in the tree view and then clicking.NET Roles. In the resulting page, you can manage existing roles, create new roles using the configured Role provider for the application, and associate application users with roles.

Authentication

Authentication is the process of determining the identity of the user making the request to the Web server. Authorization features can then use this identity to allow or reject the request to specific resources or parts of the application. In some cases, the Web server or the application can impersonate it to access resources. Finally, the application can use the identity to personalize the application experience for the requesting user.

IIS 7.0 includes the following authentication features:

• Anonymous Authentication This authentication method provides a configured Windows identity for all anonymous users of the application without the need to provide any client credentials. It is used to allow anonymous (unauthenticated) access.
• Basic Authentication This authentication method enables the client to provide the user name and password to the Web server in clear text. Basic Authentication is defined in RFC 2617, and virtually all browsers support it.
• Digest Authentication This authentication method is a more secure version of Basic Authentication, and it enables the client to provide user credentials via a hash of the user name and password. Digest Authentication is defined in RFC 2617, and most browsers support it. The implementation used in IIS 7.0 was known as the Advanced Digest Authentication method in IIS 6.0.
• Windows Authentication This authentication method supports the NT LAN Manager (NTLM) or Kerberos Windows authentication protocols.
• Client Certificate Mapping Authentication This authentication method enables client SSL certificates to be mapped to Windows accounts by using Active Directory directory services.
• IIS Client Certificate Mapping Authentication This authentication method enables client SSL certificates to be mapped to Windows accounts via one-to-one or many-to-one mappings stored in IIS configuration.
• UNC Authentication Though this is not a true authentication method in the sense that it does not help to establish the identity of the requesting client, IIS 7.0 uses UNC Authentication to establish an identity to access remote content located on a UNC share.

In addition, IIS 7.0 applications using ASP.NET Integrated mode use a unified authentication model between IIS and ASP.NET. This enables existing ASP.NET authentication modules or new managed authentication modules developed with ASP.NET APIs to be used for all content in the application. When ASP.NET is installed, the following authentication methods are also available:

• Forms Authentication This ASP.NET authentication method supports forms-based authentication against pluggable credentials stores via the ASP.NET Membership service. 

The following IIS 6.0 authentication methods are no longer supported:

• IIS 6.0 Digest Authentication IIS 7.0 Advanced Digest Authentication method is now provided as the only digest authentication method.
• .NET Passport Authentication The Passport support is not included in Windows Server 2008, and therefore this method is also no longer supported.

Developers can also provide custom authentication features developed with the new IIS 7.0 native module API or with ASP.NET APIs for applications using the Integrated mode. In fact, applications running in Integrated mode can use most existing custom ASP.NET authentication modules immediately to provide site-wide authentication. For more information on installing and leveraging custom modules, see Chapter 12.

You can configure one or more authentication methods for your Web site, application, or part thereof to protect it with user-based authorization, enable impersonation for resource access, or allow for application personalization.

Note IIS 7.0 requires that each request is authenticated. Because of this, at least one authentication method must be enabled and be able to provide an authenticated user for each request.

In the remainder of this section, we will review each of the authentication methods.

Anonymous Authentication

Anonymous authentication enables clients to access public areas of your Web site without requiring the client to provide any credentials. Anonymous authentication is the default authentication method enabled in IIS 7.0.

Note Anonymous authentication is part of the default IIS install and is enabled by default. You can manually install or uninstall it by installing or uninstalling the Anonymous-AuthnenticationModule module. See Chapter 12 for more information about installing and enabling modules.

Anonymous authentication applies for all requests that do not have an authenticated user identity determined by other authentication methods. It works by setting the authenticated user identity for such requests to be a Windows identity corresponding to the configured anonymous user account.

Caution Be sure to disable anonymous authentication for parts of your Web site that you do not want to be accessed by anonymous users. You must do this even if you have other authentication methods enabled.

By default, anonymous authentication is configured to use the new built-in IUSR account. It no longer uses the custom IUSR_ComputerName account that is used by default with anonymous authentication in IIS 6.0. Because IUSR is a built-in account, it does not have a password that must be periodically changed or synchronized between multiple servers. In addition, because it is built in, the IUSR account has the same SID on all machines. Therefore, ACLs that reference it remain valid when copied from one IIS 7.0 server to another.

When using anonymous authentication, you have the following options:

• Use the built-in IUSR account. This is the default.
• Use a custom account. You can configure a custom account that should be used for anonymous requests instead of the IUSR account.
• Use the application pool identity. You can configure anonymous authentication to use the identity of the IIS worker process (application pool identity) instead of a separate anonymous account.

You can use the application pool identity option to simplify resource access management. This ensures that that resource access is always made under the application pool identity, both when the Web server accesses application resources using the application pool identity and when the Web server or application access resources while impersonating the authenticated user. This way, you only need to manage access rights for a single identity. See the section titled "Set NTFS Permissions to Grant Minimal Access" earlier in this chapter for more information about setting permissions.

You can use IIS Manager to enable or disable anonymous authentication and set the anonymous user options. Select the desired node in the tree view and double-click Authentication. Then, select Anonymous Authentication in the list and use the Enable, Disable, and Edit commands in the Actions pane to configure it.

You can also set anonymous authentication configuration directly; use Appcmd.exe from the command line, or use configuration APIs to configure the system.webServer/security/-anonymousAuthentication section. You do this with Appcmd by using the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/anonymousAuthentication [/enabled:bool] 
[/username:string] [/password:string] [/logonMethod:enum]

The parameters of this command are shown in Table 14-10.

Table 14-10 Parameters to Set Anonymous Authentication and Anonymous User Options

Basic Authentication

Basic authentication implements the Basic Authentication protocol, a standard HTTP authentication scheme defined in RFC 2617 and supported by most HTTP client software. It enables the client to pass both the user name and the password in clear text, and it uses these credentials to log on locally at the Web server or the Web server's domain. The credentials, therefore, must correspond to a valid local or domain account, and they result in the request being authenticated with a Windows token corresponding to this account.

Note Basic authentication is not part of the default IIS install. You can manually install it from the Security feature category through Windows Features On And Off on Windows Vista. You can also install it from the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008. See Chapter 12 for more information about installing and enabling modules.

Basic authentication is a challenge-based authentication scheme. When a client makes the initial request to a resource that requires authentication, and basic authentication is enabled, the request will be rejected with a 401 unauthorized status that will include a "WWW-Authenticate: basic" response header. If the client supports basic authentication, it will usually prompt the user for credentials and then reissue the request with the credentials included. The basic authentication module will see that credentials are present on the subsequent request and attempt to authenticate the request by logging on with those credentials. The client will typically send these credentials again on every request to the same URL or any URL that is below the URL included in the initial authenticated request.

Caution Just enabling basic authentication does not mean that authentication is required for your application. You must either disable anonymous authentication and/or configure URL authorization rules or NTFS permissions that deny access to the anonymous user.

Basic authentication is not secure because it passes the credentials in clear text, and therefore may enable an attacker to steal them by eavesdropping on the request packets at the network level. This can be mitigated by using SSL to secure the communication channel between the client and the server. If SSL is used to protect all requests that include the credentials, basic authentication may be a secure option. For more information on configuring secure communication with SSL, see the section titled "Securing Communications with Secure Socket Layer (SSL)" later in this chapter.

Caution Basic authentication may enable user credentials to be leaked because it sends them to the Web server in an unencrypted form. When using basic authentication, use SSL to secure the Web site.

Because basic authentication performs the logon locally at the Web server, the resulting Windows token can be used to access resources on a remote server without configuring delegation or Protocol Transition. See the section titled "Understanding Authentication Delegation" later in this chapter for more information.

By default, basic authentication caches the logon token for the corresponding user name and password in the token cache. During this time, the token may be available inside that process. If the worker process is compromised, malicious code can use this token to elevate privileges if the token represents a user with high privileges. If you do not trust the code in the process, you can either disable token caching by uninstalling the token cache module or reduce the amount of time the tokens are cached by setting the HKLM\SYSTEM\CurrentControlSet\ Services\InetInfo\Parameters\UserTokenTTL value to the number of seconds to cache tokens for.

You can use IIS Manager to enable or disable basic authentication and set the logon method options. Select the desired node in the tree view and double-click Authentication. Then, select Basic Authentication from the list and use the Enable, Disable, and Edit commands in the Actions pane to configure it.

You can also set basic authentication configuration directly; use Appcmd.exe from the command line, or use configuration APIs to configure the system.webServer/security/basic-Authentication section. You do this with Appcmd by using the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/basicAuthentication [/enabled:bool] 
[/realm:string] [/defaultLogonDomain:string] [/logonMethod:enum]

The parameters of this command are shown in Table 14-11.

Table 14-11 Parameters for Setting Basic Authentication Configuration Directly

Digest Authentication

The Digest Authentication feature implements the Digest Authentication protocol, a standard HTTP authentication scheme defined in RFC 2617 and supported by some HTTP client software. Unlike basic authentication, the client sends an MD5 hash of the user name and the password to the server so that the real credentials are not sent over the network. The Digest Authentication scheme in IIS 7.0 was known as the Advanced Digest Authentication in IIS 6.0 (IIS 7.0 no longer supports the IIS 6.0 Digest Authentication). If successful, Digest Authentication authenticates the request with a Windows token corresponding to the user's Active Directory account.

Note Digest authentication is not part of the default IIS install. You can manually install it from the Security feature category through Windows Features On And Off on Windows Vista. You can also install it through the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008. See Chapter 12 for more information about installing and enabling modules.

Like basic authentication, digest authentication is a challenge-based authentication scheme. When a client makes the initial request to a resource that requires authentication, and digest authentication is enabled, the request will be rejected with a 401 unauthorized status that includes a "WWW-Authenticate: digest" response header containing additional information required by the Digest Authentication scheme. If the client supports digest authentication, it will usually prompt the user for the credentials and then reissue the request with the hash of the credentials and the nonce information in the challenge. The Digest Authentication module will see that the hash is present on the subsequent request and attempt to authenticate the hash by comparing it with the hash stored in Active Directory. The client will typically send the hash information again on every request to the same URL or any URL below the URL used in the initial authenticated request.

The Web server and the clients accessing it must meet the following requirements to use IIS 7.0 Digest Authentication:

• Both the Web server and the clients using your application must be members of the same domain, or the client must be a member of a domain trusted by the Web server.
• The clients must use Microsoft Internet Explorer 5 or later.
• The user must have a valid Windows user account stored in Active Directory on the domain controller.
• The domain controller must be using Windows Server 2003 or Windows Server 2008.

Unlike the IIS 6.0 Digest Authentication, the IIS 7.0 Digest Authentication does not require the application pool identity to be LocalSystem. In fact, you should not ever use LocalSystem or any other identity with Administrative privileges on the server as an application pool identity. For more information on configuring least privilege identities for application pools, see the section titled "Configuring Applications for Least Privilege" earlier in this chapter.

Caution Just enabling digest authentication does not mean that authentication is required for your application. You must either disable anonymous authentication and/or configure URL authorization rules or NTFS permissions that deny access to the anonymous user.

Unlike basic authentication, the authenticated token is not suitable for accessing remote resources, and it requires Constrained Delegation or Protocol Transition to be configured to do so. For more information, see the section titled "Understanding Authentication Delegation" later in this chapter.

You can enable or disable digest authentication by using IIS Manager. Select the desired node in the tree view and double-click Authentication. Then, select Digest Authentication from the list and use the Enable, Disable, and Edit commands in the Actions pane to configure it.

You can also set digest authentication configuration directly; use Appcmd.exe from the command line, or use configuration APIs to configure the system.webServer/security/digest-Authentication section. You do this with Appcmd by using the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/digestAuthentication [/enabled:bool] 
[/realm:string]

The parameters of this command are shown in the Table 14-12.

Table 14-12 Parameters for Setting Digest Authentication

Windows Authentication

The Windows Authentication scheme enables Windows clients to authenticate with two Windows authentication protocols, NTLM (NT LAN Manager) and Kerberos. Both of these schemes involve a cryptographic exchange between the client and the server to authenticate the client.

Note Unlike Windows Server 2003, Windows Authentication is not part of the default IIS install and is not enabled by default. You can manually install it from the Security feature category through Turn Windows Features On And Off on Windows Vista. You can also install it via the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008. See Chapter 12 for more information about installing and enabling modules. After the module is installed, you have to explicitly enable Windows Authentication for it to be available.

Windows Authentication, similar to other IIS authentication methods, is challenge-based. When a request is rejected with a 401 unauthorized response status code, Windows Authentication will issue a WWW-Authenticate challenge header including one or both of the following authentication scheme names:

• NTLM Indicates to the client that it can use the NTLM authentication protocol to authenticate. This is included for older clients that do not support the negotiate wrapper.
• Negotiate Indicates to the client that it can use Kerberos or NTLM protocols to authenticate. Negotiate is used to allow either Kerberos or NTLM authentication, depending on what is available on the client.

Note Both Kerberos and NTLM authentication methods involve the client making several (typically two to three) requests to the server as part of the authentication handshake. This means that your modules may see multiple requests as part of the authentication process. By default, authentication occurs once per connection, so it does not occur again for subsequent requests using the same connection.

The client then makes the decision to use either Kerberos (if available) or NTLM and initiates a sequence of requests to authenticate using the selected protocol. The choice of protocol is based on whether or not the client is configured to be able to use Kerberos to authenticate with the server, which requires a direct connection to the Key Distribution Center (KDC) on the domain controller as well as direct access to Active Directory. NTLM can be used in a non-domain scenario against local Windows accounts on the server or when the connection to domain services required for Kerberos is unavailable.

Note Windows Authentication is best suited for intranet environments.

Windows Authentication is a reasonable choice for Windows-based intranet environments, but for other environments, keep in mind the following limitations:

• It does not work over HTTP proxies. This is because Kerberos and NTLM are connection-based, and proxies may not keep connections open or may share connections between requests from multiple clients.
• The Kerberos protocol requires both the client and the server to be members of the same domain or two domains with a trust relationship and have a direct connection to Active Directory and the KDC services located on the domain controller.
• The Kerberos protocol requires correct Service Principal Name (SPN) registration in Active Directory for all application pools performing Kerberos authentication.

Configuring Windows Authentication

You can enable or disable Windows Authentication by using IIS Manager. Select the desired node in the tree view and double-click Authentication. Then, select Windows Authentication in the list and use the Enable, Disable, and Edit commands in the Actions pane to configure it.

You can also set digest authentication configuration directly; use Appcmd.exe from the command line, or use configuration APIs to configure the system.webServer/security/windowsAuthentication section. You do this with Appcmd by using the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
/section:system.webServer/security/windowsAuthentication [/enabled:bool] 
[/authPersistSingleRequest:bool] [/authPersistNonNTLM:bool] 
[/useKernelMode:bool] [/useAppPoolCredentials:bool]

The parameters of this command are shown in Table 14-13.

Table 14-13 Parameters for Configure Authentication

In addition, you can also control whether the server uses NTLM or Negotiate protocols. To do this, you can edit the providers collection in the system.webServer/security/windowsAuthentication configuration section. By default, this collection contains both NTLM and Negotiate protocol providers. You can force the server to use only NTLM by removing the Negotiate protocol provider. However, you cannot force the server to use only Kerberos in this configuration, because the negotiate wrapper enables the client to use either NTLM or Kerberos. There is no way to tell the client that only Kerberos is supported.

You can, however, configure the NTLM authentication level by using the Local Security Policy console and modifying the Security Settings\Local Policies\Security Options\Network Security: LAN Manager Authentication Level option, as shown in Figure 14-7. The default setting is Send NTLMv2 Response Only, which enables the server to accept all levels. You can set this setting to Send NTLMv2 Response Only. Refuse LM & NTLM for maximum security while allowing clients that do not have the ability to use Kerberos to use the NTLMv2 scheme.

Figure 14-7 Configure NTLM Authentication Level.

In IIS 6.0, to use the Kerberos authentication protocol, you have to use the Setspn.exe command line tool to register Service Principal Names (SPNs) in Active Directory for the NetBIOS and the Fully Qualified Domain Name (FDQN) names for each application pool account. Additionally, you could have only one application pool account registered for each SPN, preventing multiple application pools with different identities from using Kerberos authentication.

In IIS 7.0, kernel-based Windows Authentication (enabled by default) offers improved functionality. Because HTTP.sys performs the authentication process in the kernel, it is done under the LocalSystem account regardless of the application pool identity. This results in the following improvements:

• It should no longer be necessary to configure separate SPNs, because Kerberos will use the default NetBIOS SPN entry created automatically when the Web server computer is joined to the domain.
• Application pool identity can be changed without the need to reregister the SPN with the new account. The application pool account no longer needs to be a domain account.
• Multiple application pools can use Kerberos authentication.

These changes make it significantly easier to deploy and use the Kerberos protocol with IIS.

Note You need to use the application pool identity and register SPNs for Kerberos authentication when you are using it on a Web farm.

However, if you are using IIS on a Web farm and require the Kerberos protocol, you will need to disable the use of the LocalSystem identity for Kerberos authentication by setting the useAppPoolCredentials attribute in the system.webServer/security/authentication/windows-Authentication configuration section to true. In addition, you will need to use a domain account as an identity for the application pool. You will also be required to use Setspn.exe to register the Web site host name using this domain account under which the application pools are configured to run in Active Directory. For more information about registering SPNs for Kerberos with Setspn.exe, see https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true.

Client Certificate Mapping Authentication

Client Certificate Mapping Authentication enables clients to authenticate with the Web server by presenting client certificates over Secure Socket Layer (SSL) connections.

Note Certificate-based authentication enables clients to use client certificates to authenticate with the Web server. It is not required to enable secure communication between the client and the server.

The Client Certificate Mapping Authentication uses the Directory Services Mapper (DS Mapper) service in Active Directory to map client certificates provided by the user to domain accounts. IIS also provides a custom certificate mapping feature, the IIS Client Certificate Mapping Authentication, which allows for more flexible mapping of client certificates to Windows accounts. See the section titled "IIS Client Certificate Mapping Authentication" later in this chapter for more information.

Note Client Certificate Mapping Authentication is not part of the default IIS install and is not enabled by default. You can manually install it from the Security feature category through Turn Windows Features On And Off on Windows Vista. You can also install it via the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008. See Chapter 12 for more information about installing and enabling modules. After the module is installed, you have to explicitly enable Client Certificate Mapping Authentication for it to be available.

To use Client Certificate Mapping Authentication, you need to meet the following requirements:

• The Web server must be a member of a Windows domain.
• You must issue client certificates to your users by using a Certificate Authority (CA) trusted by the Web server.
• You must map each client certificate to a valid domain account in Active Directory.

Note You do not need to use Client Certificate Mapping Authentication to require clients to present client certificates. You can configure the server to always require client certificates to access the server, but use another authentication scheme to authenticate the client. To do this, see the section titled "Client Certificates" later in this chapter.

To enable Client Certificate Mapping Authentication on the Web server, you need to perform the following steps (after installing the Certificate Mapping Authentication module).

1. Enable Client Certificate Mapping Authentication. You can do this in IIS Manager by clicking the server node, double-clicking Authentication, selecting Active Directory Client Certificate Authentication, and clicking Enable in the Actions pane. Note that this can only be done at the server level when using IIS Manager, although you can enable Client Certificate Mapping Authentication for a specific URL through configuration.
2. Configure SSL on each Web site using this authentication method. Certificate authentication is possible only if the Web site is being accessed over an SSL connection and therefore requires an SSL binding to be configured for the Web site. See the section titled "Configuring SSL" later in this chapter for more details.
3. Enable DS Mapper for each Web site SSL binding. IIS Manager does this automatically for each Web site when the Client Certificate Mapping Authentication is enabled and you add an SSL binding for the Web site. To do this manually, use the Netsh.exe command with the following syntax: netsh http add sslcert IP Address:Port dsmapperusage=enable, where IP Address and Port are the IP address and port of the corresponding binding.
4. Configure each Web site using this authentication method to accept client certificates (and possibly require them). This ensures that the server accepts client certificates when provided by the client and can also configure the server to require the client to present a certificate to proceed with the request. See the section titled "Client Certificates" later in this chapter for more details.

You can also enable Client Certificate Mapping Authentication by editing the system.webServer/security/authentication/clientCertificateMappingAuthentication configuration section directly or by using Appcmd or other configuration APIs. You can enable this authentication method by using the following Appcmd syntax.

%systemroot%\system32\inetsrv\Appcmd set config /section: 
system.webServer/security/authentication/ 
clientCertificateMappingAuthentication /enabled:true

The enabled attribute specifies whether or not the Client Certificate Mapping Authentication is enabled. You can enable this method for a specific URL. However, do note that the decision to use the Directory Services Mapper to map certificates to Windows domain accounts is dependent on each Web site binding having been configured to use the HTTP.sys DS Mapper setting.

You can read more about configuring SSL and configuring the server to accept client certificates in the section titled "Client Certificates" later in this chapter.

IIS Client Certificate Mapping Authentication

IIS Client Certificate Mapping Authentication enables clients to authenticate with the Web server by presenting client certificates over Secure Socket Layer (SSL) connections.

Note Certificate-based authentication enables clients to use client certificates to authenticate with the Web server. It is not required to enable secure communication between the client and the server using SSL.

The IIS Client Certificate Mapping Authentication provides a more flexible mechanism for authenticating clients based on client certificates than does the Active Directory–based Client Certificate Mapping Authentication. Instead of relying on the Directory Services Mapper (DS Mapper) service to map client certificates to Windows accounts, it uses the configuration to perform the mapping. As such, it also does not require the user accounts to be domain accounts and does not require Active Directory to operate.

Note IIS Client Certificate Mapping Authentication is not part of the default IIS install and is not enabled by default. You can manually install it from the Security feature category through Turn Windows Features On And Off on Windows Vista. You can also install it via the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008. See Chapter 12 for more information about installing and enabling modules. After the module is installed, you have to explicitly enable IIS Client Certificate Mapping Authentication for it to be available.

The IIS Client Certificate Mapping Authentication feature supports the following mapping types:

• One-to-one mapping Map a single client certificate to a specific Windows account. The server will use an exact copy of the client certificate to perform the match and therefore must possess a copy of each client certificate.
• Many-to-one mapping Map client certificates to a Windows account by matching wildcard expressions involving specific certificate fields, such as issuer or subject. This does not require a copy of the client certificate.

To use IIS Client Certificate Mapping Authentication, you need to meet the following requirements:

• You cannot use Active Directory–based Client Certificate Mapping Authentication on any of the sites for which you enable IIS Client Certificate Mapping Authentication.
• You must have the passwords for all Windows accounts used to map certificates. Unlike Client Certificate Mapping Authentication, which relies on Active Directory to generate the Windows token for the account, you will need to specify both the user name and password for each account being mapped so that IIS can generate the token.
• To use one-to-one mappings, you must have an exact copy of each client certificate being mapped. If you provide the certificates to users, you will have this copy. Otherwise, you will need each user to provide you with an exported copy of the certificate. When using many-to-one mappings, you do not need copies of the certificates.

Note You do not need to use IIS Client Certificate Mapping Authentication to require clients to present client certificates. You can configure the server to always require client certificates to access the server and then use another authentication scheme to authenticate the client. For more about how to do this, see the section titled "Client Certificates" later in this chapter.

To enable IIS Client Certificate Mapping Authentication for a specific Web site or URL, you need to perform the following steps (after installing the IIS Certificate Mapping Authentication module):

1. Enable IIS Client Certificate Mapping Authentication. This option is not available in IIS Manager. To do this, you will need to edit the system.webServer/security/authentication/iisClientCertificateMappingAuthentication section directly. Alternatively, you can use Appcmd or another configuration API. You can enable IIS Client Certificate Mapping Authentication with Appcmd by using the following syntax (see details on configuring this configuration section later in this section).

   %systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath] 
   /section:system.webServer/security/authentication/ 
   iisClientCertificateMappingAuthentication /enabled:true /commit:apphost
   

2. Configure SSL on each Web site using this authentication method. Certificate authentication is possible only if the Web site is being accessed over an SSL connection. Therefore, it requires an SSL binding to be configured for the Web site. See the section titled "Configuring SSL" for more details.

3. Configure each Web site using this authentication method to accept client certificates (and possibly require them). Doing so ensures that the server accepts client certificates when the clients provide them. Doing so can also configure the server to require the client to present a certificate to proceed with the request. See the section titled "Client Certificates" for more details.

4. Configure the required one-to-one or many-to-one mappings. Create the mappings to map certificates to Windows accounts.

Note Although you can enable the IIS Client Certificate Mapping Authentication feature for a specific URL, the mapping configuration can only be set at the server or Web site level, and it is ignored if it is set at a lower configuration level.

You can read more about configuring SSL and configuring the server to accept client certificates in the section titled "Client Certificates" later in this chapter. We will describe the process for configuring certificate mappings for IIS Client Certificate Mapping Authentication next in the sections titled "Creating One-to-One Certificate Mappings" and "Creating Many-to-One Certificate Mappings."

Creating One-to-One Certificate Mappings

You can use one-to-one certificate mappings as part of a strong authentication and authorization scheme to control access to application resources based on the exact identity of the client. It can be used instead of a user name and password authentication scheme that requires the user to supply credentials. To use one-to-one mappings, you need to have the exact copy of each certificate.

IIS Manager does not provide support for configuring one-to-one mappings. You can configure them by using the Appcmd command line tool. You can also do it by editing the system.webServer/security/authentication/iisClientCertificateMappingAuthentication configuration section directly or with other configuration APIs. You can add a one-to-one mapping by using the following Appcmd syntax.

%systemroot%\system32\inetsrv\Appcmd set config [SiteName] 
/section:system.webServer/security/authentication/ 
iisClientCertificateMappingAuthentication /+oneToOneMappings 
[certificate='string',enabled='bool',username='string',password='string']

You can remove a one-to-one mapping by using the following Appcmd syntax.

%systemroot%\system32\inetsrv\Appcmd set config [SiteName] 
/section:system.webServer/security/authentication 
/iisClientCertificateMappingAuthentication /-oneToOneMappings 
[certificate='string']

These commands use the parameters in Table 14-14.

Table 14-14 Parameters for Creating Certificate Mappings

You can obtain the exact text of the certificate from an exported certificate file (containing unencrypted certificate information) or by dumping the certificate from the local or domain certificate store. To do the latter, you can use the following command.

certuil –encode –f CertName cert.cer

CertName is the friendly name of the certificate. You can view the certificate store and obtain the friendly name of the installed certificates with the following command.

certuil –viewstore StoreName

StoreName is the name of the certificate store. Use MY for the personal certificate store.

Note You must specify the exact base64 encoded certificate contents for the one-to-one mapping, with the training line feed removed. Do not use the certificate hash. If you do not specify the certificate correctly, you will get a 401.1 status error when making requests to the Web site. This error will show the 0x8009310b HRESULT, indicating that IIS failed to load the certificate from the mapping entry.

Creating Many-to-One Certificate Mappings

Many-to-one mappings, unlike one-to-one mappings, are not typically used to authenticate specific users. Instead, you can use them to authenticate a group of users by matching fields in their certificates to a single Windows account. Therefore, authorization based on the authenticated user produced by a many-to-one mapping is similar to role- or group-based authorization, with the authenticated user representing a group to which multiple users belong. For example, you can match all certificates issued by a specific organization to that organization's account. As such, many-to-one mappings may be less appropriate for user-based personalization or access control than one-to-one mappings, depending on your authorization strategy.

Note One-to-one mappings are always processed before many-to-one mappings.

Many-to-one mappings do not require the server to have the exact certificate for each user. Instead, you simply configure wildcard rules based on one or more fields in the certificate that map all certificates with matching fields to a Windows account.

IIS Manager does not provide support for configuring many-to-one mappings. You can configure them by using the Appcmd command line, too. You can also edit the system.webServer/security/authentication/iisClientCertificateMappingAuthentication configuration section directly or with other configuration APIs. You can add a one-to-one mapping by using the following Appcmd syntax.

%systemroot%\system32\inetsrv\Appcmd set config [SiteName] 
/section:system.webServer/security/authentication/ 
iisClientCertificateMappingAuthentication /+manyToOneMappings 
[name='string',enabled='bool',permissionMode='enum', 
username='string',password='string',description='string']

Then, you have to add one more matching rule to the mapping by using the following Appcmd syntax, specifying the name of the mapping created in the command shown previously.

%systemroot%\system32\inetsrv\Appcmd set config [SiteName] /section:system.webServer/security/authentication/ iisClientCertificateMappingAuthentication /+manyToOneMappings [name='string'].rules.[certificateField='enum', certificateSubField='string',matchCriteria='string', compareCaseSensitive='bool']

You can delete a mapping by using the following Appcmd syntax.

%systemroot%\system32\inetsrv\Appcmd set config [SiteName] 
/section:system.webServer/security/authentication/ 
iisClientCertificateMappingAuthentication /-manyToOneMappings 
[name='string']

These commands use the parameters in Table 14-15.

Table 14-15 Parameters for Creating Certificate Mappings

UNC Authentication

The Web server core uses UNC authentication to establish an identity for accessing remote application content inside virtual directories that reside on a UNC share. It is not a true authentication method in the sense that it does not itself support an authentication scheme for establishing the identity of the client. Rather, it is a mechanism for using the authenticated user that has been established through other authentication mechanisms—and in some cases a fixed identity set in configuration—to determine which identity should be used for remote content access.

IIS uses UNC authentication whenever a request is made to a resource that resides in a virtual directory whose physical path is located on a UNC share (whether or not the UNC share is on the local computer). During UNC authentication, the Web server determines the identity to be used for accessing remote content as follows:

1. Uses the virtual directory's fixed credentials. In IIS 7.0, any virtual directory can specify fixed credentials that IIS uses for all accesses to that location. This replaces the UNCUserName and UNCPassword properties in IIS 6.0 that were used only when the virtual directory referred to a UNC share.
2. Otherwise, uses the authenticated user if available. If the virtual directory does not specify fixed credentials, use the authenticated user if it has already been determined by an authentication method. This is referred to as pass-through authentication. You cannot use this to access web.config files, because this access occurs before IIS determines the authenticated user.
3. Otherwise, uses process identity. If IIS has not yet determined the authenticated user, it will use the identity of the IIS worker process. The Web server uses this option to access web.config files (if virtual directory credentials are not configured), because configuration is read prior to the authentication stage.

Note IIS 7.0 cannot use pass-through authentication to access web.config files located on the remote UNC share. Because of this, the virtual directory must specify fixed credentials, or the application pool identity must have Read access to the remote UNC share.

By default, IIS cannot access remote UNC content. This is because the default anonymous user IUSR is a local built-in account that does not have network privileges. Additionally, because IIS is required to access web.config by using the IIS worker process identity, it has a similar problem because the Network Service account also does not typically have the right to access remote resources. Therefore, you typically have two options for configuring UNC authentication to allow proper access of remote content:

• Use pass-through authentication Pass-through authentication requires both the application pool identity and all allowed authenticated user identities to have access to the remote UNC share. Additionally, it requires the use of an authentication scheme that is capable of delegating the user identity to a remote computer or configuring Constrained Delegation and/or Protocol Transition to enable this for other authentication schemes.
• Use virtual directory fixed credentials This is the recommended approach, because it requires you to grant access to the share for a single identity. Also, it does not have the requirement of ensuring that the authentication scheme can delegate its identities to the remote UNC share, because the fixed identity is always used to access the content. However, the fixed credential model does not enable the use of NTFS authorization and auditing for authenticated users accessing the share, because the access is always made under the specified credentials and not the authenticated user identity. For more information on setting up fixed credentials for virtual directories, see the section titled "Managing Remote Content" in Chapter 9.

Note It is highly recommended that you use the fixed credential model to configure access to remote UNC shares. Use this in all cases when you do not rely on NTFS ACL-based access control or auditing of remote content for your authenticated users.

If you do choose to use pass-through authentication, you will need to take the following steps:

1. Use a custom application pool identity that has access to the UNC share.
2. If using anonymous authentication, configure the anonymous user to be the application pool identity. Alternatively, configure a custom anonymous user that has access to the UNC share.
3. If you are using other authentication methods that produce Windows identities, ensure that these methods can delegate identities to the UNC share. Then, ensure that all authenticated users have access to the UNC share.

For more information about ensuring that your authentication scheme supports delegating authenticated user identities to remote resources, see the following section titled "Understanding Authentication Delegation."

Understanding Authentication Delegation

Many IIS authentication methods produce Windows identities that can be impersonated for the purpose of accessing resources. When the resources being accessed reside on a remote machine, the authenticated user identity needs to be transmitted to the remote machine for authentication with the remote service. This process is referred to as delegation. It occurs when IIS attempts to access files located on remote UNC shares, or when the application impersonates the authenticated user identity to connect to a remote server such as SQL Server.

Most IIS authentication methods do not produce authenticated identities that are suitable for delegation. This means that when IIS is configured to use these authentication methods, IIS and the application may fail to access resources located on remote machines when impersonating the authenticated identity.

Note In general, the rule for remembering which authentication methods can be delegated is to remember which authentication methods perform their logon locally on the Web server. For example, any authentication scheme in which the user name and password are available on the Web server—such as Basic Authentication, IIS Client Certificate Mapping Authentication, or Anonymous Authentication—use the Web server to log on and therefore can delegate authenticated identities.

To ensure that your application has access to its backed resources located on remote servers, you generally have three options:

• Use an authentication method that supports delegation (see Table 14-16).
• Use fixed virtual directory credentials to create an authentication identity that can be delegated to and can be impersonated instead of the authenticated user. For more information, see the section titled "UNC Authentication" earlier in this chapter.
• Configure Constrained Delegation and Protocol Transition to upgrade the authenticated identity to an authenticated identity you can delegate to using the Kerberos protocol.

Table 14-16 lists the built-in IIS authentication schemes and the required configuration to enable delegation of authenticated identities.

Table 14-16 Built-In IIS Schemes and Required Configuration to Enable Delegation of Authenticated Identities

Most of the authentication schemes that do not perform the logon locally on the machine require Constrained Delegation and Protocol Transition to be able to delegate the authenticated identity to a remote machine. Constrained Delegation refers to the ability of a service to use a user identity obtained using the Kerberos protocol to access remote resources. Protocol Transition, used in conjunction with Constrained Delegation, enables other authentication schemes to obtain a Kerberos identity to be used with Constrained Delegation to access remote resources. To learn more about setting up Constrained Delegation and Protocol Transition, see https://technet2.microsoft.com/WindowsServer/en/library/c312ba01-318f-46ca-990e-a597f3c294eb1033.mspx.

< Back      Next >

 

 

© Microsoft. All Rights Reserved.