Client Certificate Mapping Authentication
Certificate Mapping Authentication enables clients to authenticate with
the Web server by presenting client certificates over Secure Socket
Layer (SSL) connections.
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.
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.
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
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.
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.
Client Certificate Mapping Authentication on the Web server, you need to
perform the following steps (after installing the Certificate Mapping
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.
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.
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.
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:
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
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
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:
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.
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.
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
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.
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:
Use a custom application pool identity that has access to the UNC share.
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.
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
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.
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
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
|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)|
fixed virtual directory credentials to create an authentication
identity that can be delegated to and can be impersonated instead of the
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