Chapter 2 PowerPoint


Designing Active Directory for Security

Designing Your Forest Structure

Designing Your Domain Structure

Designing an OU Structure

Designing an Audit Strategy

Designing Your Forest Structure

Active Directory design basics

Deploying a single forest

Deploying multiple forests

Forest with Domain Trees

Deploying a Single Forest

The most common configuration for deploying Active


Shares information across every component domain in the forest

Shared Information


Defines all classes and attributes used within the forest


Maintains a listing of all domains and sites within a forest

Global catalog

Maintains a partial set of attributes for all objects

Inter-Domain Trusts

Domains are joined together by Kerberos v5 transitive trust relationships.

Microsoft Windows NT 4.0 domain trusts are not transitive in nature.

Making the Decision: Single Forest

Uses the same software across the organization

Minimizes forest-wide configuration

Reduces the management of forest-wide administrative groups

Allows single, enterprise-wide searches

Reduces management of trust relationships

Applying the Decision: A Single Forest at

Wide World Importers

No business case exists that would require the deployment of multiple forests.

Having distribution and service centers spread across national boundaries is not a business reason for creating separate forests.

Standardizing applications and the need for centrally managed user accounts indicates a need to implement a single forest.

Implementing Multiple Forests in Limited


Decentralized organizations that perform most of their network operations within their own sector of the organization

An ISP that does not want a common directory for all of its clients

Disadvantages of Deploying Multiple


A more complicated and expensive domain structure

Additional management costs for forest-wide components

Additional management costs for trust relationships

Limited use of user principal names (UPNs)

Smart card limits

Making the Decision: Possible Reasons for

Multiple Forests

Short-lived joint ventures

Mergers between companies running separate Active


Disagreement on change policies

Differing schema requirements

Distrust among administrators

Scope of transitive trust relationships

Limited replication of the global catalog

Need for preventing user accounts from appearing in the global catalog

Deploying Multiple Forests at Wide World


Deploy multiple forests if a merger takes place, due to either takeover or acquisition, where the other organization has already deployed Microsoft Windows

2000 Active Directory.

During the initial period, maintain separate forests to allow connectivity between the two forests.

Define explicit trust relationships between domains where resource access must take place.

To merge the two forests, analyze schema modifications to ensure a smooth transition to a single forest.

Designing the Domain Structure

Deploying a single domain

Deploying multiple domains

Making the Decision: Advantages of a

Single Domain

Reduces management of the forest

Reduces the number of required domain controllers


Reduces the dependency on global catalog servers for authentication

Provides an easier migration path to multiple domains

Applying the Decision: Using a Single

Domain at Wide World Importers

Initially start with a single domain.

Business objectives may require the implementation of multiple domains.

It is easy to migrate from a single domain to multiple domains.

No additional costs involved with initially deploying a single domain.

Deploying Multiple Domains

Implement multiple domains when there is a requirement for differing account policies.

Account policies cannot be varied within a single domain.

Understanding Account Policies:

Categories of Configuration

Password Policy

Defines the characteristics of passwords that may be used to authenticate to the domain

Account Lockout Policy

Defines what actions must be taken when a specified amount of failed logon attempts take place in a short duration of time

Kerberos Policy

Defines the maximum ticket lifetimes for Kerberos authentication and tolerances for clock synchronization between client computers and servers

Password Policy

Enforce Password History

Maximum Password Age

Minimum Password Age

Minimum Password Length

Passwords Must Meet Complexity Requirements

Store Password Using Reversible Encryption For All

Users In The Domain

Account Lockout Policy

Account Lockout Duration

Account Lockout Threshold

Reset Account Lockout Counter After

Kerberos Policy

Enforce User Logon Restrictions

Maximum Lifetime For Service Ticket

Maximum Lifetime For User Ticket

Maximum Lifetime For User Ticket Renewal

Maximum Tolerance For Computer Clock


Making the Decision: When to Deploy

Multiple Domains

Differing account policies

Replication issues

International considerations

Political reasons

Separate enterprise administration accounts

Applying the Decision: Multiple Domains at Wide World Importers

Separate account policies need to be defined for the

Engineering department.

Separate domains are not required based on offices in both the United States and Canada.

The current utilization of WAN links between offices is sufficient to support replication of a single domain.

The organization can deploy either a two-domain or three-domain forest.

Designing an OU Structure

Planning for delegation of administration

Planning for Group Policy deployment

Planning for Delegation of Administration:

Microsoft Windows 2000

Design is based on the ability to delegate administration to

Specific OUs

Specific objects within an OU

Specific attributes of an object

Planning for Delegation of Administration:

Microsoft Windows NT

Microsoft Windows NT required that administration be delegated by creating resource domains.

Windows NT resource domains often led to excessive user rights being assigned and excessive resource domains being created.

The Delegation Of Control Wizard

Used to delegate administration to specific OUs

Allows you to delegate the management of Active

Directory objects

Accessed by right-clicking a container in Active

Directory Users And Computers and selecting

Delegate Control

Default Options Set by the Delegation Of

Control Wizard

Users Or Groups

To Delegate Tasks

Custom Tasks

Custom Permissions

Making the Decision: Delegation of

Administration Overview

Delegate minimum rights.

Delegate rights to specific users or groups.

Do not assign rights based on the Account Operators or Server Operators groups.

Test the design.

Audit success and failures for directory management.

Enable success and failure audits for directory service access on the OU.

Making the Decision: Delegation of

Administration Design

Determine to which users administration will be delegated.

Determine where to delegate administration in the

OU hierarchy.

Determine which types of objects to delegate for administration.

Determine the required minimum set of rights.

Delegating Administration in the OU


Applying the Decision: Delegation of

Administration Design at Wide World


Business requirements

Create an OU structure for the Engineering domain that allows a nominated user to maintain group memberships of the Engineering user accounts for their distribution center.

Require the head of the IT department for Engineers at the

Washington office to manage all Engineering accounts within the domain.

OU structure facilitates the required delegation of authority required by the Engineering department.

Engineering Users OU

Planning for Group Policy Deployment

Group Policy can be applied to local computers, sites, domains, and OUs.

Group Policy can be configured for both users and computers.

An OU structure can ultimately separate computers and users into different OUs.

Group Policy Applied in a Specific Order

Group Policy Inheritance

Making the Decision: OU Group Policy


Create an OU structure that does not require blocking inheritance.

Limit the use of Site Group Policies in a multipledomain environment.

Limit the number of OU levels where the Group Policy is applied.

Apply only the necessary settings.

Applying the Decision: OU Design Based on Group Policy at Wide World Importers

Two requirements necessitate configuration of Group

Policy at Wide World Importers:

Deployment of consistent security configuration for all computers

Deployment of software for users

OU Structure for the Deployment of

Security Templates

OU Structure for the Deployment of


Designing an Audit Strategy

Configuring auditing settings

Audit Strategy Overview

Auditing is used to track who accessed specific resources and who performed specific actions.

Tracked in the Security Log of the Windows 2000

Event Viewer.

Audit settings can be configured within the Audit


Indicate which individual objects are included in the audit.

Audit Policies for a Domain

Audit Account Logon Events

Audit Account Management

Audit Directory Service Access

Audit Logon Events

Audit Object Access

Audit Policy Change

Audit Privilege Use

Audit Process Tracking

Audit System Events

Making the Decision: Determining the

Audit Strategy

Determine where to apply the audit settings.

Define DC audit settings in the Domain Controllers


Collect computers with similar audit requirements into common OUs.

Do not audit all events.

Mix failure and success audits.

Match audit strategy to the organization's risk level.

Applying the Decision: Determining the

Audit Strategy for Wide World Importers

The current network deployment is only concerned with internal network auditing.

Less emphasis can be placed on auditing for external attacks.

Proposed Auditing Structure

Audit the following:

Failure of the account logon events

Success and failure of the account management events

Success and failure of the object access events

Success and failure of the policy change events

Success and failure of the system events

Audit Information Contained in the

Security Log

All account management tasks

Account logon event failures

Success and failure auditing for object access (if enabled)

Success and failure events for policy changes

Success and failure for system events

Chapter Summary

Deploying a single forest

Deploying multiple forests

Deploying a single domain

Deploying multiple domains

Designing the delegation of administration

OUs based on Group Policy requirements

Success or failure audits

Audit design strategy