It is easier to manage groups than individual users. The rights granted to a user are based on the user s security group memberships. For this reason, a significant portion of Windows XP Professional operating system security is defined by the default access permissions granted to the Administrators, Power Users, and Users groups. If you already have a managed user environment, or if you want to move to a managed user environment, consider the capabilities and restrictions that apply to each of these security groups. Also, determine which of your users require higher levels of permissions, and which users need fewer permissions.
In the case of an upgrade from Windows NT 4.0 to Windows XP Professional, existing Users automatically become members of the Power Users group. This is because the permissions that apply to Users in Windows 2000 and Windows XP Professional are more restrictive than the permissions that apply to Users in Windows NT 4.0. As a result, after upgrading to Windows XP Professional, certain applications might not run for users who are members of the Users group. Placing Windows NT 4.0 Users in the Power Users group enables them to continue to run non-certified applications.
From a security standpoint, deploying certified applications and placing users only in the Users group is preferred. The default access control settings for the Users group on NTFS systems prevents users (or malicious applications run by users) from compromising the operating system or other users data.
Note | If you need to run non-certified applications but do not want to use the Power Users group, the Compatible security template can be used to open up permissions for Users in a manner that is consistent with the access control requirements of most legacy applications. For more information about the Compatible template, see Security Templates later in this chapter. |
In a clean installation of Windows 2000 or Windows XP Professional, security group membership depends on how users are created:
If the user is a domain user logging on to the Windows XP Professional based computer for the first time, the user becomes a member of the Users (Restricted) group on the local computer.
If the user is local and the account was created with the Local Users and Groups MMC snap-in, then the user becomes a member of the Users (Restricted) group on the local computer.
If the user is local and the account was created with User Accounts in Control Panel, then the user becomes a member of the Power Users (Standard) group on the local computer.
The Administrators, System, and Creator Owner groups are given Full Control on all file system and registry objects that exist at the beginning of GUI-mode setup. The Users group is explicitly granted Write access to specific locations, and Read-only (or less) access to the rest of the system.
Table 16-5 lists the default Write access permissions for Users in Windows XP Professional.
Object | Permission | Comment |
---|---|---|
HKEY_Current_User | Full Control | User s portion of the registry |
%UserProfile% | Full Control | User s Profile directory |
All Users\Shared Documents | Write | Shared Documents location |
All Users\Application Data | Write | Shared Application Data location |
%Windir%\Temp | Synchronize, Traverse, Add File, Add Subdir | Per-computer temp directory. This is a concession made for service-based applications so that Profiles do not need to be loaded in order to get the per-User temp directory of an impersonated user. |
\ (Root Directory) | Create Directory and Create Files under Subdirectories | Per share directory. |
Table 16-6 lists the default user rights for clean-installed workstations.
User Right | Default Workstation |
---|---|
Replace a Process-Level Token | Not assigned. |
Generate Security Audits | Not assigned. |
Log On as a Batch Job | Not assigned. |
Backup Files and Directories | Administrators, Backup Ops |
Bypass Traverse Checking | Administrators, Backup Ops, Power Users, Users, Everyone |
Create a Pagefile | Administrators |
Create Permanent Shared Objects | Not assigned. |
Create a Token Object | Not assigned. |
Debug Programs | Administrators |
Increase Scheduling Priority | Administrators |
Increase Quotas | Administrators |
Log On Interactively | Administrators, Backup Ops, Power Users, Users, Guest |
Load and Unload Device Drivers | Administrators |
Lock Pages in Memory | Not assigned. |
Add workstations to the domain | Not assigned. |
Access this computer from the network | Administrators, Backup Ops, Power Users, Users, Everyone |
Profile a single process | Administrators, Power Users |
Force shutdown from a remote system | Administrators |
Restore files and directories | Administrators, Backup Ops |
Manage audit and security logs | Administrators |
Log On as a service | Not assigned. |
Shut down the system | Administrators, Backup Ops, Power Users, Users |
Modify firmware environment variables | Administrators |
Profile system performance | Administrators |
Change system time | Administrators, Power Users |
Take ownership of files or other objects | Administrators |
Act as part of the operating system | Not assigned. |
Deny Interactive Logon | Not assigned. |
Deny Batch Logon | Not assigned. |
Deny Service Logon | Not assigned. |
Deny Network Logon | Not assigned. |
Remove Computer from a Docking Station | Administrators, Power Users, Users |
Synchronize directory service data | Not assigned. |
Enable computer and user accounts to be trusted for delegation | Not assigned. |
It is recommended that you do not grant access to Anonymous users unless you have specific reasons for doing so. To help you implement this restriction, when a Windows 2000 based system is upgraded to Windows XP Professional, resources with access control lists that grant access to the Everyone group (and not explicitly to the Anonymous Logon group) will no longer be available to Anonymous users.
In most cases, this is an appropriate restriction on Anonymous access. However, you might need to permit Anonymous access in order to support pre-existing applications that require it. In this case, you can explicitly add the Anonymous Logon security group to the access control lists for a specific resource and grant Anonymous users the right to access the computer over the network.
In some situations, however, it might be difficult or impossible to determine which resource on the computer running Windows XP Professional must grant Anonymous access, or to modify the permissions on all of the necessary resources. If this is the case, you might need to force the computer running Windows XP Professional to include the Everyone group in the Anonymous Logon security token. You can do this through the Let Everyone permissions apply to anonymous users local security setting. The security setting can be set to either Enabled or Disabled. The default setting is Disabled.
To change whether Everyone permissions apply to anonymous users
In Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Local Security Policy.
Under Security Settings, double-click Local Policies, and then click Security Options.
Right-click Network Access: Let Everyone permissions apply to anonymous users, and then click Properties.
To allow Anonymous users to be members of the Everyone security group, select Enabled. To revoke the Everyone security group security identifier in the Anonymous user s access token (the Windows XP Professional default), select Disabled.
An increasing number of Windows XP Professional based systems are connected directly to the Internet and participate in home or small business networks rather than in domains. In order to simplify the sharing and security model used in these non-domain environments, network logons performed against unjoined Windows XP Professional based computers are automatically mapped to the Guest account by default. This simplifies the sharing of resources in home or small business networks by eliminating the need to synchronize user names and passwords across all computers in the network. Authenticating users logging on to the network as Guest can provide an additional measure of security for computers connected to the Internet by eliminating the ability to access the computer remotely by using administrative credentials.
Forcing network logons to authenticate as Guest does not affect the following:
Interactive logons. In addition to console logons, this also includes remote access sessions using Terminal Services or Telnet, which are essentially remote occurrences of interactive logon sessions.
Computers that are joined to a domain. This is not the default for Windows XP Professional based computers that are joined to a domain because the domain provides single sign-on capabilities for all computers that are in the domain.
Outbound connections. The authentication and access control settings of the computer that you are attempting to access govern outbound connections.
While forcing network logons to authenticate as Guest can simplify the sharing of resources, it does not expose the detailed access control permissions that Windows XP Professional is capable of and that many advanced users might want. For example, requiring all users to authenticate as Guest means that all users must be granted the same level of permissions to the same resource. You cannot grant Alice Read-only access to one share while granting Bob Modify access to the same share, because both Alice and Bob authenticate as Guest user.
Note | When Guest-only network logons are being used, Read-only and Modify are the only permissions that can be granted to shared files. |
This also means that the actions performed remotely by Alice and Bob cannot be individually audited.
To ensure that remote administration of domain-based computers running Windows XP Professional is possible, you must include a domain-based account in the local administrators group.
You can use the Group Policy snap-in to select between the Classic and Guest-only security models that regulate the use of the Guest account and sharing behavior for Windows XP Professional in stand-alone and workgroup environments. The Classic model allows you to have explicit control over access to resources. Using the Classic model, you can grant different users different types of access to the same resource.
To select the Classic security model
In Microsoft Management Console, open Group Policy and navigate to the Security Settings container.
The file path is Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.
Double-click Network access: Sharing and security model for local accounts, and then click Properties.
Select Classic - local users authenticate as themselves, and then click OK.
The alternative policy setting, Guest only local users authenticate as Guest, requires all users to be treated equally that is, all users authenticate as Guest and thus receive the same level of access to a given resource. When the computer is not joined to a domain, this setting configures the file sharing and security tabs in Windows Explorer to correspond to the sharing and security model in use.
Caution | When using the Guest-only model, any user who can access your computer over the network (including anonymous Internet users) will be able to access your shared resources. Therefore it is important to have a firewall or similar device to protect your computer from unauthorized access. Similarly, when using the Classic model, it is important that local accounts be password protected; otherwise those user accounts can be used by anyone to access shared system resources. |
The Guest-only security model is designed to simplify many details of security management for users, including the procedures used to share files and folders. This is apparent on the Sharing tab of a folder s Properties page. When the Guest-only security model is used, the Sharing tab has only three options:
Share this folder on the network. Allows Everyone Read permissions on the folder and its contents.
Share name. The name of the share on the network.
Allow other users to change my files. Allows Everyone Full Control permissions on folders and Change permissions on files.
You can create a share at the root of the system drive; however, the default sharing model does not change the file permissions on shares created there. The Everyone group only has Read permissions on the root of the system drive, so sharing the root does not provide sufficient permissions for performing the majority of tasks associated with remote administration.
For more information about using the Home Network Wizard to enable the Guest account for sharing files and folders, and ensuring that the personal firewall is properly configured, see Windows XP Professional Help and Support Center and Connecting Remote Offices in this book.