Knowing the security provided with windows operating system(User
authentication) (Windows 2003)
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
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:

Net Logon maintains the computer’s secure channel
(not to be confused with Schannel) to a domain
controller.

Net Logon passes the user’s credentials through a
secure channel to the domain controller and returns
the domain SIDs and user rights for the user.

In the Windows 2000 Server and Windows Server 2003
operating systems, the Net Logon service publishes
service resource records in the Domain Name System
(DNS) and uses DNS to resolve names to the Internet
Protocol (IP) addresses of domain controllers.

Net Logon also implements the replication protocol
based on RPC for synchronizing Windows NT 4.0
primary domain controllers (PDCs) and backup
domain controllers (BDCs).
Msv1_0.dll
The
NTLM
authentication
authenticates
clients
that
authentication.
protocol.
do
not
This
use
protocol
Kerberos
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 lesssecure 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
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.
provides
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
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:
1. The client requests access to a service.
2. The server replies with an authentication challenge in which it
specifies the protocol that be used.
3. 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:
1. The client requests access to a service.
2. 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.
3. The client examines the contents of the reply and checks to
determine whether it supports any of the specified protocols.
o
If the client supports the preferred protocol, authentication
proceeds.
o
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.
o
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)