Windows Authentication

Overview

The element defines configuration settings for the Internet Information Services (IIS) 7 Windows authentication module. You can use Windows authentication when your IIS 7 server runs on a corporate network that is using Microsoft Active Directory service domain identities or other Windows accounts to identify users. Because of this, you can use Windows authentication whether or not your server is a member of an Active Directory domain.

Windows authentication (formerly named NTLM, and also referred to as Windows NT Challenge/Response authentication) is a secure form of authentication because the user name and password are hashed before being sent across the network. When you enable Windows authentication, the client browser sends a strongly hashed version of the password in a cryptographic exchange with your Web server.

Windows authentication supports two authentication protocols, Kerberos and NTLM, which are defined in the

element. When you install and enable Windows authentication on IIS 7, the default protocol is Kerberos. The element can also contain a useKernelMode attribute that configures whether to use the kernel mode authentication feature that is new to Windows Server 2008.

Windows authentication is best suited for an intranet environment for the following reasons:

• Client computers and Web servers are in the same domain.
• Administrators can make sure that every client browser is Internet Explorer 2.0 or later.
• HTTP proxy connections, which are not supported by NTLM, are not required.
• Kerberos version 5 requires a connection to Active Directory, which is not feasible in an Internet environment.

New in IIS 7.5

The element was introduced in IIS 7.5, which allows you to configure the settings for the new extended protection features that have been integrated into Windows authentication.

Compatibility

Version	Notes
IIS 10.0	The element was not modified in IIS 10.0.
IIS 8.5	The element was not modified in IIS 8.5.
IIS 8.0	The element was not modified in IIS 8.0.
IIS 7.5	The element was added in IIS 7.5.
IIS 7.0	The element was introduced in IIS 7.0.
IIS 6.0	The element replaces portions of the IIS 6.0 AuthType and AuthFlags metabase properties.

Setup

The default installation of IIS 7 and later does not include the Windows authentication role service. To use Windows authentication on IIS, you must install the role service, disable Anonymous authentication for your Web site or application, and then enable Windows authentication for the site or application.

After you install the role service, IIS 7 commits the following configuration settings to the ApplicationHost.config file.

Windows Server 2012 or Windows Server 2012 R2

1. On the taskbar, click Server Manager.
2. In Server Manager, click the Manage menu, and then click Add Roles and Features.
3. In the Add Roles and Features wizard, click Next. Select the installation type and click Next. Select the destination server and click Next.
4. On the Server Roles page, expand Web Server (IIS), expand Web Server, expand Security, and then select Windows Authentication. Click Next.
   .
5. On the Select features page, click Next.
6. On the Confirm installation selections page, click Install.
7. On the Results page, click Close.

Windows 8 or Windows 8.1

1. On the Start screen, move the pointer all the way to the lower left corner, right-click the Start button, and then click Control Panel.
2. In Control Panel, click Programs and Features, and then click Turn Windows features on or off.
3. Expand Internet Information Services, expand World Wide Web Services, expand Security, and then select Windows Authentication.
   
4. Click OK.
5. Click Close.

Windows Server 2008 or Windows Server 2008 R2

1. On the taskbar, click Start, point to Administrative Tools, and then click Server Manager.
2. In the Server Manager hierarchy pane, expand Roles, and then click Web Server (IIS).
3. In the Web Server (IIS) pane, scroll to the Role Services section, and then click Add Role Services.
4. On the Select Role Services page of the Add Role Services Wizard, select Windows Authentication, and then click Next.
   
5. On the Confirm Installation Selections page, click Install.
6. On the Results page, click Close.

Windows Vista or Windows 7

1. On the taskbar, click Start, and then click Control Panel.
2. In Control Panel, click Programs and Features, and then click Turn Windows Features on or off.
3. Expand Internet Information Services, then World Wide Web Services, then Security.
4. Select Windows Authentication, and then click OK.
   

How To

How to enable Windows authentication for a Web site, Web application, or Web service

Open Internet Information Services (IIS) Manager:

If you are using Windows Server 2012 or Windows Server 2012 R2:

• On the taskbar, click Server Manager, click Tools, and then click Internet Information Services (IIS) Manager.

If you are using Windows 8 or Windows 8.1:

• Hold down the Windows key, press the letter X, and then click Control Panel.
• Click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

If you are using Windows Server 2008 or Windows Server 2008 R2:

• On the taskbar, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

If you are using Windows Vista or Windows 7:

• On the taskbar, click Start, and then click Control Panel.
• Double-click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

In the Connections pane, expand the server name, expand Sites, and then the site, application, or Web service for which you want to enable Windows authentication.

Scroll to the Security section in the Home pane, and then double-click Authentication.

In the Authentication pane, select Windows Authentication, and then click Enable in the Actions pane.

How to enable Extended Protection for Windows authentication

Open Internet Information Services (IIS) Manager:

If you are using Windows Server 2012 or Windows Server 2012 R2:

• On the taskbar, click Server Manager, click Tools, and then click Internet Information Services (IIS) Manager.

If you are using Windows 8 or Windows 8.1:

• Hold down the Windows key, press the letter X, and then click Control Panel.
• Click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

If you are using Windows Server 2008 or Windows Server 2008 R2:

• On the taskbar, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

If you are using Windows Vista or Windows 7:

• On the taskbar, click Start, and then click Control Panel.
• Double-click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

In the Connections pane, expand the server name, expand Sites, and then the site, application, or Web service for which you want to enable Extended Protection for Windows authentication.

Scroll to the Security section in the Home pane, and then double-click Authentication.

In the Authentication pane, select Windows Authentication.

Click Enable in the Actions pane.

Click Advanced Settings in the Actions pane.

When the Advanced Settings dialog box appears, select one of the following options in the Extended Protection drop-down menu:

• Select Accept if you want to enable extended protection while providing down-level support for clients that do not support extended protection.
• Select Required if you want to enable extended protection without providing down-level support.
  

Click OK to close the Advanced Settings dialog box.

Configuration

The element is configurable at the site, application, or virtual directory level in the ApplicationHost.config file.

Attributes

Attribute	Description
authPersistNonNTLM	Optional Boolean attribute.

Specifies whether IIS automatically reauthenticates every non-NTLM (for example, Kerberos) request, even those on the same connection. False enables multiple authentications for the same connections.

Note: A setting of true means that the client will be authenticated only once on the same connection. IIS will cache a token or ticket on the server for a TCP session that stays established.

The default is false . authPersistSingleRequest Optional Boolean attribute.

Setting this flag to true specifies that authentication persists only for a single request on a connection. IIS resets the authentication at the end of each request, and forces reauthentication on the next request of the session.

The default value is false . enabled Required Boolean attribute.

Specifies whether Windows authentication is enabled.

The default value is false . useKernelMode Optional Boolean attribute.

Specifies whether Windows authentication is done in kernel mode. True specifies that Windows authentication uses kernel mode.

Kernel-mode authentication may improve authentication performance and prevent authentication problems with application pools that are configured to use a custom identity.

As a best practice, do not disable this setting if you use Kerberos authentication and have a custom identity on the application pool.

The default is true .

Child Elements

Element	Description
extendedProtection	Optional element.

Specifies extended protection options for Windows authentication.

Note: This element was added in IIS 7.5. providers Optional element.

Specifies security support providers used for Windows authentication.

Configuration Sample

The following default element is configured at the root ApplicationHost.config file in IIS 7.0, and disables Windows authentication by default. It also defines the two Windows authentication providers for IIS 7.0.

The following example enables Windows authentication and disables Anonymous authentication for a Web site named Contoso.

Sample Code

The following examples disable Anonymous authentication for a site named Contoso, then enable Windows authentication for the site.

Windows Authentication Concepts

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

This reference overview topic describes the concepts on which Windows authentication is based.

Authentication is a process for verifying the identity of an object or person. When you authenticate an object, the goal is to verify that the object is genuine. When you authenticate a person, the goal is to verify that the person is not an imposter.

In a networking context, authentication is the act of proving identity to a network application or resource. Typically, identity is proven by a cryptographic operation that uses either a key only the user knows (as with public key cryptography) or a shared key. The server side of the authentication exchange compares the signed data with a known cryptographic key to validate the authentication attempt.

Storing the cryptographic keys in a secure central location makes the authentication process scalable and maintainable. Active Directory is the recommended and default technology for storing identity information, which include the cryptographic keys that are the user’s credentials. Active Directory is required for default NTLM and Kerberos implementations.

Authentication techniques range from a simple logon to an operating system or a sign-in to a service or application, which identifies users based on something that only the user knows, such as a password, to more powerful security mechanisms that use something that the user has’such as tokens, public key certificates, pictures, or biological attributes. In a business environment, users might access multiple applications on many types of servers within a single location or across multiple locations. For these reasons, authentication must support environments for other platforms and for other Windows operating systems.

Authentication and authorization: A travel analogy

A travel analogy can help explain how authentication works. A few preparatory tasks are usually necessary to begin the journey. The traveler must prove their true identity to their host authorities. This proof can be in the form of proof of citizenship, birth place, a personal voucher, photographs, or whatever is required by the law of the host country. The traveler’s identity is validated by the issuance of a passport, which is analogous to a system account issued and administered by an organization—the security principal. The passport and the intended destination are based on a set of rules and regulations issued by the governmental authority.

The journey

When the traveler arrives at the international border, a border guard asks for credentials, and the traveler presents his or her passport. The process is two-fold:

The guard authenticates the passport by verifying that it was issued by a security authority that the local government trusts (trusts, at least, to issue passports) and by verifying that the passport has not been modified.

The guard authenticates the traveler by verifying that the face matches the face of the person pictured on the passport and that other required credentials are in good order.

If the passport proves to be valid and the traveler proves to be its owner, authentication is successful, and the traveler can be allowed access across the border.

Transitive trust between security authorities is the foundation of authentication; the type of authentication that takes place at an international border is based on trust. The local government does not know the traveler, but it trusts that the host government does. When the host government issued the passport, it did not know the traveler either. It trusted the agency that issued the birth certificate or other documentation. The agency that issued the birth certificate, in turn, trusted the physician who signed the certificate. The physician witnessed the traveler’s birth and stamped the certificate with direct proof of the identity, in this case with the newborn’s footprint. Trust that is transferred in this way, through trusted intermediaries, is transitive.

Transitive trust is the foundation for network security in Windows client/server architecture. A trust relationship flows throughout a set of domains, such as a domain tree, and forms a relationship between a domain and all domains that trust that domain. For example, if domain A has a transitive trust with domain B, and if domain B trusts domain C, then domain A trusts domain C.

There is a difference between authentication and authorization. With authentication, the system proves that you are who you say you are. With authorization, the system verifies that you have rights to do what you want to do. To take the border analogy to the next step, merely authenticating that the traveler is the proper owner of a valid passport does not necessarily authorize the traveler to enter a country. Residents of a particular country are allowed to enter another country by simply presenting a passport only in situations where the country being entered grants unlimited permission for all citizens of that particular country to enter.

Similarly, you can grant all users from a certain domain permissions to access a resource. Any user who belongs to that domain has access to the resource, just as Canada lets U.S. citizens enter Canada. However, U.S. citizens attempting to enter Brazil or India find that they cannot enter those countries merely by presenting a passport because both of those countries require visiting U.S. citizens to have a valid visa. Thus, authentication does not guarantee access to resources or authorization to use resources.

Credentials

A passport and possibly associated visas are the accepted credentials for a traveler. However, those credentials might not let a traveler enter or access all resources within a country. For instance, additional credentials are required to attend a conference. In Windows, credentials can be managed to make it possible for account holders to access resources over the network without repeatedly having to supply their credentials. This type of access lets users be authenticated one time by the system to access all applications and data sources that they are authorized to use without entering another account identifier or password. The Windows platform capitalizes on the ability to use a single user identity (maintained by Active Directory) across the network by locally caching user credentials in the operating system’s Local Security Authority (LSA). When a user logs on to the domain, Windows authentication packages transparently use the credentials to provide single sign-on when authenticating the credentials to network resources. For more information about credentials, see Credentials Processes in Windows Authentication.

A form of multi-factor authentication for the traveler might be the requirement to carry and present multiple documents to authenticate his identity such as a passport and conference registration information. Windows implements this form or authentication through smart cards, virtual smart cards, and biometric technologies.

Security principals and accounts

In Windows, any user, service, group, or computer that can initiate action is a security principal. Security principals have accounts, which can be local to a computer or be domain-based. For example, Windows client domain-joined computers can participate in a network domain by communicating with a domain controller even when no human user is logged on. To initiate communications, the computer must have an active account in the domain. Before accepting communications from the computer, the local security authority on the domain controller authenticates the computer’s identity, and then defines the computer’s security context just as it would for a human security principal. This security context defines the identity and capabilities of a user or service on a particular computer or a user, service, group, or computer on a network. For example, it defines the resources, such as a file share or printer, that can be accessed and the actions, such as Read, Write, or Modify, that can be performed by a user, service, or computer on that resource. For more information, see Security Principals.

An account is a means to identify a claimant—the human user or service—requesting access or resources. The traveler who holds the authentic passport possesses an account with the host country. Users, groups of users, objects, and services can all have individual accounts or share accounts. Accounts can be member of groups and can be assigned specific rights and permissions. Accounts can be restricted to the local computer, workgroup, network, or be assigned membership to a domain.

Built-in accounts and the security groups, of which they are members, are defined on each version of Windows. By using security groups, you can assign the same security permissions to many users who are successfully authenticated, which simplifies access administration. Rules for issuing passports might require that the traveler be assigned to certain groups, such as business, or tourist, or government. This process ensures consistent security permissions across all members of a group. By using security groups to assign permissions means that access control of resources remains constant and easy to manage and audit. By adding and removing users who require access from the appropriate security groups as needed, you can minimize the frequency of changes to access control lists (ACLs).

Standalone managed service accounts and virtual accounts were introduced in Windows Server 2008 R2 and Windows 7 to provide necessary applications, such as Microsoft Exchange Server and Internet Information Services (IIS), with the isolation of their own domain accounts, while eliminating the need for an administrator to manually administer the service principal name (SPN) and credentials for these accounts. Group managed service accounts were introduced in Windows Server 2012 and provides the same functionality within the domain but also extends that functionality over multiple servers. When connecting to a service hosted on a server farm, such as Network Load Balance, the authentication protocols supporting mutual authentication require that all instances of the services use the same principal.

For more information about accounts, see:

Delegated authentication

To use the travel analogy, countries might issue the same access to all members of an official governmental delegation, just as long as the delegates are well-known. This delegation lets one member act on the authority of another member. In Windows, delegated authentication occurs when a network service accepts an authentication request from a user and assumes the identity of that user in order to initiate a new connection to a second network service. To support delegated authentication, you must establish front-end or first-tier servers, such as web servers, that are responsible for handling client authentication requests and back-end or n-tier servers, such as large databases, that are responsible for storing information. You can delegate the right to set up delegated authentication to users in your organization to reduce the administrative load on your administrators.

By establishing a service or computer as trusted for delegation, you let that service or computer complete delegated authentication, receive a ticket for the user who is making the request, and then access information for that user. This model restricts data access on back-end servers just to those users or services that present credentials with the correct access control tokens. In addition, it allows for access auditing of those back-end resources. By requiring that all data be accessed by means of credentials that are delegated to the server for use on behalf of the client, you ensure that the server cannot be compromised and that you can gain access to sensitive information that is stored on other servers. Delegated authentication is useful for multitier applications that are designed to use single sign-on capabilities across multiple computers.

Authentication in trust relationships between domains

Most organizations that have more than one domain have a legitimate need for users to access shared resources that are located in a different domain, just as the traveler is permitted travel to different regions in the country. Controlling this access requires that users in one domain can also be authenticated and authorized to use resources in another domain. To provide authentication and authorization capabilities between clients and servers in different domains, there must be a trust between the two domains. Trusts are the underlying technology by which secured Active Directory communications occur and are an integral security component of the Windows Server network architecture.

When a trust exists between two domains, the authentication mechanisms for each domain trust the authentications coming from the other domain. Trusts help provide for controlled access to shared resources in a resource domain—the trusting domain—by verifying that incoming authentication requests come from a trusted authority—the trusted domain. In this way, trusts act as bridges that let only validated authentication requests travel between domains.

How a specific trust passes authentication requests depends on how it is configured. Trust relationships can be one-way, by providing access from the trusted domain to resources in the trusting domain, or two-way, by providing access from each domain to resources in the other domain. Trusts are also either nontransitive, in which case trust exists only between the two trust partner domains, or transitive, in which case trust automatically extends to any other domains that either of the partners trusts.

For information about how a trust works, see How Domain and Forest Trusts Work.

Protocol transition

Protocol transition assists application designers by letting applications support different authentication mechanisms at the user authentication tier and by switching to the Kerberos protocol for security features, such as mutual authentication and constrained delegation, in the subsequent application tiers.

Constrained delegation

Constrained delegation gives administrators the ability to specify and enforce application trust boundaries by limiting the scope where application services can act on behalf of a user. You can specify particular services from which a computer that is trusted for delegation can request resources. The flexibility to constrain authorization rights for services helps improve application security design by reducing the opportunities for compromise by untrusted services.

For more information about constrained delegation, see Kerberos Constrained Delegation Overview.