Increasing Security with Limited User Accounts and Restricted Groups

In Windows XP Home Edition, there are two basic types of local user accounts (in addition to the guest account): administrators and limited users. With XP Pro, things get a bit more complicated. Users can be placed into groups to control what they can and can’t do, or Group Policy can be used to assign specific rights to individual users. In many cases, the standard built-in groups work fine. By default, new users are members of the Users group. These accounts are limited to prevent them from making system-wide configuration changes, but there may be instances when it’s desirable to create a more customized “Limited Users” group for special situations.

Problems can arise because users can be members of multiple groups. In a domain environment, you can define Restricted Groups to control the memberships of important groups (such as administrators groups).

Local Users vs. Domain Users

All Windows administrators know that in the domain environment, there are both local and domain user accounts, but many still get confused about the use of each. A local account is created on a single computer and is stored in its Security Account Manager (SAM) database on its hard disk. Domain accounts are created on the domain controller and stored in Active Directory. To log onto the local machine (selecting its name in the logon dialog box), you need a local account. To log onto the domain, selecting the network name in the logon dialog box, you need a domain account. To confuse matters more, the same user might have local and domain accounts with the same username and password. However, these are still two entirely separate accounts with different Security Identifiers (SIDs).

A user can be an administrator on a local machine without being a domain administrator. However, by default domain administrators are added to the local administrators group of the computers that belong to the domain. Domain controllers (Windows 2000 servers or Windows Server 2003 computers) don’t have functional local administrator accounts; a local administrator account is created when you set up the server, but is disabled when it is promoted to DC. Domain controllers are administered by members of the domain administrators group.

Some applications require that you be logged on as a local administrator to run them. When giving users administrative rights for this purpose, be sure you give them only local administrative rights; do not make them domain admins. You can add users’ Active Directory accounts to the local administrators group via a logon script or by using Restricted Groups for instructions on how to do this.

The Default and Built-in Groups

Here again, we’re talking about two different groups of groups: the built-in local groups and the built-in domain groups. Then in each case, we have to divide it again, into the built-in groups (security principals) and the default user groups. The two are not the same. In Window XP, the built-in groups include:

  • Anonymous logon (those who have logged on without credentials are placed in this group)
  • Authenticated users (does not include the Guest account)
  • Creator group (in the Access Control Entry, the primary group of an object’s owner)
  • Dialup (users who access the computer through a dialup connection)
  • Interactive (users who are logged on locally)
  • Network (users who log on over the network)
  • Remote interactive logon (users who log on via an RDP connection)
  • Terminal server user (users accessing the computer through a terminal session)
  • Everyone (all users who access the computer, including guests and users from other domains. In XP, this does not include Anonymous users)

There are also a number of built-in security principals that are not groups that contain users (For example: Batch, Local Service, Network Service, Service, System, Enterprise Domain Controllers).

The default local groups, on the other hand, are user groups that are created when the operating system is installed. These are the groups that you’ll see in the Local Users and Groups node in the Computer Management console under System Tools. On Windows XP Pro, these include:

  • Administrators (have full control of the local computer)
  • Power Users (can install programs and modify system-wide settings)
  • Users (by default, all authenticated users and interactive users are added to this group; however, if the OS was upgraded to XP from NT 4.0, interactive users are added to the Power Users group)
  • Guests (have limited access)
  • Remote Desktop Users (allowed to access the computer via RDP connection)
  • Backup operators (can back up and restore files, regardless of permissions)

There are also some special purpose groups such as the Replicator group, Debugger users group, HelpServicesGroup and RS_Query group.

The built-in domain groups in a Server 2003 domain are:

  • Account Operators (can create/manage/delete accounts, log on locally, shut down the system)
  • Administrators (have full control of all domain controllers in the domain)
  • Backup Operators (can back up and restore files on all domain controllers, regardless of permissions)
  • Guests (limited access, no default user rights)
  • Network Configuration Operators (can modify TCP/IP settings)
  • Performance Monitor Users (can monitor performance counters)
  • Performance Log Users (can manage performance counters, logs and alerts)
  • Print Operators (can manage, create, share and delete printers in the domain)
  • Remote Desktop Users (can log on remotely to domain controllers via RDP connection)
  • Server Operators (can log on interactively, create/delete shared resources and perform such administrative tasks such as starting and stopping some services)
  • Users (Can perform common tasks; includes every user account created in the domain

There are also special groups such as the Replicator group and the Incoming Forest Trust Builders group, which are beyond the scope of this discussion.

The default user groups in the Users container on the domain controller include:

  • Cert publishers (can publish certificates)
  • DnsAdmins (can administer the DNS server services)
  • Domain Admins (have full control of the domain, by default is a member of the local administrators group on all computers in the domain)
  • Domain Guests (limited access)
  • Domain Users (by default, all user accounts created in the domain are members of this group)
  • Group Policy Creator Owners (can modify Group Policy in the domain)

There are additional default groups, such as Enterprise Admins and Schema Admins, that appear only in the forest root domain. There are also additional default groups, such as the IIS_WPG group, RAS and IAS servers group, DnsUpdateProxy group, and Domain Computers and Domain Controllers group, which do not contain users.

It can be difficult to determine the effective rights and permissions that apply to a particular user, especially if that user belongs to more than one group. You can use the Whoami tool (found in the Support/Tools folder on the XP Pro installation CD) to view the contents of the logged-on user’s access token.

Creating Customized Limited User Accounts

You may have some users who need access to limited resources on the network (for example, temporary workers). You don’t want them to have as much access as regular users, but they need more access than guests. You can create user accounts for them and place them in a special group for which you customize the user rights. You can also give this group permissions to certain resources (files/folders, shared printers, etc.).

Create the group at the level that will be needed for the user to do his/her job. If network resources are not needed, you can create a local account and the user can log onto the local machine instead of the domain. In most cases, you’ll want to create domain accounts so they can be centrally managed, and so the user will be able to work from different machines.

Using Restricted Groups

Sometimes it’s difficult to keep up with who belongs to a specific group. In Windows XP/Server 2003, you can use restricted groups to gain better control over membership of groups. To do so, you create a restricted groups policy. The policy specifies which users are members of the group. When you apply the policy, only those users allowed in the policy will be members of the restricted group. This prevents addition of members who should not be allowed. Only members added in the policy can belong to the group.

Restricted groups are used for local groups on XP workstations and Server 2003 member servers. The policy is defined and applied via a security template. Here’s how to create a restricted groups policy:

  1. Log on as an administrator.
  2. Click Start | Run and  enter mmc to open an empty management console.
  3. Click File | Add/Remove Snap-ins.
  4. In the dialog box, click the Add button.
  5. Under Available Standalone Snap-ins, scroll down and select Security Templates, then click the Add button and then the Close button. Click OK.
  6. In the left pane of the MMC, expand the Security Templates node, then expand the template path folder (for example, c:\WINDOWS\security\tempates), then the template you want to use (for example, securews for a secure workstation).
  7. Right click Restricted Groups and select Add Group.
  8. In the dialog box, type the name of the group for which you want to create a restricted groups policy. Click OK.
  9. In the Configure Membership for <group> dialog box, click the Add button to add members to the group or add groups of which you want this group to be a member.

You can copy restricted group entries from one template to another by copying and pasting within the Security Templates MMC.


You can increase security on your Windows XP computers and within your Windows Server 2003 domain by creating special limited user accounts. The best way to do this is to place the accounts into groups that have been given limited, customized user rights.

You can use Windows XP/Server 2003’s Restricted Groups policy feature to control who is allowed to belong to groups, and the groups to which a group should belong.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top