Basics: Authentication procedures for the Internet Information Services (IIS)

The Active Directory Certificate Services offer a number of web-based add-on interfaces (Network Device Registration Service (NDES), Certificate Enrollment Policy Web Service (CEP), Certificate Enrollment Web Service (CES), Certification Authority Web Enrollment (CAWE).

The Microsoft Internet Information Services (IIS) are thus almost indispensable for a Microsoft PKI. Each of the web-based interfaces (and also in-house developments) bring their own unique challenges in terms of authentication procedures and their implementation.

The following article should bring a little clarity to the topic.

Authentication vs. impersonation vs. delegation vs. protocol transition

As Authentication (Authentication (with respect to IIS) is when the user can identify himself as such to the web server, i.e. prove that he really is who he claims to be.

As Impersonation (Impersonation is when the user has logged in using any authentication method and the server process (e.g., the web application) subsequently performs an action in the user's security context on the same system (e.g., accessing a local directory where appropriate permissions are configured).

As Delegation (Delegation is when the user has authenticated with a Kerberos ticket (allowed as delegable) and the server process (e.g., the web application) forwards this ticket to a downstream resource (e.g., a database, or a certificate authority) on behalf of the user. In Kerberos terms, this process is also called S4U2Proxy.

As Protocol transition (English: Protocol Transition) is used when the user has authenticated himself with a method apart from Kerberos, and the server process requests a Kerberos ticket on behalf of the user in order to forward it to a downstream resource (e.g. a database). In Kerberos terms, this process is also known as S4U. This is an extremely powerful right, because it is associated with giving the server service the right to request such a TIcket for any user, that is, the server process can accept any identity.

Often one is affected by the so-called double-hop problem, i.e. one wants the server process to access a downstream resource in the security context of the logged-in user.

What are we actually up to?

When choosing the correct authentication method, we need to consider what we want to achieve:

Is authentication enough for us? (we have no no double hop scenario)
What kind of client should be able to authenticate? (Only from dmmain computers, only Windows, what authentication methods are supported by the applications? Do we want or need username/password, Kerberos ticket, or client certificate?)
Do we even want to achieve a pure Kerberos login, i.e. disable NTLM?

IIS Application Pool Identity

Please note that the Application Pool Identity can impersonate but not delegate. This would require "Network Service" (probably not recommended, but why?) or a domain account/gMSA.

Authentication procedure

In all cases, the connection should be protected with SSL, i.e. the "Require SSL" option should be enabled.

HTTP Basic Authentication

With Basic Authentication, the logging-in user submits in clear text via an HTTP header. The server thus has the plain-text password of the logged-in user, so it can request a Kerberos ticket on the user's behalf. This method does not require delegation for access in the user's security context to additional hosts.

After all, the server process can only do this for those accounts that log in to it.

For Basic Authentication to work, the following must be entered into the application's Web.config.

{system.web}
  {authentication mode="Windows"/}
{/system.web}

ASP.NET Impersonation

When ASP.NET Impersonation is enabled, all server-side code is executed in the security context of the logged-in user.

Enabling ASP.NET Impersonation puts the following in the application's Web.config.

{identity impersonate="true" /}

It also requires the "Classic" managed pipeline mode for the IIS application pool. Usually this option is not necessary, because application-related impersonation is possible. See Windows Authentication for more information.

Windows (integrated, or Kerberos) authentication

With Windows Authentication, the user authenticates via Kerberos, or if this fails, with the NTLM method (which transmits a checksum of the user password).

If the hop to another server is necessary, at least a "Kerberos only" delegation must be made for the service account of the web server.

This method works with Kerberos only if all components (client computer, user account, server service and any downstream resources) are members of the same Active Directory domain or forest, or if there is an intermediary relationship between the domains involved.

The most important thing to set up in IIS:

Anonymous Authentication must be disabled at the application level.
Windows Authentication" must be enabled at the application level.
When configuring the "Negotiate:Kerberos" (i.e. Kerberos only without NTLM) provider, Kernel Mode Authentication must be disabled.

Anonymous Authentication must be disabled at the application level.

The web page must be included in the "local intranet" zone in the browser of the user logging in for the automatic login to take place.

Client certificate mapping (IIS)

There are two forms of authentication with client certificates in IIS. "IIS Client Certificate Mapping" maps against accounts defined in IIS. It is therefore effectively only suitable for authentication, but not for impersonation, delegation or protocol transition. It is therefore not discussed further here.

Mapping of client certificates (Active Directory)

The IIS Client Certificate Mapping feature maps certificates against accounts in Active Directory. For this to work, the web server process, after receiving authentication, must request a Kerberos ticket on behalf of the logging user (hence protocol transition is required). Finally, there is no transmission of a password, hash value, or forwardable Kerberos ticket with this method. This supposed advantage is also a very big disadvantage, since the web server account is granted far-reaching rights with this.

The most important thing to set up in IIS:

The service account requires Kerberos delegation with "Use any Authentication protocol" (protocol transition).
The certification authority that issues the certificates of the logged-in users must be a member of NTAuthCertificates be. This can also pose a very significant safety risk.
On which SSL binding the "DS Mapper" must be enabled on the SSL binding (otherwise the login will abort with HTTP error code 403.2.5).
The Sending the Trust List should be enabled on the SSL binding.
The authentication procedure for "Active Directory Client Certificate Authentication" must be enabled at server level. Only there the option is available in the IIS Manager.
At the web page level, client certificate mapping (the clientCertificateMappingAuthentication option) must also be enabled.
At the website level, client certificates must be set to "Accept" if there are subfolders that selectively use this authentication method (otherwise "require").
At the application or subfolder level, client certificates must be set to "Required" if they exist.
At the web page level (if there are no subfolders) or application level, all authentication protocols must be disabled.

The Active Directory Client Certificate Authentication option is available only at the server level.

At the application level, all authentication methods must be disabled.

An example of enabling authentication with client certificates at the web page level.

%WINDIR%\System32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/authentication/clientCertificateMappingAuthentication /enabled: "True" /commit:apphost
%WINDIR%\System32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/access /sslFlags: "Ssl, SslNegotiateCert" /commit:apphost

An example of configuring SSL binding with DS-Mapper and using the ClientAuthIssuer certificate store to identify the certificate authorities allowed for login.

netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certstorename=MY certhash=71cc1fed1c7ef6cec45de66c288447a4ad464c20 appid={4dc3e181-e14b-4a21-b022-59fc669b0914} sslctlstorename=ClientAuthIssuer dsmapperusage=enable

The whole mechanism is generally rather not recommended, since two potentially highly dangerous settings (membership in NTAuthCertificates as well as Kerberos delegation with protocol transition) have to be used.