Designing Active Directory for Security

1
Designing Active Directory for Security

• Designing Your Forest Structure
• Designing Your Domain Structure
• Designing an OU Structure
• Designing an Audit Strategy

2
Designing Your Forest Structure

• Active Directory design basics
• Deploying a single forest
• Deploying multiple forests

3
Forest with Domain Trees
4
Deploying a Single Forest

• The most common configuration for deploying
  Active Directory
• Shares information across every component domain
  in the forest

5
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

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

7
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

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

9
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

10
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

11
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

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

13
Designing the Domain Structure

• Deploying a single domain
• Deploying multiple domains

14
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

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

16
Deploying Multiple Domains

• Implement multiple domains when there is a
  requirement for differing account policies.
• Account policies cannot be varied within a single
  domain.

17
Understanding Account PoliciesCategories 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

18
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

19
Account Lockout Policy

• Account Lockout Duration
• Account Lockout Threshold
• Reset Account Lockout Counter After

20
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

21
Making the Decision When to Deploy Multiple
Domains

• Differing account policies
• Replication issues
• International considerations
• Political reasons
• Separate enterprise administration accounts

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

23
Designing an OU Structure

• Planning for delegation of administration
• Planning for Group Policy deployment

24
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

25
Planning for Delegation of AdministrationMicroso
ft 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.

26
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

27
Default Options Set by the Delegation Of Control
Wizard

• Users Or Groups
• To Delegate Tasks
• Custom Tasks
• Custom Permissions

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

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

30
Delegating Administration in the OU Hierarchy
31
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.

32
Engineering Users OU
33
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.

34
Group Policy Applied in a Specific Order
35
Group Policy Inheritance
36
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.

37
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

38
OU Structure for the Deployment of Security
Templates
39
OU Structure for the Deployment of Software
40
Designing an Audit Strategy

• Configuring auditing settings

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

42
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

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

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

45
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

46
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

47
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