Client Certificate Mapping Authentication
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.
- 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.
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: 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.
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:
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 stage.
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.
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.
Use a custom application pool identity that has access to the UNC share.
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.
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.
Use an authentication method that supports delegation (see Table 6).
Table 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.
- IIS 7.0 : Implementing Access Control – Authentication (part 1)
- IIS 7.0 : Implementing Access Control – Authentication (part 2) – Digest Authentication & Windows Authentication
- IIS 7.0 : Implementing Access Control – Authentication (part 3) – IIS Client Certificate Mapping Authentication