Beruflich Dokumente
Kultur Dokumente
1 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
The interactive logon process is the first step in user authentication and authorization. Interactive logon is mandatory
in the Windows Server 2003, Windows XP, Microsoft Windows 2000, and Windows NT 4.0 operating systems.
Interactive logon provides a way to identify authorized users and determine whether they are allowed to log on and
access the system.
This section describes the interactive logon architecture, the process of an interactive logon, and the way in which the
Windows Server 2003 interactive logon process locks the workstation and helps to keep it secure.
For more information about these components, see Interactive Logon Components later in this section.
Windows Server 2003 interactive logons begin with the user pressing CTRL+ALT+DEL to initiate the logon process.
The CTRL+ALT+DEL keystroke is called a secure attention sequence (SAS); Winlogon registers this sequence during
the boot process to keep other programs and processes from using it. The GINA DLL generates the logon dialog box.
The following figure shows the Windows Server 2003 logon dialog box.
Windows Server 2003 Logon Dialog Box
4/30/2010 2:08 PM
2 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
A user who logs on to a computer using either a local or domain account must enter a user name and password,
which form the user's credentials and are used to verify the user's identity. For smart card logons, a user's credentials
are contained on the card's security chip, which is read by an external device, a smart card reader. During a smart
card logon, a user enters a personal identification number (PIN) instead of a user name, domain, and password.
Local Logon
Local logons give users access to local computer applications and resources but not to domain applications and
resources. When users log on locally, their identities are validated by authentication packages to local account
information stored in the Security Accounts Manager (SAM) database. The SAM operates in the security context of the
LSA; it protects and manages user and group information in the form of security accounts stored in the local
computer registry. Because user accounts are stored on the local computer, network access is not required for local
logons. However, if a computer has a network connection and a user logs on to a local account, there is no interaction
with the network.
Local logons can be performed on Windows client operating systems, such as Windows XP and Windows 2000
Professional. Windows server operating systems, such as Windows NT Server, Windows 2000 Server, and Windows
Server 2003, also permit local logons.
The following figure shows the local logon architecture.
Interactive Local Logon
A successful local logon begins when a user presses CTRL+ALT+DEL. Winlogon and the GINA DLL collect the user's
credentials and then send the credentials to the LSA. The LSA verifies the user's identity and then returns a logon
success and the user's access token to Winlogon and the GINA DLL. Winlogon and the GINA DLL then activate the
user's shell by creating a new process, such as Explorer.exe.
4/30/2010 2:08 PM
3 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
Domain Logon
Domain logons give users access to resources throughout the domain. Domain user accounts are stored in an Active
Directory domain. Active Directory is deployed on each domain controller, and domain user accounts are replicated
throughout a domain.
Before a user can log on to a computer by using a domain account, the computer must be joined to a domain. If the
computer has access to a network connection, the user can log on to a domain if the user has an account in the
domain's Active Directory.
The computer must transparently authenticate to the domain's Active Directory. This form of logon is called a
computer logon. Both users and computers are considered equal security principals in Active Directory; to be granted
access to network resources, both must be able to verify their identities.
Users can use a domain account to log on to Windows client operating systems, such as Windows XP and
Windows 2000 Professional. Windows server operating systems, such as Windows NT Server, Windows 2000 Server,
and Windows Server 2003, also permit domain logons. Only server operating systems can function as domain
controllers and deploy Active Directory.
The following figure shows the domain logon architecture.
Interactive Domain Logon
Unlike a local logon in which the local LSA validates the user, during a domain logon, the LSA on a domain controller
validates the user. The LSA evaluates the user's credentials to determine if the logon should be processed as a logon
to a local account or a logon to a domain account. After determining the logon type, either the NTLM or Kerberos
authentication package validates the user. If the authenticating domain controller is a computer running
Windows 2000 or Windows Server 2003, the LSA will use Kerberos, the default authentication package for domain
and network logons. The LSA uses NTLM to process domain logons in Windows NT 4.0 mixed environments.
Single Sign On
Single sign-on (SSO) uses credentials collected during an interactive domain logon to allow the user to authenticate
to a network one time and, thereafter, to have access to all authorized network resources without additional
authentication. The network resources can range from hardware devices, such as printers, to applications, files, and
other types of data, all of which may be located throughout an enterprise on servers of various types, possibly in
4/30/2010 2:08 PM
4 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
Desktop Lockdown
Winlogon helps prevent unauthorized users from gaining access to system resources by locking the computer
desktop. At any time, Winlogon is in one of three possible states: logged on, logged off, or workstation locked, as
shown in the following figure.
Winlogon States
4/30/2010 2:08 PM
5 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
Winlogon switches between three desktopsWinlogon, screen saver, and defaultdepending on its state and user
activity. The following table lists and describes 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
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 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 clicks Change Password.
4/30/2010 2:08 PM
6 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
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
By switching between the desktops for different logon tasks, Winlogon ensures that its processes will be invisible to
applications not involved in the logon process, preventing logon data from being compromised.
Standard SAS Recognition
Winlogon registers the default SAS during the boot process, which ensures that no other program can access the
same key sequence and compromise the logon 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
Winlogon monitors keyboard and mouse activity to determine when to activate screen savers. When a screen saver
that is set as secure is dismissed, Winlogon treats the workstation as locked and the GINA displays the Computer
Locked dialog box. When a screen saver not set as secure is dismissed, the user is able to access the application
desktop without being prompted to reenter credentials.
Multiple Network Provider Support
If there are multiple network providers installed on a Windows-based system, they can be included in the
authentication process and in password-updating operations. This inclusion lets additional network providers gather
identification and authentication information during a logon, using the secure desktop.
GINA
The GINA is a DLL module that operates in the security context of Winlogon. Winlogon loads the GINA early in the
boot process. The GINA is responsible for processing SAS events and activating the user's shell. The GINA can
generate SAS events in some instances.
In Windows Server 2003, Windows XP, and Windows 2000, Msgina.dll (%windir%\System32\Msgina.dll) is the
default GINA; it can be replaced to support specific and unique authentication methods. GINA customization is
enabled to accommodate the use of authentication hardware tokens, such as retinal scanners and proprietary smart
card solutions.
LSA
The LSA (%windir%\System32\lsass.exe) is a protected security subsystem that helps create secure user interactions
in Windows Server 2003. Winlogon and 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
4/30/2010 2:08 PM
7 of 13
Application programming
interfaces (APIs)
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
Manages the state of the logon session for any user authenticated by the
authentication packages.
Notification to installed
authentication packages
Authentication packages
Encryption assistance
The following figure shows the LSA architecture. Winlogon, which runs as a separate process from lsass.exe, is shown
here to illustrate the way in which the logon process interacts with the LSA.
LSA Architecture
4/30/2010 2:08 PM
8 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
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, all calls from Winlogon are sent by using the Secur32.dll LsaLogonUser call. LsaLogonUser
returns the call through local procedure call (LPC) to the LSA Server service. The LSA Server service then determines
which authentication package to use to process the logon.
You can set user rights for local computers by using the Local Security Policy snap-in of the Microsoft Management
Console (MMC). On Windows Server 2003 non-domain controllers, the Group Policy User Rights Assignment contains
information about which users are authorized to perform different tasks, including logging on to the system locally.
Domain controllers use the Domain Security Policy snap-in of the MMC to set user rights for domain computers. The
User Rights Assignment on domain controllers contains information that applies to the entire domain.
Authentication Packages
Authentication packages on the user's local computer communicate with server authentication packages to
authenticate users. Windows Server 2003 applies default authentication packages for user authentication and also
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.dll
NTLM
MSV1_0.dll
SAM
The SAM stores information about local user accounts in the Windows registry. Passwords are encrypted by the NTLM
4/30/2010 2:08 PM
9 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
authentication package. The outcome of the encryption is a hashed password transformed into ciphertext, a string of
numbers and letters that appears meaningless. The hashing process occurs by means of a hashing algorithm. NTLM
uses the same algorithm to encrypt and decrypt a user's password.
Active Directory
Domain account information is stored in Active Directory on the domain controllers. Within a particular domain, each
domain controller has an identical copy of the domain's Active Directory. Users can therefore authenticate to any
domain controller and their logon information will be recognized throughout the domain.
Component
Kerberos.dll
Description
Kerberos V5 authentication package authentication protocol.
Standard Internet protocol and default network authentication protocol in Windows
Server 2003.
Performs authentication of users and computers in Windows 2000, Windows XP, and
Windows Server 2003.
MSV1_0.dll
For more information about how the Kerberos V5 protocol implements user authentication, see Kerberos
Authentication Technical Reference [ http://technet.microsoft.com/en-us/library/cc739058(WS.10).aspx ] .
4/30/2010 2:08 PM
10 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
The GINA specifies the Negotiate authentication package when it calls into the LSA. Negotiate must then choose an
authentication package to process the logon. Negotiate sends the credentials to Kerberos, the default authentication
package in Windows Server 2003. However, the Kerberos authentication package cannot process local logons, so it
returns an error to Negotiate. Negotiate then calls NTLM to authenticate the user by comparing the received
credentials with those hashed in the SAM.
If the credentials are valid, the LSA generates an access token for the user based upon user rights assigned to the
user's account and LsaLogonUser returns the logon success and the user's access token to Winlogon and the GINA.
The GINA then activates the user's shell and Winlogon switches to the default desktop. If the credentials are invalid,
the LSA returns a logon failure, the GINA displays an error message and prompts the user to present valid
credentials, and Winlogon remains in the Winlogon desktop.
Domain Logon
Domain logons can only be performed from computers that are joined to a domain. Domain credentials consist of a
user's domain account user name, password, and the name of the domain. The local computer's LSA chooses the
appropriate authentication package to use based on the domain's environment.
The following figure shows the process that occurs when the local computer can reach a domain controller to
authenticate the user. If a domain controller is not available, a cached logon occurs.
Domain Logon Process
4/30/2010 2:08 PM
11 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
As with the local logon process, the Negotiate authentication package routes the authentication request to the default
authentication package, Kerberos.
The domain client chooses Kerberos, and Kerberos validates the user's credentials by contacting the domain
controller. The LSA on the domain controller returns the logon success or failure to the local computer's LSA. If the
domain logon succeeds, the local LSA generates an access token for the user based upon user rights assigned to the
user's account, and LsaLogonUser returns the logon success and the user's access token to Winlogon and the GINA.
The GINA then activates the user's shell, and Winlogon switches to the default desktop. If the credentials are invalid,
the LSA returns a logon failure, the GINA displays an error message and prompts the user to present valid
credentials, and Winlogon remains in the Winlogon desktop.
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.
4/30/2010 2:08 PM
12 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
Windows Server 2003 supports cached logons. The cached credentials of the last 10 users who have successfully
logged on to a domain account can be used to log a user on locally if the authenticating domain controller becomes
unavailable.
Service Name
UDP
TCP
Dynamic RPC
Dynamic RPC
Kerberos V5 port
88
88
NTLM port
Dynamic
Dynamic
You can use the Registry Editor to modify the registry to apply fixed ports for NTLM and the LSA.
Related Information
The following resources contain additional information that is relevant to this section.
Kerberos Authentication Technical Reference [ http://technet.microsoft.com/en-us/library
/cc739058(WS.10).aspx ]
Authorization and Access Control Technologies [ http://technet.microsoft.com/en-us/library
/cc782880(WS.10).aspx ]
Tags:
Community Content
"User must Change Password on Next Logon" checkbox
how is the workflow changed when the "User must Change password on next logon" checkbox is marked? because
validation does happen but at the same time it does not because gina does not activate the shell...
[tfl - 07 10 09] Hi - and thanks for your post.You should post questions like this to the Technet
Forums at http://forums.microsoft.com/technet or the MS Newsgroups at
http://www.microsoft.com/communities/newsgroups/en-us/. You are much more likely get a quick
response using the forums than through the Community Content. For specific help about:
Exchange : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.exchange%2C&
SQL Server : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.sqlserver%2C&
Windows : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.windows%2C&
Windows Server : http://groups.google.com/groups
/dir?sel=usenet%3Dmicrosoft.public.windows.server%2C&
Virtual Server : http://groups.google.com/group/microsoft.public.virtualserver/topics?lnk
Full Public : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public%2C&
4/30/2010 2:08 PM
13 of 13
http://technet.microsoft.com/en-us/library/cc780332(WS.10,printer).aspx
4/30/2010 2:08 PM