Understanding Logon and Authentication

Article
09/11/2009

When a user logs on to a computer, a series of steps begins that makes up the authentication process. Authentication validates user identity and defines resources that a user can access. Windows operating systems use NTLM or the Kerberos V5 authentication protocol. Authentication is mostly automatic, but understanding the protocols, policies, and other elements involved can help you configure and manage authentication—and strengthen security.

For information on how to obtain the Windows XP Professional Resource Kit in its entirety, please see https://www.microsoft.com/mspress/books/6795.asp.

Bb457114.3squares(en-us,TechNet.10).gif

For more information about authorization, see Chapter 17, “Managing Authorization and Access Control.”
For more information about Kerberos V5 authentication, see “Authentication” in the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit.
For more information about implementing security for Windows-based client computers and servers, see the Microsoft Windows Security Resource Kit, Second Edition (Microsoft Press, 2005).

Overview

Microsoft Windows XP Professional assures security by using the following processes:

Authentication, which verifies the identity of something or someone
Authorization, which allows you to control access to all network resources, such as files and printers

Authentication takes place all around us. For example, you are required to authenticate your identity and purpose when crossing international borders or completing business transactions. Similarly, in Windows, the identity of a user or computer must be authenticated before the user or computer has access to files, folders, and applications.

The following discussion provides detailed information about the configuration, management, and maintenance of authentication functions for Windows XP Professional–based clients, whether they are stand-alone clients or members of an Active Directory or other network environment.

New in Windows XP Professional

If you are already familiar with the security model in Microsoft Windows NT version 4.0 and Microsoft Windows 2000, you will recognize many of the features in Windows XP Professional. At the same time, you will also find a number of familiar features that have changed significantly and new features that will improve your ability to manage system security.

The following are among the changed security-related features in Windows XP Professional:

Everyone membership.

The built-in Everyone group includes Authenticated Users and Guests, but it no longer includes members of the Anonymous group.
Simple file sharing.

By default, on Windows XP Professional systems that are not connected to a domain, all attempts to log on from across the network will be forced to use the Guest account. In addition, on computers that are using the simple file sharing security model, the Security Properties dialog box is replaced by a simplified Shared Documents Properties dialog box.
Administrative ownership.

In Windows NT 4.0 and Windows 2000, all resources such as files and folders that are created by a member of the Administrators group belong to the group as a whole. In Windows XP Professional, these resources by default belong to the individual who creates them.
Encrypting File System (EFS) recovery agent.

In a Windows 2000 environment, if you attempt to configure an EFS recovery policy with no recovery agent certificates, EFS is automatically disabled. In a Windows XP Professional environment, the same action enables users to encrypt files without a Data Recovery Agent (DRA). In an environment with computers running both Microsoft Windows XP and Windows 2000, an empty EFS recovery policy turns off EFS on Windows 2000–based computers but eliminates the requirement for a DRA only on Windows XP Professional–based computers.
Permissions for installing printers.

To install a local printer in Windows XP Professional, you must belong to the Power Users or Administrators group and have the Load/Unload Device Driver privilege. Administrators have this privilege by default, but it must be explicitly granted to Power Users.
Blank password restriction.

To protect users who do not password-protect their accounts, Windows XP Professional accounts without passwords can be used only to log on at the physical computer console and not remotely over the network.

The following are among the new security-related features in Windows XP Professional:

Software Restriction policies.

New security policy options allow you to prevent certain software applications from running based on a file path, Internet zone, certificate, or hashed file path.
Fast user switching.

On computers running Windows XP Professional that are not connected to a domain, users can switch from one user account to another without logging off or closing their applications.
Stored user names and passwords.

This utility provides secure storage for user names and credentials needed to access network or Internet resources.
New service accounts.

Windows XP Professional includes two new service accounts, LocalService and NetworkService, to enable graduated levels of permissions on services. Services can run as LocalService on the local computer, as NetworkService on the network, or as part of the Local System. Any service not running as one of the three built-in service accounts must have its own account.
Password Reset Wizard.

This wizard makes it possible for users to create a secure reset disk, which they can use at a later date in case they forget the password for their local account.

For more information about these features and changes, see the applicable discussions in this chapter, and see Chapter 17, “Managing Authorization and Access Control,” and Chapter 18, “Using Encrypting File System.”

New In Windows XP Service Pack 2

SP2 makes significant changes in Windows XP to improve the overall security of the operating system. The changes are in four basic areas:

Improved network protection
Improved memory protection
Improved e-mail security
Improved browser security

Improved Network Protection

Windows XP SP2 includes the new Windows Firewall, covered in Chapter 22. This firewall is enabled by default and includes boot time security, protecting against a broad range of exploits. In addition to the new Windows Firewall, there are security enhancements in the Distributed Component Object Model (DCOM), the TCP/IP stack, the Remote Procedure Call (RPC) interface, Windows Messenger, and Windows Media Player. Finally, there are extensive changes to wireless networking in SP2 that are detailed in Chapter 21, “Wireless Networking.”

Improved Memory Protection

Windows XP SP2 adds support for both hardware- and software-enforced Data Execution Protection (DEP). Hardware DEP requires processor support. Software DEP uses an additional set of security checks designed to mitigate exploitation of exception-handling mechanisms in Windows. Applications can be written to use Safe Structured Exception Handling (SafeSEH), which allows their exception handler to be registered. Applications that do not use SafeSEH must ensure that their exception handler is located within a memory region marked as executable.

Improved E-Mail Security

Windows XP SP2 adds some important improvements to the way Outlook Express handles email. By default, the SP2 version of Outlook Express blocks access to potentially unsafe attachments while still enabling safe attachments. Additionally, e-mail that has pictures and images that could be Web beacons are blocked when viewing HTML e-mail.

Outlook Express also gives you the option to view and preview all e-mail as plain text, eliminating the security concerns related to HTML e-mail. Plain text does prevent you from seeing fonts and font effects, along with the pictures in the e-mail, but it does add an additional layer of security.

Improved Browser Security

Windows XP SP2 adds several new features to Internet Explorer to improve its security. These include a new pop-up blocker; better screening of and information about potentially harmful downloads; a new add-on manager that makes it easier to see and control what is installed into Internet Explorer; limitations on the ability of Web sites to change the window size and controls of Internet Explorer; and tighter security on the Local Machine zone.

The new gold bar—a gold-colored information bar that appears at the top of the browser window when a pop-up or potentially harmful download is blocked—provides improved information on the item being blocked, along with the ability to override the block. When a pop-up window is blocked, you can allow pop-ups temporarily or permanently for the site.

When you are downloading files from the Internet, SP2 gives you additional information about the specific file and the certificate that is attached to it. Content that might not be what it claims to be is flagged, and you also have the option to never download content from a specific publisher.

Credentials and Validation

The authentication process has two fundamental parts—credentials and validation.

Credentials

Credentials assert the identity of the applicant. A validating agent either confirms or denies the validity of the credentials, determining the level of trust granted the applicant. At an international border, for example, a passport issued by a recognized national government would be a traveler’s credentials, and a crossing guard representing the government of the country/region one attempts to enter would be the validating agent. Typically, a passport is considered a strong guarantee of a bearer’s identity. On the other hand, a business card is another kind of a credential—or proof of identity—that is validated with much less rigor.

In Windows 2000 and Windows XP Professional, a user’s credentials can be supplied by a password, a Kerberos ticket, or a smart card if the computer is equipped to handle a smart card. For more information about smart cards, see “Smart Cards” later in this chapter.

Validation

Validation in Windows is performed by a protected subsystem called the Local Security Authority (LSA), which maintains information about all aspects of local operating system security. In addition to providing interactive user authentication services, the LSA does the following:

Manages local security policy
Manages audit policy and settings
Generates tokens that contain user and group information as well as information about the security permissions for the user

The LSA validates your identity based on which of the following two entities issued your account:

LSA.

The LSA can validate your information by checking its own Security Accounts Manager (SAM) database. Any workstation or member server can store local user accounts and information about local groups. However, these accounts can be used for accessing only that workstation or computer.
Security authority for the local domain or for a trusted domain.

The LSA contacts the entity that issued your account and asks it to verify that the account is valid and that you are the account holder.

Security Principals

In Windows XP Professional, any user, group, or computer that can initiate action is a security principal. Security principals have accounts, which can be local to a computer or domain-based. A local Security Accounts Manager (SAM) database manages local accounts on the computer. A domain-based SAM manages accounts in a Windows NT 4.0 domain. Active Directory manages domain accounts in Active Directory domains.

For example, Windows XP Professional computers participate in a network domain by communicating with a domain controller even when no human user is logged on. To initiate communications, the computer must have an active account in the domain. Before accepting communications from the computer, the LSA on the domain controller authenticates the computer’s identity and then defines the computer’s security context just as it would for a human security principal. This security context defines the identity and capabilities of a user or service on a particular computer or a user, service, or computer on a network. For example, it defines the resources (such as a file share or printer) that can be accessed and the actions (such as Read, Write, or Modify) that can be performed by a user, computer, or service on that resource.

The security context of a user or computer can vary from one computer to another, such as when a user logs on to a server or a workstation other than the user’s own primary workstation. It can also vary from one session to another, such as when an administrator modifies the user’s rights and permissions. In addition, the security context is usually different when a user or computer is operating on a stand-alone basis, in a mixed network domain, or as part of an Active Directory domain. For more information about security principals and how the security context is created, see Chapter 17, “Managing Authorization and Access Control.”

About Services

Even though most Windows applications run in the security context of the user who starts them, this is not true of services. Many Windows services, such as network and printing services, are launched by the service controller when you start your computer. Services continue to run after the last human user logs off. Services have to log on using accounts to access domain resources just as human users and Windows XP Professional–based computers do.

Note Services normally run in security contexts known as Local System, Network Service, or Local Service.

Before starting a service, the service controller logs on using the account designated for the service and presents the service’s credentials for authentication by the LSA. For example, when a Windows XP Professional computer joins a domain, the messenger service on the computer connects to a domain controller and opens a secure channel to it. To obtain an authenticated connection, messenger must have credentials that the remote computer’s LSA trusts. LSA uses the credentials for the local computer’s domain account, as do all other services running in the security context of the Local System.

Security Identifiers

The rights and permissions for a user, computer, or group are determined by access control lists (ACLs) and contain security identifiers (SIDs) for a user, computer, or group. A security identifier (SID) is a unique value that identifies a user, group, or computer account within an enterprise. Every account is issued a SID when it is created. Access control mechanisms in Windows XP Professional identify security principals by SID instead of by name. Therefore, even if the name of a security principal changes, the SID remains the same.

In addition to your own unique SID, you are identified by the SIDs of the groups to which you belong. This information is stored in an access token, which encapsulates all data that relates to your identity and security context during a given session.

Access tokens

An access token is re-created every time a security principal logs on, and it contains the following information:

The SID for the user’s account.
A list of SIDs for security groups that include the user and the privileges held on the local computer by the user and the user’s security groups. This list includes SIDs both for domain-based security groups, if the user is a member of a domain, and for local security groups.
The SID of the user or security group that becomes the default owner of any object that the user creates or takes ownership of.
The SID for the user’s primary group.
The default DACLs that the operating system applies to objects created by the user if no other access control information is available.
The source, such as the Session Manager or LAN Manager, that caused the access token to be created.
A value indicating whether the access token is a primary token, which represents the security context of a process, or impersonation token, which is an access token that a thread within a service process can use to temporarily adopt a different security context, such as the security context for a client of the service.
A value that indicates to what extent a service can adopt the security context of a client represented by this access token.
Statistics about the access token that are used internally by the operating system.
An optional list of SIDs added to an access token by a process to restrict use of the token.
A session ID that indicates whether the token is associated with a Terminal Services client session. (The session ID also makes fast user switching possible.)

A copy of the access token is attached to every thread and process that the user runs. The security reference monitor (SRM) then compares the security IDs in the token with the security IDs for every file, folder, printer, or application that the user attempts to access. In this way, the access token provides a security context for the security principal’s actions on the computer.

For more information about ACLs and SIDs, see Chapter 17, “Managing Authorization and Access Control.”

Security Groups

Organizing users and other objects into groups simplifies access administration. Security groups can be described according to their scope (such as Global, Domain Local, or Universal groups in Active Directory environments) or according to their purpose, rights, and role (such as the Everyone, Administrators, Power Users, or Users groups).

Using security groups, you can assign the same security permissions to many users. This ensures consistent security permissions across all members of a group. Using security groups to assign permissions means that access control of resources remains constant and easy to manage and audit. By adding and removing users who require access from the appropriate security groups as needed, you can minimize the frequency of changes to ACLs.

Types of Logon

There are four types of logon processes in Windows 2000, Windows Server™ 2003, and Windows XP Professional:

Interactive.

Logs on to a local computer to which you have direct physical access. Terminal Services and Remote Desktop logon processes are interactive even though they take place remotely.
Network.

Accesses a system that is running Windows NT 4.0, Windows 2000, Windows Server 2003, or Windows XP Professional across the network from the computer where you logged on. In this case, the LSA on your workstation will attempt to establish your identity with the LSA on a remote computer by using the credentials that were used during your initial interactive network logon process.
Service.

When a Win32-based service starts up, it logs on to the local computer using the credentials of a local or domain user account or the LocalSystem account. A service running in the security context of the LocalSystem account on a domain controller would have unrestricted access to Active Directory™. On the other hand, a service running in the security context of a local user account would have no access to network resources.
Batch.

A batch logon is rarely used in the Windows operating system because it is usually reserved for applications that run as batch jobs, such as bank account reconciliation and big print spools. The account that is logging on must have the logon as a batch job privilege. If it does not, the account will fail to log on.

Interactive Logon Process

An interactive logon process confirms the user’s identification to either a domain account or a local computer. This process differs, depending on whether the user account is local to the computer or resides in Active Directory:

Domain account.

A user logs on to the network with a password or smart card using credentials stored in Active Directory. By using a domain account to log on, an authorized user can access resources in the domain and any trusting domains.
Local user account.

A user logs on to a local computer by using credentials stored in the SAM database. Any workstation or member server can store local user accounts, but those accounts can be used to access only that local computer.

Windows XP Professional can use a user principal name (UPN) to identify users in an interactive logon process.

If you want to log on to an Active Directory domain, and Logon domain does not appear in the dialog box, click the Options button to open an expanded dialog box. Or type your user name and the domain name as follows:

Your user principal name prefix (your user name) and your user principal name suffix (your Windows 2000 domain name), joined by the “@” character. For example, user@sales.westcoast.microsoft.

Tip The suffix in the preceding example is a fully qualified DNS domain name. An administrator might create an alternative suffix to simplify the logon process. For example, by creating a user principal name suffix of “microsoft,” the same user can log on by using the simpler address, user@microsoft.com.

Components Used in Interactive Logon

The interactive logon process in Windows XP Professional involves a number of components and a sequence of events that are not visible to the user. The logon process involves the following components, whose relationship to each other is illustrated in Figure 16-1:

Winlogon.

A secure process, responsible for managing the security-related user interactions that coordinate the logon and logoff processes and start the user’s shell.
Microsoft Graphical Identification and Authentication (MSGINA).

A DLL that is called by Winlogon to obtain a user’s account name and password and pass it back to Winlogon. MSGINA displays the standard logon dialog box.

Note Some organizations create their own GINAs or use third-party GINAs.
Local Security Authority (LSA).

The entity that receives the user name and password from Winlogon and determines whether the logon process is to be authenticated on the local computer or across the network.
Security Accounts Manager (SAM).

The protected subsystem that manages user and group account information. If the logon process is to be authenticated locally, the SAM database on the local computer is used to verify the user’s credentials. If the logon process is to be authenticated on a Windows NT 4.0 domain controller, the SAM database on the domain controller is used.
Net Logon service.

The service used, together with the NTLM protocol, to query the SAM on a domain controller to validate the user’s credentials.
Active Directory.

The directory service in Windows 2000 and later. If the logon process is to be authenticated on a domain controller, the KDC service queries Active Directory to verify the user’s credentials.
Kerberos Key Distribution Center (KDC) service.

The service used, together with the Kerberos authentication protocol, to authenticate logon requests to Active Directory.

Figure 16-1 Components involved in interactive logon

Using RunAs to Start a Program

Administrators require a greater range of permissions than other users to perform their tasks, such as accessing files, installing and running applications, or modifying systems. However, running Windows XP Professional all the time as an administrator or a member of an administrative group makes the network more vulnerable to viruses, Trojan horses, and other security risks. To reduce risk, it is recommended that you perform nonadministrative tasks by using accounts that have only Users or Power Users rights and use your Administrator account only when you perform administrative tasks.

You can use administrative rights and privileges even while logged on as a member of the Users or Power Users group. The RunAs program and the RunAs Service let you log on by using one security context and then, within the initial logon session, authenticate and use a second account. Figure 16-2 illustrates the RunAs dialog box.

Figure 16-2 RunAs dialog box

Warning For security reasons, you might want to disable the RunAs feature on Windows XP desktops. For more information, see article 830568, “How to disable the Run As feature on a Windows Server 2003–based or on a Windows XP–based computer,” in the Microsoft Knowledge Base at https://support.microsoft.com.

The RunAs Service logs on an account with expanded permissions. For example, when you log on as a member of the Users group, you can perform routine tasks such as running programs and visiting Internet sites without exposing your computer to unnecessary risk. As a member of the Power Users group, you can perform routine tasks and install programs, add printers, and use most Control Panel items. Then, when you use the RunAs program to log on as an administrator, you can start a program in the Administrators group security context. You can use the RunAs program to start any program, program shortcut, saved MMC console, or Control Panel item if the following conditions exist:

You provide the appropriate user account and password information.
The user account can log on to the computer.
The program, MMC snap-in, or Control Panel item is available on the system and to the user account.

Note Some applications are started indirectly by Windows XP Professional and therefore cannot be started by the RunAs program.

To use RunAs to start a program as an administrator

In Windows Explorer, click the program you want to open, such as an MMC console or Control Panel.
Press Shift; right-click the program, tool, or item; and then click Run As.
In the Run As dialog box, click The following user.
In the User name and Password boxes, type the user name and password for the administrator account you want to use.
In the Domain box, do one of the following:
- If you want to use the local administrator account on your computer, type the name of your computer.
  
  – or –
- If you want to use the domain administrator account from the domain your computer is a member of or any trusted domain on your computer, type the name of the domain.

You can perform a secondary logon from a command prompt by using the following syntax:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

runas /user: domain_name
administrator_account program_name

If the Administrator account in the microsoft.com domain is named Administrator, you can use the following command to start MMC as Administrator:

runas /user:microsoft\administrator mmc

If you attempt to start a program, an MMC console, or a Control Panel item from a network location by using the RunAs dialog box or command, it might fail if the credentials used to connect to the network share are different from the credentials used to start the program. For more information, see article 303308, “Cannot Use Runas.exe to Run Remote Programs on Mapped Drives,” in the Microsoft Knowledge Base at https://support.microsoft.com.

Note If the RunAs program fails, the RunAs Service might not be running. You can set the RunAs Service to start when the system starts by using the Services MMC snap-in.

Working with Authentication Protocols

Windows 2000, Windows Server 2003, and Windows XP Professional support several protocols for verifying the identity of users who claim to have accounts on the system. These include protocols for authenticating dial-up connections and protocols for authenticating external users who try to connect to the network over the Internet. However, the following authentication protocols are the primary choices for network authentication between Windows NT 4.0, Windows 2000, and Windows Server 2003 domains, and Windows XP Professional–based clients:

Kerberos V5 protocol.

The default authentication protocol for Windows 2000 and Windows XP Professional
NTLM protocol.

The default authentication protocol in Windows NT 4.0

Even though the Kerberos V5 authentication protocol is the default for Windows 2000, Windows Server 2003, and Windows XP Professional, both the network domain controllers and the client computers must be running Windows 2000, Windows Server 2003, or Windows XP Professional for Kerberos authentication to be used. The alternative NTLM protocol is used for authentication if the following conditions exist:

Computers running Microsoft Windows 3.11, Microsoft Windows 95, Microsoft Windows 98, or Windows NT 4.0 use the NTLM protocol for network authentication in Windows 2000 or Windows Server 2003 domains.
Computers running Windows 2000 Professional or later or Microsoft Windows 2000 Server or later use the NTLM protocol to authenticate to servers running Windows NT 4.0.
Computers running Windows 2000 Professional or later and Windows 2000 Server or later use the NTLM protocol to authenticate when they are not participating in a domain–that is, when they operate as stand-alone computers or as part of a workgroup.

Protocol Selection

The following processes determine whether the Kerberos or NTLM protocol is used to complete the network authentication process:

After the user name and password are entered, the LSA passes this information to the Security Support Provider Interface (SSPI), an interface that communicates with both the Kerberos and NTLM services.

Tip SSPI also allows developers to write “security-aware” applications whether the Kerberos or NTLM protocol is used.
SSPI passes the user name and password to the Kerberos Security Support Provider (SSP), which exchanges messages directly with the domain’s Kerberos Key Distribution Center (KDC). The Kerberos SSP determines whether the target computer name is the local computer or the domain name.
If the domain name is referenced and the KDC recognizes the user name, the Kerberos authentication process proceeds.
If the user name is not recognized, the KDC passes an internal error message to the SSPI. If a KDC cannot be found, the following message (transparent to the user) is passed back to the LSA:

“No logon server available.”
The internal error message triggers the process to start over again. MSGINA passes the information to LSA again, and then LSA passes the information back to SSPI.
SSPI then passes the user name and password to the NTLM driver, MSV1_0 SSP. MSV1_0 then uses the Net Logon service to complete the NTLM authentication process.

If both the Kerberos and NTLM protocols fail to authenticate the user account, the following error message appears, and the user can try to log on again:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

“The system could not log you on.
 Make sure your User name and domain are correct,
 then type your password again.
 Letters in passwords must be typed using the correct case.
 Make sure  that Caps Lock is not accidentally on.”

Note The same error message appears whether the password is typed incorrectly or the user name is not in the local SAM database. This is done to make it more difficult for an intruder to determine the reason that the logon attempt failed.

NTLM

The NTLM protocol authenticates users and computers based on a challenge/response mechanism. When the NTLM protocol is used, a resource server must contact a domain authentication service on the domain controller for the computer or user’s account domain to verify its identity whenever a new access token is needed.

Note In the absence of a domain, the NTLM protocol can also be used for peer-to-peer authentication.

Challenge/Response Authentication

NTLM authentication in Windows 2000, Windows Server 2003, and Windows XP Professional supports the following three methods of challenge/response authentication:

LAN Manager (LM).

The least secure form of challenge/response authentication that is supported by Windows XP Professional (but more secure than cleartext). LM is available so that computers running Windows XP Professional can connect to file shares on computers running Microsoft Windows for Workgroups, Windows 95, or Windows 98.
NTLM version 1.

A more secure form of challenge/response authentication than LM. It is available so that computers running Windows XP Professional can connect to servers in a Windows NT domain that has at least one domain controller running Windows NT 4.0 Service Pack 3 or earlier.
NTLM version 2.

The most secure form of challenge/response authentication that is supported by Windows XP Professional. It is used when computers running Windows XP Professional connect to servers in a Windows NT domain where all domain controllers are upgraded to Windows NT 4.0 Service Pack 4 or later. It is also used when computers running Windows 2000, Windows Server 2003, or Windows XP Professional connect to servers running Windows NT in a Windows 2000 or Windows Server 2003 domain. In addition, computers running Windows 95 or Windows 98 can use this form of challenge/response authentication if the Directory Service Client Pack has been installed.

By default, all three challenge/response mechanisms are enabled so that clients running Microsoft Windows for Workgroups, Windows 95, or Windows 98 can access network resources. You can disable authentication that uses weaker variants by setting the Network Security: LAN Manager authentication level option in Local Security Policy\Computer Configuration\Windows Settings\Local Policies\Security Options or in the appropriate security template. If you do so, however, computers that rely on the weaker variants for authentication might not be able to access network resources.

For more information about configuring the LAN Manager authentication level, see “Account Policies” later in this chapter.

Interactive Logon with NTLM

The following process, shown in Figure 16-3, is essentially the same on any version of NTLM you use:

The user presses Ctrl+Alt+Del, which is the Secure Attention Sequence (SAS) on computers that have a standard Windows XP Professional configuration. Winlogon calls a replaceable Graphical Identification and Authentication (GINA) dynamic-link library (DLL) to display a logon user interface.
After the user enters a user name and password, Winlogon sends the information to the LSA.
If the user’s account is local to the computer, the LSA uses the MSV1_0 authentication package to compare the user’s logon information with data in the computer’s SAM database. If the user is not local to the computer, the LSA validates the user’s credentials by using the MSV1_0 authentication package and Net Logon service to query the SAM on a Windows NT domain controller.
If the user’s logon name and password are valid, the SAM communicates this information back to the LSA, along with the user’s security identifier (SID) and the SIDs that apply to any groups that the user belongs to. The LSA uses this information to create an access token that includes the user’s SIDs.
Winlogon starts the user’s shell with the token attached.

Figure 16-3 NTLM logon process

Kerberos V5 Authentication Protocol

The Kerberos V5 protocol provides a means for mutual authentication between a client—such as a user, computer, or service—and a server. This is a more efficient means for servers to authenticate clients, even in the largest and most complex network environments. The Kerberos protocol is based on the assumption that initial transactions between clients and servers take place on an open network—an environment in which an unauthorized user can pose as either a client or a server and intercept or tamper with communication between authorized clients and servers. Kerberos V5 authentication also provides secure and efficient authentication for complex networks of clients and resources.

The Kerberos V5 protocol uses secret key encryption to protect logon credentials that travel across the network. The same key can then be used to decrypt these credentials on the receiving end. This decryption and the subsequent steps are performed by the Kerberos Key Distribution Center (KDC), which runs on every domain controller as part of Active Directory.

An authenticator—a piece of information such as a time stamp that is different each time it is generated—is included with the encrypted login credentials to verify that previous authentication credentials are not being reused. A new authenticator is generated and incorporated with the KDC’s encrypted response to the client to confirm that the original message was received and accepted. If the initial logon credentials and the authenticator are accepted, the KDC issues a ticket-granting ticket (TGT) that is used by the LSA to get service tickets. These service tickets can then be used to access network resources without having to re-authenticate the client as long as the service ticket remains valid. These tickets contain encrypted data that confirms the user’s identity to the requested service. Except for entering an initial password or smart-card credentials, the authentication process is transparent to the user.

Interactive Logons Using Kerberos Authentication

The Kerberos authentication process was designed to be more secure and scalable across large, diverse networks than NTLM authentication. The Kerberos authentication process includes the following actions (shown in Figure 16-4):

The user presses Ctrl+Alt+Del, the SAS on computers that have a standard Windows XP Professional configuration. Winlogon calls a replaceable Graphical Identification and Authentication (GINA) dynamic-link library (DLL) to display a logon user interface.
After the user enters a user name and password, Winlogon sends the information to the LSA.
When the logon request reaches the LSA, it passes the request to the Kerberos authentication package. The client sends an initial authentication request (AS_REQ), which includes the user’s credentials and an encrypted timestamp to the KDC. This is a request for authentication and a TGT.

Note The logon request uses the principal name of krbtgt*@ domain_name*, where domain_name is the name of the domain in which the user account is located. The first domain controller in the domain generates the krbtgt*@ domain_name* account.
The KDC uses the secret key to decrypt the timestamp and issues a TGT to the client. This TGT (AS_REP) contains a session key, the name of the user to whom the session key was issued, the maximum lifetime of the ticket, and any additional data fields or settings that might be required. The AS_REP is encrypted with the user’s key and returned to the user. The ticket is encrypted with the KDC’s key and enclosed in the AS_REP. The authorization data portion of the TGT contains the SID for the user account and SIDs for any global and universal groups to which the user belongs.

Note The SIDs are returned to the LSA for inclusion in the user’s access token. The maximum lifetime of a ticket is defined by the domain policy. If a ticket expires during an active session, the client requests a new ticket.
When the user attempts to access a resource, the client system uses the TGT to request a service ticket (TGS_REQ) from the Kerberos ticket-granting service on the domain controller. The TGS then issues a service ticket (TGS_REP) to the client. This service ticket is encrypted using the server’s secret key. The SIDs are copied by the Kerberos service from the TGT into all subsequent service tickets obtained from the Kerberos service.

Note This TGS session uses a separate session key than the earlier TGT transaction.
The client presents this service ticket directly to the requested network service. The service ticket proves both the user’s identity and permissions to the service, and the service’s identity to the user.

Figure 16-4 Logon process using the Kerberos V5 authentication protocol

For more information about Kerberos V5 authentication, see “Logon and Authentication” in the Distributed Systems Guide. For more information about configuring the Kerberos V5 authentication service, see “Account Policies” later in this chapter.

Kerberos Ticket Cache

Windows stores tickets and keys obtained from the KDC in a credentials cache, an area of memory protected by the LSA. Only processes running in the LSA’s security context have access to the cache. Its memory is never paged to disk. All tickets and keys are stored per user logon session, which means that they are destroyed when a security principal logs off or the system is turned off.

The credentials cache is managed by the Kerberos SSP, which runs in the LSA’s security context. Whenever tickets and keys must be obtained or renewed, the LSA calls the Kerberos SSP to accomplish the task.

The credentials cache is also used to store a copy of an interactive user’s password-derived key. If the user’s TGT expires during a logon session, the Kerberos SSP uses its copy of the key to obtain a new TGT without interrupting the user’s logon session. The key is not stored permanently on the computer, and the local copy in the credentials cache is destroyed when the credentials cache is flushed.

Password-derived keys for services and computers are handled differently. They are stored in a secure area of the computer’s registry just as they are in Windows NT. Password-derived keys for user accounts on the local system, which are used only for access to computers in stand-alone mode, are also stored in the registry. These keys are never used for network access.

Kerberos Interoperability

The Windows 2000 or later implementation of the Kerberos V5 protocol supports Internet Engineering Task Force (IETF) standard RFC 1510 to help ensure interoperability with other vendors’ implementations of Kerberos V5 authentication. This interoperability allows single sign-on to be provided within large mixed environments.

Applications or other operating systems based on the Generic Security Service Application Program Interface (GSSAPI) can obtain service tickets from a Windows 2000 or Windows Server 2003 domain. A Windows 2000 Professional, Windows 2000 Server, Windows Server 2003, or Windows XP Professional client likewise can authenticate to a third-party Kerberos KDC for authentication.

A Kerberos realm is not a Windows domain. As a result, the computer running Windows XP must be configured as a member of a workgroup and it must be configured to locate the Kerberos realm by its name. A Windows XP Professional client that uses a non-Windows Kerberos V5 realm must be configured to locate the realm, available KDC servers, and available Kerberos password servers.

Note Additional Kerberos V5 configuration tools are available on the Windows Server 2003 distribution media in the \Support\Tools folder.

You can use the command-line tool Ksetup to configure Windows XP Professional clients to use a third-party Kerberos V5 KDC.

To enable user logon to a non-Windows Kerberos realm

In the Run dialog box, type cmd, and then click OK.
At the command line, type:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.
```
ksetup /addkdc REALM.MYDOMAIN.COM 
```

kdc.realm.mydomain.comksetup /addkdc REALM.MYDOMAIN.COM kdc-master.realm.mydomain.com

This configures the computer to use two KDCs for the realm REALM.*MYDOMAIN*.COM.

If the Kerberos realm supports the Kerberos change password protocol, the kpasswd servers can be configured. This will allow the user to change his or her password after pressing Ctrl+Alt+Del. To configure the kpasswd server, at the command line, type:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.
```
ksetup /addkpasswd REALM.MYDOMAIN.COM
```

kdc-master.realm.mydomain.com

**Note** Windows XP can also locate the KDC and kpasswd servers based on the DNS SRV records if no KDCs or kpasswd entries exist for the configured realm.

The computer needs to have a local account that is authorized with the interactive logon right to the appropriate Kerberos principal. To map a local account with the username “alice,” at the command line, type:
```
ksetup /mapuser alice@REALM.MYDOMAIN.COM username
```
This maps the local account “alice” to the Kerberos principal “alice@REALM.MYDOMAIN.COM”. When the user “alice@REALM.MYDOMAIN.COM” logs on to the computer, the local identity “alice” is used for access control and to locate a user profile.

Note It is best not to trust all users to access your computer. If no mapping exists for a particular user, they cannot log on.
If you want to grant guest access to any users, an explicit mapping for the guest account needs to be set up and the guest account must be enabled. To map the guest account, at the command line, type:
```
ksetup /mapuser * guest
```
Restart the computer to implement your changes.

You might also want to enable Windows XP Professional users to access services by presenting the Kerberos credentials associated with their mapped identities.

To enable Kerberos authentication for services

In the Run dialog box, type cmd, and then click OK.
Because a Kerberos realm is not a Windows domain, the computer running Windows XP Professional must be configured as a member of a workgroup and the computer configured to locate the Kerberos realm by its name. To do this, at the command line, type:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.
```
ksetup /addkdc REALM.MYDOMAIN.COM 
```

kdc.realm.mydomain.com ksetup /addkdc REALM.MYDOMAIN.COM kdc-master.realm.mydomain.com

This configures the computer to use two KDCs for the realm REALM.*MYDOMAIN*.COM configuration.

Configure the computer to authenticate to the realm in which the computer’s host service principal was created. To accomplish this, create a new KDC entry by typing:
```
ksetup /setrealm REALM.MYDOMAIN.COM
```
Configure the computer’s password so that it corresponds to the host service principal created for the computer in the Kerberos realm. At the command line, type:
```
ksetup /setmachpassword the-password
```
To set up mappings for users to control explicit access, at the command line, type:
```
ksetup /mapuser alice@REALM.MYDOMAIN.COM alice
```
This will map the Kerberos principal “alice@REALM.MYDOMAIN.COM” to the local account “alice”. You can use the local account “alice” on access control lists on resources or local groups on the computer to grant or deny access to specific resources.

Note If no mapping exists for a Kerberos principal, the user will be anonymous and will be able to access any resource for which anonymous access is allowed.
Restart the computer.

Managing Credentials

Authentication is an organization’s first defense against malicious intruders. As a result, many organizations have implemented stringent validation criteria, including strong passwords and smart cards.

Passwords can be the weakest link in a computer security scheme. Network passwords that once took weeks to break can now be broken in hours. However, it still can take months to crack a strong password. A strong password that is hard to break has the following characteristics:

Contains at least six characters
Contains characters from each of the following three groups:
- Uppercase and lowercase letters (A, a, B, b, C, c, and so on)
- Numerals
- Symbols (characters that are not defined as letters or numerals, such as !, @, #, and so on)
Contains at least one symbol character in the second through sixth positions
Is significantly different from prior passwords
Does not contain your name or user name
Is not a common word or name

Windows XP Professional passwords can have up to 127 characters. However, if you use Windows XP Professional on a network that also has computers using Windows 95 or Windows 98, consider using passwords no longer than 14 characters. If your password is longer, you might not be able to log on to your network from those computers.

Warning Require users to change passwords frequently. Although a strong password can help protect against intruders, given enough time, automated password-cracking tools can crack any password. Changing passwords can minimize the risk of an intruder determining a password. It also minimizes potential damage when a password is compromised without the user’s knowledge.

Blank Password Restrictions

By default, Windows XP Professional does not require users with local accounts, including administrators, to have passwords. Users can choose to set passwords on their own accounts, or administrators can assign passwords to users on a local computer.

To protect users who do not password-protect their accounts, Windows XP Professional accounts without passwords can be used to log on only at the physical computer console. By default, accounts with blank passwords can no longer be used to log on to the computer remotely over the network or for any other logon activity except at the main physical console logon screen. For example, you cannot use the secondary logon service (RunAs) to start a program as a local user with a blank password.

Caution If your computer is not in a physically secured location, it is recommended that you assign passwords to all local user accounts. Failure to do so allows anyone with physical access to the computer to log on using an account that does not have a password. This is especially important for portable computers, which should always have strong passwords on all local user accounts.

Assigning a password to a local account removes the restriction that prevents logging on over a network and permits that account to access any resources it is authorized to access, even over a network connection.

Note This restriction does not apply to domain accounts. It also does not apply to the local Guest account. If the Guest account is enabled and has a blank password, it will be permitted to log on and access any resource authorized for access by the Guest account. For more information about managing network logons using the Guest account, see Chapter 17, “Managing Authorization and Access Control.”

If you want to disable the restriction against logging on to the network without a password, you can do so through Local Security Policy. The policy setting that controls blank password restriction can be modified using the Local Security Policy or Group Policy MMC snap-ins. You can use either tool to find this policy option at Security Settings\Local Policies\Security Options. The name of the policy is Accounts: Limit local account use of blank passwords to console logon only. It is enabled by default.

Caution Disabling this policy setting might degrade the security of your Windows XP Professional computer. Before disabling this policy setting, ensure that all local accounts have strong passwords, or that the computer is in a secure and trusted environment where it will not be subject to attack.

Password Management

You can use User Accounts in Control Panel or the Local Users and Groups MMC snap-in to add and remove local user accounts, add and remove users from groups, and work with passwords. When the Windows XP Professional–based computer is connected to a Windows NT, Windows 2000, or Windows Server 2003 domain, you can use Local Users and Groups to assign domain user accounts to local groups. When the Windows XP Professional–based computer is not connected to a domain, you can use User Accounts to add and remove local user accounts and assign users to local groups.

To change the password for a user

In Control Panel, open User Accounts. In the User Accounts dialog box, click the user’s name, and then click Reset Password.
Enter the new password twice in the Reset Password dialog box.
If desired, type in a word or phrase in the box provided for password hints.

In the Local Users and Groups MMC snap-in, double-click the Users folder.
Select and right-click the name of the user who has a local account that you want to manage, and then select Properties.
On the user’s Properties page, select one or more of the following options:
- User must change password at next logon.
- User cannot change password.
- Password never expires.
- Account is disabled.
- Account is locked out.

Group Policy

You can use Group Policy to perform more advanced password management tasks, such as setting a minimum password length or the interval between password changes. When you review your password security policies, establish your Account Lockout Policy at the same time. This policy locks a user account after a certain number of incorrect passwords are tried in succession. For more information about password-related policy options, see “Account Policies” later in this chapter.

Note You must log on as an administrator or be a member of the Administrators group to add and delete user accounts, assign users to a local group, and set or change user passwords.

Stored User Names and Passwords

It is not always desirable to use one set of credentials for access to different resources. For example, when an administrator accesses a remote server, you might want him or her to use administrative rather than user credentials. Similarly, if a user will be accessing external resources such as a bank account, you might prefer that he or she use credentials that are different than their network username and password.

Stored User Names and Passwords in Control Panel simplifies the management and use of multiple sets of logon credentials, including X.509 certificates used with smart cards and Passport credentials. The credentials—part of the user’s profile—are stored until needed. This can increase security on a per-resource basis by ensuring that if one password is compromised, it does not compromise all security.

Note Microsoft Passport provides a single name and password that can be used on multiple Web sites.

After a user logs on and attempts to access additional password-protected resources, such as a share on a server, and if the user’s default logon credentials are not sufficient to gain access, Stored User Names and Passwords is queried. If alternate credentials with the correct logon information have been saved in Stored User Names and Passwords, these credentials are used to gain access. Otherwise, the user is prompted to supply new credentials, which can then be saved for reuse, either later in the logon session or during a subsequent session.

Several restrictions apply:

If Stored User Names and Passwords contains invalid or incorrect credentials for a specific resource, access to the resource will be denied and the Stored User Names and Passwords dialog box will not appear.
Stored User Names and Passwords stores credentials only for NTLM, Kerberos, Passport, and SSL authentication. Microsoft Internet Explorer maintains its own cache for basic authentication.

These credentials become an encrypted part of a user’s local profile in the \Documents and Settings\Username\Application Data\Microsoft\Credentials directory. As a result, these credentials can roam with the user if the user’s network policy supports Roaming Profiles. However, if you have copies of Stored User Names and Passwords on two different computers and change the credentials that are associated with the resource on one of these computers, the change will not be propagated to Stored User Names and Passwords on the second computer.

To store a new user name and password

In Control Panel, open User Accounts.
On computers joined to a domain, click the Advanced tab, and then click Manage Passwords.

– or –

On computers not joined to a domain, click the icon that represents your user account, and then, under Related Tasks, click Manage your stored passwords.
Click Add.
Type the appropriate information in the spaces provided.

Warning Educate your users about the importance of using strong passwords for all credentials stored in Stored User Names and Passwords.

To store a Passport ID

In Control Panel, open User Accounts.
On computers not joined to a domain, click the icon that represents your user account, and then, under What do you want to change about your account?, click Create a Passport.

– or –

On computers joined to a domain, click the Advanced tab, and then click .NET Passport Wizard.
Type the appropriate information in the spaces provided.
In the When accessing box, type *.passport.com.

Warning Some credentials are used infrequently. Others might be for extremely sensitive resources that the user wants to protect more carefully. When appropriate, have users store credentials for “This logon session only.” Credentials for a single logon session are typically stored by selecting the appropriate check box in the User Names and Passwords dialog box.

Some administrators might not feel comfortable with allowing users to store network credentials for later use. This might be because of concerns about reduced security, or a potential increase in the number of account lockouts when credentials stored in User Names and Passwords expire. As a result, a Group Policy setting has been introduced to allow you to limit use of Stored User Names and Passwords.

To limit use of Stored User Names and Passwords

In the Group Policy MMC snap-in, double-click the Security Options folder (Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options).
Right-click Network access: Do not allow storage of credentials or .NET Passports for network authentication.
Click Enabled, and then click OK.

Backing Up and Restoring Passwords

Forgetting passwords is one of the most common problems users—including administrators—encounter on local computers. To prevent users from being locked out of their computers, a Password Reset Wizard has been added to Windows XP Professional. The wizard allows users to create a backup disk, which they can use later to reset their password if they forget their Windows password.

Note The ability to back up and restore passwords applies only to local user accounts. It does not apply to network-based passwords and accounts. Also, users can back up passwords only for accounts that they are logged on to. Administrators can create password backups only for their own accounts, not for other users.

The backup disk does not actually store the user’s password—that would pose a security risk. Instead, the disk contains a private and public key pair that the backup process generates. A file containing the user’s password encrypted with the public key is stored on the computer, but it is separate from the Security Accounts Manager database.

The following procedure describes the password backup process, which can be performed when a password is set or at any time the user chooses.

To back up a password

In Control Panel, click User Accounts, and then select your own account.
In the Related Tasks pane, click Create a Password Reset Disk to launch the Password Reset Wizard, and then click Next.

Note If the computer is joined to a domain, the domain-based version of User Accounts is used even when the user logs on by using a local account. To access the Password Reset Wizard in this situation, press CTRL+ALT+DEL, click Backup, and then click Next.
Insert removable media into the drive where the backup key will be stored, and then click Next.

Note The backup can be stored only to removable media, not to the local computer.
In Current User Account Password, in the Current user account password box, type your existing password, and then click Next.
A progress indicator appears. During this phase, the following events occur:
- A file containing a 2048-bit public key is created on the local computer. This file is a self-signed certificate containing the SID of the user and the user’s password encrypted by the public key.
- The certificate and the private key are written to removable media.
Click Finish.

The Password Reset Wizard allows users to back up their passwords without having to create a new backup disk for every password change. Every time a user changes a password, the new password is encrypted using the public key and a function of the previous encrypted password. The encrypted password is then added to a list of previous password changes in the file where the public key resides.

To restore a password, Windows XP Professional includes the Password Reset Wizard, which appears when the user enters an incorrect password. This wizard asks for the drive where the backup disk is located and prompts the user for a new account password. After the new password is entered, the user’s private key is retrieved from the backup media, the user’s profile is loaded, and the wizard attempts to decrypt the last encrypted password by using the private key. If the process succeeds, the password entered earlier in the process becomes the new password and the user is allowed to access the system. If the decryption fails, the user is informed that the reset disk is invalid and the wizard closes.

Note You cannot reset the user password if the hard disk is reformatted or the file containing the chain of encrypted passwords is deleted.

Smart Cards

A smart card is an integrated circuit card (ICC) approximately the size of a credit card. You can use it to store certificates and private keys and to perform public key cryptography operations, such as authentication, digital signing, and key exchange.

A smart card enhances security as follows:

Provides tamper-resistant storage for private keys and other forms of personal identification
Isolates critical security computations involving authentication, digital signatures, and key exchange from parts of the system that do not require this data
Enables moving credentials and other private information from one computer to another (for example, from a workplace computer to a home or remote computer)

A smart card uses a personal identification number (PIN) instead of a password. The smart card is protected from misuse by the PIN, which the owner of the smart card selects. To use the smart card, the user inserts the card into a smart card reader attached to a computer and then enters the PIN.

A PIN offers more protection than a standard network password. The strength of the password depends on its length, how well it is protected, and how difficult it is to guess. In contrast, a PIN never travels on the network. In addition, smart cards allow a limited number (typically three to five) of failed attempts to key in the correct PIN before the card locks itself. After the limit is reached, entering the correct PIN does not work. The user must contact a system administrator to unlock the card.

Windows 2000 or later supports industry-standard, Personal Computer/Smart Card (PC/SC)–compliant smart cards and Plug and Play smart card readers that conform to specifications developed by the PC/SC Workgroup. To function with Windows 2000, Windows Server 2003, and Windows XP Professional, a smart card must conform physically and electronically to ISO 7816-1, 7816-2, and 7816-3 standards.

Smart card readers attach to standard personal computer peripheral interfaces such as RS-232, PC Card, and Universal Serial Bus (USB). Some RS-232 readers have an extra cable that plugs into the PS/2 port to draw power for the reader. However, the reader does not communicate through the PS/2 port. Readers are standard Windows devices, and they carry a security descriptor and a Plug and Play identifier. Smart card readers are controlled by standard Windows device drivers, and you can install and remove them by using the Hardware Wizard.

Windows 2000, Windows Server 2003, and Windows XP Professional include drivers for various commercially available Plug and Play smart card readers that are certified to display the Windows-compatible logo. Some manufacturers might provide drivers for noncertified smart card readers that currently work with the Windows operating system. Nevertheless, to ensure continued support by Microsoft, it is recommended that you purchase only smart card readers that display the Windows-compatible logo.

Logging On by Using a Smart Card

Smart cards can be used to log on only to domain accounts, not local accounts. When you use a password to log on interactively to a domain account, Windows 2000, Windows Server 2003, and Windows XP Professional use the Kerberos V5 protocol for authentication. If you use a smart card, the operating system uses Kerberos V5 authentication with X.509 v3 certificates unless the domain controller is not running Windows 2000 Server or Windows Server 2003.

To initiate a typical logon session, a user must prove his or her identity to the KDC by providing information known only to the user and the KDC. The secret information is a cryptographic shared key derived from the user’s password. A shared secret key is symmetric, which means that the same key is used for both encryption and decryption.

To support logging on by using a smart card, Windows 2000 Server and Windows Server 2003 implement a public key extension to the Kerberos protocol’s initial authentication request. In contrast to shared secret key cryptography, public key cryptography is asymmetric; that is, two different keys are needed—one to encrypt, another to decrypt. Together, the keys needed to perform both operations make up a private/public key pair.

When a smart card is used in place of a password, a private/public key pair stored on the user’s smart card is substituted for the shared secret key derived from the user’s password. The private key is stored only on the smart card. The public key can be made available to anyone with whom the owner wants to exchange confidential information.

In the public key extension to the Kerberos protocol, the client encrypts its part of the initial Authentication Service Exchange (AS Exchange) with the private key and passes the certificate to the KDC. The KDC encrypts the user’s logon session key with the public half of the user’s key pair. The client then decrypts the logon session key by using the private half of the key pair.

Initiating a smart card logon session involves the following process:

The user inserts a smart card into a card reader attached to the computer.
The insertion of the card signals the SAS just as pressing Ctrl+Alt+Del signals the SAS on computers configured for logging on using a password.
In response, Winlogon dispatches to MSGINA, which displays a modified logon dialog box. In this case, however, the user types only the personal identification number (PIN).
MSGINA sends the user’s logon information to the LSA just as it does with a logon session using a password.
The LSA uses the PIN for access to the smart card, which contains the user’s private key along with an X509 v3 certificate that contains the public half of the key pair.
The Kerberos SSP on the client computer sends the user’s public key certificate to the KDC as pre-authentication data in its initial authentication request.
The KDC validates the certificate, extracts the public key, and then uses the public key to encrypt a logon session key. It returns the encrypted logon session key and a TGT to the client.
If the client owns the private half of the key pair, it can use the private key to decrypt the logon session key. Both the client and the KDC then use this logon session key in all future communications with one another.

Warning All cryptographic operations that use these keys take place on the smart card.

The rest of the authentication process is the same as for a standard logon session.

For information about the types of smart cards and smart card readers supported by Windows XP Professional, see the Windows Catalog at https://www.microsoft.com/windows/catalog.

Automating Logon

Using Windows XP Professional, you can automate the logon process by storing your password and other pertinent information in the registry. Using this feature, other users can start your computer and use the account you enable to log on automatically.

Caution Although enabling autologon can make it more convenient to use Windows XP Professional, using this feature is a security risk. Setting a computer for autologon means that anyone who can physically obtain access to the computer can gain access to all the computer’s contents, potentially including any network or networks it is connected to. A second risk is that enabling autologon causes the password to be stored in the registry in plain text. The specific registry key that stores this value is remotely readable by the Authenticated Users group. As a result, this setting is appropriate only when the computer is physically secured and unauthorized users are prevented from remotely accessing the registry.

You can enable autologon by using the following procedure to edit the registry.

Caution Do not edit the registry unless you have no alternative. The Registry Editor bypasses standard safeguards, allowing settings that can damage your system or even require you to reinstall Windows. If you must edit the registry, back it up first.

To add logon information by editing the registry

In the Run dialog box, type regedit.exe and then click OK.
Navigate to the registry subkey HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows NT\CurrentVersion\Winlogon.
Double-click the DefaultUserName entry.
In the Value data box, type your user name, and then click OK.
If the DefaultPassword entry does not exist, click New on the Edit menu, and then select String Value.
1. In the Name box, type DefaultPassword.
2. Double-click DefaultPassword.
3. In the Value Data field, type your password.
Double-click AutoAdminLogon, and then enter 1 in the Value data box.
Close the Registry Editor.
Restart your computer.

Starting the computer now causes the logon process to occur automatically.

Disabling the Welcome Screen

On computers running Windows XP Professional that are not members of a domain, the default is for users to see a Welcome screen that includes the names of all users with accounts on the computer. The user’s password prompt is revealed when the user clicks his or her name. Because the names of all user accounts are made visible on this Welcome screen, this behavior is less secure than using the Ctrl+Alt+Del user interface.

To disable the Welcome screen and require CTRL+ALT+DEL to be used for logons

In Control Panel, click User Accounts.
Click Change the way users log on or off.
Clear the Use the Welcome screen check box. This also disables the Use Fast User Switching option.

Users will now log on using the Ctrl+Alt+Del user interface.

Setting Authentication Policy Options

Authentication policies and other security policies can be applied to stand-alone computers, as well as member computers and domain controllers, by using the Security Configuration Manager tools. The Security Configuration Manager tools consist of:

Local Security Policy
Security Settings extension to Group Policy
Security Templates snap-in
Security Configuration and Analysis snap-in
Secedit.exe command-line tool

To set or modify individual security settings on individual computers, use Local Security Policy. To define security settings that are enforced on any number of computers, use the Security Settings extension to Group Policy. To apply several settings in a batch, use Security Templates to define the settings and then apply those settings by using Security Configuration and Analysis or Secedit.exe, or import the template that contains your settings into Local or Group Policy. Figure 16-5 shows the Group Policy snap-in with the Security Settings extensions expanded.

Figure 16-5 Group Policy snap-in

Note For more information about working with Group Policy, see Chapter 5, “Managing Desktops.” For more information about security-related Group Policy, see Chapter 17, “Managing Authorization and Access Control.”

The following security policy options are logon options and authentication options that can be configured on a computer running Windows XP Professional. This section does not include security policy options that affect other areas of desktop security management.

Warning The default values of security policy settings described in the sections following are those found in Local Security Policy on a stand-alone Windows XP computer. If a Windows XP computer is joined to a Windows 2000 or Windows Server 2003 domain, these default settings might be modified by Group Policy, specifically by settings configured in the Default Domain Policy GPO.

Account Policies

Account policies affect Windows XP Professional computers in two ways. When applied to a local computer, account policies apply to the local account database that is stored on that computer. When applied to domain controllers, the account policies affect domain accounts for users logging on from Windows XP Professional computers that are joined to that domain.

Domain-wide account policies are defined in the Default Domain Group Policy object (GPO). All domain controllers pull the domain-wide account policy from the Default Domain GPO regardless of the organizational unit in which the domain controller exists. Thus, while there might be different local account policies for member computers in different organizational units, there cannot be different account policies for the accounts in a domain.

By default, all computers that are not domain controllers will also receive the default domain account policy for their local accounts. However, different account policies might be established for local accounts on computers that are not domain controllers by setting an account policy at the organizational unit level. Account policies for stand-alone computers can be set using Local Security Policy.

Password Policy

To modify the following password policy settings, open Local Security Policy or Group Policy and go to Computer Configuration\Windows Settings\Security Settings\Account Policies\
Password Policy.

Maximum password age.

The number of days a password can be used before the user must change it. Changing passwords regularly is one way to prevent passwords from being compromised. Typically, the default varies from 30 to 42 days.
Enforce password history.

The number of unique, new passwords that must be associated with a user account before an old password can be reused. When used in conjunction with Minimum password age, this setting prevents reuse of the same password over and over. Most IT departments set a value greater than 10.
Enforce password history.

The number of days a password must be used before the user can change it. The default value is zero, but it is recommended that this be reset to a few days. When used in conjunction with similarly short settings in Enforce password history, this restriction prevents reuse of the same password over and over.
Minimum password length.

The minimum number of characters a user’s password can contain. The default value is zero. Seven characters is a recommended and widely used minimum.
Passwords must meet complexity requirements.

The default password filter (Passfilt.dll) included with Windows XP Professional requires that a password have the following characteristics:
- Does not contain your name or user name
- Contains at least six characters
- Contains characters from each of the following three groups: uppercase and lowercase letters (A, a, B, b, C, c, and so on), numerals, and symbols (characters that are not defined as letters or numerals, such as !, @, #, and so on)
This policy is disabled by default.

Tip It is strongly recommended that you enable this policy setting.

Account Lockout Policy

Account lockout policy options disable accounts after a set number of failed logon attempts. Using these options can help you detect and block attempts to break passwords. To modify lockout policy settings, launch Local Security Policy or Group Policy and go to Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.

Account lockout threshold.

The number of failed logon attempts before a user account is locked out. A locked-out account cannot be used until an administrator resets it or until the account lockout duration expires. You can set values from 1 through 999 failed logon attempts, or you can specify that the account is never locked out by setting the value to 0.
- This setting is disabled (set to zero invalid logon attempts) in the Default Domain Group Policy object and in Local Security Policy for workstations and servers. You must change this to enable lockout after a specified number of attempts.
- Unsuccessful attempts to log on to workstations or member servers that have been locked using either CTRL+ALT+DEL or password-protected screen savers do not count as failed logon attempts under this policy setting. Failed attempts to log on remotely do count.
Account lockout duration.

The number of minutes (from 1 through 99999) an account remains locked out before it unlocks. By setting the value to 0, you can specify that the account remains locked out until an administrator unlocks it. By default, this policy is not defined because it has meaning only when an account lockout threshold is specified.
Reset account lockout counter after.

Determines how many minutes (1 through 99999) must elapse after a failed logon attempt before the counter resets to 0 bad logon attempts. This value must be less than or equal to the account lockout duration. Typically, a reset time of 30 minutes is sufficient because the purpose of an account lockout is to delay an attack on a password.

To manually reset an account that has been locked out, open the user’s property sheet in Active Directory Users and Computers. On the Account tab, clear the Account is Locked Out check box. Even though it is a good practice to reset the user’s password at the same time, changing the password does not unlock the account.

Kerberos Policy

Kerberos policy does not apply to local account databases because the Kerberos authentication protocol is not used to authenticate local accounts. Therefore, the Kerberos policy settings can be configured only by means of the default domain GPO, where it affects domain logons performed from Windows XP Professional computers.

For information about Kerberos policy, see “Authentication” in the Distributed Systems Guide.

Local Policies

In Local Security Policy and Group Policy, three categories of security policy are located under Computer Configuration\Windows Settings\Security Settings\Local Policies:

Audit Policy
User Rights Assignment
Security Options

Note For information about Audit Policy, see “Auditing and Troubleshooting Logon and Authentication” in this chapter.

User Rights Assignment

User rights are typically assigned on the basis of the security groups to which a user belongs, such as Administrators, Power Users, or Users. The policy settings in this category are typically used to allow or deny users’ permission to access their computer based on the method of access and their security group memberships.

In the Local Security Settings and Group Policy snap-ins, the following policy options that affect users’ rights based on their method of accessing the computer are located under the Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment extension.

Note The User Rights Assignment extension includes additional policy options that are not listed here.

Access this computer from the network.

Allows a user to connect to the computer over the network. By default, permissions are granted to members of the Administrators, Everyone, Users, Backup Operators, and Power Users groups.
Deny access to this computer from the network.

A user cannot connect to the computer over the network.
Allow logon through Terminal Services.

Allows a user to connect to the computer by means of a terminal services session.
Deny logon through Terminal Services.

A user cannot connect to the computer by means of a terminal services session.
Log on as a batch job.

Allows a user to log on by means of a batch-queue facility. For example, when a user submits a job by using the task scheduler, the task scheduler logs that user on as a batch user instead of as an interactive user. This user right is defined in the Default Domain Controller Group Policy object and in the local security policy of workstations and servers. By default, only the LocalSystem account has permissions to be logged on as a batch job.
Deny logon as a batch job.

Certain accounts cannot log on as a batch job. This policy setting supercedes the Log on as a batch job policy setting if a user account is subject to both policies. This user right is defined in the Default Domain Controller Group Policy object and in the local security policy of workstations and servers. By default, no users are prevented from logging on as a batch job.
Log on as a service.

Certain service accounts can register a process as a service. This user right is defined in the Default Domain Controller Group Policy object and in the local security policy of workstations and servers. By default, no user or computer accounts have permissions to log on as a service. By default, only System, LocalService, and NetworkService have the right to log on as a service.
Deny logon as a service.

A security principal cannot log on as a service to establish a security context. The LocalSystem account always retains the right to log on as a service. Any service that runs under a separate account must be granted this right.
Log on locally.

Allows certain users to log on at the computer. This user right is defined in the Default Domain Controller Group Policy object and in the local security policy of workstations and servers. The default groups that have this right on Windows XP Professional are Administrators, Backup Operators, Power Users, Users, and Guest.
Deny logon locally.

Certain users cannot log on at the computer. This policy setting supercedes the Log on locally policy setting if an account is subject to both policies. This user right is defined in the Default Domain Controller Group Policy object and in the local security policy of workstations and servers. By default, the Guest account is denied local logon permission.

Security Options

You might want to set the following security options to modify logon-related behaviors:

Interactive logon
Microsoft network server
Network access
Network security
Recovery console
Shutdown

The following policy options are located under Computer Configuration\Windows Settings\
Security Settings\Local Policies\Security Options.

Note The Security Options extension includes additional policy options that are not listed here.

Interactive Logon: Do not display last user name.

Determines whether the name of the last user to log on to the computer is displayed in the Windows logon screen. If this policy is enabled, the name of the last user to successfully log on is not displayed in the Log On to Windows dialog box. If this policy is disabled, the name of the last user to log on is displayed. This policy is defined in Local Computer Policy, where it is disabled by default.
Interactive Logon: Do not require CTRL+ALT+DEL.

Determines whether a user must press Ctrl+Alt+Del to log on. If this policy is enabled, a user is not required to press Ctrl+Alt+Del to log on. This policy is not defined by default.

Caution Not having to press CTRL+ALT+DEL leaves the user’s password vulnerable to interception. Requiring CTRL+ALT+DEL before logging on ensures that the user is communicating by means of a trusted path when entering a password.
Interactive Logon: Message text for users attempting to log on.

Specifies message text that appears when a user logs on. This text is often used for legal reasons, such as to warn users against misusing company information or to tell them that their actions might be audited. This policy is defined by default, but no default text is specified.
Interactive Logon: Message title for users attempting to log on.

Allows the specification of a title to appear in the title bar of the window that contains the message for users attempting to log on. This policy is not defined by default, and no default text is specified.
Interactive Logon: Number of previous logons to cache (in case a domain controller is not available).

Windows 2000 Server and Windows XP Professional store previous user logon information locally so that a subsequent user can log on even if a domain controller is unavailable. This setting determines how many unique previous logons are cached. If a domain controller is unavailable and a user’s logon information is stored, the user is prompted by this message: “A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on may not be available.” If a domain controller is unavailable and a user’s logon information is not stored, the user is prompted by this message: “The system cannot log you on now because the domain DOMAIN NAME is not available.” In this policy setting, a value of 0 disables logon storing. Any value above 50 stores only 50 logon attempts. The default value is 10 logons.
Interactive Logon: Prompt user to change password before expiration.

Determines how far in advance the operating system warns users that their password is about to expire. Advanced warning gives the user time to construct a strong password. The default value is 14 days.
Interactive Logon: Require domain controller authentication to unlock.

If a computer is locked, a user must authenticate against a domain controller to unlock the computer. Otherwise, cached credentials can be used.
Interactive Logon: Smart card removal behavior.

Allows you to configure one of three consequences if a smart card is removed in the middle of a session: Lock workstation, Force Logoff, and No Action.
Network Access: Allow anonymous SID/Name translation.

Makes it possible for anonymous users to translate SIDs into user names and user names into SIDs. This policy is disabled by default.
Network Access: Do not allow anonymous enumeration of SAM accounts.

Prevents anonymous users from generating a list of accounts in the SAM database. This policy is enabled by default.
Network Access: Do not allow anonymous enumeration of SAM accounts and shares.

Prevents anonymous users from generating a list of accounts and shares in the SAM database. This policy is disabled by default.
Network Access: Do not allow Stored User Names and Passwords to save passports or credentials for domain authentication.

Prevents Stored User Names and Passwords from saving passport or domain authentication credentials after a logon session has ended. This policy is disabled by default.
Network Access: Sharing and security model for local accounts.

Allows you to choose between the Guest only security model or the Classic security model. In the Guest only model, all attempts to log on to the local computer from across the network will be forced to use the Guest account. In the Classic security model, users who attempt to log on to the local computer from across the network authenticate as themselves. This policy does not apply to computers that are joined to a domain. Otherwise, Guest only is enabled by default.
Network Access: Let Everyone permissions apply to Anonymous users.

Restores Everyone permissions to users logging on anonymously. In Windows 2000, Anonymous logons received Everyone permissions by default. This default behavior was removed in Windows XP Professional.
Network Access: Do not store LAN Manager hash value on next password change

Clears the LAN Manager hash value the next time a password is changed. This policy is disabled by default.
Network Access: Force logoff when logon time expires.

Determines whether to disconnect users who are connected to the local computer outside their valid logon hours. This setting affects the Server Message Block (SMB) component of a Windows 2000 server. When this policy is enabled, client sessions with the SMB server are disconnected when the client’s logon hours expire. If this policy is disabled, an established client session can continue after the client’s logon time expires.
Network Access: LAN Manager Authentication Level.

Determines which challenge/response authentication protocol is used for network logons. These policy options affect the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers. The following options are available:
- Send LM & NTLM responses.
  
  Clients use LM and NTLM authentication, and they never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication.
- Send LM & NTLM - use NTLMv2 session security if negotiated.
  
  Clients use LM and NTLM authentication, and they use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
- Send NTLM response only.
  
  Clients use NTLM authentication only, and they use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
- Send NTLMv2 response only.
  
  Clients use NTLMv2 authentication only, and they use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
- Send NTLMv2 response only\refuse LM.
  
  Clients use NTLMv2 authentication only, and they use NTLMv2 session security if the server supports it; domain controllers refuse LM authentication and accept only NTLM and NTLMv2 authentication.
- Send NTLMv2 response only\refuse LM & NTLM.
  
  Clients use NTLMv2 authentication only, and they use NTLMv2 session security if the server supports it; domain controllers refuse LM and NTLM (and accept only NTLMv2) authentication.
  
  Caution The more restrictive NTLM settings are, the more they can affect the ability of clients running Windows XP Professional to communicate over the network with clients running Windows NT 4.0 or earlier.
Network Access: Minimum session security for NTLM SSP based (including secure RPC) clients.

Allows you to configure the following options for Windows XP Professional clients:
- Require message integrity
- Require message confidentiality
- Require NTLMv2 session security
- Require 128-bit encryption
Shutdown: Allow system to be shut down without having to log on.

Determines whether a computer can be turned off without logging on. When this policy is enabled, the Shut Down command is available on the logon screen. When this policy is disabled, the option to turn off the computer does not appear on the logon screen. In this case, users must be able to log on to the computer successfully and have the Shut down the system user right to turn off the system. By default, this option is enabled on workstations and disabled on servers in Local Computer Policy.

Auditing and Troubleshooting Logon and Authentication

You can monitor logon activity in Windows 2000 Server and Windows XP Professional in a very detailed way by enabling success-and-failure auditing in the system’s Audit policy.

Security Options

You can also monitor logon events. The following option is under Computer Configuration\
Windows Settings\Security Settings\Local Policies\Security Options:

Audit: Shut down system immediately if unable to log security audits.

Determines whether the system turns off when it is unable to log security events. If this policy is enabled, the system halts if a security audit cannot be logged. Typically, an event fails to be logged when the security audit log is full and the retention method specified for the security log is either Do Not Overwrite Events or Overwrite Events by Days. By default, this policy is disabled.

Audit Policy

Monitoring logon attempts and account management activity can help you to identify when unwanted logons are taking place. The following audit policy options, which allow you to monitor these activities, can be found under Computer Configuration\Windows Settings\
Security Settings\Local Policies\Audit Policy:

Audit account logon events.

Governs auditing of each instance when a user logs on or logs off another computer than was used to validate the account. For domain controllers, this policy is defined in the Default Domain Controllers Group Policy object. The default setting is No auditing.

If you define this policy setting, you can specify whether to audit successes and failures or not audit the event at all. Success auditing generates an audit entry when an account logon process is successful. Failure auditing generates an audit entry when an attempted account logon process fails. You can select No auditing by defining the policy setting and clearing the Success auditing and Failure auditing check boxes.

You can use this policy to track logon attempts that occur on remote computers. For example, if Success auditing is enabled for account logon events on a domain controller, an entry is logged for each user who is validated against that domain controller even though the user is actually logging on to a workstation joined to the domain.
Audit account management.

Determines whether the system audits each event of account management on a computer. Examples of account management events include:
- A user account or group is created, changed, or deleted.
- A user account is renamed, disabled, or enabled.
- A password is set or changed.
By default, this value is set to No auditing in the Default Domain Controller Group Policy object and in the local policies of workstations and servers. If you define this policy setting, you can specify whether to audit successes or failures or not audit the event type at all. Success auditing generates an audit entry when any account management event is successful. Failure auditing generates an audit entry when any account management event fails. You can select No auditing by defining the policy setting and clearing the Success auditing and Failure auditing check boxes.
Audit logon events.

Determines whether to audit each instance of a user logging on, logging off, or making a network connection to this computer. If you are auditing successful Audit account logon events on a domain controller, workstation logons do not generate logon audits. Only interactive and network logons to the domain controller itself generate logon events. Account logon events are generated on the local computer for local accounts and on the domain controller for network accounts. Logon events are generated where the logon occurs. By default, this value is set to No auditing in the Default Domain Controller Group Policy object and in the local policies of workstations and servers. If you define this policy setting, you can specify whether to audit successes or failures or not audit the event at all. Success auditing generates an audit entry when a successful logon occurs. Failure auditing generates an audit entry when an attempted logon fails. You can select No auditing by defining the policy setting and clearing the Success auditing and Failure auditing check boxes.

Security Event Messages

Auditing logon attempts can generate numerous security events, depending on whether you are auditing successes or failures or both. You can view these audit events with Event Viewer, which maintains logs about program, security, and system events on your computer. The Event Log service starts automatically when you start Windows XP Professional.

To view the error messages generated by your audit events

On the Start menu, click Control Panel.
Click Performance and Maintenance, click Administrative Tools, and then click Event Viewer.

– or –

Start Event Viewer by installing it in a custom MMC console.

Event logs consist of a header, a description of the event, and optional additional data as shown in Figure 16-6.

Figure 16-6 Typical security event message

For more information about security event messages, see the “Security Event Messages” document on the companion CD.

Additional Resources

These resources contain additional information and tools related to this chapter.

“Logon and Authentication” in the Distributed Systems Guide
Chapter 17, “Managing Authorization and Access Control”
Chapter 15, “Connecting Remote Offices,” for more information about authentication by using Remote Access Service
“Security Event Messages” document on the companion CD
Inside Microsoft Windows 2000, Third Edition, by David A. Solomon and Mark E. Russinovich, 2000, Redmond, WA: Microsoft Press
Microsoft Windows 2000 Security Handbook by Jeff Schmidt, Theresa Hadden, Travis Davis, Dave Bixler, and Alexander Kachur, 2000, Indianapolis: Macmillan Computer Publishing.

“Security” in Windows XP Professional Help and Support Center
“Stored User Names and Passwords” in Windows XP Professional Help and Support Center
“Smart Cards” in Windows XP Professional Help and Support Center
“Logon Scripts” in Windows XP Professional Help and Support Center
The Microsoft Windows Security Resource Kit, by Ben Smith and Brian Komar with the Microsoft Security Team, 2003, Redmond, WA: Microsoft Press

Understanding Logon and Authentication

On This Page

Related Information

Overview

New in Windows XP Professional

New In Windows XP Service Pack 2

Improved Network Protection

Improved Memory Protection

Improved E-Mail Security

Improved Browser Security

Credentials and Validation

Credentials

Validation

Security Principals

About Services

Security Identifiers

Access tokens

Security Groups

Types of Logon

Interactive Logon Process

Components Used in Interactive Logon

Using RunAs to Start a Program

To use RunAs to start a program as an administrator

Working with Authentication Protocols

The default authentication protocol in Windows NT 4.0

Protocol Selection

NTLM

Challenge/Response Authentication

Interactive Logon with NTLM

Kerberos V5 Authentication Protocol

Interactive Logons Using Kerberos Authentication

Kerberos Ticket Cache

Kerberos Interoperability

To enable user logon to a non-Windows Kerberos realm

To enable Kerberos authentication for services

Managing Credentials

Blank Password Restrictions

Password Management

To change the password for a user

To perform advanced password-related tasks

Group Policy

Stored User Names and Passwords

To store a new user name and password

To store a Passport ID

To limit use of Stored User Names and Passwords

Backing Up and Restoring Passwords

To back up a password

Smart Cards

Logging On by Using a Smart Card

Automating Logon

To add logon information by editing the registry

Disabling the Welcome Screen

To disable the Welcome screen and require CTRL+ALT+DEL to be used for logons

Setting Authentication Policy Options

Account Policies

Password Policy

Account Lockout Policy

Kerberos Policy

Local Policies

User Rights Assignment

Security Options

Auditing and Troubleshooting Logon and Authentication

Security Options

Audit Policy

Security Event Messages

To view the error messages generated by your audit events

Additional Resources

Related Information

Related Help Topics

Additional resources