Microsoft Windows XP Professional Resource Kit 2003
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2005
Pages: 338
Pages: 338
Creating and deleting user accounts and defining and using security groups are important security tasks. Defining the security restrictions or permissions that might apply to different groups of users and resources in your network will help to simplify the implementation and management of the permissions and restrictions in your organization. For example, you can create a Printer Operators group and give it precisely delineated administrative control over a finite group of printers.
In order for you to effectively manage security groups in your organization, you need to be familiar with the relationship between accounts, security groups, and built-in security principals. It is also important for you to become familiar with the techniques and tools available for managing group membership.
Every user has an account containing unique credentials that allow the user to access resources on a local computer or domain. Accounts can be local to a computer or domain based. If the account is specific to a local computer, the user will not be able to access network based resources unless the resources have been configured to allow Anonymous access. If the account is domain based, the user will be able to access network resources from the local computer. However, his or her permissions as a user of network resources might be quite different than his or her rights on the local computer. For more information about how accounts are authenticated, see Logon and Authentication in this book.
Two user accounts Administrator and Guest are created automatically when Windows XP Professional is installed. The Administrator account can be used to initially log on and configure the computer. For example, the Administrator can install software, configure printers, join the computer to a domain, and so on. After the computer has been configured, it is necessary to log on as Administrator only to perform administrative tasks.
| Tip | It is best if the Administrator account has a password that meets complexity requirements. You can also rename the Administrator account to make it more difficult for potential hackers to gain access to your system. |
The Guest account can be used to allow different users to log on and access local resources without having to create an account for each user. The Guest account can also be enabled to simplify file and printer sharing with other Windows-based computers that are configured in a workgroup environment. Otherwise, it is recommended that you turn off the Guest account.
Except for the Administrator and Guest accounts, local user accounts are not created automatically when Windows XP Professional is installed. Instead, local user accounts must be created by a member of the Administrators group after the installation is complete. In turn, only domain-level Administrators and Account Operators can create domain accounts.
User accounts, which include information such as the user s name, alias, password, and unique security identifier (SID), enable users to log on to the network or local computer and to access local and network resources. Any domain or local user can then manage permissions on resources on the local computer as long as the user has change permission rights on the resource.
To create, delete, and manage user accounts, administrators can use User Accounts in Control Panel, the Local Users and Groups snap-in to the Microsoft Management Console (if the user account is local to a particular computer) or the Active Directory Users and Computers snap-in (if the account is to participate in a domain). For more information about creating, deleting, and managing user accounts, see Local Users and Groups in Windows XP Professional Help and Support Center.
User accounts are also members of security groups. Depending on the organizational environment, groups used to administer security can be defined by their scope, their purpose, their rights, or their role. The scope of a security group can be a single computer, a single domain, or multiple domains within a forest. In general, Windows 2000 and Windows XP Professional groups fall into one of several categories.
Computer local groups are security groups that are specific to a computer and are not recognized elsewhere in the domain. These groups are a primary means of managing rights and permissions to resources on a local computer.
Domain local groups are local to the domain in which they are created, and thus can be given permissions and user rights only to objects on computers within the domain.
Global groups, which are also created on domain controllers, are used for combining users who share a common access profile based on job function or business role. Global groups can contain user accounts from the same domain and other global groups from the same domain, and can be granted permissions to any computer running Windows NT 4.0, Windows 2000, or Windows XP Professional in any domain in a forest.
Universal groups are used in larger, multi-domain organizations where there is a need to grant access to similar groups of accounts defined in multiple domains in a forest. Universal groups are used only in multiple domain trees or forests that have a global catalog. They can contain groups from any Windows 2000 domain, and can be used to grant access on any computers running Windows 2000 or Windows XP Professional in any domain in the forest.
Built-in security principals, also called special identities, apply to any account that is using the computer in specified ways, such as for Anonymous and Remote logons. Unlike the other types of security groups, built-in security principals do not have specific memberships that you can view or modify, nor do you even see them when you administer groups. However, they are available for use when you assign rights and permissions to group members.
The scope of a group determines where in the network you are able to use the group and assign permissions, and the amount of network traffic the group creates. Using the most appropriate group for a task simplifies administration and, in a domain environment, reduces network traffic by reducing the amount of replication required. The following sections discuss the computer local and special identity groups in greater detail.
Windows XP Professional includes a number of built-in computer local security groups. You can manage the membership of these groups by using the Local Users and Groups snap-in to the Microsoft Management Console (MMC) or by using User Accounts in Control Panel. However, if you are using Windows XP Professional in a stand-alone or workgroup configuration, by using User Accounts in Control Panel you can manage only three of these built-in security groups Administrators, Users (which are also referred to as Limited users), and Guests. If you are using Windows XP Professional in a stand-alone or workgroup configuration and want to use other security groups in addition to these three, you need to manage them from the Local Users and Groups snap-in.
The following sections describe the roles and privileges associated with each computer local security group.
Members of this group have total control of the local computer. The default Windows XP Professional security settings do not restrict administrative access to any registry object or file system object. Administrators can perform any and all functions supported by the operating system. Any right that Administrators do not have by default, they can grant to themselves.
| Warning | If a hacker or virus gains access to a computer while a member of the Administrators group is logged on, the hacker or virus can use the administrator s security context to perform any task on the local computer or, in the case of a network administrator, on the network that the administrator can perform. Impress upon all members of the Administrators group the importance of minimizing the amount of time that they are logged on with these privileges. |
Default members of the local Administrators group include the first account created on a clean installation, existing members of the local Administrators group in an upgrade, and members of the Domain Administrators group.
Administrators can create or delete user accounts and modify permissions for users and resources. Administrative access to the system is ideally used only to:
Install the operating system and components (including drivers for hardware, system services, and so forth).
Install service packs and hot fixes.
Install Windows updates.
Upgrade the operating system.
Repair the operating system.
Configure critical computer-wide operating system parameters.
Take ownership of objects.
In some cases, administrative accounts must also be used to install and run legacy Windows-based applications.
| Tip | Limit the membership of the Administrators group. The greater the number of members in the Administrators group, the greater the number of accounts that a hacker or virus can potentially use to gain access to a computer. |
Members of this group can back up and restore files on the computer, regardless of the permissions that protect those files. They can also log on to the computer and shut it down, but they cannot change security settings.
By default, members of the Guests group are denied access to the application and system event logs. Otherwise, members of the Guests group have the same access rights as members of the Users group. This allows occasional or one-time users to log on to a workstation s built-in Guest account and be granted limited abilities. Members of the Guest group can also shut down the system.
| Note | The Guest account, which is a member of the Guests group by default, is not an authenticated user. When logged on interactively, the Guest account is a member of both the Guests group and the Users group. However, when logged on over the network, the Guest account is not a member of the Users group. |
Members of this group can use helper applications to diagnose system problems. This group, in conjunction with the Support and HelpAssistant accounts, can be used by members of Microsoft Help and Support Center to access the computer from the network and to log on locally.
Members of this group have limited administrative privileges that allow them to configure networking features, such as IP address assignment.
Power Users have less system access than Administrators but more than Users. By default, members of this group have Read/Write permissions to other parts of the system in addition to their own profile.
The default Windows 2000 and later security settings for Power Users are backward compatible with the default security settings for Users in the Windows NT 4.0 operating system. This allows Power Users to run legacy applications that are not certified for Windows 2000 and Windows XP Professional and therefore cannot be run under the more secure Users context.
Power Users can perform many system-wide operations, such as changing system time and display settings, and creating user accounts and shares. Power Users also have Modify access to:
HKEY_LOCAL_MACHINE \Software
Program files
%windir%
%windir%\System32
Although Power Users have Modify access to the %windir% and %windir%\System32 directories, they have Read-only access to the files that are installed in these directories during Windows XP Professional text-mode setup. This allows non-certified applications to write new files into the system directories but prevents Power Users from modifying the Windows XP Professional system files.
While Power Users have the permissions necessary to install most applications, not all application installations will succeed. For example, many applications check for explicit membership in the Administrators group before installing. Other applications attempt to replace operating system files, which Power Users cannot do. Finally, because Power Users cannot install services, they cannot install applications that have a service component.
To install local printer drivers, you need to be a member of the Power Users or Administrators group and have the Load and unload device drivers privilege assigned to you.
To add the Load and unload device drivers privilege for Power Users
In Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Local Security Policy.
In the console tree, double-click Local Policies, and then double-click User Rights Assignment.
In the right pane, right-click the Load and unload device drivers policy, and then click Properties.
Click Add, enter the Power Users group, and then click OK.
Like Users, Power Users are not allowed to access data stored in other users profiles.
Members of this group are allowed to replicate files across a domain.
Members of this group have the right to log on remotely.
Unlike Administrators, Users have limited access on the system. By default, members of the Users group have Read/Write permissions only to their own profile.
| Note | Users are referred to as Limited users in stand-alone or workgroup installations of Windows XP Professional when viewed in User Accounts in Control Panel. |
User security settings are designed to prohibit members of the Users group from compromising the integrity of the operating system and installed applications. Users cannot modify computer-wide registry settings, operating system files, or program files, and they cannot install applications that can be run by other Users. As a result, the Users group is secure to the extent that members also cannot run viruses or Trojan horse applications that affect the operating system or other users of the operating system.
| Note | Users can install peripherals, such as printers, only if the following three conditions are met: The driver package is already present on the system or available via a trusted path, the driver package is signed, and the driver package can be installed without any user interface. For more information about installing printers with Windows XP Professional, see Enabling Printing and Faxing in this book. For more information about installing other peripherals, see Managing Devices and Supporting Mobile Users in this book. |
Only applications that are certified for Windows 2000 or Windows XP Professional run successfully under the secure Users context. Many legacy applications were not designed with operating system security in mind, and as a result, members of the Users groups cannot run them.
The best way to increase the security and manageability of the operating system is to make all end users members of the Users group only, and deploy only applications that are certified for Windows 2000 and Windows XP Professional.
| Warning | To ensure that users can run all the applications they need to run, it is recommended that you test all of your applications at the privilege levels of the users who need to run them. |
Windows XP Professional includes a Program Compatibility wizard that allows Users to run applications in a security context appropriate for legacy applications. Using the Program Compatibility wizard, users can specify that individual applications run in a security context appropriate to the following operating systems:
Microsoft Windows 95
Windows NT 4.0 (Service Pack 5)
Microsoft Windows 98 or Microsoft Windows Millennium Edition (Me)
Windows 2000
| Caution | The Program Compatibility wizard is not intended to make it possible to run operating system specific applications such as anti virus or backup software. Doing so can damage important system files and cause serious problems. |
To open the Program Compatibility wizard
On the desktop, double-click the Run in Compatibility Mode icon.
For more information about using the Program Compatibility wizard, see Windows XP Professional Help and Support Center.
Domain local versions of all except the Power Users and HelpServices groups plus a number of additional server-specific built-in groups are included on domain controllers. Users access to the local computer and network depends primarily on the computer local and domain local security groups to which their account belongs. In other words, users accounts identify who they are, and in some cases permissions and restrictions are set on an individual basis. However, the security groups to which the user belongs are primarily responsible for determining what permissions and restrictions govern their activities on the local computer and on the network.
For more information about the rights and permissions of computer local groups, see Managing User Rights by Using Security Groups later in this chapter.
Built-in security principals apply to any account that is using the computer in a specified way. Built-in security principals allow you to configure security based on the manner in which a resource is being accessed.
The following built-in security principals apply to any user account that is using a computer running Windows XP Professional in the ways specified:
| Note | Several additional built-in security principals are available on computers running Windows 2000 Server. |
Anonymous Logon. Network logons for which credentials are not provided. Users cannot log on anonymously and interactively at the same time.
Authenticated Users. Any user, except a user of the Guest account, who is authenticated locally by a trusted domain controller. This identity provides users with the rights necessary to operate the system as an end user. (The Guest account is never treated as an Authenticated User.)
Creator Group. A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object s current owner.
Creator Owner. A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID of the object s current owner.
Dialup. Any user who accesses the computer over a dial-up connection.
Everyone. All users who access the computer, including Guests and Users from other domains. By default, Everyone includes Authenticated Users and Guests, but not Anonymous logons.
Interactive. Any user who logs on locally.
Network. Any user who logs on over the network.
Remote Interactive Logon. All users who log on to the computer by using a Remote Desktop connection.
Terminal Server User. Any user who accesses the computer by using a terminal server session.
The following security principals apply to any non-human user that is using the computer in a specified way:
Batch. Any batch process that is accessing a resource on the computer.
Local Service. Services that are local to the computer, have no need for extensive local privileges, and do not need authenticated network access. A service running as Local Service has significantly less authority than a service running as System, both locally and on the network. When services running as Local Service access local resources, they do so as members of the local Users group. When they access network resources, they do so as Anonymous users.
Network Service. Services that have no need for extensive local privileges but do need authenticated network access. A service running as Network Service has the same network access as a service running as System, but has significantly reduced local access. When services running as Network Service access local resources, they do so as members of the local Users group. When they access network resources, they do so using the SID assigned to the computer.
Service. Any service.
System. The operating system.
Built-in security principals are used to manage the rights and restrictions that apply to users based on the type of logon session they have initiated. For example, suppose there is a file or share that you want Alice to be able to access but only when she is logged on interactively. You can accomplish this by allowing Alice access to the resource but denying access to requests accompanied by access tokens that include the Dialup security principal.
The following security principles are available when a computer running Windows XP Professional is a member of a domain:
Enterprise Domain Controllers. Includes all domain controllers in a forest of domains.
Restricted. An identity used by a process that is executing in a restricted security context. When code executes at the restricted security level, the Restricted SID is added to the user s access token.
Self. A placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Self, you grant these permissions to the security principal represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal represented by the object.
| Warning | It is recommended that you not remove or change the permissions that pertain to the built-in security principals themselves. |
In Windows NT 4.0, the Everyone group is used as a catchall for file system ACLs, registry ACLs, and user rights. An administrator cannot define who does and does not belong to the Everyone group. Instead, Windows NT 4.0 automatically controls the group membership so that everyone is a member of the Everyone group. If an administrator wants more granular access control, the default ACLs have to be modified in order to remove the Everyone group and add groups that the administrator can control.
In Windows 2000 and later, groups whose membership is automatically configured by the operating system, such as Everyone and Authenticated Users, are not used to assign permissions to file and registry objects. Only those groups whose membership can be controlled by an administrator primarily Users, Power Users, and Administrators are used to assign permissions. When users are members of a group, they automatically have the permissions that have been assigned to that group.
The users that constitute the default memberships in these groups are listed in Table 16-1.
| Local Group | Default Workstation Members |
|---|---|
| Administrators | Administrators |
| Power Users | None |
| Users | Authenticated Users, Interactive Users |
With a clean installation of Windows 2000 and Windows XP Professional, the Authenticated Users group and the Interactive group are added to the Users group. Thus, by default, any non-administrative user accessing a Windows 2000 or Windows XP Professional based system interactively is a member of the Users group. Because the Guest account and Anonymous logons are not considered to be authenticated, these users do not receive User level access over the network.
On upgrades from Windows NT 4.0, the Interactive users group is added to the Power Users group. Because Windows 2000 and Windows XP Professional Power Users have the same file system and registry permissions that Windows NT 4.0 Users have, Interactive users on Windows 2000 and Windows XP Professional based computers that were upgraded from Windows NT 4.0 can run any application that Windows NT 4.0 Users could run.
Deploying certified applications and then removing Interactive Users from the Power Users group secures a Windows XP Professional based workstation that was upgraded from Windows NT 4.0. In this way, non-administrators who log on will be subject to the secure permissions granted to the Users group without having to change any file or registry ACLs.
For more information about security group permissions on systems that have been upgraded see Managing User Rights by Using Security Groups later in this chapter.
SIDs are associated with a user s account, security groups, and security principals. Most of these SIDs are unique. However, the values of some specific SIDs are constant across all systems. These are called well-known SIDs because they identify generic users or generic groups. For example, well-known SIDs identify the following users and groups:
Everyone (S-1-1-0). The identifier authority value for this SID is 1 (World Authority). It has only one subauthority value, 0 (Null relative identifier (RID)).
Creator Owner (S-1-3-0). The generic user Creator Owner is a placeholder in an inheritable ACE. When the ACE is inherited, the system replaces the SID for Creator Owner with the SID for the object s current owner. The identifier authority value for this SID is 3 (Creator Authority). It has only one subauthority value, 0 (Null RID).
Self (S-1-5-10). The generic user Self is a placeholder in an ACE on a User, Group, or Computer object in Active Directory. When you grant permission to Self, you grant it to the security principal represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal represented by the object. The identifier authority for this SID is 5 (NT Authority). It has only one subauthority value, 10 (Self RID).
For information about other well-known SIDs, see the appendix Well-Known Security Identifiers in the Distributed Systems Guide.
The Whoami utility, which is available in the Support/Tools directory on the Windows XP Professional operating system CD, allows you to view the rights and permissions that apply to an individual user. This command-line tool returns the domain or computer name and the user name of the user who is currently logged on to the computer on which the tool is run, as well as the complete contents of the current user s access token. It displays the user name and security identifiers (SIDs), the groups and their SIDs, the privileges and their status (for example, enabled or disabled), and the logon ID.
| Note | To install Whoami, double-click Setup.exe in the Support/Tools directory on the Windows XP Professional operating system CD. Then complete the steps in the Support Tools Setup Wizard to complete the installation. |
To view an individual s user rights and permissions
At the command line, type:
Whoami
You can use the following command-line options to customize the results you receive from whoami:
/ALL. Displays all information in the current access token.
/USER. Displays the user identified in the current access token.
/GROUPS. Displays groups listed in the current access token.
/PRIV. Displays privileges associated with the current access token.
/LOGONID. Displays the logon ID used for the current session.
/SID. Displays the SIDS associated with the current session (must be used in combination with the /USER, /GROUPS, /PRIV, or /LOGONID switches).
/NOVERBOSE. Displays minimal information (must be used in combination with the /USER, /GROUPS, /PRIV, or /LOGONID switches).
For example, on a clean installation of Windows XP Professional, whoami used with the /GROUPS option reveals that an Administrator user belongs to the following default groups:
Everyone
Builtin/Administrators
NT Authority/Users
Local
NT Authority/Interactive
NT Authority/Authenticated Users
A Standard or Power User who runs whoami would generate the following group results:
Everyone
Builtin/Power Users
NT Authority/Users
Local
NT Authority/Interactive
NT Authority/Authenticated Users
A member of the Limited or User group who runs whoami would generate the following group results:
Everyone
NT Authority/Users
Local
NT Authority/Interactive
NT Authority/Authenticated Users
When used with the /USER /SID switches, whoami also allows you to identify the unique security identifiers that are associated with a given logon session, as the following output illustrates:
[User] = "HQ-RES-PRO-01\Limited" S-1-5-21-1454471165-1645522239-1547161642-1009
Nesting groups, or adding groups to other groups, can reduce the number of permissions that need to be assigned to users or groups individually. As you assign members of your organization to global groups in order to apply security settings based on a user s job or business unit, you can nest the groups into the Users and Power Users groups, and in this way apply the security settings that are inherent to Users and Power Users to the members of the global groups contained within them.
For example, Alice and other employees in the Accounting department can be added to a group that is specific to that department. An administrator responsible for the Accounting department can control the membership of this group. The administrator can assign organization-wide security permissions to these users by making the Accounting department security group a member of the Users domain local group. The administrator thus only needs to configure the Accounting department security group to allow members access to the resources specific to the Accounting department.
This also facilitates the management of employees who are reassigned within an organization. It is much easier, for example, to move a user from the Accounting security group to the Marketing group than it is to reconfigure the many ACEs and ACLs required to permit the user to access the resources needed to perform the new job, and remove access to resources the user no longer needs.
The process of creating groups across domains involves the following steps:
Administrators in each domain create global groups and add user accounts that have the same resource requirements to the global groups.
A domain administrator creates a domain local group for each resource that exists within a domain, such as file shares or printers, and then adds the appropriate global groups from each domain to this domain local group.
A domain administrator assigns the appropriate permissions for the resource to the domain local group. Users in each global group receive the required permissions because their global group is a member of the domain local group.
Effectively nesting groups in a multi-domain environment reduces network traffic between domains and simplifies administration in a domain tree. The extent to which you can use nesting in your organization depends on whether you are operating in mixed mode or in native mode. In mixed mode, only one type of nesting is available: global groups can be members of domain local groups. Universal groups do not exist in mixed mode. In native mode, multiple levels of nesting are available. The nesting rules for group memberships for Windows 2000 are listed in Table 16-2.
| Group Scope | Can contain | Can be a member of |
|---|---|---|
| Domain Local Group | User accounts and universal and global groups from any trusted domain. Domain local groups from the same domain. | Domain local groups in the same domain. |
| Global Group | User accounts and global groups from the same domain. | Universal and domain local groups in any domain. Global groups in the same domain. |
| Universal Groups | User accounts, and universal and global groups from any domain. | Domain local or universal groups in any domain. |