1: Active Directory

Presenter
Pawan Sharma | Consultant | HCL Comnet
Introduction

 Trainer introduction & background

 Pawan Sharma
 Consultant, HCL

 Goals of the learning event:

 Solid foundation in Active Directory
 AD structure
 Administrative tools, best practices
 Security recommendations
 Group policy understanding

 Ground rules
 Cell phones and pagers silent
 Hold questions until Q&A session
What is Active Directory?

 Active Directory is the Windows directory service

 “A store of useful information about objects of interest on the network”
 Uses database underpinnings (SQL server) for performance, recoverability and
scalability
 Addresses weakness of NT domain structure
 Competes with NDS (Novell) and others
 Like NDS, it is X.500 based
Benefits of Active Directory

 A multipurpose directory service

 Extensible
 AD enabled applications available
 Best example is Exchange server

 Highly scalable
 Flexible design and administration
 Based on external standards (ish)
 Policy based administration
  aims to reduce TCO
NT domain weaknesses

 Not scalable (40,000 object maximum)

 Minimal delegation capability
 Minimal control over replication
 Netbios limitations
  multi-domain structures
 Trust relationship problems
 Non-transitive
 Manually created
 Could fail and need management
Components of AD

 Domain
 Organizational Unit (OU)
 Site
 Domain naming and Trees
 Forests
 Database components and Domain Controllers
 Global Catalog Servers
Domain

 The building block of AD, a partition of the database

 Must have at least one domain
 Single domain sufficient for many organizations
 Forms a security, administrative and replication boundary
 Requires DNS for naming
 Every domain must have at least one domain controller to store and
manage the Active Directory database
 Recommend at least 2 DCs/domain
DOMAIN.COM
Organizational Unit (OU)

 Not a partition of Active Directory

 A logical division of a domain
 Easy to create, rename, reorganize
 Much more flexible than domains
 No incremental cost
 Used for:
 Delegation of administrative rights and authority
 Management of Group Policy
 Logically organizing objects to facilitate easy administration
 Can be used to conceal objects
Domain Naming and Trees

 Every domain has a name that follows DNS rules

 Names do not have to be registerable
 You can have multiple domains that have the same DNS root – this is called
a Tree
 e.g. child.parent.com
 Can have many trees in a forest xyz.com
 With different namespaces
 No security component to this
 Just naming

west.xyz.com east.xyz.com
Forest

 A forest is a single Active Directory structure not connected by default to

anything else
 All the domains in a forest share:
 Schema
 Configuration
 Global Catalog
 Transitive trust relationships between all domains
 Forest root domain
 Enterprise administrators group
Forest designs

 There are only three forest designs:

 Single domain forest
 Single tree forest (multiple domains)
 Multi tree forest (multiple domains)

xyz.com
abc.net

us.abc.net west.xyz.com east.xyz.com

Site

 Sites are used to control the network traffic associated with domains
 Logon traffic from clients
 Replication traffic between domain controllers
 There is a single site by default
 Site structure mirrors your physical network
 A site consists of one or more IP subnets
 Generally there will be one site per physical location (LAN or group of LANs)
Database components

 Active Directory database is stored and maintained on Domain Controllers

(DCs)
 DCs only store information about their own domain
 NTDS.dit is the name of the database file
 Partitions = Naming Contexts
 Active directory database has at least three partitions:
 Schema – common to entire forest
 Configuration – common to entire forest
 Domain – specific to that domain
 Application partition – data related to a particular application

 Sysvol folder also gets replicated within the domain

Schema partition

 Active Directory is made up of Objects and Attributes

 Objects may be container or leaf objects
 The definition of all objects and attributes is stored in the schema partition of
the database
 The schema can be extended to meet the needs of an organization or to
support a directory enabled application
 Care should be taken before modifying the schema
 Schema is the same for all domains in the forest and changes are replicated
to all domain controllers
Configuration partition

 Configuration partition stores the structure (both logical and physical) of

Active Directory
 So that all domains are aware of trust relationships and the site structure
 It is replicated to all domain controllers in the forest automatically
 It is the same for all domains
 It will change when the structure or configuration of Active Directory
changes
 May also store data related to AD-enabled apps such as Exchange server
Domain partition

 Stores complete replicas of all objects in the domain

 Can be modified on any domain controller
 Changes are synchronized automatically through the replication process
 Each domain controller in a domain stores a complete copy of its domain
partition (in addition to the schema and configuration partitions common to
the forest)
 Is replicated in partial form to Global Catalog servers
 Most day to day changes occur in the domain partition
Application partition

 New in Windows Server 2003

 Store application data
 Cannot contain security principals
 Created by the application that uses them, or less often by
administrators
 Only default examples are the 2 application partitions created for
DNS
 Defines a list of DCs that should store and replicate that partition
Global Catalog Servers

 Store a complete copy of their own domain partitions, and partial copies of every other domain
 Partial = all objects, but only some of their attributes
 Attributes stored = Partial Attribute Set
 Can choose additional attributes to be replicated to the GC  but more data to replicate
 Must be at least one GC per forest, but can be more
 Should be one GC per site
 Used for searching the entire directory and for logon in multi domain environments
 The global catalog limits the overall size of Active Directory to about 10 million objects
DNS support for AD

 DNS services are required for Active Directory to function

 Support for service (SRV) records is required
 BIND or Windows DNS can support this
 Other DNS features are highly desirable:
 ADI zones (for security and redundancy)
 IXFR (Incremental Zone Transfer)
 Unicode support (for International characters)
 Dynamic update
Summary – AD basics

 Active Directory introduction

 Components of Active Directory
 Components of the database
 Domain controllers and global catalog servers
 DNS and AD
AD design considerations

 Factors influencing the design

 Overview of the design process
 Forest, Domain, OU, Site design
Factors driving the design

 Organizational goals
 Reduce TCO
 Simplify administration

 Administrative style
 Centralized, decentralized or hybrid

 Technical constraints
 Hardware, network bandwidth, services

 Security needs
Design process overview

 Forest design first

 Then domain/tree design
 OU design
 Site/physical design
 Generally design accomplished by a team
 Single individual does not usually have the necessary information
 Technical issues
 Organizational issues
Forest considerations

 A Forest shares:
 Schema, configuration, global catalog, trusts, enterprise admins group

 If you don’t want to share these  multiple forests is the only

answer
 More forests = more cost, complexity…
 Other business needs may also apply
Domain considerations

 Fewer domains generally better

 Desired naming will impact domain structure
 Domains are a unit of incremental cost
 One major consideration is account policy
 Others include replication, international, administrative, possibly
security
Dedicated Forest root domain

 Basically an empty domain

 Benefits are:
 Long term AD structure flexibility
 Isolation of Enterprise/Schema Admins

 Not originally a best practice

 Now very widely implemented
 More expensive, but not excessively so considering the alternatives
OU considerations

 OUs generally allow for:

 Delegation of administration
 Application of group policy
 Organization of objects

 Easy to get carried away and create too many OUs

 But easy to fix if necessary
 1 domain/many OUs far superior to multiple domains
Physical design

 Sites, subnets, servers (DCs)

 Also locations (printers etc.)
 Less discussion, more mechanical
 Used to control or concentrate network traffic associated with AD
 Authentication
 Query
 Replication
U of M design

 2 domain, 2 tree forest

 For naming reasons (shorter FQDNs)
 Dedicated forest root
 Allows flexibility for later changes
 Virtual organization hosting
 Allows for creation of new domains
 Or the upgrade of NT4 domains

 Allows distribution of load away from DCs in the joinable domain to

the DCs in the root
OU structure

UOM.MEMPHIS.EDU

 Key points: Domain

Controller
 All users in same OU s
Single OU -
People
All Users
 Each LSP has own OU LSP Groups,
LSP “A” Temp Accts
 Common OU structure
PCs
 OUs by delegation Servers

 Then object type Services Svc accts

Shares File, Print

 Possibly additional OUs Shares
Labs Lab
(graphic lifted from DPS document)
Machines

LSP “B”

GPO
Library
Active Directory Administration

 OU structure should facilitate delegation

 Recommendations:
 Delegate to groups not users
 Delegate at container/OU level
 Not recommended:
 Setting permissions on individual objects
 Removing default permissions
 Permissions granted can be broad:
 Full control over an OU hierarchy
 Or very narrow (or in between):
 Specific attributes of specific objects
How to administer

 MMC tools typically work locally or remotely

 Remote desktop also useful
 Fewer limitations
 Puts load on server
 Readily securable
Types of permission

 Full control (allows further delegation)

 Broad permissions to a specific object (create, manage, delete)
 Limited permissions to existing objects (reset password, unlock
account)
 Permissions to specific attributes of specific objects (write to
organizational information)
Object naming

 Every AD object has a DN (distinguished name)

 CN = common name (**)
 OU = organizational unit
 DC = domain component
 DN must be unique in the directory
 Indicates the name and location of object
 Like a file path

 ** also used for AD default containers

Object creation - GUI

 GUI = Active Directory Users & Computers

 Create various object types:
 Users, computers, groups, OUs, folders, printers etc.

 Also can manage Exchange server related attributes/tasks

 MMC snap-in
 Can be used in a custom console
Printers

 Printers on Windows print servers are created automatically

 Generally hidden in AD
 Can be displayed, and moved to increase visibility
 Can manually create printers also
Object creation - CLI

 New Windows Server 2003 tools

 DS___ tools
 Dsadd, dsmove, dsrm, dsquery, dsget, dsmod

 Use DN
 General command structure:
 Ds<cmd> <objecttype> <objectDN> -<switches/options>

 Can be batched together in a file

Object Creation – VB script

 Limitless scope, not just AD

 More to learn/more powerful
 Example of user creation:
 Set objOU = GetObject("LDAP://OU=management,dc=fabrikam,dc=com")
Set objUser = objOU.Create("User", "cn=MyerKen")
objUser.Put "sAMAccountName", "myerken“

objUser.SetInfo
Object creation – mass

 Import and export tools

 CSVDE & LDIFDE
 Differ in file format
 Differ in capabilities
 Csvde creates objects only
 Ldifde can create, modify and delete objects
Searching for objects

 ADUC find tool

 Common queries
 Saved queries
 Dsquery
 Dsget
 Dsquery and dsget compared
Object management

 Common tasks include:

 Reset user password/force change
 Manipulating printers
 Rename accounts
 Reset computer account
 Delete/readd computer to domain
 Modify object attribute
 Mass changes

 Can be done graphically or not

© Chris Alberts/ExecuTrain of Austin

Session wrap up

 Intro to AD
 Structure and terminology

 AD design considerations
 Factors influencing design

 AD administration
 Tools, commands
2: Security & Group Policy

 Components of Security
 Recommendations
 Group policy
Components of Security

 Physical security
 Role based security for all computers
 OS configuration – settings (templates)
 Administrative security
 Confidential information in AD
 Data transmission security
 Security from intruders (firewall)
Recommendations

 DCs should be physically secure (all servers)

 Minimal data on workstations
 Educate users about the importance of maintaining security
 Use features of Windows to implement security
 Group policy
 Security templates/ sec. configuration & analysis
 IPSec
 Windows Firewall (SP1)
Introduction to Group Policy

 Introduced with Windows 2000

 Can be used with or without AD
 Major factor in reducing TCO
 Ensures compliance with organizational policy
 Underutilized feature generally
 Needs to be done right – thoroughly tested before implementation
 Powerful tool, being expanded constantly
Benefits of Group Policy

 Understand that security is heavily reliant upon user activities

 GP exists to restrict user activities
 Can restrict administrators, but better to avoid regular users having
administrative rights
 Configuration management –
 Enforce security settings consistently
 Restrict users’ access to parts of the interface
 Wide range of settings, customizable
Additional benefits

 Ability to deploy and manage software

 Restrict or configure many areas of Windows
 Restrict which software can run on the computer
 Scripts
 Can impact MS Office or other apps
Basic Structure of GP

 GP enforces registry settings

 Like the registry, contains computer and user related settings
 Most basic security is under Computer
 Windows\Security settings node

 Most user restrictions are under User

 Administrative Templates node
How is GP applied?

 With Active Directory

 Policy set on AD containers
 Site, Domain and OU
 Enforced automatically based on the location of the user/computer in
AD
 Complicated inheritance/conflicts

 Without AD
 Set manually, or secedit script on boot
 Fewer options available (eg. s/w dist)
Policy application (detail)

 Site, Domain, OU (basic rule)

 Local policy applied first
 May be many policies applying
 If settings compatible  all apply (inheritance)
 If settings conflict  setting from the policy closest to the user/computer
is the overriding policy

 “Last writer wins”

Exceptions to the basic rule

 Block inheritance (container setting)

 No override/enforce (policy setting)
 Account policy only honored at the domain level
 Policy filtering using permissions
 WMI filtering
 Loopback
Loopback (detail)

 Two modes
 Replace
 Merge

 Redirects user policy to the policy applying to the computer’s

location in AD
 Used in closely managed environments
 And in structures where it is not practical to set policies over user
objects directly
GP and the boot process

 First time = thoroughly evaluates policy

 afterwards = checks GPOlist
 Only reapplies if list has changed
 Not individual settings

 Policy refreshed dynamically

 Every 90 mins + offset for non-DCs
 Can be controlled

 Designed to minimize impact on boot and logon

Security settings within GP

 Wide range of settings:

 Service settings (auto/manual/disabled)
 Restricted groups
 Security options
 IE restrictions
 Software restriction
 IPSec
 …many, many more
Managing computer security by role

 Computers should be organized into roles for appropriate

application of security
 In AD this will impact your OU structure
 Examples –
 Standard desktops
 Notebooks, workstations
 Domain controllers
 Application servers
 Network Infrastructure servers etc.
 Kiosks
Security templates

 Templates fit in with the idea of role based security

 A template is a file (.adm) containing security settings
 Templates can be imported into local or group policy or applied
using secedit
 MS supplies some with Windows (see help)
 Can edit those or create your own
 Use the security templates tool
Security configuration and analysis

 Used with security templates

 Can be used to compare a template to the current settings
 And/or to apply the template to the computer
 Easily shows settings that are not in compliance
 Command line version: secedit /?
Testing security policy settings

 Inappropriately applied policy can render a computer unusable

 Important to test before applying
 Easier in an AD environment –
 Dummy OU, spare computer

 Tougher in a standalone environment –

 Maintain a rollback template
Other policy settings

 Software installation and maintenance

 Windows updates
 Software restriction
 Scripts
 Certificate enrollment
 Folder redirection
 Administrative Templates
Software installation

 GP can deploy software

 Also patch, update and remove (cleanly)
 If installed by GP

 Uses Windows Installer service

 Uses .msi files
 User does not require install rights

 Can be deployed in 3 ways

 Assign to computer
 Assign to user
 Publish to user

 Must be thoroughly tested

 Repackage with WinInstall LE
Windows Auto Update

 System control panel settings

 Can be controlled through policy
 Point users to internal SUS server
 Prevent them bypassing

 SUS server is your box

 Synchronized from MS Windows Update servers
 Allows testing before applying
 SUS  WSUS (was WUS) soon
Software Restriction Policy

 New in 2003 (& XP)

 Allows or prevents software from running in Windows
 Basic policy (allow or restrict)
 Rules for exceptions
 Path (folder or registry
 Hash (specific file)
 Certificate
 Internet zone (.msi files only)
 Computer or user based
 Needs thorough testing
Scripts

 4 types
 Startup (computer)
 Login (user)
 Logoff (user)
 Shutdown (computer)

 Now the recommended way to assign scripts

 Old way (ADUC) still works
 Scripts are used for…?
Certificate policies

 Can be used to auto enroll

 Specify trusted root authorities
 Certificates useful for:
 User authentication (smart cards)
 IPSec
 SSL/TLS/SecureMIME
 Computer authentication
 Code signing
Folder redirection

 Redirect special folders

 My Documents
 Application Data
 Desktop
 Start Menu

 Part of user profile

 Provides consistent environment
 Keeps data off the client computer
Administrative Templates

 Hundreds of settings (mostly user)

 Impact the interface and operation of:
 Windows
 Windows components (IE, WMP)
 Applications (with add’l .adm files)

 Can be misinterpreted by users

 Don’t get carried away
 The implicit “deal”
GP management tools

 Built in tools
 ADUC
 GP object editor
 Security Templates
 Security configuration & analysis

 Group Policy Management Console

 Downloadable
 Aka GPMC
ADUC

 The ‘old’ way to manage policy

 Can set policy for Domain & OUs
 Used AD Sites & Services for site policy
 Tab altered when GPMC is installed
 No longer recommended
Adding the GP snap in
GP editing interface
Security options

© Chris Alberts/ExecuTrain of Austin

Security Templates tool
Template detail
Security config & analysis tool
Tool detail
Results of analysis
GPMC

 Downloadable (search for GPMC.msi)

 Adds lots of functionality:
 Copy/import policies
 Backup and restore policies
 A big picture view
 RSoP
 Multi forest administration

 The recommended way to go

Policy Monitoring

 RSoP introduction
 Different ‘modes’
 RSoP in ADUC
 RSoP in Windows Help & Support
 Gpresult.exe
 GPMC
RSoP

 RSoP = Resultant Set of Policy

 = the net effect of all policies affecting a user/computer
 Takes account of inheritances
 Used to explain what the user sees and where it is coming from
 Useful troubleshooting/predicting tool
 Can be delegated permission to use RSoP
RSoP Modes

 RSoP can be in two modes

 Planning (or Modelling)
 Speculative
 Allows prediction of the effect of a change
 What if type modelling

 Logging (or Results)

 Based on actual data
 Queries the registry of a computer

 Mode names differ based on interface used

RSoP in ADUC

 Right click a container (planning) or a user (logging)

 Generates a report in the GP object editor interface
 Not recommended
 Can delegate permissions to use RSoP using the delegation wizard
Windows Help & Support Center

 Users can use this to see a simplified view of RSoP

 A useful tool if you’re at the user’s station
 Start | Help and Support | Tools | Advanced System Information |
View GP settings applied
Gpresult.exe

 Command line tool

 Changed since W2k
 Command line version of RSoP
 Various switches /v /z
 Built in tool (XP )
GPMC

 Gives graphical (HTML) report

 Much neater, easier to read
 Summary + detail
 Allows drill down
 Tabs can show any logged events related to policy (results mode)
 Or the query you ran (modelling)