Logon and Authentication Technologies
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Logon and Authentication Technologies
The Microsoft Windows Server 2003 operating system implements a default set of authentication protocols, including Negotiate, Kerberos, NTLM, Schannel (secure channel), and Digest, as part of an extensible architecture. These protocols enable authentication of users, computers, and services; the authentication process, in turn, enables authorized users and services to access resources in a secure manner.
Authentication Concepts
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 you are not dealing with an imposter.
Similarly, 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 directory service 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, 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, for Windows Server 2003, and for other Windows operating systems.
Authentication and Authorization: A Travel Analogy
A travel analogy can help explain how authentication works. For example, when you cross an international border, a border guard asks for credentials and you present a 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 you by verifying that your face matches the face of the person pictured on the passport.
If the passport proves to be valid and you prove to be its owner, you are who you say you are.
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 you, but it trusts that your government does. When your government issued your passport, it did not know you either. It trusted the agency that issued your birth certificate. The agency that issued your birth certificate, in turn, trusted the physician who signed the certificate. The physician witnessed your birth and stamped the certificate with your footprint, direct proof of your identity. Trust that is transferred in this way, through trusted intermediaries, is transitive.
Similarly, transitive trust is the foundation for network security in Windows Server 2003. 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; however 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 you are the proper owner of a valid passport does not necessarily authorize you 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 blanket 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 allows U.S. citizens to enter Canada. However, U.S. citizens attempting to enter Brazil or India would 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 (or authorization).
Single Sign-On
Single sign-on (SSO) makes it possible for users to access resources over the network without having to repeatedly supply their credentials. Forcing users to enter multiple passwords — or to enter a single password multiple times — to access system resources is inefficient and provides an unpleasant user experience.
Users of the Windows Server 2003 operating systems must supply their credentials only once to access network resources; subsequent authentication is transparent to users. SSO allows users to authenticate once with the system in order to access all applications and data sources that they are authorized to use without entering another account ID or password. The Microsoft 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 SSO when authenticating to network resources.
Authentication Architecture
Windows Server 2003 Authentication Services
Windows Server 2003 provides a method for applications to authenticate users by using the Security Support Provider Interface (SSPI) to abstract calls to authentication. Thus, developers do not need to understand the complexities of specific authentication protocols or build authentication protocols into their applications.
For best results, however, before starting the application design process, developers should understand the different types of authentication, the effects of using different protocols, and the interfaces they support. Then they can specify their preferred authentication protocol and use the authentication protocols provided by the Windows platform.
If the preferred protocol is not in Windows Server 2003, developers can use a custom Security Support Provider (SSP). Implementing authentication protocols on an application-by-application basis is inefficient and can introduce security flaws across the organization.
Security Subsystem Architecture
Windows Server 2003 operating systems include a set of security components that make up the Windows security model. These components ensure that applications cannot gain access to resources without authentication and authorization.
The Local Security Authority (LSA) is a protected subsystem that authenticates and logs users on to the local computer. In addition, LSA maintains information about all aspects of local security on a computer (these aspects are collectively known as the local security policy), and it provides various services for translation between names and security identifiers (SIDs).
The security subsystem keeps track of the security policies and the accounts that are in effect on a computer system. In the case of a domain controller, these policies and accounts are the ones that are in effect for the domain in which the domain controller is located. These policies and accounts are stored in Active Directory.
The local security policy identifies the following:
Which domains are trusted to authenticate logon attempts.
Who can have access to the system and in what way (for example, interactively, over the network, or as a service).
Who is assigned what rights.
What security auditing is performed.
What the default memory quotas are for paged and non-paged memory pool usage.
LSA Architecture
.gif "LSA Architecture")
The LSA security subsystem provides services for validating access to objects, checking user rights, and generating audit messages. A local procedure call (LPC) occurs between components on the same system. A remote procedure call (RPC) occurs between components on different systems, as do LDAP communications.
In general, the LSA performs the following functions:
Manages local security policy.
Provides interactive user authentication services.
Generates access tokens.
Manages the audit policy and settings.
LSA Components for All Systems
| Component | Description |
|---|---|
Winlogon.exe |
The executable file responsible for managing secure user interactions. Winlogon initiates the logon process for Windows Server 2003, Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows NT 4.0 operating systems. |
Msgina.dll |
The default dynamic-link library (DLL) module that operates in the security context of Winlogon. The Graphical Identification and Authentication (GINA) is responsible for processing secure attention sequence (SAS) events and activating the user’s shell. The GINA can generate SAS events in some instances. |
Netlogon.dll |
Some of the services that Net Logon performs include:
|
Msv1_0.dll |
The NTLM authentication protocol. This protocol authenticates clients that do not use Kerberos authentication. |
Schannel.dll |
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) authentication protocol. This protocol provides authentication over an encrypted channel instead of a less-secure clear channel. |
Kerberos.dll |
The Kerberos V5 authentication protocol. This protocol provides authentication using Kerberos protocol instead of plaintext, NTLM, or digest method. |
Wdigest.dll |
Simple challenge-and-response protocol that provides increased security over basic authentication. |
Lsasrv.dll |
The LSA Server service, which both enforces security policies and acts as the security package manager for the LSA. |
Samsrv.dll |
The Security Accounts Manager (SAM), which stores local security accounts, enforces locally stored policies, and supports APIs. |
Secur32.dll |
The multiple authentication provider that holds all of the components together. |
LSA Components Unique to Domain Controllers
| Component | Description |
|---|---|
Kdcsvc.dll |
The Kerberos Key Distribution Center (KDC) service, which is responsible for providing ticket-granting tickets to clients. |
Ntdsa.dll |
The directory service module, which supports the Windows Server 2003 and Windows 2000 replication protocol and LDAP, and manages partitions of data. |
Security Support Provider Interface
The Security Support Provider Interface (SSPI) is the foundation for authentication in Windows Server 2003. SSPI is the implementation of the Generic Security Service API (GSSAPI) in Windows Server 2003. For more information about GSSAPI, see RFCs 2743 and 2744 in the IETF RFC Database.
The default Security Support Providers in Windows Server 2003 — Negotiate (SPNEGO), Kerberos, NTLM, Schannel, and Digest authentication protocols — are plugged into the SSPI in the form of DLLs. Additional SSPs can be plugged in if they are interoperable with the SSPI.
SSPI in Authentication
The SSPI in Windows Server 2003 provides a mechanism that carries authentication tokens over the existing protocol, thus eliminating the need for communicating parties to specify a network protocol for use during authentication. When two parties need to be authenticated so that they can communicate, the requests for authentication are routed to the SSPI, which completes the authentication process, regardless of the network protocol currently in use.
SSPI Architecture
.gif "SSPI Architecture")
Any application can make a request of the SSPI. Each of these requests goes through the SSPI, for example:
Winlogon sends requests to the Local Security Authority (LSA), which obtains tickets to access the local computer.
Internet Explorer obtains tickets to access information about a Web site.
An LDAP client obtains tickets to enable access to information in an x500 directory, such as Active Directory.
Some applications integrate use of the SSPI into their authentication designs. When such applications need to authenticate a user, they ask the SSPI to complete the authentication by using specific parameters, such as the user’s name and secret key (if they were not cached from a previous logon), and the service that the user wants to access. The SSPI receives the request, examines its contents, and passes the request to the SSP specified in the request. The SSP handles the details of the authentication and sends a success or failure message back to the SSPI, which relays the message back to the application that initially requested authentication. SSPI enables an application to use various security models available on a computer or network without changing the interface to the security system.
For example, if a client has a service ticket for a server for which the preferred authentication protocol is Kerberos, and the client wants to issue that server a remote procedure call (RPC), the client’s Kerberos SSP generates a request message based on standard GSS-API (RFC 1964) calls, which the application sends to the server. When the server receives the request, the server passes the ticket to the Kerberos SSP. The client routes the reply token to its SSP, which then evaluates and manages the contents of the reply. The server and the client know nothing about the contents of the token that is used to enable secure communication, because this information is handled by the SSP. The details of authentication are handled behind the scenes, and the results of the authentication process are passed back to the applications.
Security Support Provider Selection
The SSPI in Windows Server 2003 can use any of the five protocols — Negotiate, Kerberos, NTLM, Schannel, and Digest — that it supports. However, because not all operating systems support the same SSP packages that Windows Server 2003 supports; clients and servers must negotiate to use a protocol that they both support. Windows Server 2003 prefers clients to use Kerberos, a strong standards-based protocol, when possible, but continues to allow clients that do not support Kerberos, such as Windows NT 4.0 clients, to authenticate.
Before authentication can take place, however, the two communicating computers must agree on a protocol that they both can support. For any protocol to be usable through the SSPI, each party must have the appropriate SSP. For example, in order for a client and server to use the Kerberos authentication protocol, they must both support Kerberos V5. Windows Server 2003 uses the function EnumerateSecurityPackages to identify which SSPs are supported on a computer and what the capabilities of those SSPs are.
The selection of an authentication protocol can be handled in one of two ways, each of which is described in more detail below:
A single authentication protocol can be specified.
The negotiate option can be used to allow the parties to attempt to find an acceptable protocol. This is based on the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO, RFC 2478).
Single Authentication Protocol Specified
When a single acceptable protocol is specified, the server allows only one acceptable authentication method for the exchange. If the client does not support the protocol specified, the communication fails. When a single acceptable protocol is specified, the authentication exchange takes place as follows:
The client requests access to a service.
The server replies with an authentication challenge in which it specifies the protocol that be used.
The client examines the contents of the reply and checks to determine whether it supports the specified protocol. If the client does support the specified protocol, the authentication continues. If the client does not support the protocol, the authentication fails, regardless of whether the client is authorized to access the resource.
For example, if a Windows Server 2003 client received a reply that specified the Kerberos protocol, the authentication exchange could proceed. On the other hand, if a Windows NT 4.0 client received the same reply, the authentication exchange would fail, because computers running versions of Windows earlier than Windows 2000 do not support Kerberos authentication. If the specified protocol fails, then negotiation is needed.
Negotiate Option Is Used
When the authentication begins with the option to negotiate for an authentication protocol, the SPNEGO exchange takes place as follows:
The client requests access to a service.
The server replies with a list of authentication protocols that it can support and an authentication challenge based on the protocol that is its first choice. For example, the server might list Kerberos and NTLM, and send a Kerberos challenge.
The client examines the contents of the reply and checks to determine whether it supports any of the specified protocols.
If the client supports the preferred protocol, authentication proceeds.
If the client does not support the preferred protocol, but does support one of the other protocols listed by the server, the client lets the server know which authentication protocol it supports, and the authentication proceeds.
If the client does not support any of the listed protocols, the authentication exchange fails.
For example, if the server specified Kerberos and NTLM, and returned a Kerberos challenge, a Windows Server 2003 client could immediately authenticate by using Kerberos. A Windows NT 4.0 client could negotiate to complete the authentication exchange by using NTLM.
Kerberos SSP
The Kerberos SSP (Kerberos.dll) is the first choice for authentication in Windows Server 2003. The Kerberos SSP uses the Kerberos V5 authentication protocol (RFC 1510).
Because Kerberos is the default authentication protocol for Windows Server 2003, all domain services support the Kerberos SSP, which includes:
Active Directory queries using the Lightweight Directory Access Protocol (LDAP).
Remote server or workstation management using RPC calls.
Print services.
Client-server authentication.
Remote file access using Common Internet File System/server message block (CIFS/SMB).
Distributed file system management and referrals.
Intranet authentication to Internet Information Services (IIS).
Security authority authentication for Internet Protocol security (IPSec).
Certificate requests to Certificate Services for domain users and computers.
NTLM SSP
Windows Server 2003 supports the NTLM SSP, Msv1_0.dll, to enable clients running versions of Windows earlier than Windows 2000 to authenticate. NTLM is the default authentication protocol for Windows NT 4.0. The NTLM SSP includes the NTLM and NTLMv2 authentication protocols.
Windows Server 2003 can use the NTLM SSP for the following:
Client/server authentication
Print services
File access using CIFS/SMB
Secure RPC/DCOM-based services
Negotiate SSP
Microsoft Negotiate is a security support provider (SSP) that acts as an application layer between the Security Support Provider Interface (SSPI) and the other SSPs. When an application calls in to the SSPI to log on to a network, it can specify an SSP to process the request. If the application specifies Negotiate, Negotiate analyzes the request and picks the best SSP to handle the request based on customer-configured security policy.
Negotiate implements RFC 2478, “The Simple and Protected GSS-API Negotiation Mechanism.”
Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos by default unless Kerberos cannot be used by one of the systems involved in the authentication or the calling application did not provide sufficient information to use Kerberos.
Secure Channel (Schannel) SSP
The Schannel SSP is used for access to Web-enabled services, such as mail or personal information served on Web pages.
The Schannel SSP, which includes a suite of four authentication protocols, uses public key certificates to authenticate parties. When authenticating parties, Schannel SSP selects one of the four protocols in the following order of preference:
Transport Layer Security (TLS).
Secure Socket Layer (SSL) version 3.0.
Private Communications Technology (PCT). PCT is disabled by default in Windows Server 2003.
SSL version 2.0.
The protocol that is selected is the preferred authentication protocol that both parties can support. For example, if a server supports all four Schannel protocols and the client supports only SSL 3.0 and SSL 2.0, the authentication process uses SSL 3.0.
Digest SSP
Digest SSP (Wdigest.dll) is the preferred authentication protocol for certain applications, such as LDAP and HTTP. Digest SSP is used for the following:
Internet Explorer (IE) and Internet Information Services (IIS) access.
LDAP queries.
Passport SSP
Windows Server 2003 contains no specific Passport SSP. Instead, passport authentication is enabled by an Internet Server Application Programming Interface (ISAPI) DLL called Passport.dll that captures and processes any cookie information that contains passport credentials.
Authentication Protocols
Each authentication protocol is composed of a series of steps, used by two or more parties, that verifies the identity of one or more of the parties.
The authentication process is vulnerable to numerous types of security attacks. For example, an attacker who has access to authentication information can steal keys to the network, modify messages, or replay old messages.
The authentication protocols in Windows Server 2003, which include Kerberos, NTLM, Schannel, Digest, and Passport, are designed to address potential security threats by verifying the identities of one or more of the communicating parties.
Windows Server 2003 Authentication Protocols
| Authentication Protocol | Description |
|---|---|
Kerberos V5 authentication |
An industry standard protocol that is used with either a password or a smart card for interactive logon. It is also the default method of network authentication for services in Windows 2000, Windows XP, and Windows Server 2003. |
Digest authentication |
An industry standard that is used in Windows Server 2003 for Lightweight Directory Access Protocol (LDAP) and Web authentication that transmits credentials across the network as an MD5 hash or message digest. |
Negotiate |
Negotiate implements RFC 2478, “The Simple and Protected GSS-API Negotiation Mechanism.” Currently, the Negotiate security package selects between Kerberos and NTLM. By default, Negotiate selects Kerberos unless Kerberos cannot be used by one of the systems involved in the authentication, or the calling application did not provide sufficient information to use Kerberos. |
NTLM authentication |
A challenge response protocol that is used to provide compatibility with versions of Windows earlier than Windows 2000. |
Passport authentication |
A user-authentication service that provides a Web-based authentication mechanism enabling Web-services to offer a single sign-in service. |
Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication |
A protocol that is used for Web-based server authentication, such as when a user attempts to access a secure Web server. |
Each of these protocols is used in different ways in Windows Server 2003 to promote secure communication in a network environment that is not secure.
Logon Authentication Scenarios
It is not possible to use a computer that is running Windows Server 2003 without using at least some system services. To use a system service, the account must be a client of the service, and all clients must first be authenticated by the service. Authentication requires the service to know the user’s credentials.
On computers running Windows Server 2003, system services can run under various accounts depending on the way that the applications are written. For example, a computer can access domain resources by using the network service, local system, or domain user accounts. Domain users who log on interactively must also be assigned the appropriate permissions before they can access the computer’s services.
Interactive Logon
The logon process begins when a user enters credentials into the Log On to Windows dialog box or when the user inserts a smart card into the smart card reader. Credentials consist of a user’s user name and password for local logons and the user’s user name, password, and domain for domain logons. The process confirms the user’s identification to the security database on the user’s local computer or to an Active Directory domain. This mandatory logon process cannot be turned off for users in a domain.
Users can perform an interactive logon to a computer in either of two ways:
Locally, when the user has direct physical access to the computer.
Remotely, through Terminal Services, in which case the logon is further qualified as remote interactive.
After an interactive logon, Windows runs applications on the user's behalf and the user can interact with those applications.
Users can perform an interactive logon by using a local user account or a domain account to log on to a computer.
Local Logon
A local logon grants a user access to Windows resources on the local computer. A local logon requires that the user have a user account in the Security Accounts Manager (SAM) on the local computer. The SAM protects and manages user and group information in the form of security accounts stored in the local computer registry. The computer can have network access, but it is not required. Local user account and group membership information is used to manage access to local resources.
Domain Logon
A domain logon grants a user access to local and domain resources. A domain logon requires that the user have a user account in Active Directory. The computer must have an account in the Active Directory domain and be physically connected to the network. Users must also have the user rights to log on to a local computer or a domain. Domain user account information and group membership information is used to manage access to domain and local resources.
Smart Card Logon
Logging on to a domain with a smart card provides a strong form of authentication because smart cards use cryptography-based identification and proof of possession when authenticating a user to a domain.
To log on to a domain with a smart card, a user does not need to press CTRL+ALT+DEL and enter credentials into the Log On to Windows dialog box. The user merely inserts the smart card into the smart card reader and the computer prompts for the user’s personal identification number (PIN) instead of the user name and password.
Smart cards are a tamper-resistant, portable way to provide security solutions for tasks such as client authentication, code signing, securing e-mail, and logging on to a Windows Server operating systems domain.
Smart cards provide:
Tamper-resistant storage for protecting private keys and other forms of personal information.
Isolation of security-critical computations involving authentication, digital signatures, and key exchange from other parts of the computer that do not have a “need to know.” The security critical operations are all performed on the smart card.
Portability of credentials and other private information between computers at work, home, or on the road.
Network Logon
A network logon can only be used after a user, service, or computer authentication has taken place. During network logon, the process does not use the logon dialog boxes, such as the Log On to Windows dialog box, to collect data. Instead, previously established credentials or another method to collect credentials is used. This process confirms the users identification to any network service that the user is attempting to access. This process is typically invisible to the user unless alternate credentials need to be provided.
To provide this type of authentication, the security system includes these authentication mechanisms:
Kerberos V5
Public key certificates
Secure Sockets Layer/Transport Layer Security (SSL/TLS)
Digest
NTLM (for compatibility with Windows NT 4.0-based systems)