Managing accounts is one of your primary tasks as a Microsoft Windows Server 2003 administrator. Chapter 7, discussed computer accounts. This chapter examines user and group accounts. You use user accounts to enable individual users to log on to the network and access network resources. You use group accounts to manage resources for multiple users. The permissions and privileges you assign to user and group accounts determine which actions users can perform, as well as which computer systems and resources they can access.
Although you might be tempted to give users wide access, you need to balance the user’s need for job-related resources with your need to protect sensitive resources or privileged information. For example, you wouldn’t want everyone in the company to have access to payroll data. Consequently, you’d make sure that only those who need that information have access to it.
You control access to network resources with the components of the Windows Server 2003 security model. The key components you need to know about are the ones used for authentication and access controls.
Windows Server 2003 authentication is implemented as a two-part process. That process consists of interactive logon and network authentication. When a user logs on to a computer using a domain account, the interactive logon process authenticates the user’s logon, which confirms the user’s identity to the local computer and grants access to Active Directory directory service. Afterward, whenever the user attempts to access network resources, network authentication is used to determine whether the user has permission to do so.
Windows Server 2003 supports many network authentication protocols. The key protocols are:
Kerberos v5. A standard Internet protocol for authenticating users and systems. It’s the primary authentication mechanism for Windows Server 2003.
NT LAN Manager (NTLM). The primary Microsoft Windows NT authentication protocol. It’s used to authenticate computers in a Windows NT domain.
Note
Windows Server 2003 web and application services support authentication using Anonymous Authentication, Basic Authentication, Integrated Windows Authentication, Digest Authentication, and .NET Passport Authentication. With Microsoft Internet Information Services (IIS) 6.0, Passport authentication enables you to use Active Directory information to authenticate Internet, intranet, and extranet users. For details, see Chapter 7, "Enhancing Web Server Security," of the Microsoft IIS 6.0 Administrator’s Pocket Consultant (Microsoft Press, 2003).
A key feature of the Windows Server 2003 authentication model is that it supports Single Sign-On. Single Sign-On works in the following way:
A user logs on to the domain by using a logon name and password or by inserting a smart card into a card reader.
The interactive logon process authenticates the user’s access. With a local account, the credentials are authenticated locally and the user is granted access to the local computer. With a domain account, the credentials are authenticated in Active Directory and the user has access to local and network resources.
Now the user can authenticate to any computer in the domain through the network authentication process. With domain accounts, the network authentication process typically is automatic (through Single Sign-On). With local accounts, on the other hand, users must provide a user name and password every time they access a network resource.
Windows Server 2003 R2 features Active Directory Federation Services (ADFS), which extends Single Sign-On to trusted resources on the Internet. Using ADFS, organizations can extend their existing Active Directory infrastructure to provide access to trusted Internet resources, which can include third parties as well as geographically separated units of the same organizations. After you configure federated servers, users at the organization can sign on once to the organization’s network and are then automatically logged on to trusted Web applications hosted by partners on the Internet. Federated Web Single Sign-On uses Federated Authorization for seamless access. In addition to user identity and account information, security tokens used in Federated Authorization include authorization claims that detail user authorization and specific application entitlement.
Active Directory is object-based. Users, computers, groups, shared resources, and many other entities are all defined as objects. Access controls are applied to these objects with security descriptors. Security descriptors do the following:
List the users and groups that are granted access to objects
Specify permissions the users and groups have been assigned
Track events that should be audited for objects
Define ownership of objects
Individual entries in the security descriptor are referred to as access control entries (ACEs). Active Directory objects can inherit ACEs from their parent objects. This means that permissions for a parent object can be applied to a child object. For example, all members of the Domain Admins group inherit permissions granted to this group.
When working with ACEs, keep the following points in mind:
ACEs are created with inheritance enabled by default.
Inheritance takes place immediately after the ACE is written.
All ACEs contain information specifying whether the permission is inherited or explicitly assigned to the related object.
Windows Server 2003 provides user accounts and group accounts (of which users can be a member). User accounts are designed for individuals. Group accounts are designed to make the administration of multiple users easier. Although you can log on with user accounts, you can’t log on with a group account. Group accounts are usually referred to simply as groups.
Real World
Windows Server 2003 supports the InetOrgPerson object. Essentially, this object is the same as a user object and you could use it as such. However, the real purpose for the InetOrgPerson object is to allow for compatibility and transition from third-party X.500 and Lightweight Directory Access Protocol (LDAP) directory services that use this object to represent users. If you are migrating from a third-party directory service and end up with many InetOrgPerson objects, don’t worry. These objects can be used as security principals just like user accounts. The InetOrgPerson object is fully enabled only when working in Windows Server 2003 operations mode. In this mode, you can set passwords for InetOrgPerson objects and you can change the object class if desired. When you change the object class, the InetOrgPerson object is converted to a user object and from then on is listed as the User type in Active Directory Users And Computers.
In Windows Server 2003, two types of user accounts are defined:
Domain user accounts. User accounts defined in Active Directory are called domain user accounts. Through Single Sign-On, domain user accounts can access resources throughout the domain. You create domain user accounts in Active Directory Users And Computers.
Local user accounts. User accounts defined on a local computer are called local user accounts. Local user accounts have access to the local computer only, and they must authenticate themselves before they can access network resources. You create local user accounts with the Local Users And Groups utility.
Note
In a domain, only member servers and workstations have local user and group accounts. On the initial domain controller for a domain, these accounts are moved from the local Security Account Manager (SAM) database to Active Directory and then become domain accounts.
All user accounts are identified with a logon name. In Windows Server 2003, this logon name has two parts:
User name. The text label for the account
User domain or workgroup. The workgroup or domain where the user account exists
For the user wrstanek, whose account is created in the microsoft.com domain, the full logon name for Windows Server 2003 is [email protected]. The pre-Windows 2000 logon name is MICROSOFTwrstanek.
When working with Active Directory, you might also need to specify the fully qualified domain name (FQDN) for a user. The FQDN for a user is the combination of the Domain Name System (DNS) domain name, the container or organizational unit that contains the user, and the user name. For the user microsoft.comuserswrstanek, microsoft.com is the DNS domain name, users is the container or organizational unit location, and wrstanek is the user name.
User accounts can also have passwords and public certificates associated with them. Passwords are authentication strings for an account. Public certificates combine a public and private key to identify a user. You log on with a password interactively. You log on with a public certificate using a smart card and a smart card reader.
Although Windows Server 2003 displays user names to describe privileges and permissions, the key identifiers for accounts are security identifiers (SIDs). SIDs are unique identifiers that are generated when you create accounts. Each account’s SID consists of the domain’s security ID prefix and a unique relative ID, which is allocated by the relative ID master.
Windows Server 2003 uses these identifiers to track accounts independently from user names. SIDs serve many purposes. The two most important ones are to allow you to change user names easily and to allow you to delete accounts without worrying that someone might gain access to resources simply by recreating an account with the same name.
When you change a user name, you tell Windows Server 2003 to map a particular SID to a new name. When you delete an account, you tell Windows Server 2003 that a particular SID is no longer valid. Afterward, even if you create an account with the same user name, the new account won’t have the same privileges and permissions as the previous one. That’s because the new account will have a new SID.
In addition to user accounts, Windows Server 2003 provides groups. Generally speaking, you use groups to grant permissions to similar types of users and to simplify account administration. If a user is a member of a group that can access a resource, that particular user can access the same resource. Thus, you can give a user access to various work-related resources just by making the user a member of the correct group. Note that although you can log on to a computer with a user account, you can’t log on to a computer with a group account.
Because different Active Directory domains might have groups with the same name, groups are often referred to by domaingroupname, such as workgmarketing for the gmarketing group in the work domain. When you work with Active Directory, you might also need to specify the FQDN for a group. The FQDN for a group is the concatenation of the DNS domain name, the container or organizational unit location, and the group name. For the group microsoft.comusersgmarketing, microsoft.com is the DNS domain name, users is the container or organizational unit location, and gmarketing is the group name.
Real World
Employees in a marketing department probably need access to all marketing-related resources. Instead of granting access to these resources individually, you could make the users members of a marketing group. That way they automatically obtain the group’s privileges. Later, if a user moves to a different department, you simply remove the user from the group, thus revoking all access permissions. Compared to having to revoke access for each individual resource, this technique is pretty easy—so, you’ll want to use groups whenever possible.
In Windows Server 2003, there are three types of groups:
Local groups. Groups that are defined on a local computer. Local groups are used on the local computer only. You create local groups with the Local Users And Groups utility.
Security groups. Groups that can have security descriptors associated with them. You define security groups in domains using Active Directory Users And Computers.
Distribution groups. Groups that are used as e-mail distribution lists. They can’t have security descriptors associated with them. You define distribution groups in domains using Active Directory Users And Computers.
In Active Directory, groups can have different scopes–domain local, built-in local, global, and universal. That is, the groups have different areas in which they’re valid.
Domain local groups. Groups primarily used to assign access permissions to resources within a single domain. Domain local groups can include members from any domain in the forest and from trusted domains in other forests. Typically, global and universal groups are members of domain local groups.
Built-in local groups. Groups with a special group scope that have domain local permissions and, for simplicity, are often included in the term domain local groups. The difference between built-in local groups and other groups is that you can’t create or delete built-in local groups. You can only modify built-in local groups. References to domain local groups apply to built-in local groups unless otherwise noted.
Global groups. Groups that are used primarily to define sets of users or computers in the same domain that share a similar role, function, or job. Members of global groups can include only accounts and groups from the domain in which they’re defined.
Universal groups. Groups that are used primarily to define sets of users or computers that should have wide permissions throughout a domain or forest. Members of universal groups include accounts, global groups, and other universal groups from any domain in the domain tree or forest. Security universal groups are available only when Active Directory is running in Windows 2000 native operations mode or in Windows Server 2003 operations mode. Distribution universal groups are available in any domain functional mode.
Best Practices
Universal groups are very useful in large enterprises where you have multiple domains. If you plan properly, you can use universal groups to simplify system administration. Members of universal groups shouldn’t change frequently. Each time you change the members of a universal group, you need to replicate these changes to all the global catalogs in the domain tree or forest. To cut down on changes, assign other groups to the universal group rather than user accounts. For more information, see the section in this chapter entitled "When to Use Domain Local, Global, and Universal Groups."
When you work with groups, there are many things you can and can’t do based on the group’s scope. A quick summary of these items is shown in Table 8-1. For complete details on creating groups, see Chapter 9.
Table 8-1. How Group Scope Affects Group Capabilities
Group Capability | Domain Local Scope | Global Scope | Universal Scope |
|---|---|---|---|
Windows Server 2003/Windows 2000 Native Mode | Accounts, global groups, and universal groups from any domain; domain local groups from the same domain only | Accounts and global groups from the same domain only | Accounts from any domain, as well as global and universal groups from any domain |
Windows 2000 Mixed Mode | Accounts and global groups from any domain | Only accounts from the same domain | Security universal groups can’t be created in mixed-mode domains |
Member Of | Can be put into other domain local groups and assigned permissions only in the same domain | Can be put into other groups and assigned permissions in any domain | Can be put into other groups and assigned permissions in any domain |
Scope Conversion | Can be converted to universal scope, provided it doesn’t have as its member another group having domain local scope | Can be converted to universal scope, provided it’s not a member of any other group having global scope | Can’t be converted to any other group scope |
As with user accounts, Windows Server 2003 uses unique SIDs to track group accounts. This means that you can’t delete a group account, recreate it, and then expect all the permissions and privileges to remain the same. The new group will have a new SID, and all the permissions and privileges of the old group will be lost.
Windows Server 2003 creates a security token for each user logon. The security token specifies the user account ID and the SIDs of all the security groups to which the user belongs. The token’s size grows as the user is added to additional security groups. This has several consequences:
The security token must be passed to the user logon process before logon can be completed. Because of this, as the number of security group memberships grows, the logon process takes longer.
To determine access permissions, the security token is sent to every computer that the user accesses. Because of this, the size of the security token has a direct impact on the network traffic load.
Domain local, global, and universal groups provide a lot of options for configuring groups in the enterprise. Although these group scopes are designed to simplify administration, poor planning can make these group scopes your worst administration nightmare. Ideally, you’ll use group scopes to help you create group hierarchies that are similar to your organization’s structure and the responsibilities of particular groups of users. The best uses for domain local, global, and universal groups are as follows:
Domain local groups. Groups with domain local scope have the smallest extent. Use groups with domain local scope to help you manage access to resources, such as printers and shared folders.
Global groups. Use groups with global scope to help you manage user and computer accounts in a particular domain. Then you can grant access permissions to a resource by making the group with global scope a member of the group with domain local scope.
Universal groups. Groups with universal scope have the largest extent. Use groups with universal scope to consolidate groups that span domains. Normally, you do this by adding global groups as members. Now when you change membership of the global groups, the changes aren’t replicated to all the global catalogs. This is because the membership of the universal group didn’t change.
Tip
If your organization doesn’t have two or more domains, you don’t really need to use universal groups. Instead, build your group structure with domain local and global groups. Then, if you ever bring another domain into your domain tree or forest, you can easily extend the group hierarchy to accommodate the integration.
To put this in perspective, consider the following scenario. Say that you have branch offices in Seattle, Chicago, and New York. Each office has its own domain, which is a part of the same domain tree or forest. These domains are called Seattle, Chicago, and NY. You want to make it easy for any administrator (from any office) to manage network resources, so you create a group structure that is very similar at each location. Although the company has marketing, IT, and engineering departments, let’s focus on the structure of the marketing department. At each office, members of the marketing department need access to a shared printer called MarketingPrinter and a shared data folder called MarketingData. You also want users to be able to share and print documents. For example, Bob in Seattle should be able to print documents so that Ralph in New York can pick them up on his local printer, and Bob should also be able to access the quarterly report on the shared folder at the New York office.
To configure the groups for the marketing departments at the three offices, you’d perform these steps:
Start by creating global groups for each marketing group. In the Seattle domain, create a group called GMarketing and add the members of the Seattle marketing department to it. In the Chicago domain, create a group called GMarketing and add the members of the Chicago marketing department to it. In the NY domain, create a group called GMarketing and add the members of the New York marketing department to it.
In each location, create domain local groups that grant access to the shared printers and shared folders. Call the printer group LocalMarketingPrinter. Call the New York shared folder group LocalMarketingData. The Seattle, Chicago, and NY domains should each have their own local groups.
Create a group with universal scope called UMarketing on the domain at any branch office. Add SeattleGMarketing, ChicagoGMarketing, and NYGMarketing to this group.
Add UMarketing to the LocalMarketingPrinter and LocalMarketingData groups at each office. Marketing users should now be able to share data and printers.
When you install Windows Server 2003, the operating system installs default users and groups. These accounts are designed to provide the basic setup necessary to grow your network. Three types of default accounts are provided:
Built-In. User and group accounts installed with the operating system, applications, and services
Predefined. User and group accounts installed with the operating system
Implicit. Special groups created implicitly when accessing network resources; also known as special identities
Note
Although you can modify the default users and groups, you can’t delete default users and groups created by the operating system. The reason you can’t delete these accounts is that you wouldn’t be able to recreate them. The SIDs of the old and new accounts wouldn’t match, and the permissions and privileges of these accounts would be lost.
Built-in user accounts have special purposes in Windows Server 2003. All Windows Server 2003 systems have three built-in user accounts:
LocalSystem. LocalSystem is a pseudo-account for running system processes and handling system-level tasks. This account grants the logon right Log On As A Service. Most services run under the LocalSystem account. In some cases, these services have the privilege to interact with the desktop. Services that need alternative privileges or logon rights run under the LocalService or NetworkService accounts.
LocalService. LocalService is a pseudo-account for running services that need additional privileges and logon rights on a local system. Services that run under this account are granted the right to Log On As A Service and the privileges Change The System Time and Generate Security Audits by default. Services that run as LocalService include Alerter, Messenger, Remote Registry, Smart Card, Smart Card Helper, SSDP Discovery Service, TCP/IP NetBIOS Helper, Uninterruptible Power Supply, and WebClient.
NetworkService. NetworkService is a pseudo-account for running services that need additional privileges and logon rights on a local system and the network. As with LocalService, services that run under the NetworkService account are granted the right to Log On As A Service and the privileges Change The System Time and Generate Security Audits. Services that run as NetworkService include Distributed Transaction Coordinator, DNS Client, Performance Logs and Alerts, and Remote Procedure Call (RPC) Locator.
When you install add-ons or other applications on a server, other default accounts might be installed. You can usually delete these accounts.
When you install IIS, you might find several new accounts, including IUSR_hostname and IWAM_hostname, where hostname is the computer name. The IUSR_hostname account is the built-in account for anonymous access to IIS. IIS uses the IWAM_hostname account to start out-of-process applications. These accounts are defined in Active Directory when they’re configured on a domain. However, they’re defined as local users when they’re configured on a stand-alone server or workstation. Another built-in account that you might see is TSInternetUser. Terminal Services uses this account.
Several predefined user accounts are installed with Windows Server 2003: Administrator, ASPNET, Guest, and Support. With member servers, predefined accounts are local to the individual system they’re installed on.
Predefined accounts have counterparts in Active Directory. These accounts have domain-wide access and are completely separate from the local accounts on individual systems.
Administrator is a predefined account that provides complete access to files, directories, services, and other facilities. You can’t delete or disable this account. In Active Directory, the Administrator account has domain-wide access and privileges. Otherwise, the Administrator account generally has access only to the local system. Although files and directories can be protected from the Administrator account temporarily, the Administrator account can take control of these resources at any time by changing the access permissions. See Chapter 13.
Security
To prevent unauthorized access to the system or domain, be sure to give the account an especially secure password. Also, because this is a known Windows account, you might want to rename the account as an extra security precaution. If you rename the original Administrator account, you might also want to create a dummy Administrator account. This dummy account should have no permissions, rights, or privileges, and you should disable it.
You usually won’t need to change the basic settings for this account. However, you might need to change its advanced settings, such as membership in particular groups. By default, the Administrator account for a domain is a member of these groups: Administrators, Domain Admins, Domain Users, Enterprise Admins, Group Policy Creator Owners, and Schema Admins. You’ll find more information on these groups in the next section.
Real World
In a domain environment, you’ll use the local Administrator account primarily to manage the system when you first install it. This allows you to set up the system without getting locked out. You probably won’t use the account once the system has been installed. Instead, you’ll probably want to make your administrators members of the Administrators group. This ensures that you can revoke administrator privileges without having to change the passwords for all the Administrator accounts.
For a system that’s part of a workgroup where each individual computer is managed separately, you’ll typically rely on this account anytime you need to perform your system administration duties. Here, you probably won’t want to set up individual accounts for each person who has administrative access to a system. Instead, you’ll use a single Administrator account on each computer.
The ASPNET account is used by the built-in .NET framework and is designed so that the account can run ASP.NET worker processes. The account is a member of the Domain Users Group and, as such, the account has all the same privileges as ordinary users in the domain.
Guest is designed for users who need one-time or occasional access. Although guests have limited system privileges, you should be very careful about using this account. Whenever you use this account, you open the system to potential security problems. The risk is so great that the account is initially disabled when you install Windows Server 2003.
The Guest account is a member of Domain Guests and Guests by default. It is important to note that the Guest account–like all other named accounts–is also a member of the implicit group Everyone. The Everyone group typically has access to files and folders by default. The Everyone group also has a default set of user rights.
The Support account is used by the built-in Help And Support service. The account is a member of the HelpServicesGroup and Domain Users. The account has the right to log on as a batch job. This user rights assignment allows the Support account to execute batch updates.
Built-in groups are installed with all Windows Server 2003 systems. Use built-in and predefined groups to grant a user the group’s privileges and permissions. You do this by making the user a member of the group. For example, you give a user administrative access to the system by making a user a member of the local Administrators group. You give a user administrative access to the domain by making a user a member of the domain local Administrators group in Active Directory.
In Windows NT, implicit groups were assigned implicitly during logon and were based on how a user accessed a network resource. For example, if a user accessed a resource through interactive logon, the user was automatically a member of the implicit group called Interactive. In Windows 2000 and Windows Server 2003, the object-based approach to the directory structure changes the original rules for implicit groups. Although you still can’t view the membership of special identities, you can grant membership in implicit groups to users, groups, and computers.
To reflect the new role, implicit groups are also referred to as special identities. A special identity is a group whose membership can be set implicitly, such as during logon, or explicitly through security access permissions. As with other default groups, the availability of a specific implicit group depends on the current configuration. Use Table 8-2 to determine the availability of the various implicit groups. Implicit groups are discussed later in this chapter.
Table 8-2. Availability of Implicit Groups Based on the Type of Network Resource
Group Name | Active Directory Domain | Windows Server 2003 Member Server |
|---|---|---|
Anonymous Logon | Yes | Yes |
Authenticated Users | Yes | Yes |
Batch | Yes | Yes |
Creator Group | Yes | Yes |
Creator Owner | Yes | Yes |
Dialup | Yes | Yes |
Enterprise Domain Controllers | Yes | No |
Everyone | Yes | Yes |
Interactive | Yes | Yes |
Local Service | No | Yes |
Network | Yes | Yes |
Network Service | No | Yes |
Proxy | Yes | No |
Remote Interactive Logon | No | Yes |
Restricted | Yes | No |
Self | Yes | No |
Service | Yes | Yes |
System | Yes | Yes |
Terminal Server User | Yes | Yes |
When you set up a user account, you can grant the user specific capabilities. You generally assign these capabilities by making the user a member of one or more groups, thus giving the user the capabilities of these groups. You withdraw capabilities by removing group membership.
In Windows Server 2003, you can assign various types of capabilities to an account. These capabilities include:
Privileges. A type of user right that grants permissions to perform specific administrative tasks. You can assign privileges to both user and group accounts. An example of a privilege is the ability to shut down the system.
Logon rights. A type of user right that grants logon permissions. You can assign logon rights to both user and group accounts. An example of a logon right is the ability to log on locally.
Built-in capabilities. A type of user right that is assigned to groups and includes the group’s automatic capabilities. Built-in capabilities are predefined and unchangeable, but they can be delegated to users with permission to manage objects, organizational units, or other containers. An example of a built-in capability is the ability to create, delete, and manage user accounts. This capability is assigned to administrators and account operators. Thus, if a user is a member of the Administrators group, the user can create, delete, and manage user accounts.
Access permissions. A type of user right that defines the operations that can be performed on network resources. You can assign access permissions to users, computers, and groups. An example of an access permission is the ability to create a file in a directory. Access permissions are discussed in Chapter 13.
As an administrator, you’ll be dealing with account capabilities every day. To help track built-in capabilities, refer to the following sections. Keep in mind that although you can’t change a group’s built-in capabilities, you can change a group’s default rights. For example, an administrator could revoke network access to a computer by removing a group’s right to access the computer from the network.
A privilege is a type of user right that grants permissions to perform a specific administrative task. You assign privileges through group policies, which can be applied to individual computers, organizational units, and domains. Although you can assign privileges to both users and groups, you’ll usually want to assign privileges to groups. In this way, users are automatically assigned the appropriate privileges when they become members of a group. Assigning privileges to groups also makes it easier to manage user accounts.
Table 8-3 provides a brief summary of each of the privileges that you can assign to users and groups. To learn how to assign privileges, see Chapter 9.
Table 8-3. Windows Server 2003 Privileges for Users and Groups
Privilege | Description |
|---|---|
Act As Part Of The Operating System | Allows a process to authenticate as any user and gain access to resources as any user. Processes that require this privilege should use the LocalSystem account, which already has this privilege. |
Add Workstations To Domain | Allows users to add computers to the domain. |
Adjust Memory Quotas For A Process | Allows users to adjust process-based memory usage quotas. |
Back Up Files And Directories | Allows users to back up the system regardless of the permissions set on files and directories. |
Bypass Traverse Checking | Allows users to pass through directories while navigating an object path regardless of permissions set on the directories. The privilege doesn’t allow the user to list directory contents. |
Change The System Time | Allows users to set the time for the system clock. |
Create A Pagefile | Allows users to create and change paging file size for virtual memory. |
Create A Token Object | Allows processes to create token objects that can be used to gain access to local resources. Processes that require this privilege should use the LocalSystem account, which already has this privilege. |
Create Permanent Shared Objects | Allows processes to create directory objects in the Windows 2000, Windows XP Professional, or Windows Server 2003 object manager. Most components already have this privilege, and it’s not necessary to specifically assign it. |
Debug Programs | Allows users to perform debugging. |
Enable User And Computer Accounts To Be Trusted For Delegation | Allows users and computers to change or apply the trusted for delegation setting, provided they have write access to the object. |
Force Shutdown Of A Remote System | Allows users to shut down a computer from a remote location on the network. |
Generate Security Audits | Allows processes to make security log entries for auditing object access. |
Impersonate A Client After Authentication | Allows Web applications to act as clients during processing of requests. Services and users can also act as clients. |
Increase Scheduling Priority | Allows processes to increase the scheduling priority assigned to another process, provided they have write access to the process. |
Load And Unload Device Drivers | Allows users to install and uninstall Plug and Play device drivers. This doesn’t affect device drivers that aren’t Plug and Play, which can only be installed by administrators. |
Lock Pages In Memory | Allows processes to keep data in physical memory, preventing the system from paging data to virtual memory on disk. |
Manage Auditing And Security Log | Allows users to specify auditing options and access the security log. You must turn on auditing in the group policy first. |
Modify Firmware Environment Values | Allows users and processes to modify system environment variables. |
Perform Volume Maintenance Tasks | Allows administration of removable storage, disk defragmenter, and disk management. |
Profile A Single Process | Allows users to monitor the performance of nonsystem processes. |
Profile System Performance | Allows users to monitor the performance of system processes. |
Remove Computer From Docking Station | Allows undocking a laptop and removing it from the network. |
Replace A Process Level Token | Allows processes to replace the default token for subprocesses. |
Restore Files And Directories | Allows users to restore backed-up files and directories, regardless of the permissions set on files and directories. |
Shut Down The System | Allows users to shut down the local computer. |
Synchronize Directory Service Data | Allows users to synchronize directory service data on domain controllers. |
Take Ownership Of Files Or Other Objects | Allows users to take ownership of files and any other Active Directory objects. |
A logon right is a type of user right that grants logon permissions. You can assign logon rights to both user and group accounts. As with privileges, you assign logon rights through group policies, and you’ll usually want to assign logon rights to groups rather than to individual users.
Table 8-4 provides a brief summary of each of the logon rights that you can assign to users and groups. To learn how to assign logon rights, see Chapter 9.
Table 8-4. Windows Server 2003 Logon Rights for Users and Groups
Description | |
|---|---|
Access This Computer From The Network | Grants remote access to the computer. |
Allow Logon Locally | Grants permission to log on at the computer’s keyboard. On servers, this right is restricted by default and only members of these groups can log on locally: Administrators, Account Operators, Backup Operators, Print Operators, and Server Operators. |
Allow Logon Through Terminal Services | Grants access through Terminal Services; necessary for remote assistance and remote desktop. |
Deny Access To This Computer From The Network | Denies remote access to the computer through network services. |
Deny Logon As Batch Job | Denies the right to log on through a batch job or script. |
Deny Logon As Service | Denies the right to log on as a service. |
Deny Logon Locally | Denies the right to log on to the computer’s keyboard. |
Deny Logon Through Terminal Services | Denies the right to log on through Terminal Services. |
Log On As A Batch Job | Grants permission to log on as a batch job or script. |
Log On As A Service | Grants permission to log on as a service. LocalSystem account has this right. A service that runs under a separate account should be assigned this right. |
The built-in capabilities for groups in Active Directory are fairly extensive. The tables that follow summarize the most common capabilities that are assigned by default. Table 8-5 shows the default user rights for groups in Active Directory domains. This includes both privileges and logon rights. Note that any action that’s available to the Everyone group is available to all groups, including the Guests group. This means that although the Guests group doesn’t have explicit permission to access the computer from the network, a member of the Guests group can still access the system because the Everyone group has this right.
Table 8-5. Default User Rights for Groups in Active Directory
User Right | Groups Assigned |
|---|---|
Access This Computer From The Network | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, IWAM_host, IUSR_host, Pre-Windows 2000 Compatible Access |
Add Workstations To Domain | Authenticated Users |
Adjust Memory Quotas For A Process | Administrators, IWAM_host, Local Service, Network Service |
Allow Logon Locally | Account Operators, Administrators, Backup Operators, IUSR_host, Print Operators, Server Operators |
Back Up Files And Directories | Administrators, Server Operators, Backup Operators |
Bypass Traverse Checking | Everyone, Authenticated Users, Administrators, Pre-Windows 2000 Compatible Access |
Change The System Time | Administrators, Server Operators |
Create A Pagefile | Administrators |
Debug Programs | Administrators |
Deny Access To This Computer From The Network | Support |
Deny Logon Locally | Support |
Enable Computer And User Accounts To Be Trusted For Delegation | Administrators |
Force Shutdown From A Remote System | Administrators, Server Operators |
Generate Security Audits | Local Service, Network Service |
Increase Quotas | Administrators |
Increase Scheduling Priority | Administrators |
Load And Unload Device Drivers | Administrators, Print Operators |
Log On As Batch Job | Administrator, IUSR_host, IWAM_host, Support, Local Service, IIS_WPG |
Log On As A Service | Network Service |
Manage Auditing And Security Log | Administrators |
Modify Firmware Environment Variables | Administrators |
Profile Single Process | Administrators |
Profile System Performance | Administrators |
Remove Computer From Docking Station | Administrators |
Replace A Process Level Token | IWAM_host, Local Service, Network Service |
Restore Files And Directories | Administrators, Backup Operators, Server Operators |
Shut Down The System | Account Operators, Administrators, Backup Operators, Print Operators, Server Operators |
Take Ownership Of Files Or Other Objects | Administrators |
Table 8-6 shows the default user rights for local groups on member servers. Again, this includes both privileges and logon rights. Note that on these systems, Power Users have privileges that normal users don’t.
Table 8-6. Default User Rights for Workgroups and Member Servers
User Right | Groups Assigned |
|---|---|
Adjust Memory Quotas For A Process | Administrators, Local Service, Network Service, IWAM_host |
Allow Logon Through Terminal Services | Administrators, Remote Desktop Users |
Back Up Files And Directories | Administrators, Backup Operators |
Bypass Traverse Checking | Everyone, Administrators, Users, Power Users, Backup Operators |
Change The System Time | Administrators, Power Users |
Create A Pagefile | Administrators |
Debug Programs | Administrators |
Deny Access To The Computer From The Network | Support |
Deny Logon Locally | Support |
Deny Logon Through Terminal Services | ASPNET |
Force Shutdown From A Remote System | Administrators |
Generate Security Audits | Local Service, Network Service |
Impersonate A Client After Authentication | Administrators, ASPNET, IIS_WPG, Service |
Increase Scheduling Priority | Administrators |
Load And Unload Device Drivers | Administrators |
Log On As A Batch Job | ASPNET, IIS_WPG, IUSR_host, IWAM_host, Local Service |
Log On As Service | ASPNET, Network Service |
Log On Locally | IUSR_host, Administrators, Users, Power Users, Backup Operators |
Manage Auditing And Security Log | Administrators |
Modify Firmware Environment Variables | Administrators |
Perform Volume Maintenance Tasks | Administrators |
Profile Single Process | Administrators, Power Users |
Profile System Performance | Administrators |
Remove Computer From Docking Station | Administrators, Power Users |
Replace A Process Level Token | Local Service, Network Service, IWAM_host |
Restore Files And Directories | Administrators, Backup Operators |
Shut Down The System | Administrators, Backup Operators, Power Users |
Take Ownership Of Files Or Other Objects | Administrators |
Table 8-7 summarizes capabilities that you can delegate to other users and groups. As you study the table, note that restricted accounts include the Administrator user account, the user accounts of administrators, and the group accounts for Administrators, Server Operators, Account Operators, Backup Operators, and Print Operators. Because these accounts are restricted, Account Operators can’t create or modify them.
Table 8-7. Other Capabilities for Built-In and Local Groups
Task | Description | Group Normally Assigned |
|---|---|---|
Assign User Rights | Allows user to assign user rights to other users | Administrators |
Create, Delete, And Manage User Accounts | Allows user to administer domain user accounts | Administrators, Account Operators |
Modify The Membership Of A Group | Allows user to add and remove users from domain groups | Administrators, Account Operators |
Create And Delete Groups | Allows user to create new group and delete existing groups | Administrators, Account Operators |
Reset Passwords On User Accounts | Allows user to reset passwords on user accounts | Administrators, Account Operators |
Read All User Information | Allows user to view user account information | Administrators, Server Operators, Account Operators |
Manage Group Policy Links | Allows user to apply existing group policies to sites, domains, and organizational units for which they have write access to the related objects | Administrators |
Manage Printers | Allows user to modify printer settings and manage print queues | Administrators, Server Operators, Printer Operators |
Create And Delete Printers | Allows user to create and delete printers | Administrators, Server Operators, Printer Operators |
The default group accounts are designed to be versatile. By assigning users to the correct groups, you can make managing your Windows Server 2003 workgroup or domain a lot easier. Unfortunately, with so many groups, understanding the purpose of each isn’t easy. To help, let’s take a closer look at groups used by administrators and groups that are implicitly created.
An administrator is someone who has wide access to network resources. Administrators can create accounts, modify user rights, install printers, manage shared resources, and more. The main administrator groups are Administrators, Domain Admins, and Enterprise Admins, as compared in Table 8-8.
Table 8-8. Administrator Groups Overview
Administrator Group Type | Network Environment | Group Scope | Membership | Account Administration |
|---|---|---|---|---|
Administrators | Active Directory domains | Domain Local | Administrator, Domain Admins, Enterprise Admins | Administrators |
Administrators | Workgroups, computers not part of a domain | Local | Administrator | Administrators |
Domain Admins | Active Directory domains | Global | Administrator | Administrators |
Enterprise Admins | Active Directory domains | Global or Universal | Administrator | Administrators |
Tip
The local group Administrator and the global groups Domain Admins and Enterprise Admins are members of the Administrators group. The Administrator user membership is used to access the local computer. The Domain Admins membership allows other administrators to access the system from elsewhere in the domain. The Enterprise Admins membership allows other administrators to access the system from other domains in the current domain tree or forest. To prevent enterprise-wide access to a domain, you can remove Enterprise Admins from this group.
Administrators is a local group that provides full administrative access to an individual computer or a single domain, depending on its location. Because this account has complete access, you should be very careful about adding users to this group. To make someone an administrator for a local computer or domain, all you need to do is make that person a member of this group. Only members of the Administrators group can modify this account.
Domain Admins is a global group designed to help you administer all the computers in a domain. This group has administrative control over all computers in a domain because it’s a member of the Administrators group by default. To make someone an administrator for a domain, make that person a member of this group.
Tip
In a Windows Server 2003 domain, the Administrator local user is a member of Domain Admins by default. This means that if someone logs on to a computer as the administrator and the computer is a member of the domain, the user will have complete access to all resources in the domain. To prevent this, you can remove the local Administrator account from the Domain Admins group.
Enterprise Admins is a global group designed to help you administer all the computers in a domain tree or forest. This group has administrative control over all computers in the enterprise because it’s a member of the Administrators group by default. To make someone an administrator for the enterprise, make that person a member of this group.
Tip
In a Windows Server 2003 domain, the Administrator local user is a member of Enterprise Admins by default. This means that if someone logs on to a computer as the administrator and the computer is a member of the domain, the user will have complete access to the domain tree or forest. To prevent this, you can remove the local Administrator account from the Enterprise Admins group.
Windows Server 2003 defines a set of special identities that you can use to assign permissions in certain situations. You usually assign permissions implicitly to special identities. However, you can assign permissions to special identities when you modify Active Directory objects. The special identities include:
The Anonymous Logon identity. Any user accessing the system through anonymous logon has the Anonymous Logon identity. This identity is used to allow anonymous access to resources, such as a Web page published on the corporate presence servers.
The Authenticated Users identity. Any user accessing the system through a logon process has the Authenticated Users identity. This identity is used to allow access to shared resources within the domain, such as files in a shared folder that should be accessible to all the workers in the organization.
The Batch identity. Any user or process accessing the system as a batch job (or through the batch queue) has the Batch identity. This identity is used to allow batch jobs to run scheduled tasks, such as a nightly cleanup job that deletes temporary files.
The Creator Group identity. Windows Server 2003 uses this group to automatically grant access permissions to users who are members of the same group(s) as the creator of a file or a directory.
The Creator Owner identity. The person who created the file or the directory is a member of this group. Windows Server 2003 uses this group to automatically grant access permissions to the creator of a file or directory.
The Dial-Up identity. Any user accessing the system through a dial-up connection has the Dial-Up identity. This identity is used to distinguish dial-up users from other types of authenticated users.
The Enterprise Domain Controllers identity. Domain controllers with enterprise-wide roles and responsibilities have the Enterprise Domain Controllers identity. This identity allows them to perform certain tasks in the enterprise using transitive trusts.
The Everyone identity. All interactive, network, dial-up, and authenticated users are members of the Everyone group. This group is used to give wide access to a system resource.
The Interactive identity. Any user logged on to the local system has the Interactive identity. This identity is used to allow only local users to access a resource.
The Network identity. Any user accessing the system through a network has the Network identity. This identity is used to allow only remote users to access a resource.
The Proxy identity. Users and computers accessing resources through a proxy have the Proxy identity. This identity is used when proxies are implemented on the network.
The Restricted identity. Users and computers with restricted capabilities have the Restricted identity. On a member server or workstation, a local user who is a member of the Users group (rather than the Power Users group) has this identity.
The Self identity. The Self identity refers to the object itself and allows the object to modify itself.
The Service identity. Any service accessing the system has the Service identity. This identity grants access to processes being run by Windows Server 2003 services.
The System identity. The Windows Server 2003 operating system itself has the System identity. This identity is used when the operating system needs to perform a system-level function.
The Terminal Server User identity. Any user accessing the system through Terminal Services has the Terminal Server User identity. This identity allows terminal server users to access terminal server applications and to perform other necessary tasks with Terminal Services.