Secure your Active Directory Environment

Juan Martinez Information Security Consultant International Network Services

Agenda
Active Directory design issues Trust Relationships Schema Protection Firewall Considerations Protecting Service Management Group Policy Architecture System Hardening

Active Directory Design Issues

Security Boundaries
Forest security boundary Domain boundaries for administration Why is the forest the security boundary?
1. Forest-level service management 2. Implicit transitive trusts between all domains in a forest.

Forest-level Service Management

Implicit Transitive Trusts

Domain Trust Vulnerability

Users authorization data contains SIDs

Domain Trust Vulnerability

Trusting domain doesnt verify SIDs

Domain Trust Vulnerability

Solution: SID Filtering

Design Implications
You cant delete trusts between domains in a forest You cant implement SID Filtering between domains in a forest Well You can, but it will break stuff So a domain cant be considered a security boundary All Domain Admins must be trusted

Design Spec Empty Root

DMZ Considerations
Preferred > no AD systems in DMZ Extranet considerations
Separate forest to provide isolation Administrators that span forests should have separate accounts for each

Trust Relationships

Restricting Trust Relationships

SID Filtering
Enabled by default for external or forest trusts

Restricting Trust Relationships

Limit Trust
TopLevelExclusion Record

Selective Authentication vs. Forest-wide Authentication

Selective authentication restricts Allowed to Authenticate permission Use carefully

Protect the Schema

Soft Controls
Protecting the AD Schema is more about following sound security practices than technical solutions Policy Guidelines Configuration Management Roles / responsibilities

Schema Policy
Ownership
Management of schema naming prefix Delegating OIDs Configuration Management
Define evaluation criteria for proposed schema extensions Provide final approval/disapproval

Maintenance and documentation

Soft Controls
Guidelines
Configuration management evaluation criteria OID Maintenance Documentation Splitting application deployment Schema testing guidelines

Access Control
Most important protect Schema Admins group!

Firewall Considerations

Firewall Considerations
Firewall the Root domain?
No real security gained, just added complexity

Firewall the Schema Master?

Firewall the Schema Master

Firewall Considerations
When a firewall exists between Active Directory systems
Use IPSEC tunnels

Protecting Service Management

Stronger Password Policies

Policy: stronger password requirements for elevated privilege accounts Two options:
Custom password complexity requirements Store all service management accounts in forest root domain

Stronger Password Policies

Controlled OU structure in forest root domain
ROOT Domain

Service Management - <domain -name >

Users and Groups

Controlled OU Security
Type Name Access Applies To

Allow Allow

Enterprise Admins

Full Control

This object and all child objects This object and all child objects This object and all child objects This object and all child objects This object and all child objects This object and all child objects

Service Management Owners - <domain- Full Control name> SYSTEM <domain-name>\Domain Admins Full Control List Contents Read All Properties Read Permissions List Contents Read All Properties Read Permissions List Contents Read All Properties Read Permissions

Allow Allow

Allow

Pre-Windows 2000 Compatible Access

Allow

Enterprise Domain Controllers

Controlled OU Audit Settings

Type Name Access Applies To

Success

Everyone

Write All Properties Delete Delete Subtree Modify Permissions Modify Owner All Validated Writes All Extended Rights Create All Child Objects Delete All Child Objects

This object and all child objects

Gotchas
Several issues with using separate domain for service management accounts model
Custom Domain Admin type group requires Domain Admin-level permissions
Cant add directly to Domain Admins group

Procedures must be followed closely

Best Practices
Restrict membership to within forest Separate accounts Cached credentials Default service management accounts
Dont use Account Operators, Server Operators

Group Policy Architecture

The Basics

The Problem
How do I enforce enterprise-wide security policies? Problem
Domains are boundaries for Group Policy

Possible solutions
Site-level GPOs Non-technical solutions

Site-Level GPOs

Disadvantages
UGLY!!!
Replication issues Performance issues Issues with placement of ROOT DCs Does not apply to Password policies

Non-technical solutions can be just as effective

Group Policy Best Practices

Local Group Policy vs. Domain Group Policy Use synchronous mode Security Policy Processing
Process even if the Group Policy objects have not changed

Explore capabilities
Extend group policy

Group Policy Best Practices

Minimize use of block policy inheritance and Enforce options Limit number of GPOs Link GPOs as closely as possible Disable user/computer configuration when possible Avoid cross domain linking of GPOs

System Hardening

Adopt a Baseline/Guideline
BASELINE !! BASELINE !! BASELINE !! BASELINE !!

Hardening Guideline Components

1. Preliminary Security Measures (Done offline)
BIOS level protection AV Physical security Patch Verify software, shares, users Patches

Hardening Guideline Components

2. Apply group policy
Automatic OU placement (netdom) DS restore mode password

2. Manual hardening procedures 2. Verify functionality and security 3. Back out procedures 4. Known vulnerabilities register

Domain Controllers and DHCP

Dont run DHCP on Domain Controllers if youre using dynamic updates (DNSUpdateProxy group issue)

Questions
Juan Martinez juan.martinezjr@ins.com www.ins.com