Managing OUs, Users, and Groups in Active Directory
- Active Directory after Installation
- Administering OUS
- Administering Users 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 six classes in the OUs you want:
- Users
- Contacts
- Computers
- Groups
- Shared folders
- Printers
This chapter covers managing OUs and the first four 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 four other classes (i.e., users, contacts, computers, and groups).
Finally, we discuss some additional features of the Users and Computers snap-in, and we 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 LDIFDE, CSVDE, scripting, or some Resource Kit tools. Although listed at the end of this chapter, these tools are covered later in the book.
NOTE
Behind the scenes, a domain object can contain objects of 23 classes and an OU can contain objects of 35 classes. However, with the Users and Computers snap-in, you can normally create and see objects of only the 7 classes just listed.
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 Programs, Administrative Tools, Active Directory Users and Computers.
){kind=link}
Figure 3.1 A newly installed domain (sanao.com in the figure), which is the root domain of a forest
TIP
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 (or group accounts)
One computer object (or computer account) for your domain controller
NOTE
Active Directory contains only objects. Users, groups, and computers, however, are often called accounts instead of objects.
If you upgrade a Windows NT 4.0 or 3.51 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. You cannot rename or delete them—they are always there.
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 |
|
Computers |
No |
This is a default container for computer objects corresponding to Windows NT/2000 workstations and member servers in this domain. |
Computer, contact, group, printer, user, 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, shared folder |
|
ForeignSecurity- 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, shared folder |
|
Users |
No |
This is a default container for users and Computer, contact, groups. |
group, printer, user, shared folder |
NOTE
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 4.0 or 3.51 to Active Directory. During the upgrade process, the old user and group accounts 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 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.
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.
NOTE
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 you installed in your server. Table 3.2 lists the 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 |
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.OutofProcessPool component (part of IIS) uses this user account. |
|
krbtgt |
Always; disabled 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 |
|
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. After all, anyone who "walks in the door" can use it. 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 Windows 2000. You often need to assign individual rights and permissions, probably not using the predefined groups. But that's a 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.
){kind=link}
Figure 3.2 I 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 Windows 2000, but in addition both group categories have certain direct permissions to Active Directory objects.
NOTE
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 a domain 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.
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. Note that each group in the table is always present in all domains. They have rights and/or permissions to their local domain only.
By default, members of the Administrators and four "operators" groups can log on locally to domain controllers.
NOTE
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.
NOTE
When you install the first domain of the forest, Enterprise Admins and Schema Admins are global groups. When you later change this domain to native mode (as discussed later in this chapter), those groups will change to universal groups, which allows them to have members from other domains.
Enterprise Admins and Schema Admins are present only in the first domain of the forest. The remaining groups are present in each domain, although the DNS groups are missing if there is no DNS service in the domain.
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.
){kind=link}
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" permission for almost all objects in the domain. |
|
Account Operators |
None |
By default, members of this group can create, delete, and manage user, group, and computer objects in the Active Directory domain. |
|
Server Operators |
None |
Members of this group can create, delete, and manage file shares, printers, and services in the domain controllers of the domain. |
|
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. |
|
Print Operators |
None |
Members of this group can create, delete, manage, and share printers in domain controllers of the domain, and by default they can create, delete, and manage printer objects in the Active Directory domain. |
|
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, TsInternetUser |
By default, this group has no rights or permissions. You can just ignore this group. |
|
Pre-Windows 2000 Compatible Access |
Everyone**, if you selected "Permissions compatible with pre-Windows 2000 servers when you installed the domain; otherwise, no members |
By default, this group has permission to see all the objects in a domain and all the properties of all users and groups. You 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. |
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.
){kind=link}
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. |
|
Schema Admins |
Administrator of the first domain of the forest |
Members of this group can modify the schema of the forest. |
|
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 (GPOs) if they also have appropriate permissions for the 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 |
By default, this group has permission to read and write that is running an the userCertificate property of the users and com-enterprise certificate puters in the domain. Therefore, members of this group authority can publish certificates for users and computers. |
|
DnsUpdateProxy |
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. |
|
DnsAdmins |
None |
Members of this group can administer the DNS service. |
|
RAS and IAS Servers |
Each computer |
By default, this group has permission to read Logon that is running the Information, Remote Access Information, and Account Routing and Remote Restrictions of all users of the domain. RRAS servers need Access Services those permissions. |
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.
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.
TABLE 3.5 End-User Memberships
|
Group |
Type |
Group's Domain |
All Forest Users |
Guest |
Anonymous |
|
Everyone |
Well-known |
X |
X |
X |
X |
|
Users |
Built-in local |
X |
X |
X |
|
|
Authenticated Users |
Well-known |
X |
X |
|
|
|
Domain Users |
Global |
X |
|
X |
|
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.
Changing the Domain Mode
An Active Directory domain is in one of two modes.
Mixed mode: This mode enables you to have Windows NT 4.0 and 3.51 backup domain controllers (BDCs) in the domain and to install new ones.
Native mode: In this mode, all current and future domain controllers must be running Windows 2000.
When you install a new domain, it first runs in mixed mode. You can change the domain's mode to native mode when you don't have old BDCs and you know for sure that you are not going to add any. The mode change is irreversible. Native mode is better, so when you start straight with Windows 2000, there is normally no reason not to change the mode right after you install each new domain.
While a domain is in mixed mode, you are subject to the following restrictions:
You cannot have universal security groups.
You cannot change the type or scope of any group.
You cannot nest groups, except that you can make a global group a member of a domain local group.
Domain local groups are not available in member servers or workstations.
If a Windows NT workstation is joined in a mixed-mode domain, it cannot fully benefit from the transitivity of trusts between domains. The domain list in the logon dialog box contains only the workstation's host domain and the domains that are directly trusted. Consequently, users from indirectly trusted domains (i.e., using transitive trusts) cannot log on to that workstation. The same indirectly trusted domains are missing also from the List Names From list of the User Manager and permission dialog boxes. Therefore, users of those domains cannot be members or have permissions in this workstation. However, a user on this workstation can access resources from indirectly trusting domains with the help of transitive trusts.
You cannot use per-user remote access policies.
You can have "only" 40,000 objects in your domain.
The SID History feature is not available. When SID History becomes available in native mode, you can move users from one domain to another so that they retain their old permissions for folders and other resources.
A global catalog server is not very "important." Once in native mode, a global catalog server must be contacted during each logon; otherwise, the logon will fail.
IF YOU KNOW NT
In mixed mode, you have the same groups as in Windows NT and they work exactly the same way.
If you don't want to test how things work in mixed mode, you can change your test domain to native mode at this point. To do so, perform the following steps.
Open the Users and Computers snap-in.
Right-click your domain object and choose Properties.
Click the Change Mode button on the General tab and confirm your selection by clicking the Yes button.
NOTE
If you are familiar with Windows NT, you might want to postpone changing the domain mode. This will help you learn in steps, because later in this chapter we explain how groups work in mixed mode. At that point, if your test domain is still in mixed mode, you will have an opportunity to try the familiar groups in a new environment. After that, you can switch to native mode and try the groups again, this time with the new features enabled.
If there is more than one domain controller in your domain, all other domain controllers will know about the new mode once the information has replicated to them. You will know that this replication has occurred when you see the text "Domain operation mode: Native Mode" in the domain properties dialog box. Note that you must connect to a specific domain controller with the Users and Computers snap-in to see the status of that domain controller.