Troubleshooting Computer Accounts

Troubleshooting Computer Accounts

Active Directory domains treat computers as security principals. This means that a computer, just like a user, has an account—or, more specifically, properties within the computer object such as a name, a password, and a SID. Like user accounts, computer accounts require maintenance and, occasionally, troubleshooting. This topic focuses on skills and concepts related to troubleshooting computer objects.

Deleting and Disabling and Resetting Computer Accounts

Computer accounts, like user accounts, maintain a unique SID, which enables an administrator to grant permissions to computers. Also like user accounts, computers can belong to groups. Therefore, like user accounts, it is important to understand the effect of deleting a computer account. When a computer account is deleted, its group memberships and SID are lost. If the deletion is accidental, and another computer account is created with the same name, it is nonetheless a new account, with a new SID. Group memberships must be reestablished, and any permissions assigned to the deleted computer must be reassigned to the new account. Delete computer objects only when you are certain that you no longer require those security-related attributes of the object.

To delete a computer account using Active Directory Users And Computers, locate and select the computer object and, from the Action menu or the shortcut menu, select the Delete command. You will be prompted to confirm the deletion and, because deletion is not reversible, the default response to the prompt is No. Select Yes and the object is deleted.

The DSRM command-line tool introduced in earlier topic allows you to delete a computer object from the command prompt. To delete a computer with DSRM, type:

DSRM ObjectDN

Where ObjectDN is the distinguished name of the computer, such as “CN=Desktop15, OU=Desktops,DC=mcseweb,DC=local.” Again, you will be prompted to confirm the deletion.

If a computer is taken offline or is not to be used for an extended period of time, you may disable the account. Such an action reflects the security principle, that an identity store allow authentication only of the minimum number of accounts required to achieve the goals of an organization. Disabling the account does not modify the computer’s SID or group membership, so when the computer is brought back online, the account can be enabled.

The context menu, or Action menu, of a selected computer object exposes the Disable Account command. A disabled account appears with a red “X” icon in the Active Directory Users And Computers snap-in, as shown in below Figure.

While an account is disabled, the computer cannot create a secure channel with the domain. The result is that users who have not previously logged on to the computer, and who therefore do not have cached credentials on the computer, will be unable to log on until the secure channel is reestablished by enabling the account.

To enable a computer account, simply select the computer and choose the Enable Account command from the Action or shortcut menus.

To disable or enable a computer from the command prompt, use the DSMOD command. The DSMOD command modifies Active Directory objects. The syntax used to disable or enable computers is:

DSMOD COMPUTER ComputerDN -DISABLED YES

DSMOD COMPUTER ComputerDN -DISABLED NO

If a computer account’s group memberships and SID, and the permissions assigned to that SID, are important to the operations of a domain, you do not want to delete that account. So what would you do if a computer was replaced with a new system, with upgraded hardware? Such is one scenario in which you would reset a computer account.

Resetting a computer account resets its password, but maintains all of the computer object’s properties. With a reset password, the account becomes in effect “available” for use. Any computer can then join the domain using that account, including the upgraded system.

In fact, the computer that had previously joined the domain with that account can use the reset account by simply rejoining the domain.

The Reset Account command is available in the Action and context menus when a computer object is selected. The DSMOD command can also be used to reset a computer account, with the following syntax:

dsmod computer ComputerDN -reset

The NETDOM command, included with the Windows Server 2003 Support Tools in the CD-ROM’s Support\Tools directory, also enables you to reset a computer account.

Recognizing Computer Account Problems

Computer accounts, and the secure relationships between computers and their domain are robust. In the rare circumstance that an account or secure channel breaks down, the symptoms of failure are generally obvious. The most common signs of computer account problems are:

Messages at logon indicate that a domain controller cannot be contacted; that the computer account may be missing; or that the trust (another way of saying “the secure relationship”) between the computer and the domain has been lost. An example is shown in below Figure.

* Error messages or events in the event log indicating similar problems or suggesting that passwords, trusts, secure channels, or relationships with the domain or a domain controller have failed.

* A computer account is missing in Active Directory.

If one of these situations occurs, you must troubleshoot the account. You learned earlier how to delete, disable, and reset a computer account and, at the beginning of the chapter, how to join a machine to the domain.

The rules that govern troubleshooting a computer account are:

A. If the computer account exists in Active Directory, it must be reset.

B. If the computer account is missing in Active Directory, you must create a computer account.

C. If the computer still belongs to the domain, it must be removed from the domain by changing its membership to a workgroup. The name of the work-group is irrelevant. Best practice is to try and choose a workgroup name that you know is not in use.

D. Rejoin the computer to the domain. Alternatively, join another computer to the domain; but the new computer must have the same name as the computer account.

To troubleshoot any computer account problem, apply all four rules. These rules can be addressed in any order, except that Rule D, involving rejoining the computer to the domain, must as always be performed as the final step. Let’s examine two scenarios.

In the first scenario, a user complains that when he or she attempts to log on, the system presents error messages indicating that the computer account might be missing. Applying Rule A, you open Active Directory Users And Computers and find that the computer account exists. You reset the account. Rule B does not apply—the account does exist. Then, using Rule C, you disjoin the system from the domain and, following Rule D, rejoin the domain.

In a second scenario, if a computer account is reset by accident, the first item that has occurred is Rule A. Although the reset is accidental, you must continue to recover by applying the remaining three rules. Rule B does not apply because the account exists in the domain. Rule C indicates that if the computer is still joined to the domain, it must be removed from the domain. Then, by Rule D, it can rejoin the domain.

With these four rules, you can make an informed decision, on the job or on the certification exams, about how to address any scenario in which a computer account has lost functionality.

Managing Computer Accounts

In the previous topic, you examined the fundamental components of a computer’s relationship with a domain: the computer’s account, and joining the computer to the domain. This Topic looks more closely at the computer object in Active Directory. You will learn about the other properties and permissions that make computer objects “tick,” and how to manage those properties and permissions using GUI and command-line tools.

Managing Computer Object Permissions

In previous topic, you learned that you could join a computer to a domain by providing domain administrator credentials when prompted by the computer during the join process. Security concerns, however, require us to use the minimum necessary credentials to achieve a particular task, and it does seem like overkill to need a Domain Admins’ account to add a desktop to the domain.

Fortunately, Active Directory allows you to control, with great specificity, the groups or users that can join a computer to a domain computer account. Although the default is Domain Admins, you can allow any group (for example, a group called “Installers”) to join a machine to an account. This is most easily achieved while creating the computer object.

When you create a computer object, the first page of the New Object–Computer dialog box indicates The Following User or Group Can Join This Computer to A Domain. Click Change and you can select any user or group. This change modifies a number of permissions on the computer object in Active Directory.

The following page of the New Object–Computer dialog box prompts you for the globally unique identifier (GUID) of the computer, which is necessary if you install a system using Remote Installation Services (RIS). For more information on RIS, see the Microsoft online Knowledge Base, http://support.microsoft.com/.

If the computer that is using the account that you are creating is running a version of Windows earlier than 2000, select the Assign This Computer Account As A Pre–Windows 2000 Computer check box. If the account is for a Windows NT backup domain controller, click Assign This Computer Account As A Backup Domain Controller.

Configuring Computer Properties

Computer objects have several properties that are not visible when creating a computer account in the user interface. Open a computer object’s Properties dialog box to set its location and description, configure its group memberships and dial-in permissions, and link it to a user object of the computer’s manager. The Operating System properties page is read-only. The information is published automatically to Active Directory, and will be blank until a computer has joined the domain using that account.

Several object classes in Active Directory support the Manager property that is shown on the Managed By property page of a computer. This linked property creates a cross-reference to a user object. All other properties the addresses and telephone numbers are displayed directly from the user object. They are not stored as part of the computer object itself.

The DSMOD command, as discussed in previous topic, can also modify several of the properties of a computer object. You will see the DSMOD command in action in the following section regarding troubleshooting computer accounts.

Finding and Connecting to Objects in Active Directory

When a user calls you with a particular problem, you might want to know what operating system and service pack is installed on that user’s system. You learned that this information is stored as properties of the computer object. The only challenge, then, is to locate the computer object, which may be more difficult in a complex Active Directory with one or more domains and multiple OUs.

The Active Directory Users and Computers snap-in provides easy access to a powerful, graphical search tool. This tool can be used to find a variety of object types. In this con-text, however, your search entails an object of the type Computer. Click the Find Objects In Active Directory button on the console toolbar. The resulting Find Computers dialog box is illustrated in below Figure. You can select the type of object (Find), the scope of the search (In), and specify search criteria before clicking Find Now.

The list of results allows you to select an object and, from the File menu or the shortcut menu, perform common tasks on the selected object. Many administrators appreciate learning that you can use the Manage command to open the Computer Management console and connect directly to that computer, allowing you to examine its event logs, device manager, system information, disk and service configuration, or local user or group accounts.

Joining a Computer to a Domain

The default configuration of Windows Server 2003, and all Microsoft Windows operating systems, is that the computer belongs to a workgroup. In a workgroup, a Windows NT–based computer (which includes Windows NT 4, Windows 2000, Windows XP, and Windows Server 2003) can authenticate users only from its local Security Accounts Manager (SAM) database. It is a stand-alone system, for all intents and purposes. Its workgroup membership plays only a minor role, specifically in the browser service. Although a user at that computer can connect to shares on other machines in a workgroup or in a domain, the user is never actually logged on to the computer with a domain account.


Before you can log on to a computer with your domain user account, that computer must belong to a domain. The two steps necessary to join a computer to a domain are, first, to create an account for the computer and, second, to configure the computer to join the domain using that account. This Topic will focus on the skills related to the creation of computer accounts and joining computers to domains. The next topic will explore, in more depth, the computer accounts themselves.

Computers maintain accounts, just as users do, that include a name, password, and security identifier (SID). Those properties are incorporated into the computer object class within Active Directory. Preparing for a computer to be part of your domain is therefore a process strikingly similar to preparing for a user to be part of your domain: you must create a computer object in Active Directory.

Creating Computer Accounts

You must be a member of the Administrators or Account Operators groups on the domain controllers to create a computer object in Active Directory. Domain Admins and Enterprise Admins are, by default, members of the Administrators group. Alternatively, it is possible to delegate administration so that other users or groups can create computer objects.

However, domain users can also create computer objects through an interesting, indirect process. When a computer is joined to the domain and an account does not exist, Active Directory creates a computer object automatically, by default, in the Computers OU. Each user in the Authenticated Users group (which is, in effect, all users) is allowed to join 10 computers to the domain, and can therefore create as many as 10 computer objects in this manner.

Creating Computer Objects Using Active Directory Users and Computers

To create a computer object, or “account,” open Active Directory Users And Computers and select the container or OU in which you want to create the object. From the Action menu or the right-click shortcut menu, choose the New–Computer command. The New Object–Computer dialog box appears, as illustrated in below Figure.

In the New Object–Computer dialog box, type the computer name. Other properties in this dialog box will be discussed in the following lesson. Click Next. The following page of the dialog box requests a GUID. A GUID is used to prestage a computer account for Remote Installation Services (RIS) deployment, which is beyond the scope of this discussion. It is not necessary to enter a GUID when creating a computer account for a machine you will be joining to the domain using other methods. So just click Next and then click Finish






Creating Computer Objects Using DSADD

Chances are, this is something you’ve done before. But before you decide there’s nothing new under the sun, Windows Server 2003 provides a useful command-line tool, DSADD, which allows you to create computer objects from the command prompt or a batch file.

In earlier topic, “Administering Microsoft Windows Server 2003,” you used DSADD to create user objects. To create computer objects, simply type dsadd computer ComputerDN, where ComputerDN is the distinguished name (DN) of the computer, such as CN=Desktop123, OU=Desktop, DC=mcseweb DC=com.

If the computer’s DN includes a space, surround the entire DN with quotation marks. The ComputerDN… parameter can include more than one distinguished name for new computer objects, making DSADD Computer a handy way to generate multiple objects at once. The parameter can be entered in one of the following ways:

* By piping a list of DNs from another command, such as dsquery.

* By typing each DN on the command line, separated by spaces.

* By leaving the DN parameter empty, at which point you can type the DNs, one at a time, at the keyboard console of the command prompt. Press ENTER after each DN. Press CTRL+Z and ENTER after the last DN.

The DSADD Computer command can take the following optional parameters after the DN parameter:

*-samid SAMName

*-desc Description

*-loc Location

Creating a Computer Account with NETDOM

The NETDOM command is available as a component of the Support Tools, installable from the Support\Tools directory of the Windows Server 2003 CD. The command is also available on the Windows XP and Windows 2000 CDs. Use the version that is appropriate for the platform. NETDOM allows you to perform numerous domain account and security tasks from the command line.

To create a computer account in a domain, type the following command:

netdom add ComputerName /domain:DomainName /userd:User /PasswordD:UserPassword [/ou:OUDN]

This command creates the computer account for ComputerName in the domain DomainName using the domain credentials User and UserPassword. The /ou parameter causes the object to be created in the OU specified by the OUDN distinguished name following the parameter. If no OUDN is supplied, the computer account is created in the Computers OU by default. The user credentials must, of course, have permissions to create computer objects.

Joining a Computer to a Domain

A computer account alone is not enough to create the secure relationship required between a domain and a machine. The machine must join the domain.

To join a computer to the domain, perform the following steps:

1. Right-click My Computer and choose Properties. Click the Computer Name tab.

❑Open Control Panel, select System, and in the System Properties dialog box, click the Computer Name tab.

❑Open the computer’s Computer Name properties. These properties can be accessed in several ways:

2. Open the Network Connections folder from Control Panel and choose the Network Identification command from the Advanced menu.

3. On the Computer Name tab, click Change. The Computer Name Changes dialog box, shown in below Figure allows you to change the name and the domain and workgroup membership of the computer.

4. In the Computer Name Changes dialog box, click Domain and type the name of the domain.

5. Click OK. The computer contacts the domain controller. If there is a problem connecting to the domain, examine network connectivity and configuration, as well as DNS configuration.













When the computer successfully contacts the domain, you will be prompted, as in below Figure, for a user name and password with privileges to join the domain. Note that the credentials requested are your domain user name and password.

If you have not created a domain computer account with a name that matches the computer’s name, Active Directory creates an account automatically in the default Computers container. Once a domain computer account has been created or located, the computer establishes a trust relationship with the domain, alters its SID to match that of the account, and makes modifications to its group memberships. The computer must then be restarted to complete the process.







The Computers Container vs. OUs

The Computers container is the default location for computer objects in Active Directory. After a domain is upgraded from Windows NT 4 to Windows 2000, all computer accounts are found, initially, in this container. Moreover, when a machine joins the domain and there is no existing account in the domain for that computer, a computer object is created automatically in the Computers container.

Although the Computers container is the default container for computer objects, it is not the ideal container for computer objects. Unlike OUs, containers such as Computers, Users and Builtin cannot be linked to policies, limiting the possible scope of computer-focused group policy. A best-practice Active Directory design will include at least one OU for computers. Often, there are multiple OUs for computers, based on administrative division, region, or for the separate administration of laptops, desktops, file and print servers, and application servers. As an example, there is a default OU for Domain Controllers in Active Directory, which is linked to the Default Domain Controller Policy. By creating one or more OUs for computers, an organization can delegate administration and manage computer configuration, through group policy, more flexibly.

If your organization has one or more OUs for computers, you must move any computer objects created automatically in the Computers container into the appropriate OU. To move a computer object, select the computer and choose Move from the Action menu. Alternatively, use the new drag-and-drop feature of the MMC to move the object.

You can also move a computer object, or any other object, with the DSMOVE command. The syntax of DSMOVE is:

dsmove ObjectDN [-newname NewName] [-newparent ParentDN]

The -newname parameter allows you to rename an object. The -newparent parameter allows you to move an object. To move a computer named DesktopABC from the Computers container to the Desktops OU, you would type the following:

dsmove ?CN=DesktopABC,CN=Computers,DC=mcseweb,DC=com? -newparent
?OU=Desktops,DC=mcseweb ,DC=com?

In this command you again see the distinction between the Computers container (CN) and the Desktops organizational unit (OU).

You must have appropriate permissions to move an object in Active Directory. Default permissions allow Account Operators to move computer objects between containers including the Computers container and any OUs except into or out of the Domain Controllers OU. Administrators, which include Domain Admins and Enterprise Admins, can move computer objects between any containers, including the Computers container, the Domain Controllers OU, and any other OUs.

Computer Accounts

1. Joining a Computer to a Domain
2. Managing Computer Accounts
3. Troubleshooting Computer Accounts

Using Automation to Manage Group Accounts

Although the Active Directory Users And Computers MMC is a convenient way to create and modify groups individually, it is not the most efficient method for creating large numbers of security principals. A tool included with Windows Server 2003, Ldifde.exe, facilitates the importing and exporting of larger numbers of security principals, including groups.

Using LDIFDE

The Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) is a draft Internet standard for a file format that may be used to perform batch operations against directories that conform to the LDAP standards. LDIF can be used to export and import data, allowing batch operations such as add, create, and modify to be per-formed against the Active Directory. A utility program called LDIFDE is included in Windows Server 2003 to support batch operations based on the LDIF file format standard.

LDIFDE is a command-line utility, available on all Windows Server 2003 editions. From a command prompt or command shell, you run the LDIFDE utility with the appropriate command switches. Below Figure lists the primary commands used with LDIFDE displayed by typing ldifde /? at the command prompt.

Details the primary LDIFDE commands.

LDIFDE Commands (Primary)

General parameters

-i : Turn on Import Mode (The default is Export)

-f filename: Input or Output filename

-s servername: The server to bind to

-c FromDN ToDN:  Replace occurrences of FromDN to ToDN

-v : Turn on Verbose mode

-j path: log File Location

-t port:  Port Number (default=389)

-? : Help


Export specific parameters

-d RootDN :The root of the LDAP search (Default to Naming Context)

-r Filter: LDAP search filter (Default to “(objectClass=*)”)

-p SearchScope: Search Scope (Base/OneLevel/Subtree)

-l list: List of attributes (comma-separated) to look for in an LDAP search

-o list: List of attribute (Comma-Separated) to omit from input

-g: Disable Paged Search

-m: Enable the Security Accounts Manager (SAM) Logic On export

-n: Do not export binary values

Import specific parameters

-k :The import will ignore “Constraint Violation” and “Object Already Exists” errors

Credentials parameters

-a UserDN: Sets the command to run using the supplied user distinguished name and password.

For example: “cn=administrator, dc=mcseweb, dc-com password”

-b UserName: Sets the command to run as username domain password. The default is to Domain run using the credentials of the currently logged on user.

Creating Groups with DSADD

The DSADD command, introduced in earlier topic, is used to add objects to Active Directory. To add a group, use the syntax

dsadd group GroupDN…

The GroupDN… parameter is one or more distinguished names for the new user objects. If a DN includes a space, surround the entire DN with quotation marks. The GroupDN… parameter can be entered one of the following ways:

* By piping a list of DNs from another command, such as dsquery.

* By typing each DN on the command line, separated by spaces.

* By leaving the DN parameter empty, at which point you can type the DNs, one at a time, at the keyboard console of the command prompt. Press ENTER after each DN. Press CTRL+Z and ENTER after the last DN.

The DSADD GROUP command can take the following optional parameters after the DN parameter:

* secgrp {yes | no} determines whether the group is a security group (yes) or a distribution group (no). The default value is yes.

* scope {l |  g | u} determines whether the group is a domain local (l), global (g, the default), or universal (u).

* -samid SAMName

* -desc Description

* -memberof GroupDN... specifies groups to which to add the new group.

* -members MemberDN... specifies members to add to the group.

As discussed in earlier topic, you can add -s, -u, and -p parameters to specify the domain controller against which DSADD will run, and the user name and password—the credentials—that will be used to execute the command.

* {-s Server -d Domain}

* -u UserName

*-p{Password | *}

Modifying Groups with DSMOD

The DSMOD command, introduced in earlier topic, is used to modify objects in Active Directory. To modify a group, use the syntax

dsmod group GroupDN…

The command takes many of the same switches as DSADD, including -samid, -desc, -secgrp, and -scope. Typically, though, you won't be changing those attributes of an existing group. Rather, the most useful switches are those that let you modify the membership of a group, specifically

* -addmbr Member...    adds members to the group specified in Group

* -rmmbr Member...     removes members from the group specified in Group

where, as with all directory service commands, the DN is the full, distinguished name of another Active Directory object, surrounded by quotes if there are any spaces in the DN.

Managing Group Accounts

The Active Directory Users And Computers MMC is the primary tool you will use to administer security principals—users, groups, and computers—in the domain. In the creation of groups, you will configure the scope, type, and membership for each. You will also use the Active Directory Users And Computers MMC to modify membership of existing groups.

Creating a Security Group

The tool that you will use most often in the creation of groups is the Active Directory Users And Computers MMC, which can be found in the Administrative Tools folder. From within the Active Directory Users And Computers MMC, right-click the details pane of the container within which you want to create the group, and choose New, Group. You then must select the type and scope of group that you want to create.

The primary type of group that you will likely create is a security group because this is the type of group used to set permissions in an ACL. In a mixed or interim domain functional level domain, you can only set a security group for the domain local and global scopes. As below Figure illustrates, you cannot create a security group that has universal scope in mixed or interim domain functional level domains.

Domain local, global, and universal groups can, however, be created as a distribution type in a mixed or interim domain functional level domain. In a mixed or interim domain functional level domain, security groups can be created in any scope.











Modifying Group Membership

Adding or deleting members from a group is also accomplished through Active Directory Users And Computers. Right-click any group, and choose Properties. Below Figure illustrates the Properties dialog box of a global security group called Sales.

Below Table explains the member configuration tabs of the Properties dialog box.

Membership Configuration

Members      : Adding, removing, or listing the security principals that this container holds as members

Member Of  :Adding, removing, or listing the containers that hold this container as a member










Finding the Domain Groups to Which a User Belongs

Active Directory allows for flexible and creative group nesting, where

* Global groups can nest into other global groups, universal groups, or domain local groups.

* Universal groups can be members of other universal groups or domain local groups.

* Domain local groups can belong to other domain local groups.

This flexibility brings with it the potential for complexity, and without the right tools, it would be difficult to know exactly which groups a user belongs to, whether directly or indirectly. Fortunately, Windows Server 2003 adds the DSGET command, which solves the problem. From a command prompt, type:

dsget user UserDN -memberof [-expand]

The -memberof switch returns the value of the MemberOf attribute, showing the groups to which the user directly belongs. By adding the -expand switch, those groups are searched recursively, producing an exhaustive list of all groups to which the user belongs in the domain.

Understanding Group Types and Scopes

Groups are containers that can contain user and computer objects within them as members. When security permissions are set for a group in the access control list (ACL) on a resource, all members of that group receive those permissions.


Windows Server 2003 has two group types: Security and distribution. Security groups are used to assign permissions for access to network resources. Distribution groups are used to combine users for e-mail distribution lists. Security groups can be used as a distribution group, but distribution groups cannot be used as security groups. Proper planning of group structure affects maintenance and scalability, especially in the enterprise environment, in which multiple domains are involved.

Group Scope

Group scope defines how permissions are assigned to the group members. Windows Server 2003 groups, both security and distribution groups, are classified into one of three group scopes: domain local, global, and universal.

Local Groups

Local groups (or machine local groups) are used primarily for backward compatibility with Windows NT 4. There are local users and groups on computers running Windows Server 2003 that are configured as member servers. Domain controllers do not use local groups.

* Local groups can include members from any domain within a forest, from trusted domains in other forests, and from trusted down-level domains.

* A local group has only machinewide scope; it can grant resource permissions only on the machine on which it exists.

Domain Local Groups

Domain local groups are used primarily to assign access permissions to global groups for local domain resources. Domain local groups:

* Exist in all mixed, interim and native functional level domains and forests.

* Are available domainwide only in Windows 2000 native or Windows Server 2003 domain functional level domains. Domain local groups function as a local group on the domain controllers while the domain is in mixed functional level.

* Can include members from any domain in the forest, from trusted domains in other forests, and from trusted down-level domains.

* Have domainwide scope in Windows 2000 native and Windows Server 2003 domain functional level domains, and can be used to grant resource permission on any Windows Server 2003 computer within, but not beyond, the domain in which the group exists.

Global Groups

Global groups are used primarily to provide categorized membership in domain local groups for individual security principals or for direct permission assignment (particularly in the case of a mixed or interim domain functional level domain). Often, global groups are used to collect users or computers in the same domain and share the same job, role, or function. Global groups:

* Exist in all mixed, interim, and native functional level domains and forests

* Can only include members from within their domain

* Can be made a member of machine local or domain local group

* Can be granted permission in any domain (including trusted domains in other forests and pre–Windows 2003 domains)

* Can contain other global groups (Windows 2000 native or Windows Server 2003 domain functional level only)

Universal Groups

Universal groups are used primarily to grant access to resources in all trusted domains, but universal groups can only be used as a security principal (security group type) in a Windows 2000 native or Windows Server 2003 domain functional level domain.

* Universal groups can include members from any domain in the forest.

* In Windows 2000 native or Windows Server 2003 domain functional level, universal groups can be granted permissions in any domain, including domains in other forests with which a trust exists.



Group Conversion

The scope of a group is determined at the time of its creation. However, in a Windows 2000 native or Windows Server 2003 domain functional level domain, domain local and global groups can be converted to universal groups if the groups are not members of other groups of the same scope. For example, a global group that is a member of another global group cannot be converted to a universal group. The use of Windows Server 2003 domain groups as security principals (group type: security) are below summarizes.

Group Scope and Allowed Objects

Windows 2000 native or Windows Server 2003 functional level domain

Domain Local: Computer accounts, users, global groups, and universal groups from any forest or trusted domain. Domain local groups from the same domain. Nested domain local groups in the same domain.

Global: Users, computers and global groups from same domain. Nested global (in same domain), domain local, or universal groups.

Universal: Universal groups, global groups, users and computers from any domain in the forest. Nested global, domain local, or universal groups.


Windows 2000 mixed or Windows Server 2003 interim functional level domain

Domain Local: Computer accounts, users, global groups from any domain. Cannot be nested.

Global: Only users and computers from same domain. Cannot be nested.

Universal: Not available.


Special Identities

There are also some special groups called special identities, that are managed by the operating system. Special identities cannot be created or deleted; nor can their membership be modified by administrators. Special identities do not appear in the Active Directory Users And Computers snap-in or in any other computer management tool, but can be assigned permissions in an ACL. Details of some of the special identities in Windows Server 2003 are given below.

Special Identities and Their Representation

Everyone: Represents all current network users, including guests and users from other domains. Whenever a user logs on to the network, that user is automatically added to the Everyone group.

Network: Represents users currently accessing a given resource over the network (as opposed to users who access a resource by logging on locally at the computer where the resource is located). Whenever a user accesses a given resource over the network, the user is automatically added to the Network group.

Interactive: Represents all users currently logged on to a particular computer and accessing a given resource located on that computer (as opposed to users who access the resource over the network). Whenever a user accesses a given resource on the computer to which they are logged on, the user is automatically added to the Interactive group.

Anonymous Logon: The Anonymous Logon group refers to any user who is using network resources, but did not go through the authentication process.

Authenticated Users: The Authenticated Users group includes all users who are authenticated into the network by using a valid user account. When assigning permissions, you can use the Authenticated Users group in place of the Everyone group to prevent anonymous access to resources.

Creator Owner: The Creator Owner group refers to the user who created or took ownership of the resource. For example, if a user created a resource, but the Administrator took ownership of it, then the Creator Owner would be the Administrator.

Dialup: The Dialup group includes anyone who is connected to the network through a dialup connection.

Group Accounts

1. Understanding Group Types and Scopes
2. Managing Group Accounts
3. Using Automation to Manage Group Accounts