- User and Group Accounts
- Understanding Active Directory
- Understanding and Implementing Policy
- Practice Questions
- Need to Know More?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding Active Directory
Windows 2000's Active Directory goes far beyond what the Security Accounts Manager (SAM) database does for Windows NT 4. SAM and Active Directory both store security account information for users, groups, computers, and user rights, but that's where the similarity ends. Active Directory's database stores objects that represent enterprise resources, including users, groups, computers, printers, folders, applications, connections, security and configuration settings, and network topology. For each of these types, or classes, of objects, Active Directory can store numerous properties, or attributes. So a user account is far more than a username and password; it is information about the user's mailbox, the user's address and phone number, the role of the user within the organization (including the user's manager and location), and far, far more.
As a central store of information related to the enterprise network, Active Directory allows administrators to create a virtual representation or model of the enterprise—linking various objects together, grouping objects based on how they are administered, and structuring the enterprise information technology (IT) to best support the organization's goals. In addition, Active Directory's database is extensible, which means you can customize and append it with additional attributes and object classes. So if an organization wants to keep track of salary information for each employee, it can simply extend the information that Active Directory stores about employees to include salary or, better yet, purchase a payroll application that is Active Directory aware and can automatically extend the directory appropriately.
A database is of no use if it simply stores information. One must be able to somehow access and manipulate that information in the database, and Active Directory includes numerous services, most based on Internet standard, that allow you to do just that. To provide the functionality required to search or query a database for a particular enterprise resource, locate that resource out on the network, manage that resource's record in Active Directory, and ensure that the record is consistent throughout the network.
Active Directory's database and services reside on servers that have been designated domain controllers. Unlike with Windows NT 4, Windows 2000 domain controllers are not created while the operating system is installed. Rather, a functioning server is promoted to act as a domain controller, at which time it obtains a copy of Active Directory and launches the required services. Also unlike with NT 4, there is no "primary" domain controller. All domain controllers can write to the directory. Therefore, a change to the domain is replicated to all domain controllers, making Active Directory a multimaster replication model.
For the Windows 2000 Professional exam, it is important that you have a basic understanding of Active Directory's structure, which, like that of Windows NT 4, begins with a domain. The domain is the fundamental administrative, security, and replication unit of Active Directory. The domain is specified by two names: its down-level Network Basic Input/Output System (NetBIOS) name—such as CONOSCO, which was also used in NT 4—and its DNS name, such as conosco.com. DNS is the primary name resolution methodology in Windows 2000.
When an enterprise decides to implement a multidomain model within its Active Directory database, it creates what are called domain trees or forests. Multidomain models, however, fall outside the scope of the Windows 2000 Professional exam, so this chapter focuses on what you need to know in a single-domain environment.
In a single domain, Active Directory can contain millions of objects. To increase the manageability of those objects, you can place them in containers called OUs. OUs can contain other OUs, allowing a nested, hierarchical structure to be created within a domain (see Figure 3.2).
)
Figure
3.2 An example of an Active Directory domain that contains several OUs.
An enterprise uses its OU structure to control the administration and configuration of objects in the enterprise. For example, the organization depicted in Figure 3.2 might give an IT Admins group full control over the OUs displayed, which would allow that group to create, delete, and fully manage all the objects within those OUs. A Help Desk group might be given permission to reset passwords for user objects in the Finance and Marketing OUs and to put users in those OUs into groups based on the resource access they require. Workstations in the Finance OU could be configured to limit which users are allowed to log on locally. And users in the Payroll OU might have the payroll application installed on their machines, all through properties of the OU.
The OUs' virtual model of administration and configuration offers enormous flexibility and simplifies the effort it takes to manage large and small networks. As objects are moved between OUs, they are administered and configured differently. For example, referring to Figure 3.2, if a user named Jane is moved from the Production OU to the Payroll OU, the payroll application is deployed automatically. In addition, the Help Desk can reset Jane's password because, by default, properties of OUs (including delegated administrative permissions) are inherited from their parent OUs. If the computer PRO3 is moved from the Accounts Receivable OU to the Marketing OU, the limitation on which users can log on locally (which it was inheriting from the Finance OU) is removed.
The complexities and mechanics of designing and implementing Active Directory are not among the objectives of the Windows 2000 Professional exam. However, it is important that you realize that within a domain, you can use OUs to control administration and configuration of all objects, including users and computers, and that OUs by default inherit the administrative and configuration properties of OUs higher up in the OU structure. You will see these concepts in action in the section "Group Policy," later in this chapter.