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.
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 no longer includes members of the Anonymous group.
Simple 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 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. In order 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 granted to Power Users.
Blank password restriction. To protect users who do not password-protect their accounts, Windows XP Professional accounts without passwords can only be used to log on at the physical computer console.
The following are among the new security related features in Windows XP Professional:
Restricted software policy. 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 Authorization and Access Control and Encrypting File System in this book.
The authentication process has two fundamental parts credentials and validation.
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 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 entity issued your account. If it was issued by:
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 only be used for accessing 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.
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 they can be 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 Authorization and Access Control in this book.
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 to 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 to 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.
The rights and permissions for a user, computer, or group are determined by access control lists (ACLs), 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. Thus, 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.
An access token is recreated every time a security principal logs on, and 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 Authorization and Access Control in this book.
Organizing users and other objects into groups simplifies access administration. Security groups can be described according to their scope (such as Global or Universal) or according to their purpose, rights, and role (such as the Everyone, Administrators, Power Users, or Users groups).
Using Microsoft Windows 2000 Server and Windows XP Professional 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.
There are four types of logon processes in Windows 2000 Server 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, 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 Microsoft Windows 2000 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.
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 only be used to access 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 a Windows 2000 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 Windows 2000 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. |
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 15-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 Account 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.
Kerberos Key Distribution Center (KDC) service. The service used, together with the Kerberos authentication protocol, to authenticate logon requests to Active Directory.
Active Directory. The directory service in Windows 2000 and later. If the logon process is to be authenticated on a Windows 2000 domain controller, the KDC service queries Active Directory to verify the user s credentials.
Figure 15-1: Components involved in interactive logon
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, such as the Trojan horse, and other security risks. To reduce risk, it is recommended that you perform non-administrative 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 15-2 illustrates the RunAs dialog box.
Figure 15-2: RunAs dialog box
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:
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.
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. |