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 Directory

Shares information across every component domain in the forest

Shared Information

Schema Defines all classes and attributes used within the

forest Configuration

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 Scenarios

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 Forests

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 Directories 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 Importers

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 (DCs) 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

Synchronization

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 Hierarchy

Applying the Decision: Delegation of Administration Design at Wide World Importers 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 Requirements

Create an OU structure that does not require blocking inheritance.

Limit the use of Site Group Policies in a multiple-domain 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 Software

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 Policy.

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 OU. 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