IIS 7.0 : Implementing Access Control - Authentication (part 4)

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.

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.

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 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.
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.

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.

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.
  

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.

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 6).

  Table 6. Built-In IIS Schemes and Required Configuration to Enable Delegation of Authenticated Identities

  Authentication	Configuration
  Anonymous	Delegates when using a custom anonymous user or when using a custom application pool identity as the anonymous user (1 hop)
  Basic	Delegates by default (1 hop)
  Windows (Kerberos)	Requires Constrained Delegation
  Windows (NTLM)	Requires Constrained Delegation and Protocol Transition
  Digest	Requires Constrained Delegation and Protocol Transition
  Client certificate mapping	Requires Constrained Delegation and Protocol Transition
  IIS Client certificate mapping	Delegates by default (1 hop)

  
  

• Use fixed virtual directory credentials to create an authentication identity that can be delegated to and can be impersonated instead of the authenticated user.
  

• 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.

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.