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.
Kerberos is a Windows Security Protocol designed to authenticate users and services on an organizations network and relies on three components; a client, a service and a trusted third party. The trusted third party in most Windows networks would likely be the Key Distribution Center (KDC) which creates the shared secret that is leveraged to allow access to the service. The KDC is located on the domain controller.
The Kerberos security protocol has been a part of Windows since Windows Server 2000 and was intended as a replacement for NTLM. Kerberos is more secure than the older NTLM protocol. Also it is faster because it is using an authentication ticket and not having to go back to AD with each request. In order to use Kerberos applications need to have SPNs registered.
5) Claims-Based Authentication
A Claim may be related to a name, permissions to access information or perform a task, your identity, or group you are a member of. These claims, when packaged together by a claims provider make up a security token that provides digitally signed proof of the integrity and validity of the claims and the claim provider.
ADFS uses claims-based authorization and can offer benefits such as Web single sign on (SSO), Partner federation, Claims mapping.
The following steps are performed in the claims authentication process:
- The end user hits the SharePoint site generating an HTTP (GET) request.
- SharePoint redirects the user to the Identity Provider to get a security token.
- The end user is prompted for credentials by the Identity Provider.
- The Identity Provider validates the provided credentials with the authentication provider (in this case AD DS) and if successful provides the client a security token.
- The Identity Provider sends the end user a SAML security token.
- The end user submits a new request to SharePoint with the SAML token.
- The SharePoint STS generates the SharePoint security token, the FedAuth cookie and the requested SharePoint site.
6) Forms Authentication
A default Login Page will be available like Outlook Web App login, where user will be authenticated instead of automatically getting the credentials from the System logged in credentials .i.e. the current user of the windows system.Once the user is authenticated, he/she will be allowed to access the requested page. Here IIS does not come into effect for authentication, it all depends on the web application.