Designing active directory for security
Download
1 / 47

Designing Active Directory for Security - PowerPoint PPT Presentation


  • 118 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Designing Active Directory for Security' - ulmer


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Designing active directory for security
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
Designing Your Forest Structure

  • Active Directory design basics

  • Deploying a single forest

  • Deploying multiple forests



Deploying a single forest
Deploying a Single Forest

  • The most common configuration for deploying Active Directory

  • Shares information across every component domain in the forest


Shared information
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
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
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
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
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
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
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
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
Designing the Domain Structure

  • Deploying a single domain

  • Deploying multiple domains


Making the decision advantages of a single domain
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
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
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
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
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 Policy

  • Account Lockout Duration

  • Account Lockout Threshold

  • Reset Account Lockout Counter After


Kerberos policy
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
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
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
Designing an OU Structure

  • Planning for delegation of administration

  • Planning for Group Policy deployment


Planning for delegation of administration microsoft windows 2000
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
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
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
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
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
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.



Applying the decision delegation of administration design at wide world importers
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.



Planning for group policy deployment
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.




Making the decision ou group policy requirements
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
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




Designing an audit strategy
Designing an Audit Strategy

  • Configuring auditing settings


Audit strategy overview
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 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
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
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
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
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
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


ad