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