Application Pool Identity – An application pool identity allows you to run an application pool under a unique account without having to create and manage domain or local accounts. The name of the application pool account corresponds to the name of the application pool (eg. IIS APPPOOL\DefaultAppPool). This will be the account that IIS will use to access the application folder.
By default the Application Pool Identity is a member of IIS_IUSRS group and Users Group.
When configuring the permissions for an application folder it is recommended to disable inheritance of permissions so that accounts and groups (eg. Users, TrustedInstaller) are not automatically given permissions on that folder.
When you enable Anonymous authentication, IIS does not use any other authentication schemes unless NTFS permissions deny access to a resource.
By default IIS will use the Application Pool Identity to access the application folder, but you can also use a custom windows account that must be given NTFS permissions to the application folder.
Requires the creation of individual Windows accounts for each user. It is insecure unless using SSL/TLS, which impacts performance.
When a client attempts to access a resource requiring Digest authentication, IIS send a challenge to the client to create a digest and send it to the server. The client concatenates the password with data known to both the server and the client. The client then applies a digest algorithm (specified by the server) to the combined data. The client sends the resulting digest to the server as the response to the challenge. The server uses the same process as the client to create a digest using a copy of the client’s password it obtains from Active Directory, where the password is stored using reversible encryption.
One of the downsides of Digest Auth is that it requires storing of passwords in cleartext using reversible encryption for all domain accounts in Active Directory that will use this type of authentication.
Digest authentication is only a slight improvement over Basic authentication. In the absence of SSL/TLS, an attacker could record communication between the client and server. Using this information, the attacker can then use that information to replay the transaction.
4) Windows authentication
Integrated Windows authentication can use either NTLM or Kerberos authentication.
If Internet Explorer recognizes the Negotiate header, it will choose it because it is listed first. When using Negotiate, the browser will return information for both NTLM and Kerberos. At the server, IIS will use Kerberos if both the client (browser) and server (IIS) are members of the same domain or trusted domains. Otherwise, the server will default to using NTLM.
If Internet Explorer does not understand Negotiate, it will use NTLM.
NTLM is a Windows integrated authentication protocol that leverages the interactive use of a login box that requires the end user to input their network credentials manually. Those credentials would include the users Username, password and domain name if logging into an organizations domain. Because it is windows integrated NTLM also supports SSO. When using NTLM it is not required to have direct access to the domain controller.
Read More »