Managing Active Directory OUs, Users, and Groups
- Active Directory after Installation
- Administering OUs
- Administering Users, InetOrgPersons, and Contacts
- Administering Computer Objects
- Administering Groups
- Tips on Tools
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
The most visible part of Active Directory administration is managing objects with the Users and Computers snap-in. This snap-in enables you to create organizational units (OUs) to set up an OU tree in a domain. You also use this snap-in to populate the OU tree by creating objects of the following eight classes in the OUs you want:
-
Users (or alternatively, inetOrgPersons, new in AD2003)
-
Contacts
-
Computers
-
Groups
-
MSMQ queue aliases (new in AD2003)
-
Shared folders
-
Printers
This chapter covers managing OUs and the first five classes in the list. We will proceed as follows:
-
First, we describe the contents of your Active Directory domain right after installation.
-
Second, we explore how to manage OUs and objects of each of the five other classes (i.e., users, inetOrgPersons, contacts, computers, and groups).
-
Finally, we discuss some additional features of the Users and Computers snap-in, and we discuss or list additional tools for managing objects.
This chapter focuses on the Users and Computers snap-in. If you have to create many objects, other tools you can use include DSAdd (new in AD2003), LDIFDE, CSVDE, scripting, or some Resource Kit tools. DSAdd we cover at the end of this chapter; the other tools we just list there, but cover later in the book.
Behind the scenes, a domain object can contain objects of 35 classes (23 in AD2000), and an OU can contain objects of 59 classes (35 in AD2000). However, with the Users and Computers snap-in, you can normally create and see objects of only the nine classes just listed.
MSMQ Queue Alias is listed as an alternative when you create new objects in the Users and Computers snap-in. You can, however, create and use such objects only if you first install Microsoft Message Queuing 3.0 (MSMQ). Because such aliases (corresponding to the msMQ-Custom-Recipient class) reside in the directory, they help applications to locate message queues. Further discussion of the topic is outside the scope of this book. Also, we don't mention MSMQ queue aliases later in this chapter, even though they would appear in some lists, and so on.
Active Directory after Installation
After you have created your first domain by installing Active Directory on a server (i.e., promoting it to a domain controller), there are certain users, computers, groups, and containers already in place (see Figure 3.1). You see these objects with the Users and Computers snap-in, which you start by clicking the Start button and selecting Administrative Tools, Active Directory Users and Computers.
)
Figure 3.1 A newly installed domain (sanao.com in the figure), which is the root domain of a forest
Another way to start the Users and Computers snap-in is to click the Start button, select Run, type dsa.msc, and press Enter.
You will see the following predefined objects in the snap-in:
-
Five containers, one of which is an OU
-
Some user objects (or user accounts)
-
Some group objects (sometimes referred to as group accounts)
-
One computer object (or computer account) for your domain controller
Active Directory contains only objects. Users, groups, and computers, however, are often called accounts instead of objects. You could also argue that an account is something that can authenticate (user or computer), so a group is not an account, but "just" a group of accounts.
If you upgrade a Windows NT domain, you will see the users, groups, and computers of that domain in Active Directory.
Predefined OUs and Other Containers
The objects in a domain should reside in containers instead of at the domain level, just as files on disk should reside in folders instead of in the root folder. Accordingly, the predefined objects are stored in containers below the domain level. Table 3.1 describes the five predefined containers. Because they have extra system-flags protection, you cannot rename, move, or delete them—they are always there (unless you redirect some of them, as explained a little later in the section "Redirecting the Users and Computers Containers to OUs").
Table 3.1. The Predefined Containers in Active Directory
|
Container |
OU |
Purpose |
Possible Contents |
|---|---|---|---|
|
Builtin |
No |
This is a container for the predefined built-in local security groups (you cannot create them yourself). |
Computer, group, user, inetOrgPerson |
|
Computers |
No |
This is a default container for computer objects corresponding to Windows NT/2000/XP workstations and member servers in this domain. |
Computer, contact, group, printer, user, inetOrgPerson, shared folder |
|
Domain Controllers |
Yes |
This is a default container for computer objects corresponding to domain controllers of this domain. |
Computer, contact, group, OU, printer, user, inetOrgPerson, shared folder |
|
Foreign Security Principals |
No |
This is a container for placeholders that represent group members from domains external to the forest. This includes well-known security principals, such as Authenticated Users, if they are members of some group in the domain. [*] Objects in this container are visible only when the snap-in's Advanced Features are turned on. |
Computer, contact group, printer, user, inetOrgPerson, shared folder |
|
Users |
No |
This is a default container for users and groups. |
Computer, contact, group, printer, user, inetOrgPerson, shared folder |
In Table 3.1, the Possible Contents column lists the object types (that is, classes) that you can create in the corresponding container using the Users and Computers snap-in. With an "under-the-hood" tool, such as ADSI Edit, you could create other types of objects. However, there is no need to use the predefined containers for anything but what is described in the table.
You shouldn't use the Builtin container for anything, even though it is possible to create computers, groups, and users in it. Likewise, you could create users in the Computers container or computers in the Users container, but there is no point in doing so. Putting such things together is comparable to placing your cookbooks and music CDs on the same shelf. It is possible, but why do it?
If you want, you can keep your users in the Users container and computers in the Computers container. If you do so, however, you can neither create OUs in them nor assign Group Policy for them, because these containers are not OUs. If you have more than 20 users, for example, and you want to delegate some administration, you will probably end up creating new OUs for your users and computers (i.e., outside the Users or Computers containers). We will come back to this issue in the "Administering OUs" section later in this chapter.
The Domain Controllers container is an OU, and therefore you can create OUs in it and assign Group Policy(ies) for it. This OU already has a Default Domain Controllers Policy Group Policy object (GPO) assigned, which affects the security and other settings of your domain controllers. You are likely to keep the computer objects for your domain controllers in this container and other OUs that you create below it.
Why These Containers?
It may seem that the way these predefined containers were chosen is odd. Why are most of them not OUs? Some explanation is given by the fact that these containers ease the upgrade from Windows NT to Active Directory. During the upgrade process, the old user accounts and groups are migrated to the Users container, old workstation and member server accounts are migrated to the Computers container, and old domain controller accounts are migrated to the Domain Controllers container.
In addition to migration, the default Users and Computers containers are also used whenever users, groups, and computers are created using downlevel tools. Such tools are Windows NT User Manager and Server Manager, Net commands (Net User, Net Group, Net Localgroup, Net Computer), Windows Support Tools NetDom Add command without the /OU switch, and any tool that uses the old Windows NT APIs to create these objects. Also, when a Windows NT/2000/XP workstation joins a domain and there is no precreated computer account, the account will be created in the default Computers container.
In Windows NT, built-in local groups were internally stored separately from other groups, users, and computer accounts. This separation was brought over to Active Directory in the form of the Builtin container.
So why are these three containers not OUs? One explanation could be that this way you are intentionally discouraged from using them in the long run and you must create new OUs instead.
Redirecting the Users and Computers Containers to OUs
If your domain is on the Windows Server 2003 functional level, you can redirect the predefined Users container and the Computers container to OUs you have created. After the redirection, these new OUs will be the default containers for users, groups, and computers. For example, you can create the Employees OU and the Workstations OU, and then perform the redirection using the following commands:
redirusr OU=Employees,DC=Sanao,DC=com redircmp OU=Workstations,DC=Sanao,DC=com
During the redirection, the system-flags protection is moved from the old default containers to the new ones. Therefore, you could rename or delete the old containers.
The predefined Users container and Computers container don't allow you to apply group policies to them, but if you perform the redirection to a normal OU, you can apply group policies. On the other hand, if your users and computers are already in normal OUs and you don't use any tools that would create new users or computers in the default containers, there is not much advantage in the redirection.
For more information, see the Microsoft Knowledge Base article 324949 at http://www.microsoft.com.
Predefined Users
Two user objects are always present: Administrator and Guest. You cannot delete either of them, but you can rename them at will. Renaming Administrator offers some extra protection because a potential network intruder would need to guess the new name in addition to the password. However, if you have a large network and many administrative personnel, it may be confusing for the Administrator account to have a different name.
The default permissions of Active Directory allow any user of the forest to see the names of administrative accounts, so renaming them is really minimal "protection." You can think of it as adding a small extra hurdle in a potential intruder's path. If you chose permissions compatible with pre–Windows 2000 servers, anonymous users can also see this information.
Active Directory has predefined user accounts besides Administrator and Guest, depending on what services are installed. Table 3.2 lists the typical predefined user accounts in Active Directory.
Table 3.2. The Predefined User Accounts in Active Directory
|
Name |
Present |
Description |
|---|---|---|
|
Administrator |
Always (although could be renamed); cannot be disabled in AD2000 but can be disabled in AD2003 |
The only user account you can use when you log on for the first time. The Administrator account of the first domain in a forest has the widest possible administrative permissions on Active Directory and the domain controllers in the same forest. You can create other user accounts with permissions as wide. The Administrator accounts of the later domains in a forest have the widest possible administrative permissions for their own domains. |
|
Guest |
Always (although could be renamed); disabled by default |
If someone doesn't have a user account, he can use the Guest account (if the account is enabled). (See the discussion in the text.) |
|
IUSR_servername |
One for each domain controller that has IIS installed |
If IIS allows anonymous access (e.g., by Web browsers), anonymous users use permissions of this user account. |
|
IWAM_servername |
One for each domain controller that has IIS installed |
IWAM stands for IIS Web Application Manager. The IISWAM. OutofProcess Pool component (part of IIS) uses this user account. |
|
krbtgt |
Always; disabled by default; hidden by default; cannot be enabled or renamed |
The Kerberos key distribution center (KDC) uses this account. "Krbtgt" is part of the KDC's service principal name (SPN). Also, a symmetric key is derived from the password of krbtgt, and this key is used to encrypt and decrypt TGTs. Only the KDC knows this password and it changes the password periodically. |
|
TsInternetUser |
For Windows 2000 Terminal Services |
When an optional Internet Connector license is enabled, Terminal Services clients are not prompted with a logon dialog box. Instead, they are logged on automatically with the TsInternetUser account. |
If you enable the Guest account, be careful about the permissions you give to it or the Everyone group (and in AD2000 also to the Domain Users or Users groups). After all, anyone who "walks in the door" can use the Guest account. There are two ways to use the Guest account.
-
If your workstation is a member of a domain of the forest where the Guest account is enabled (in some of its domains), you just type "guest" in the logon dialog box, select the correct domain, and start using the workstation and the network.
-
If your workstation is in a workgroup or in a different forest from the one in which the Guest account is enabled (in some of its domains), you first need to log on with some other user account. When you connect to the resources of the domain where the Guest account is enabled, you are granted access based on that Guest account's permissions. You never type "guest" anywhere—you just use "Jack," for example. When the server doesn't recognize "Jack," it switches to use "Guest" automatically. The catch is that if there is another Jack, who most likely uses a different password, you are denied access. The server just thinks that someone is trying to crack Jack's account and doesn't use Guest at all.
Predefined Groups
Active Directory includes predefined security groups. Some of them reside in the Builtin container and the rest reside in the Users container, as follows:
-
Builtin: Built-in local security groups
-
Users: Mostly global security groups
The primary purpose of most of these predefined groups is to be the means by which administrative rights and permissions are assigned. To be anything more than an end user in the network, a user needs one or more of the following types of permission or rights:
-
User rights, such as permission to change the system time or log on locally. These rights are controlled with Group Policy settings and/or local policy settings. There are also some fixed rights. For example, only members of the Administrators group can format hard drives, and you cannot give this right to anyone else.
-
Administrative permissions (i.e., the ability to create, delete, change, and so on) for Active Directory objects.
-
Administrative permissions for registry keys.
-
Administrative permissions for folders and files.
-
Administrative permissions for other resources (printers, for example).
Most of the predefined groups have specific administrative rights or permissions associated with them, so you can give some users the appropriate rights and permissions by adding their names to the corresponding groups. Instead of worrying about all of the items in the list individually, it is far easier to just put Jack in the Account Operators group and Jill in the DNS Admins group, for example. They will get suitable permissions in one package.
Sticking just to "predefined" doesn't get you through life, though—at least not with Active Directory. You often need to assign individual rights and permissions, probably not using the predefined groups. But that's another story for another chapter (Chapter 4, to be exact).
Figure 3.2 shows the relationship among the groups in the Builtin and Users containers in an Active Directory domain. It also shows the corresponding relationships that existed in Windows NT.
)
Figure 3.2 In Windows NT, the only meaning of predefined global groups (Domain Admins, Domain Users, and Domain Guests) was that they
were members of some built-in local groups, which in turn had rights to administer the system. This is true also for Active
Directory, but in addition both group categories have certain direct permissions to Active Directory objects.
In addition to the permissions and rights shown in Figure 3.2, built-in local (security) groups have permissions for system files and registry keys.
In Windows NT it was easy to make a user of another domain an administrator in a local domain. It only required making him a member of the Administrators group in the local domain. Because of the difference in how global groups get permissions, as illustrated in Figure 3.2, this is more difficult in Active Directory. If you make the foreign user a member of Administrators in Active Directory, he won't get the permissions of Domain Admins, so he will be only a partial administrator. You cannot make him a member of Domain Admins, because that group accepts members only from the same domain. Note that this note only applies to the administrative privileges for the domain account database and domain controllers. It doesn't apply to the administrative privileges for any member servers or workstations.
Predefined Built-in Local Security Groups
Table 3.3 describes the predefined groups in the Builtin container. You cannot delete, rename, or move any of them, because of their system-flags protection. Note that each group in the table is always present in all domains. They have rights and/or permissions to their local domain only, and those rights/permissions apply only on the domain controllers. For example, the Remote Desktop Users group members can use the remote desktop of the domain controllers of the domain in question.
Table 3.3. The Predefined Built-in Local Security Groups
|
Name |
Predefined Members |
Abilities [*] |
|---|---|---|
|
Administrators |
Administrator, Domain Admins, Enterprise Admins |
By default, members of this group have almost total control of the domain controllers of the domain, including formatting hard drives and all the rights that the following four "operators" have. For Active Directory, this group has by default "Full Control except Delete Subtree or Delete All Child Objects" permission for almost all objects in the domain. |
|
Account Operators |
None |
By default, members of this group can create, delete, and manage user, inetOrgPerson, group, and computer objects in the Active Directory domain, except in the Domain Controllers OU. Account operators can log on locally to domain controllers of the domain and shut them down. In Windows 2000, Account Operators can modify their own account and the accounts of other account operators. However, they cannot modify administrator accounts. Starting with Windows 2000 SP4 and Windows Server 2003, Account Operators cannot modify account operators. For more information, see the "AdminSDHolder Object" section in Chapter 4. |
|
Server Operators |
None |
In the domain controllers of the domain, members of this group can create, delete, and manage file shares and printers, and start, stop, and configure services. Also in the domain controllers, they can log on locally, back up and restore files, change computer time, and shut down the domain controller either locally or remotely. Note that the list here is descriptive, but not quite exhaustive. |
|
Backup Operators |
None |
By default, members of this group can back up and restore files and folders in the domain controllers of the domain, even if the member user doesn't have permissions for those files and folders. They can also log on locally on the domain controllers of the domain and shut the domain controllers down. |
|
Print Operators |
None |
Members of this group can create, delete, manage, and share printers in the domain controllers of the domain, and by default they can create, delete, and manage printer objects in the Active Directory domain. They can also log on locally on the domain controllers of the domain and shut the domain controllers down. |
|
Users |
Domain Users, Authenticated Users, Interactive |
By default, this group has no user rights or permissions. You can just ignore this group. [**] If you want to give permissions to all forest users, you can use Authenticated Users. You can also create groups such as SanaoUsers or SanaoBostonUsers and use them instead of the predefined Users group. |
|
Guests |
Guest, Domain Guests, IUSR-_servername, IWAM_servername (in AD2000) |
By default, this group has no rights or permissions. You can just ignore this group. |
|
Pre-Windows 2000 Compatible Access |
Everyone [***] and Anonymous Logon, if you selected "Permissions compatible with pre-Windows 2000 server operating systems" when you installed the domain; otherwise, Authenticated Users (the latter is the default) |
By default, this group has permission to see all the objects in a domain and all the properties of all users, inetOrgPersons, and groups. Everyone/Anonymous need these permissions if you have certain server services (e.g., Remote Access Service) running on Windows NT servers in your Active Directory domain. |
|
Replicator |
None |
Windows NT servers and workstations use this group for the Directory Replicator service. |
|
Remote Desktop Users |
None |
Members of this group are allowed to use the Remote Desktop connection. |
|
Network Configuration Operators |
None |
Members of this group can modify the local TCP/IP settings and some other network settings of the domain control lers. For a complete list, see Microsoft Knowledge Base article 297938. |
|
Performance Monitor Users |
None |
Members of this group can use the Performance console, or perform similar monitoring with another tool. |
|
Performance Log Users |
Network Service |
Members of this group can use the Performance Logs and Alerts console, or perform similar monitoring with another tool. |
|
Incoming Forest Trust Builders |
None |
This group appears only in the forest root domain. The members can create incoming, one-way trusts to the forest. |
|
Windows Authorization Access Group |
Enterprise Domain Controllers |
Members of this group can read the constructed tokenGroupsGlobalAndUniversal (TGGAU) attribute on user, inetOrgPerson, group, and computer objects. TGGAU contains a list of the object's global and universal group memberships, and an application can use this information, for example, to make decisions about users that are not logged on. The Pre-Windows 2000 Compatible Access group can also read TGGAU, but if the application is not in that group, you could use the Windows Authorization Access Group instead. For more information, see Microsoft Knowledge Base article 331951. |
|
Terminal Server License Servers |
None |
This group is used for Terminal Server licensing. |
In the next chapter, we describe in more detail the default user rights and default Active Directory permissions of the groups in Table 3.3.
Predefined Groups in the Users Container
The remaining predefined groups are in the Users container. They are mostly global security groups, but there are also some domain local security groups. Table 3.4 describes the predefined groups in the Users container of a domain.
Table 3.4. The Predefined Groups in the Users Container
|
Name |
Predefined Members |
Description |
|---|---|---|
|
Enterprise Admins |
Administrator of the first domain of the forest |
Members of this group can administer all the domains in the enterprise. By default, this group is a member of Administrators in all domains of the forest. Enterprise Admins has Full Control to practically all objects in all domains of the forest. In addition, membership in this group is necessary to create child domains or sites. This group appears only in the first domain of the forest (that is, the forest root domain.) |
|
Schema Admins |
Administrator of the first domain of the forest |
Members of this group can modify the schema of the forest. This group appears only in the first domain of the forest (that is, the forest root domain.) |
|
Domain Admins |
Administrator |
Members of this group can administer this domain. By default, this group is a member of Administrators in this domain and all joined workstations/member servers. Domain Admins has Full Control to most objects of the domain. |
|
Group Policy Creator Owners |
Administrator |
Members of this group can create Group Policy objects if they also have appropriate permissions for the OU for which they are creating the GPO. In addition, they can manage the GPOs they have created. |
|
Domain Users |
Every user account of the same domain |
By default, this group has no rights or permissions. You can use it if you need to give permissions to all users of the domain. |
|
Domain Guests |
Guest |
By default, this group has no rights or permissions. You probably don't need this group. |
|
Domain Controllers |
Each domain controller of the same domain |
By default, this group has no rights or permissions. You can use it if you need to give permissions to all domain controllers of the domain. |
|
Domain Computers |
Each workstation and member server of the same domain |
By default, this group has no rights or permissions. You can use it if you need to give permissions to all workstations and member servers of the domain. |
|
Cert Publishers |
Each computer that is running an enterprise certificate authority |
By default, this group has permission to read and write the userCertificate property of the users and computers in the domain. Therefore, members of this group can publish certificates for users and computers. |
|
DnsUpdate Proxy |
None |
DHCP servers may dynamically register DNS resource records on behalf of DHCP clients. In this case, the DHCP servers become the owners of those records. This is a problem if the client or some other DHCP server later wants to start maintaining those records. By placing the computer objects of the DHCP servers as members in this group, the servers won't become record owners, so the problem described here is resolved. This group is missing if there is no DNS service in the domain. |
|
IIS_WPG |
None |
The IIS_WPG group (worker process group) appears with Internet Information Services (IIS) 6.0, and it is used for the needs of IIS. |
|
DnsAdmins |
None |
Members of this group can administer the DNS service. This group is missing if there is no DNS service in the domain. |
|
RAS and IAS Servers |
Each computer that is running the Routing and Remote Access Services (RRAS) |
By default, this group has permission to read Logon Information, Remote Access Information, Group Membership, and Account Restrictions of all users of the domain. RRAS servers need those permissions. |
When you install the first domain of the forest, Enterprise Admins and Schema Admins are global groups. When you later change this domain to the Windows 2000 native or Windows Server 2003 functional level (as discussed in Chapter 2), those groups will change to universal groups, which allows them to have members from other domains.
By default, Domain Admins is a member of the Administrators group of all workstations and member servers. Similarly, Domain Users is a member of the Users group of those computers.
Figure 3.3 illustrates the memberships of some predefined users, global groups, and built-in local groups that are listed in Tables 3.2 through 3.4.
)
Figure 3.3 The predefined users and groups have several predefined memberships. In addition, any new user is a member of Domain Users.
In Chapter 4, we discuss the well-known security principals. Many of them are like groups, and you can assign permissions to them. They are not real groups, however, because the operating system, not a network administrator, controls their "membership."
Well-known security principals include Authenticated Users and Everyone, which you already saw as group members in Table 3.3 and Table 3.4. Therefore, we have included Figure 3.4 to illustrate those memberships here, even though the remaining discussion is in the next chapter.
)
Figure 3.4 The well-known security principals Authenticated Users, Everyone, and Anonymous Logon can be seen as part of the membership
hierarchy. However, their "membership" is controlled by the operating system, not by a network administrator.
In AD2000, Anonymous Logon is a "member" of Everyone. In AD2003, the security was tightened, and the "membership" is true only if you enable the security policy "Network access: Let Everyone permissions apply to anonymous users." This policy is located in Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. See Chapter 7 for more information on policies.
Figure 3.4 reveals the memberships for the various end-user groups. Table 3.5 lists the end users (users of the group's domain, users of the whole forest, and so on) that are members of each user group.
Table 3.5. End-User Memberships
|
Group |
Type |
All Users in Group's Domain |
All Forest Users |
Guest |
Anonymous |
|---|---|---|---|---|---|
|
Everyone |
Well-known |
X |
X |
X |
(see the Note) |
|
Users |
Built-in local |
X |
X |
only in AD2000 |
|
|
Authenticated Users |
Well-known |
X |
X |
||
|
Domain Users |
Global |
X |
only in AD2000 |
Typically, an administrator uses Authenticated Users to assign permissions to all users of a forest and Domain Users to assign permissions only to the users of one domain.
Predefined Computer Objects
In the beginning, there is just one computer object. It is for your first (and at that point, only) domain controller in the Domain Controllers container.