Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Active Directory: Organization, Structure, and Function

Active Directory provides a hierarchical directory for Windows 2000 and Windows Server 2003 domains. Objects in the directory, computers, users, shares, printers, and so on can be defined, managed, and secured using native tools. There are several security-specific characteristics:

Active Directory's hierarchical structure, flexible domain architecture, and replication and Group Policy functions allow granular configuration of security settings and automatic maintenance across large numbers of computers and users at far less administrative cost than would be possible without it.

Because its structure separates sites and domains and provides for the segmentation of domains into Organizational Units (OUs), administrative authority can be delegated.

Active Directory's reliance on DNS provides additional opportunities for security infrastructure and new potential vulnerabilities.

Kerberos-style transitive trust relations exist between domains within a forest, and access to resources within one domain can be granted to users from another domain.

Tight coupling of domain infrastructure within the forest enables potential breaches of domain boundaries by rogue administrators. The domain is not a rigid security boundary.

Trust relationship and critical security boundary issues will be covered in the next chapter.

Successful Active Directory designs and implementations are the result of applying key concepts and knowledge of the needs and requirements of the organization. Active Directory key concepts are as follows:

The hierarchical structure of Active Directory and its schema

Active Directory Replication

Group Policy structure and function

Delegation of Authority

Reliance on DNS

Hierarchical Structure

The Active Directory security boundary, or forest, is composed of one or more trees. Each tree represents a contiguous DNS namespace. For example, an Active Directory forest might be composed of two trees: the chicago.local tree and the sanfrancisco.local tree. The trees are joined during the creation of the second namespace. Within each tree, any number of domains can be added. Each domain will incorporate the name of its parent domain. Figure 7-1 shows a representative forest with several subdomains.

Each domain represents a logical division of the network and is represented by a security policy boundary. A security policy boundary is a part of the network that is bound by a common security policy. A security policy boundary differs from a security boundary because a trusted administrator in one security policy boundary might be able to breach another security policy boundary. The security of each domain relies on the cooperation and trustworthiness of its administrators and that of the other domain administrators in the forest.

The domain security policy is unique for each domain. A security policy defined in one domain has no bearing on the security policy of another domain, with one exception. Forest-wide permissions are granted by default to members of the Enterprise Admins and Schema Admins group. The privileges and rights that these group members hold define the forest-wide security policy. For example, a member of the Enterprise Admins group can modify security settings in any domain in the forest.

Domains can be further divided into logical units called OUs. Each OU can have a unique security policy. However, each OU is affected by the security policy of the domain. OUs can be subdivided into a hierarchical structure of child OUs.

NOTE: Security Policy Boundary

The term "security policy boundary" is not a Microsoft term. It is used in this book to define an area where a security policy applies. Security policy boundaries are defined in Active Directory by the forest, site, domain, and OU. It is a useful way to explain the difference between a security boundary, such as a forest (which also is a security policy boundary), and an area like a domain, where security policy can be uniquely applied and administered but that is not a security boundary. However, a security policy boundary is not a security boundary. The security policy implemented within the boundary may be the result of the application of a GPO, other configuration tools may have been used, and it may even consist of administrative policy that cannot enforce or is not enforced by technical controls. It also may consist of rights and privileges granted inherently, not configured. You should not equate a security policy boundary with a security boundary or with GPOs. It may be that you can implement the entire security policy by applying a GPO to a security policy boundary, but this is not necessarily the case.

Domains and OUs are logical boundaries in the forest. Sites represent physical boundaries. Sites roughly correspond to physical network locations. There may or may not be an exact one-to-one correspondence because sites are administratively defined, and there is nothing to prevent administrators from leaving all physical locations in one Active Directory site or dividing one physical location into multiple sites. Sites are defined by recording the physical subnets within their boundaries. A site may consist of only computers joined in a single domain or may include domain controllers or client machines from multiple domains. Figure 7-2 illustrates this fact. In the illustration, the downtown site includes Chicago.local DCs and a SanFrancisco.local DC. The burbs site just contains a Chicago.local DC. Sites are not designed to be security boundaries; however, a unique security policy can be defined for a site.

The information that describes Active Directory objects (sites, domains, OUs, user and computer accounts, information on printers, shares, applications and system services, and so on) is stored in the Active Directory database. The structure of these objects and the attributes that described them (and the permissions that can be applied to them) are defined in templates called classes. Each object class and its attributes are defined in the Active Directory schema.

The hierarchical structure of AD lends itself to delegation of authority and merged security policy. Administrative authority is by default structured to match the hierarchy and can be further delegated. Forest-wide administration and domain-wide administration are natively ascribed to Enterprise Admins and Domain Admins Windows groups, respectively. Custom Windows groups can be created, and control over subcontainers in the forest can be delegated to these groups. Security policies defined at higher levels in the forest can be merged with security policies applied at lower levels, although there are rules that constrain and precisely define the impact of multiple policies on objects such as users and computers. Security policy is applied by defining GPOs and linking them to appropriate containers.

Replication

Two types of replication are used in a Windows Server 2003 forest: Active Directory replication and file replication. Active Directory replication ensures that changes made to the database on one domain controller are transferred to all other appropriate domain controllers in the forest. Replication between domains located in the same site occurs automaticallyit is managed by the Knowledge Consistency Checker (KCC). The default implementation of Active Directory creates one site. However, additional sites may be added, and when they are, a site link, which manages replication between sites, is created. The creation of sites modifies replication patterns and both inter- and intrasite replication patterns, and schedules can be manually configured. File replication is managed by the File Replication Service and is used by default to replicate files necessary for forest functioning. It can also be manually configured and used to replicate other files.

Domain controllers (DC) contain a copy of AD. Each domain controller in the domain contains both AD information that is forest-wide, such as the schema and configuration data, and domain-specific data, such as user and computer accounts. For example, if new domain-specific information, such as a new user account, is added at a specific DC, the information will be shared with all DCs in the domain via replication. On the other hand, changes to the schema, such as new classes added during the installation of Microsoft Exchange Server, will be replicated to every DC in the forest.

Windows Server 2003 DCs also may contain an Active Directory Application partition. The application partitions make it possible to restrict application-specific data to only those DCs where it is desired. An example of an application partition might consist of the specification of which DCs would contain DNS data when DNS is integrated with Active Directory. In Windows 2000, AD-integrated DNS data is replicated to all domain controllers. However, with Windows Server 2003, you can specify which DCs will have a copy of the DNS data. The use of application partitions can improve replication performance because less data must be replicated to every DC.

Most replication in Active Directory is multimasterthat is, it can be created on any DC and is then replicated between all DCs in the domain; if it is not domain-specific, it is replicated among all domains in the forest. However, there are some exceptions to this rule. Two are especially important to a discussion of security: Global Catalog replication and the role of the PDC Emulator.

The Global Catalog server (GC) is a designated DC whose Active Directory database contains an additional partition. This partition hosts a record of all objects in the forest but does not include all of the attributes of all of these objects. The GC is important to forest-wide functioning because it provides enough information so that objects can be easily located within the forest, or so that objects that refer to objects in different domains have a centralized storage place. For example, when Universal groups (which can contain users from any domain in the forest) are assigned resource permissions, it must be possible during logon to discover any Universal group memberships that a user might have. It must be possible, for example, to search for a specific user account membership in Universal groups to assign them access to resources in other domains.

The GC role is not the only unique role that may be assigned to a DC. Five Flexible Single Master Operations (FSMOs) manage specific functions within the AD, and these roles are assigned to DCs. Another name for FSMOs often used in Microsoft documentation is Operations Masters. FSMOs and their roles are defined in Table 7-1.

Group Policy

Group Policy is an administrative tool that can be used to manage domain user and member computer accounts. A wide range of items can be managed, including the following:

Installing software on domain member computers

Applying startup and shutdown scripts

Applying security settings

Applying configuration settings as defined in administrative templates

Maintaining Internet Explorer settings

Restricting Remote Installation Services

Restricting which software can run

Providing for folder redirection

Group Policy Configuration and Inheritance

Configuring Group Policy consists of creating a Group Policy Object (GPO) and defining the settings for each of the items listed in the previous section. Two main divisions of the GPO exist: one that is applied to computers and one that is applied to users. Several default GPOs exist, including a local GPO for each Windows XP, Windows 2000, or Windows Server 2003 computer, and if a forest is established, a unique default domain GPO and unique default domain controller GPO for each domain in the forest.

A GPO can be linked to a site, domain, or OU object in the Active Directory. Windows 2000 documentation often refers to these containers by naming them in the order in which they are applied: local, site, domain, OU, and child OU. Instead of repeating the entire list of possible objects to which a GPO can be linked, or using the initials SDOU, Windows Server 2003 documentation refers to each of these containers as a Scope of Management (SOM). When a GPO is linked to an SOM, the policies within the GPO are applied to any user, group, or computer account that resides in the SOM. For example, if Mary's account is in the Accounting OU and Fred's is in the Users container of the domain, then a GPO linked to the Accounting OU will impact Mary's account but not Fred's. A GPO can be linked to many SOMs, and many GPOs can be linked to a single SOM.

NOTE: The User and Computer Containers Are Not SOMs

User and Computer containers in Active Directory are not SOMs; therefore, a GPO cannot be linked to them. User accounts in the User container are affected by site and domain GPOs, as are computer accounts in the Computer container. The Domain Controllers container is, however, a SOM (it's an OU). The default domain controller's GPO is linked to this container, and additional GPOs also can be linked there.

Because multiple GPOs exist by default, and more can be created, Group Policy rules define how settings are applied and what occurs when a conflict between settings in a GPO exists. Five main concepts apply.

First, the computer portions of a GPO are applied during boot, and the user portion of a GPO is applied during the user's logon process. This means that some parts of policy remain constant no matter which user logs on to a computer, and other parts are uniquely applied depending on the logged on user. During computer boot and logon or user logon, the relevant GPO GUIDs are collected from Active Directory. The policies are then downloaded from their location on a DC sysvol share. If a policy is changed, and the user or computer is still logged on, the process of applying these changes is begun approximately within five minutes on DCs and within 90 minutes on member computers. The security settings portion of AD is applied every 16 hours regardless of whether changes have been made to this section. However, how quickly a new Group Policy or changes to Group Policy are applied is a function of other higher priority activity occurring on the DC, replication processes, the refresh process, and what part of the GPO the policy changes reside in. The latency of GPO application needs to be considered when updating security policy. Knowing the replication latency for a specific network will help you understand normal delays in policy application. Remember that two types of replication, AD and FRS, impact GPOs. Active Directory replication and FRS must both be working correctly for security policy to be applied and maintained.

Second, when a GPO is created or modified in a Windows 2000 domain, the information is written by default to the domain controller that is the PDC Emulator. If and only if this DC is not available, an authorized administrator may select another DC. One feature that is new to Windows Server 2003 is that the default DC location for the creation of GPOs can be selected by an administrator who has the Create and Manage GPO right.

GPO information is written to two different placessome to Active Directory and some to the %windir%\SYSVOL folderas shown in Figure 7-3. Each GPO is given a unique GUID, or globally unique ID number, and this number is used to coordinate the parts of the GPOs. The information in Active Directory is replicated through the normal Active Directory Replication process. However, the information in the SYSVOL share is replicated to the %windir%\SYSVOL\sysvol folder (shared as SYSVOL) on each domain controller using the File Replication Service (FRS). Each policy is placed in this share within a folder named by the domain name. Any scripts are placed in the %windir%\SYSVOL\sysvol\scripts folder (the netlogon share) under that domain.

Third, a GPO will apply to all computer or user accounts that exist within the SOM to which the GPO is applied unless special options are set. Because some SOMs contain other SOMs (domains contain OUs, for example), multiple GPOs may be applied to computer and user accounts. You can determine which GPOs are applied to a specific account by applying the SDOU rule mentioned in the "Group Policy Configuration and Inheritance" section previously. First the local policy is applied, followed by the site policy, the domain policies, and then the OU policies. If, for example, Fred's user account is in the Accounting OU, which is a child OU, of the Finance OU in the Chicago domain, his account will have any local GPO, any site GPO, the default domain GPO, and any GPOs linked to the Accounting OU. Figure 7-5 illustrates this example. In the figure, Fred's user and computer account are located in the Accounting OU. The Accounting OU is a sub-OU of the Finance OU, and both are located in the Chicago.local domain. The Chicago.local domain has servers, users, and computers in the Downtown site and the Burbs site. Fred is affected by every GPO linked to SOMs within the hierarchy of the OU structure and the local GPO on the computer he logs on from. If Fred, who has an account in the Accounting OU of the Chicago.local domain and is sitting at a computer in the Burbs site, logs on, he will be affected by settings in the Local GPO of his computer and in any GPOs linked to the Burbs site, the default Domain Security Policy of the Chicago.local domain, and any GPOs linked to the Finance and Accounting OUs. If user and computer accounts exist in different OUs, the GPOs for those OUs are applied.

Fourth, while all of the relevant GPOs are applied and in essence merged, if a conflict exists, the last setting applied wins. Examples of policy conflicts are further discussed in Chapter 9.

Finally, in reality, many factors can affect the process of inheritance. Table 7-2 lists these issues.

Delegation of Administrative Authority

In versions of Windows prior to Windows 2000, administrative authority is defined for selected built-in groups (administrators, domain admins, server operators, account operators,) and accounts (Administrator, Guest). A custom group or new user account can be given some administrative authority by granting predefined user rights such as Add workstations to domain, or backup files and directories to a group or user account. In a Windows 2000 or Windows Server 2003 domain, an extremely granular level of administrative authority can be granted by modifying access control lists (ACLs) on Active Directory Objects. To simplify the process, the Delegation of Control Wizard can be used. Instructions on using this wizard to develop administrative roles in Windows Server 2003 can be found in the section "Delegation of AdministrationUsing the Delegation of Control Wizard."

Reliance on DNS

Active Directory forests are defined by DNS namespaces. Without access to a properly configured and active DNS server, Active Directory cannot function. Member computers cannot connect to the domain controllers, users cannot log on, and security policy cannot be applied. These functions can only occur if users and computers can locate the following services on the network.

_ldap
Necessary to use ldap to query AD.

_Kerberos
Necessary for Kerberos authentication.

_gc
The Global Catalog servers, necessary for lookup of forest-wide data including membership in Universal Groups (caching of Universal group membership is an option in Windows Server 2003 domains. If enabled, access to a global catalog server is not necessary at every logon.)

These services are advertised in DNS as Service locator (SRV) resource records, and an example is shown in Figure 7-6. Multiple servers that offer TCP/IP-based services can advertise the same service, and a single DNS request can locate them. Each SRV record in DNS includes the following:

DNS domain name

Service (many services are defined in RFC 1700)

Protocol (typically TCP or UDP)

Priority, which sets a preference among multiple servers offering the same service

Weight, which can be used with preference to provide load balancing (several servers with the same priority can be weighted so that one is chosen more or less frequently than the others)

Port number (service port on target host)

Host offering this service target or DNS host name, which provides the service

During logon, computer and user accounts query DNS for appropriate services, obtain the DNS name of the hosts offering them, select a host, and query DNS for the IP address of the host. The authentication process continues, and once authenticated, the current security policies or GPOs are downloaded and applied to the computer or user.

When DNS is not functioning due to misconfiguration or as the result of an attack, users may have trouble locating network resources, and security policy is not applied.