How Interactive Logon Works

Updated: March 28, 2003
In this section
•
Interactive Logon Architecture
•
Interactive Logon Components
•
Interactive Logon Protocols
•
Interactive Logon Processes and Interactions
•
Network Ports Used by Interactive Logon
•
Related Information
Theinteractive logon process is the first step in user authentication andauthorization. Interactive logon is mandatory in the Microsoft WindowsServer 2003, Windows XP, Windows 2000, and Windows NT 4.0 operatingsystems. Interactive logon provides a way to identify authorized usersand determine whether they are allowed to log on and access the system.
Thissection describes the interactive logon architecture, the process of aninteractive logon, and the way in which the Windows Server 2003interactive logon process locks down the workstation and keeps itsecure.
Interactive Logon Architecture
The Windows Server 2003 interactive logon architecture includes the following components:
•
Winlogon
•
Graphical Identification and Authentication (GINA) dynamic-link library (DLL)
•
Local Security Authority (LSA)
•
Authentication packages (NTLM and Kerberos)
For more information about these components, see “Interactive Logon Components" later in this section.
WindowsServer 2003 interactive logons begin with the user pressingCTRL+ALT+DEL to initiate the logon process. The CTRL+ALT+DEL keystrokeis called a secure attention sequence (SAS); Winlogon registers thissequence during the boot process to keep other programs and processesfrom using it. The GINA generates the logon dialog box. The followingfigure shows the Windows Server 2003 logon dialog box.
Windows Server 2003 Logon Dialog Box

Auser who logs on to a computer using either a local or domain accountmust enter a user name and password, which form the user’s credentialsand are used to verify the user’s identity. In the case of smart cardlogons, however, a user’s credentials are contained on the card’ssecurity chip, which is read by an external device, a smart cardreader. During a smart card logon, a user enters a personalidentification number (PIN) instead of a user name, domain, andpassword.
Local Logon
Locallogons give user’s access to local computer applications and resources,but not to domain applications and resources. When user’s log onlocally, their identities are validated by authentication packages tolocal account information stored in the Security Accounts Manager (SAM)database. The SAM operates in the security context of the LSA; itprotects and manages user and group information in the form of securityaccounts stored in the local computer registry. Because user accountsare stored on the local computer, network access is not required forlocal logons. However, if a computer has a network connection and auser logs on to a local account, there is no interaction with thenetwork.
Local logons can be performed on Windows clientoperating systems, such as Windows XP and Windows 2000. Windows serveroperating systems, such as Windows NT, Windows 2000 Server, and WindowsServer 2003, also permit local logons.
The following figure shows the local logon architecture.
Interactive Local Logon

Asuccessful local logon begins when a user presses CTRL+ALT+DEL.Winlogon and the GINA collect the user’s credentials and then call theLSA to give it the user’s credentials. The LSA verifies the user’sidentity and then returns a logon success and the user’s access tokento Winlogon and the GINA. Winlogon and the GINA then activate theuser’s shell by creating a new process, such as Explorer.exe.
Domain Logon
Domainlogons give user’s access to resources throughout the domain. Domainuser accounts are stored in an Active Directory domain. ActiveDirectory is deployed on each domain controller and domain useraccounts are replicated throughout a domain.
Before a user canlog on to a computer using a domain account, the computer must bejoined to a domain. If the computer has access to a network connection,the user can log on to a domain provided that the user has an accountin the domain’s Active Directory.
The computer must transparentlyauthenticate to the domain’s Active Directory. This form of logon iscalled a computer logon. Both user’s and computers are considered equalsecurity principals in Active Directory; to be granted access tonetwork resources, both must be able to verify their identities.
Userscan use a domain account to log on to Windows client operating systems,such as Windows XP and Windows 2000. Windows Server operating systems,such as Windows NT, Windows 2000 Server, and Windows Server 2003, alsopermit domain logons. Only server operating systems can function asdomain controllers and deploy Active Directory.
The following figure shows the domain logon architecture.
Interactive Domain Logon

Unlikea local logon in which the local LSA validates the user, during adomain logon, the LSA on a domain controller validates the user. TheLSA evaluates the user’s credentials to determine if the logon shouldbe processed as a logon to a local account or a logon to a domainaccount. After determining the logon type, either the NTLM or Kerberosauthentication package validates the user. If the authenticating domaincontroller is a computer running Windows 2000 or Windows Server 2003,the LSA will use Kerberos, the default authentication package fordomain and network logons. The LSA uses NTLM to process domain logonsin Windows NT 4.0 mixed environments.
Single Sign On
SingleSign-On (SSO) uses credentials collected during an interactive domainlogon to allow the user to authenticate to a network one time and,thereafter, to have access to all authorized network resources withoutadditional authentication. The network resources can range fromhardware devices, such as printers, to applications, files, and othertypes of data, all of which may be spread throughout an enterprise onservers of various types, possibly in different domains and runningdifferent operating systems.
Cached Credentials
Aftera successful domain logon, information is cached; this means that latera user can log on to the computer with the domain account even if thedomain controller that authenticated the user is not available. Becausethe user has already been authenticated, Windows uses the cachedcredentials to log the user on locally. For example, if a mobile userlogs on to a domain-joined laptop with a domain account and then takesthe laptop to a location where the domain is unavailable, Windows willattempt to use the cached credentials from the last successful logonwith a domain account to locally log on the user and allocate access tolocal computer resources.
Top of page
Interactive Logon Components
Thecomponents of the interactive logon process are responsible for helpingto establish secure user authentication. This section describes theroles and functions of the user logon components.
Winlogon
Winlogon(%windir%\System32\Winlogon.exe) is the executable file responsible formanaging secure user interactions. Winlogon initiates the logon processfor Windows Server 2003, Windows 2000, Windows XP, and Windows NT 4.0.
Winlogon is responsible for the following tasks.
•
Desktop lockdown
•
Standard SAS recognition
•
SAS routine dispatching
•
User profile loading
•
Screen saver control
•
Multiple network provider support
Desktop Lockdown
Winlogonhelps prevent unauthorized user’s from gaining access to systemresources by locking down the computer desktop. At any time, Winlogonis in one of three possible states: logged on, logged off, orworkstation locked, as shown in the following figure.
Winlogon States

Winlogonswitches between three desktops — Winlogon, Screen-saver, and Default —depending on its state and user activity. The following table lists anddescribes each of these desktops.
Winlogon Desktops
Desktop Description
Winlogon
Also called the secure desktop. There are five dialog boxes in the Winlogon desktop, which are described in the following table.
Screen-saver
Used as a result of the execution of a screen saver.
Default
Displayed when a user has successfully logged on to Windows Server 2003 and the user’s shell has been activated. The user’s applications run in this desktop.
The following table lists and describes the five dialog boxes in the Winlogon desktop.
Winlogon Desktop Dialog Boxes
Desktop Description
Welcome to Windows
Displayed when a computer has initially booted and no user has entered a SAS or when a user has logged off.
Log On to Windows
Displayed after a user presses CTRL+ALT+DEL when no user is currently logged on.
Windows Security and Change Password
Displayed when:
•
A logged-on user presses CTRL+ALT+DEL when the workstation is not locked.
OR
•
When the workstation is not locked, after a user presses CTRL+ALT+DEL and chooses the Change Password option.
Computer Locked
Displayed when the workstation is locked either explicitly by the user or when a screen saver is set as secure and is dismissed.
Unlock Computer
Displayed when a user presses CTRL+ALT+DEL when the workstation is locked.
Byswitching between the desktops for different logon tasks, Winlogonensures that its processes will be invisible to applications notinvolved in the logon process, preventing logon data from beingcompromised.
Standard SAS Recognition
Winlogonregisters the default SAS during the boot process, which ensures thatno other program can access the same key sequence and compromise thelogon process by impersonating Winlogon and its logon dialog boxes.
SAS Routine Dispatching
When Winlogon recognizes a SAS event or the GINA delivers a SAS, Winlogon calls one of the SAS processing functions of the GINA.
User Profile Loading
After a successful logon, Winlogon loads user profiles into the HKEY_CURRENT_USER registry key.
Screen Saver Control
Winlogonmonitors keyboard and mouse activity to determine when to activatescreen savers. When a screen saver set as secure is dismissed, Winlogontreats the workstation as locked and the GINA displays the ComputerLocked dialog box. When a screen saver not set as secure is dismissed,the user is able to access the application desktop without beingprompted to reenter credentials.
Multiple Network Provider Support
Ifthere are multiple network providers installed on a Windows-basedsystem, they can be included in the authentication process and inpassword-updating operations. This inclusion lets additional networkproviders gather identification and authentication information during alogon, using the secure desktop.
GINA
TheGINA is a DLL module that operates in the security context of Winlogon.Winlogon loads the GINA early in the boot process. The GINA isresponsible for processing SAS events and activating the user’s shell.The GINA can generate SAS events in some instances.
In WindowsServer 2003, Windows XP, and Windows 2000, Msgina.dll(%windir%\System32\Msgina.dll) is the default GINA; it can be replacedto support specific and unique authentication methods. GINAcustomization is enabled to accommodate the use of authenticationhardware tokens, such as retinal scanners and proprietary smart cardsolutions.
LSA
The LSA(%windir%\System32\lsass.exe) is a protected security subsystem thathelps create secure user interactions in Windows Server 2003. Winlogonand the GINA call the LSA to process logon credentials.
The following components involved in user logon run in the security context of the LSA:
•
Authentication packages
•
SAM
•
Active Directory
LSA Responsibilities
Role Description
Application programming interfaces (APIs)
The LSA provides APIs for:
•
Packages to create a user’s logon token after authentication.
•
Applications to call directly for user logon.
•
Microsoft Security Support Provider Interface (SSPI) requests and the routing of requests to the appropriate authentication package.
•
Applications to enumerate available authentication packages and query package capabilities.
•
Applications to resolve Security Identifier -to-Name and Name-to-Security Identifier.
•
Applications to store secret information in the system.
Logon session state
Manages the state of the logon session for any user authenticated by the authentication packages.
Notification to installed authentication packages
Notifies installed authentication packages of user logon, logoff, and credential updates.
Authentication packages
Loads and unloads authentication packages.
Encryption assistance
Includes subcomponents that provide encryption services to user’s of the local computer.
Thefollowing figure shows the LSA architecture. Winlogon, which runs as aseparate process from lsass.exe, is shown here to illustrate the way inwhich the logon process interacts with the LSA.
LSA Architecture

Note
•
Some components shown in this figure run only on domain controllers or non-domain controllers. The SAM runs only on non-domain controllers and Windows NT computers; Directory Services runs only on domain controllers.
As the figure shows, allcalls from Winlogon are sent by using the Secur32.dll LsaLogonUsercall. LsaLogonUser returns the call through local procedure call (LPC)to the LSA Server service. The LSA Server service then determines whichauthentication package to use to process the logon.
You can setuser rights for local computers by using the Local Security Policysnap-in of the Microsoft Management Console (MMC). On WindowsServer 2003 non-domain controllers, the Group Policy User RightsAssignment contains information about which user’s are authorized toperform different tasks, including logging on to the system locally.Domain controllers use the Domain Security Policy snap-in of the MMC toset user rights for domain computers. The User Rights Assignment ondomain controllers contains information that applies to the entiredomain.
Authentication Packages
Authenticationpackages on the user’s local computer communicate with serverauthentication packages to authenticate user’s. Windows Server 2003applies default authentication packages for user authentication andalso supports custom authentication packages.
The following table lists the Windows Server 2003 authentication packages used for interactive logons.
Interactive Logon Authentication Packages
Name Associated Protocol Environment
Kerberos version 5 (V5)
Kerberos.dll
Windows 2000, Windows XP, and Windows Server 2003
NTLM
MSV1_0.dll
Windows NT 4.0 and mixed environments
SAM
TheSAM stores information about local user accounts in the Windowsregistry. Passwords are encrypted by the NTLM authentication package.The outcome of the encryption is a hashed password transformed intociphertext, a string of numbers and letters that appears meaningless.The hashing process occurs by means of a hashing algorithm. NTLM usesthe same algorithm to encrypt and decrypt a user’s password.
Active Directory
Domainaccount information is stored in Active Directory on the domaincontrollers. Within a particular domain, each domain controller has anidentical copy of the domain’s Active Directory. Users can thereforeauthenticate to any domain controller and their logon information willbe recognized throughout the domain.
Top of page
Interactive Logon Protocols
Innetwork environments, authentication protocols are used to authenticateuser’s, computers, and groups. For local logons, Windows Server 2003supports the NTLM authentication protocol. For domain logons, WindowsServer 2003 supports the Kerberos V5 and NTLM authentication protocols.Windows Server 2003 also supports custom authentication packages.
Logon Protocols
Component Description
Kerberos.dll
•
Kerberos V5 authentication package authentication protocol.
•
Standard Internet protocol and default network authentication protocol in Windows Server 2003.
•
Performs authentication of user’s and computers in Windows 2000, Windows XP, and Windows Server 2003.
MSV1_0.dll
•
NTLM authentication package authentication protocol.
•
Default network authentication protocol in Windows NT 4.0.
•
Performs authentication of user’s and computers in Windows NT 4.0 mixed environments.
•
Included in Windows Server 2003 for compatibility with Windows NT 4.0 mixed environments.
For more information about how the Kerberos V5 protocol implements user authentication, see “Kerberos Authentication Technical Reference.”
Top of page
Interactive Logon Processes and Interactions
This section describes the events that occur during an interactive logon.
Local Logon
The following figure shows the local logon process.
Local Logon Process

TheGINA specifies the Negotiate authentication package when it calls intothe LSA. Negotiate must then choose an authentication package toprocess the logon. Negotiate sends the credentials to Kerberos, thedefault authentication package in Windows Server 2003. However, theKerberos authentication package cannot process local logons, so itreturns an error to Negotiate. Negotiate then calls NTLM toauthenticate the user by comparing the received credentials with thosehashed in the SAM.
If the credentials are valid, the LSAgenerates an access token for the user based upon user rights assignedto the user’s account and LsaLogonUser returns the logon success andthe user’s access token to Winlogon and the GINA. The GINA thenactivates the user’s shell and Winlogon switches to the Defaultdesktop. If the credentials are invalid, the LSA returns a logonfailure; the GINA displays an error message and prompts the user topresent valid credentials; and Winlogon remains in the Winlogon desktop.
Domain Logon
Domainlogons can only be performed from computers that are joined to adomain. Domain credentials consist of a user’s domain account username, password, and the name of the domain. The local computer’s LSAchooses the appropriate authentication package to use based on thedomain’s environment.
The following figure shows the process thatoccurs when the local computer can reach a domain controller toauthenticate the user. If a domain controller is not available, acached logon occurs.
Domain Logon Process

Aswith the local logon process, the Negotiate authentication packageroutes the authentication request to the default authenticationpackage, Kerberos.
The domain client chooses Kerberos andKerberos validates the user’s credentials by contacting the domaincontroller. The LSA on the domain controller returns the logon successor failure to the local computer’s LSA. If the domain logon succeeds,the local LSA generates an access token for the user based upon userrights assigned to the user’s account and LsaLogonUser returns thelogon success and the user’s access token to Winlogon and the GINA. TheGINA then activates the user’s shell and Winlogon switches to theDefault desktop. If the credentials are invalid, the LSA returns alogon failure; the GINA displays an error message and prompts the userto present valid credentials; and Winlogon remains in the Winlogondesktop.
Note
•
In Windows NT 4.0 mixed environments, the NTLM authentication package validates the user’s credentials by contacting the domain controller. Windows NT 4.0 stores user accounts in the SAM.
Smart Card Logons
WindowsServer 2003 can be configured to support smart card logons. All smartcard logons are processed by the Kerberos authentication package.During a smart card logon, the local computer checks to ensure theuser’s PIN is valid. The domain controller then authenticates the userbased on the user’s credentials in the smart card.
Cached Logons
WindowsServer 2003 supports cached logons. The cached credentials of the last10 user’s who have successfully logged on to a domain account can beused to log a user on locally if the authenticating domain controllerbecomes unavailable.
Top of page
Network Ports Used by Interactive Logon
Becausethe logon process can be deployed across various network boundaries, itcan span one or more firewalls. The following table lists the threemain configurable ports used by interactive logon.
Port Assignments for Interactive Logon
Service Name UDP TCP
LSA RPC port
Dynamic RPC
Dynamic RPC
Kerberos V5 port
88
88
NTLM port
Dynamic
Dynamic
You can use the Registry Editor tool to modify the registry to apply fixed ports for NTLM and the LSA.