Windows Authentication Overview

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

This navigation topic for the IT professional lists documentation resources for Windows authentication and logon technologies that include product evaluation, getting started guides, procedures, design and deployment guides, technical references, and command references.

Feature description

Authentication is a process for verifying the identity of an object, service or person. When you authenticate an object, the goal is to verify that the object is genuine. When you authenticate a service or person, the goal is to verify that the credentials presented are authentic.

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 Domain Services is the recommended and default technology for storing identity information (including 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, which identifies users based on something that only the user knows — like a password, to more powerful security mechanisms that use something that the user has — like tokens, public key certificates, and biometrics. In a business environment, services or users might access multiple applications or resources 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.

The Windows operating system implements a default set of authentication protocols, including Kerberos, NTLM, Transport Layer Security/Secure Sockets Layer (TLS/SSL), and Digest, as part of an extensible architecture. In addition, some protocols are combined into authentication packages such as Negotiate and the Credential Security Support Provider. These protocols and packages enable authentication of users, computers, and services; the authentication process, in turn, enables authorized users and services to access resources in a secure manner.

For more information about Windows Authentication including

Practical applications

Windows Authentication is used to verify that the information comes from a trusted source, whether from a person or computer object, such as another computer. Windows provides many different methods to achieve this goal as described below.

To.	Feature	Description
Authenticate within an Active Directory domain	Kerberos	The Microsoft WindowsВ Server operating systems implement the Kerberos version 5 authentication protocol and extensions for public key authentication. The Kerberos authentication client is implemented as a security support provider (SSP) and can be accessed through the Security Support Provider Interface (SSPI). Initial user authentication is integrated with the Winlogon single sign-on architecture. The Kerberos Key Distribution Center (KDC) is integrated with other Windows Server security services running on the domain controller. The KDC uses the domain’s Active Directory directory service database as its security account database. Active Directory is required for default Kerberos implementations. For additional resources, see Kerberos Authentication Overview.
Secure authentication on the web	TLS/SSL as implemented in the Schannel Security Support Provider	The Transport Layer Security (TLS) protocol versions 1.0, 1.1, and 1.2, Secure Sockets Layer (SSL) protocol, versions 2.0 and 3.0, Datagram Transport Layer Security protocol version 1.0, and the Private Communications Transport (PCT) protocol, version 1.0, are based on public key cryptography. The Secure Channel (Schannel) provider authentication protocol suite provides these protocols. All Schannel protocols use a client and server model. For additional resources, see TLS — SSL (Schannel SSP) Overview.
Authenticate to a web service or application	Integrated Windows Authentication Digest Authentication	For additional resources, see Integrated Windows Authentication and Digest Authentication, and Advanced Digest Authentication.
Authenticate to legacy applications	NTLM	NTLM is a challenge-response style authentication protocol.In addition to authentication, the NTLM protocol optionally provides for session security—specifically message integrity and confidentiality through signing and sealing functions in NTLM. For additional resources, see NTLM Overview.
Leverage multifactor authentication	Smart card support Biometric support	Smart cards are a tamper-resistant and portable way to provide security solutions for tasks such as client authentication, logging on to domains, code signing, and securing e-mail. Biometrics relies on measuring an unchanging physical characteristic of a person to uniquely identify that person. Fingerprints are one of the most frequently used biometric characteristics, with millions of fingerprint biometric devices that are embedded in personal computers and peripherals. For additional resources, see Smart Card Technical Reference.
Provide local management, storage and reuse of credentials	Credentials management Local Security Authority Passwords	Credential management in Windows ensures that credentials are stored securely. Credentials are collected on the Secure Desktop (for local or domain access), through apps or through websites so that the correct credentials are presented every time a resource is accessed.
Extend modern authentication protection to legacy systems	Extended Protection for Authentication	This feature enhances the protection and handling of credentials when authenticating network connections by using Integrated Windows Authentication (IWA).

Software requirements

Windows Authentication is designed to be compatible with previous versions of the Windows operating system. However, improvements with each release are not necessarily applicable to previous versions. Refer to documentation about specific features for more information.

Server Manager information

Many authentication features can be configured using Group Policy, which can be installed using Server Manager. The Windows Biometric Framework feature is installed using Server Manager. Other server roles which are dependent upon authentication methods, such as Web Server (IIS) and Active Directory Domain Services, can also be installed using Server Manager.

Overview of ASP.NET Core authentication

Authentication is the process of determining a user’s identity. Authorization is the process of determining whether a user has access to a resource. In ASP.NET Core, authentication is handled by the IAuthenticationService , which is used by authentication middleware. The authentication service uses registered authentication handlers to complete authentication-related actions. Examples of authentication-related actions include:

• Authenticating a user.
• Responding when an unauthenticated user tries to access a restricted resource.

The registered authentication handlers and their configuration options are called «schemes».

Authentication schemes are specified by registering authentication services in Startup.ConfigureServices :

• By calling a scheme-specific extension method after a call to services.AddAuthentication (such as AddJwtBearer or AddCookie , for example). These extension methods use AuthenticationBuilder.AddScheme to register schemes with appropriate settings.
• Less commonly, by calling AuthenticationBuilder.AddScheme directly.

For example, the following code registers authentication services and handlers for cookie and JWT bearer authentication schemes:

The AddAuthentication parameter JwtBearerDefaults.AuthenticationScheme is the name of the scheme to use by default when a specific scheme isn’t requested.

If multiple schemes are used, authorization policies (or authorization attributes) can specify the authentication scheme (or schemes) they depend on to authenticate the user. In the example above, the cookie authentication scheme could be used by specifying its name ( CookieAuthenticationDefaults.AuthenticationScheme by default, though a different name could be provided when calling AddCookie ).

In some cases, the call to AddAuthentication is automatically made by other extension methods. For example, when using ASP.NET Core Identity, AddAuthentication is called internally.

The Authentication middleware is added in Startup.Configure by calling the UseAuthentication extension method on the app’s IApplicationBuilder . Calling UseAuthentication registers the middleware which uses the previously registered authentication schemes. Call UseAuthentication before any middleware that depends on users being authenticated. When using endpoint routing, the call to UseAuthentication must go:

• After UseRouting , so that route information is available for authentication decisions.
• Before UseEndpoints , so that users are authenticated before accessing the endpoints.

Authentication Concepts

Authentication is responsible for providing the ClaimsPrincipal for authorization to make permission decisions against. There are multiple authentication scheme approaches to select which authentication handler is responsible for generating the correct set of claims:

• Authentication scheme, also discussed in the next section.
• The default authentication scheme, discussed in the next section.
• Directly set HttpContext.User.

There is no automatic probing of schemes. If the default scheme is not specified, the scheme must be specified in the authorize attribute, otherwise, the following error is thrown:

InvalidOperationException: No authenticationScheme was specified, and there was no DefaultAuthenticateScheme found. The default schemes can be set using either AddAuthentication(string defaultScheme) or AddAuthentication(Action configureOptions).

Authentication scheme

The authentication scheme can select which authentication handler is responsible for generating the correct set of claims. For more information, see Authorize with a specific scheme.

An authentication scheme is a name which corresponds to:

• An authentication handler.
• Options for configuring that specific instance of the handler.

Schemes are useful as a mechanism for referring to the authentication, challenge, and forbid behaviors of the associated handler. For example, an authorization policy can use scheme names to specify which authentication scheme (or schemes) should be used to authenticate the user. When configuring authentication, it’s common to specify the default authentication scheme. The default scheme is used unless a resource requests a specific scheme. It’s also possible to:

• Specify different default schemes to use for authenticate, challenge, and forbid actions.
• Combine multiple schemes into one using policy schemes.

Authentication handler

An authentication handler:

• Is a type that implements the behavior of a scheme.
• Is derived from IAuthenticationHandler or AuthenticationHandler .
• Has the primary responsibility to authenticate users.

Based on the authentication scheme’s configuration and the incoming request context, authentication handlers:

• Construct AuthenticationTicket objects representing the user’s identity if authentication is successful.
• Return ‘no result’ or ‘failure’ if authentication is unsuccessful.
• Have methods for challenge and forbid actions for when users attempt to access resources:
  • They are unauthorized to access (forbid).
  • When they are unauthenticated (challenge).

Authenticate

An authentication scheme’s authenticate action is responsible for constructing the user’s identity based on request context. It returns an AuthenticateResult indicating whether authentication was successful and, if so, the user’s identity in an authentication ticket. See AuthenticateAsync. Authenticate examples include:

• A cookie authentication scheme constructing the user’s identity from cookies.
• A JWT bearer scheme deserializing and validating a JWT bearer token to construct the user’s identity.

Challenge

An authentication challenge is invoked by Authorization when an unauthenticated user requests an endpoint that requires authentication. An authentication challenge is issued, for example, when an anonymous user requests a restricted resource or clicks on a login link. Authorization invokes a challenge using the specified authentication scheme(s), or the default if none is specified. See ChallengeAsync. Authentication challenge examples include:

• A cookie authentication scheme redirecting the user to a login page.
• A JWT bearer scheme returning a 401 result with a www-authenticate: bearer header.

A challenge action should let the user know what authentication mechanism to use to access the requested resource.

Forbid

An authentication scheme’s forbid action is called by Authorization when an authenticated user attempts to access a resource they are not permitted to access. See ForbidAsync. Authentication forbid examples include:

• A cookie authentication scheme redirecting the user to a page indicating access was forbidden.
• A JWT bearer scheme returning a 403 result.
• A custom authentication scheme redirecting to a page where the user can request access to the resource.

A forbid action can let the user know:

• They are authenticated.
• They aren’t permitted to access the requested resource.

See the following links for differences between challenge and forbid:

Authentication providers per tenant

ASP.NET Core framework does not have a built-in solution for multi-tenant authentication. While it’s certainly possible for customers to write one, using the built-in features, we recommend customers to look into Orchard Core for this purpose.

Orchard Core is:

• An open-source modular and multi-tenant app framework built with ASP.NET Core.
• A content management system (CMS) built on top of that app framework.

See the Orchard Core source for an example of authentication providers per tenant.