1 / 47

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. Active Directory design basics Deploying a single forest Deploying multiple forests.

ulmer
Download Presentation

Designing Active Directory for Security

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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

More Related