The physical structure of Active Directory (AD) indeed stores information about objects on the network. Objects in Active Directory refer to the discrete components that are part of the network, such as
- printers, and
- other resources.
The physical structure of AD is defined by two core components: domain controllers and sites.
A domain controller (DC) is a server that responds to security authentication requests within a Windows Server domain. Each DC maintains a copy of the Active Directory database that stores all directory information for all objects within the domain, which includes user data, groups, application settings, and network resources.
The information about each object stored in the Active Directory database includes attributes that define the object. For example, a user object would include attributes such as username, full name, and password, among others. A printer object would include the printer's location, its IP address, and perhaps its print queue status.
Sites, another key part of the physical structure of AD, represent the physical structure or topology of your network. Active Directory uses site information to facilitate network traffic efficiency by enabling clients to log in to the nearest domain controller and to replicate directory data changes across wide area networks (WANs) efficiently.
In summary, the physical structure of Active Directory indeed plays a critical role in storing and managing information about network objects. It is fundamental to the directory's ability to organize, manage, and facilitate access to resources within a network environment.
Document your Active Directory site names and locations. Active Directory is the directory service for Windows 2000 and Windows Server 2003 family of products. It stores information about objects on the network. An Active Directory site is defined as one or more well-connected TCP/IP subnets. A well-connected TCP/IP subnet has a fast, reliable network connection.
The logical structure of your organization is represented by the following Active Directory components:
- Organizational units
The physical structure of your organization is represented by the following Active Directory components:
- Active Directory sites (physical subnets)
- Domain controllers
When planning your SMS hierarchy design, consider your Active Directory logical layout (hierarchical forest arrangement and domain structure), and its physical structure (Active Directory site topology). Later, when planning your SMS deployment and configuration, become familiar with the more granular details of the logical structure, such as organizational units, because these can help determine how you organize collections, distribute software, and perform queries in SMS.
Document your physical Active Directory structure and domain structure before you begin the planning phase.
It is important to keep in mind that certain Windows security policies can be set only at the domain level.
These include the settings in the Account Policies node:
- account policies,
- account lockout policies, and
- Kerberos policies.
This means that an Active Directory domain can have only one of these policies in effect at any given time: all users within a single domain will be bound to a single policy for elements like
- password length and complexity,
- frequency of password changes,
- PKI policies, and
- Kerberos settings.
The only exception to this is if you create a separate account policy on an Organizational Unit (OU) containing member servers. In this case, the local user accounts on machines within a given OU can have a different account policy apply to them. However, any domain accounts, even within a separate OU, will adhere to the domain account policy. If you have a significant portion of your user base that requires different policies for account passwords, lockouts, then you should consider creating a separate domain.
Because of the transitive trusts
created by Windows 2000 and Windows Server 2003, managing multiple domains isn’t nearly as tedious as it was under Windows NT. However, maintaining separate domains will still add a level of complexity to your Active Directory environment; be sure when planning your AD infrastructure that you carefully consider these domain-level policies before creating an unworkable Active Directory structure.