rfp12-03 microsoft active directory design

Novell to Microsoft Conversion

Assessment:

Active Directory Design

Presented to:

03/11/11

1215 Hamilton Lane, Suite 200

Naperville, IL 60540

www.MoranTechnology.com

Voice & Fax: 877-212-6379

http://www.morantechnology.com/


HACC

of 38

Version History

Ver. # Ver. Date Author Description

1.0 19-Jan-11 Brian Desmond Initial Draft

1.1 25-Jan-11 Scott Weyandt Edits

1.2 03-Feb-11 Brian Desmond Edits at HACC

1.3 09-Feb-11 Brian Desmond Updated drawings

1.4 09-Mar-11 Brian Desmond Updates based on review w/ HACC


HACC

of 38

Table of Contents Introduction .................................................................................................................................. 5

Background ............................................................................................................................... 5

Approach ................................................................................................................................... 6

Current Environment .............................................................................................................. 6

Design Goals ............................................................................................................................. 6

Forest & Domain Design ............................................................................................................. 7

Forest Model ............................................................................................................................. 7

Domain Model .......................................................................................................................... 7

Trusts ......................................................................................................................................... 8

Schema Customizations .......................................................................................................... 9

Site Topology & Domain Controller Placement .................................................................... 11

Site Layout .............................................................................................................................. 11

Replication Topology ............................................................................................................ 12

Exchange Server Considerations ......................................................................................... 13

Domain Controller Hardware & OS ................................................................................... 14

Domain Controller Placement .............................................................................................. 16

Global Catalog Placement ..................................................................................................... 17

Read Only Domain Controller Placement .......................................................................... 18

Filtered Attribute Set ......................................................................................................... 19

Password Replication Policy ............................................................................................ 19

FSMO Placement .................................................................................................................... 20


HACC

of 38

Name Resolution ........................................................................................................................ 23

DNS Namespace Design ....................................................................................................... 23

Time Sync .................................................................................................................................... 25

Best Practices........................................................................................................................... 25

Time Sync Design ................................................................................................................... 25

Disaster Recovery....................................................................................................................... 27

Backup ..................................................................................................................................... 27

Restore ..................................................................................................................................... 28

Active Directory Recycle Bin ................................................................................................ 29

Administrative Model ............................................................................................................... 30

Organizational Unit Design .................................................................................................. 30

Top-Level OU Design ........................................................................................................ 31

Enterprise Support OU...................................................................................................... 33

Site-Level OU Design ........................................................................................................ 35

Recommended Site-Level OU Design ......................................................................... 36

Object Lifecycle Management .............................................................................................. 37

Summary ..................................................................................................................................... 38


HACC

of 38

Introduction

This document details the recommendations of Moran Technology Consulting

(MTC) for the design of the new Harrisburg Area Community College (HACC) Active

Directory.

Background

HACC has engaged MTC to conduct a thorough and impartial evaluation of its

current network operating system and email environment (Novell NDS and

GroupWise). As part of this assessment, MTC will identify the pros and cons of

converting to a Microsoft Windows Server Active Directory and Exchange Server 2010

from the current Novell NetWare and GroupWise products. In addition, MTC will

develop a project plan that identifies the total cost of conversion, including:

Estimates for hardware and software (licensing and support);

Resource, time, and cost estimates for implementing the new solution (upgrade

or migration);

Knowledge transfer and training of HACC to operate and maintain the new

solution.

As part of this effort, MTC has developed the following design for Windows Server

2008 R2 Active Directory to enable detailed pricing and planning information to be

developed.


HACC

of 38

Approach

As a firm that specializes in IT Management and Technical consulting for higher

education clients, MTC recognizes the importance of the cultural, organizational, and

technical challenges that must be addressed in order to develop and implement an

efficient design and plan for HACC.

At the kickoff of the project, a HACC design team was assembled to provide

stakeholder input into the design to ensure that it meets the technical and functional

needs of all the parties dependent on the new Active Directory. Several meetings and

workshops were conducted to socialize the proposed design and gather inputs from

each of the campuses.

Current Environment

HACC is currently utilizing a Novell Netware/NDS as its directory platform and

Network Operating System. The Novell infrastructure is comprised of centrally hosted

and distributed Novell servers at each of the campuses. Novell primarily supports file

services for employees (faculty and staff) and GroupWise.

Design Goals

The primary goal of this design is to provide an Active Directory infrastructure

which will meet the authentication and administrative needs of the HACC stakeholders

while also conforming to current best practice standards for Active Directory. The

following design was established to support a proposed Microsoft Exchange Server

2010 deployment as well as desktop authentication and file services for all of the HACC

campuses. Substantial consideration will be given to ensuring that administrators for

each of the campuses can continue to perform all of their duties in an efficient and

timely manner.


HACC

of 38

Forest & Domain Design

The two top level elements of any Active Directory design are the forest and

domain. Forests are security boundaries in an Active Directory and contain one or more

domains. While domains are a replication boundary within a forest, they are never a

security boundary. Therefore, when complete separation of administration is necessary

in an Active Directory environment, a separate forest must be deployed.

A common misconception is that deploying an empty root domain to hold

enterprise level administrative groups is more secure than collocating those groups in a

general use domain. Given the architecture of Active Directory, it is in fact quite

possible for administrators in one domain to affect other domains. Thus a single domain

design is just as secure as a multi-domain design. Empty roots were originally

conceived in an era where popular wisdom was that there were technical advantages to

the deployment of the root domain. Today, the cases where the empty root makes sense

are corner cases rather than the norm.

Forest Model

The business and technical requirements for HACC’s new Active Directory

design do not present any reason to implement more than one forest. The

administration of the new HACC Active Directory infrastructure will be centralized.

Furthermore, there are no special cases where a complete separation of administration

is necessary, thus making the primary driving factor for additional forests a moot point.

Domain Model

As the HACC network is well connected by high speed network links, there is no

need to consider segregating Active Directory replication at the domain level to control

network traffic. The new HACC forest will consist of a single domain which will be

utilized across the entire Active Directory environment.


HACC

of 38

The new domain will have the following names:

DNS Name – ad.hacc.edu

NetBIOS Name – HACC

In the unlikely event that the HACC need to deploy an additional domain, it is

logical to either deploy that domain as a child of ad.hacc.edu (e.g.

domain2.ad.hacc.edu) or as a separate tree in the ad.hacc.edu forest (e.g. domain2.net).

This flexibility exists regardless of whether or not an empty root domain is deployed as

part of the forest design.

Trusts

Trusts enable disparate domains and forests to coexist with pass through

authentication. Trusts can exist between domains or between forests, with forest trusts

operating in a transitive manner similar to the implicit trusts between domains in a

multi-domain forest.

SID Filtering is a security feature which can be enabled or disabled on a per trust

basis. SID Filtering prevents SIDs from domains other than a principal’s parent domain

from being included in a token across a trust. When migrating security principals

between domains, SID History is typically used to maintain an archive of the principal’s

previous SID(s). This way the principal can access resources (such as file shares) which

are secured using an older SID without needing to update the resource’s ACL. In order

for this functionality to work across trusts, SID Filtering must be disabled on the trust.

Selective authentication is a security feature of trusts in Windows Server 2003

and newer domains. By default users from a trusted domain have access to all data in

the trusting domain which is secured with the Authenticated Users security principal.

When selective authentication is enabled, users from a trusted domain have an “Other

Organization” Security Identifier (SID) added to their security token by the domain

controller. Likewise, users in the trusting domain have the “This Organization” SID


HACC

of 38

added to their security token at logon. Additionally when a user from a trusted domain

attempts to access a server in the trusting domain, domain controllers verify that the

user has the Allowed to Authenticate right on that computer object in Active Directory.

The Other Organization SID can be used to deny access to domain resources only to

users in an external domain.

There are no Trusts required for this deployment.

Schema Customizations

The Active Directory schema is customizable, allowing for administrators to

define additional data which can be stored in the directory. Administrators can define

new attributes of existing objects (such as storing the shoe size for all users), or new

types of objects (classes). Many software packages include schema extensions which

enable the package to take advantage of Active Directory. Microsoft Exchange is a

popular example of this.

Schema extensions are often treated as a taboo change. While it’s recommended

that a process be wrapped around extending the Active Directory schema, it’s not

necessary to treat this process with intense fear. Active Directory schema changes are

irreversible; however it is unlikely that a schema change will have a negative impact on

the environment. It is also possible to disable (defunct) unused schema changes at a

later date.

When evaluating a schema change, there are a few key elements to consider in

order to ensure that the schema change will be successful and will not have negative

implications at a further date:

Are all attribute and class names prefixed with a unique prefix?

Are the Object IDs (OIDs) registered to the creator of the schema extension?

If linked attributes are included, are automatic link IDs used? If not, are the link

IDs registered with Microsoft?


HACC

of 38

Are attributes which will be searched frequently indexed?

In addition to these per class/attribute considerations, simply evaluate the need for

information to be stored in the directory. Is the information of global significance? Is the

information better kept in another pre-existing database? Are there privacy concerns

surrounding the information? It is difficult (though not impossible) to secure attributes

in Active Directory such that they are only viewable by certain groups.

Based on input from HACC, the following schema extensions are recommended as

part of the initial ad.hacc.edu forest deployment:

Microsoft Exchange Server 2010

Microsoft System Center Configuration Manager 2007 R3


HACC

of 38

Site Topology & Domain Controller Placement

Active Directory administrators are responsible for maintaining a logical

network topology inside the directory. This topology is used to determine such things

as which domain controllers clients will use, what replication connections are built

between domain controllers, and which domain controllers will be used by individual

applications. Applications such as Distributed File System (DFS), Exchange 2007 and

newer, and System Center Configuration Manager depend upon this topology for their

own needs as well.

Site Layout

Sites represent a logical boundary within the network. A site is loosely defined as

a well-connected network. The definition of “well connected” varies, but typically a

good benchmark is for network speeds of ten megabits (10Mb) or faster. This is not a

hard rule however as it can often still make sense to separate locations which are

connected at high speeds into separate Active Directory sites.

Sites boundaries are defined by associating IP subnets with the site objects in

Active Directory. Clients and servers determine their site association based on matching

their IP address to a subnet object in Active Directory. While the IP addresses of domain

controllers should match their sites, domain controllers are manually associated with

the site they reside in within Active Directory. It is important to keep subnet

information in Active Directory up to date as otherwise clients will not associate with

the correct sites and unnecessary network traffic will be created as well as poor client

performance due to latency. It is permissible to have sites in Active Directory which

have no domain controller associated with them. These sites will be automatically

covered by a domain controller based on the site link topology defined in Active

Directory.


HACC

of 38

When there is a need to isolate an application server or series of servers such

that they only use certain domain controllers, administrators may create a site specific

to that application and place certain domain controllers in that site. Prior to Exchange

2007, it was extremely common to use this method to create a dedicated site for

Exchange servers due to the high global catalog load Exchange creates.

Given HACC’s current network and application requirements, the most effective

site design is to create one site per college plus one site per core datacenter. In the event

any Extension division needs to host a domain controller or other Active Directory site

topology aware application, a site will need to be provisioned for that location.

The site configuration is detailed in the table below:

Name Description Location Attribute

Gettysburg Gettysburg Campus Gettysburg

Harrisburg Harrisburg Campus Harrisburg

Lancaster Lancaster Campus Lancaster

Lebanon Lebanon Campus Lebanon

York York Campus York

Replication Topology

Active Directory builds the replication topology between domain controllers

based on information provided by the administrator. The bulk of this information is

contained in the site objects as well as site links. Site links are provisioned to define

logical connectivity between sites along which replication can occur. There are three

properties of site links which can be used to control replication:

Cost

Schedule

Frequency


HACC

of 38

Cost is only relevant when there is more than one path between any two given sites.

When this is the case, Active Directory uses cost to determine the preferred path.

Schedule defines when replication can begin. Note that once replication begins, it will

not stop until it is complete, even if the schedule window has passed. Finally, frequency

defines how often Active Directory attempts to replicate over a site link.

Given HACC’s network requirements, it is recommended that one site link be

created between each spoke site and the datacenter site. The configuration for these site

links is detailed below.

Name Sites Frequency Schedule Cost

Harrisburg-

Gettysburg

Harrisburg

Gettysburg

15 Always 15

Harrisburg-

Lancaster

Harrisburg

Lancaster

15 Always 15

Harrisburg-

Lebanon

Harrisburg

Lebanon

15 Always 15

Harrisburg-

York

Harrisburg

York

15 Always 15

Exchange Server Considerations

If HACC elects to place Exchange servers in multiple locations, it is important to

remember that Exchange Server 2007 and newer depends on the Active Directory site

topology to establish mail routing. This means that the topology in Active Directory

must match the desired path for mail flow.

Additionally, each Active Directory site which contains a Mailbox server or

Unified Messaging server must also contain a Hub Transport server. Client Access

servers (CAS) also use the Active Directory site topology when proxying connections


HACC

of 38

across site boundaries.

Domain Controller Hardware & OS

Standardizing on the hardware platform for domain controllers across an Active

Directory environment will inevitably reduce administration cost through

simplification. Administering only one hardware platform will reduce the need for

testing different configurations as well as make planning for hardware refreshes and

upgrades much easier.

In some scenarios it makes sense to have “large” and “small” domain controller

specifications such as for situations where datacenters are much more heavily utilized

than branch offices, for example. In HACC’s situation, the environment is not large

enough either in terms of physical scale or size of the directory to warrant this

differentiation.

The most important factor when planning domain controller hardware is

ensuring that there is enough physical memory to cache the entire Active Directory

database (ntds.dit) file in RAM. It is important to take in to consideration the present

size of the database as well as estimates of the growth in size the database over the

course of the lifecycle of the domain controller hardware. By caching the entire Active

Directory database in RAM, the domain controller no longer needs to access the disk for

read operations. RAM access is substantially faster than disk access.

The following configuration is the recommended specification for the new

HACC domain controllers, assuming a hardware standard of Dell PowerEdge servers.

Description P/N Qty.

PowerEdge R610: Chassis for Up to Six 2.5-Inch Hard Drives [224-8479] 1

Primary Processor: Intel® Xeon® E5620 2.4Ghz, 12M Cache, Turbo,

HT, 1066MHz Max Memory

[317-4112] 1


HACC

of 38

Description P/N Qty.

Memory: 12GB Memory (6x2GB), 1333MHz Dual Ranked RDIMMs

for 1 Processor, Optimized

[317-7388] 1

Rails: Sliding Ready Rails With Cable Management Arm [330-3520] 1

Internal Controller: PERC H200 Integrated RAID Controller [342-0663] 1

Hard Drives: 146GB 10K RPM Serial-Attach SCSI 6Gbps 2.5in Hot

plug Hard Drive

[342-2014] 2

Power Supply: High Output Power Supply, Redundant, 717W [330-3518] 1

Embedded Management: iDRAC6 Enterprise [467-8648] 1

BIOS Setting: Performance BIOS Setting [330-3492] 1

Internal Optical Drive: DVD+/-RW, SATA, Internal [313-9090] 1

Embedded NIC Ports: Dual Two-Port Embedded Broadcom®

NetXtreme II 5709 Gigabit Ethernet NIC

[430-1764] 1

There are a number of key considerations to make when virtualizing domain

controllers. First, consider the role that Active Directory plays in the environment. If

Active Directory is a fundamental core service, it often makes sense to have one or more

domain controllers running on physical hardware. In the event of a datacenter failure,

there will not be any prerequisites to restoring Active Directory service (such as

virtualization software, SAN availability, etc.).

It is also extremely important that the Snapshot functionality in the virtualization

platform not be used in conjunction with Active Directory virtual machines. Snapshots

enable a scenario known as USN Rollback to occur (as well as other catastrophic

replication related scenarios). These scenarios cause Active Directory replication to fail.

Windows Server 2003 SP1 introduced logic to detect many USN Rollback scenarios, and

when this is detected, all future replication to the domain controller is disabled and it


HACC

of 38

must be forcefully demoted (and re-promoted).

Finally, virtualization introduces an additional influence on system time. Active

Directory environments depend on the correct time, and it is highly recommended that

the host time synchronization feature of the virtualization platform be disabled on all

virtualized domain controllers.

Windows Server 2008 introduced the Server Core variant of the operating

system. Server Core provides a much smaller footprint over the traditional operating

system install and limits the installed components to those which are required to

perform the installed server role.

While some server roles are not available under Server Core, Active Directory is

a supported role. In addition to Active Directory, the DNS Server and WINS Server

roles are also supported under Server Core. This makes Server Core a viable and

recommended platform for Active Directory deployments.

Given HACC’s requirements, Windows Server 2008 R2 Standard Edition

installed as a Server Core installation is the recommended operating system image for

all domain controllers in the ad.hacc.edu Active Directory forest.

Domain Controller Placement

Placing domain controllers near clients is critical to ensuring fast and reliable

authentications as well as directory lookups. It’s also critical to take in to account the

cost of deploying domain controllers to every location which clients are located at.

Many times the network is more than fast enough to support authenticating clients

remotely over the WAN. Thus, it’s important to define criteria for determining whether

a location requires a domain controller or not.

Important factors for determining whether or not to place a domain controller at

a location include:

Does the location support business critical operations? Can those operations


HACC

of 38

proceed in the event of a WAN outage?

Are there Active Directory intensive applications (e.g. Microsoft Exchange)

located at this site?

Does the number of workstations at the site exceed an agreed upon baseline (e.g.

300)?

Taking in to consideration HACC’s requirements, the following table details a list of

recommended domain controller placements for the ad.hacc.edu forest.

Name Location Type

RWDC01 Harrisburg Writeable

RWDC02 Harrisburg Writeable

RODC01 Gettysburg Read Only

RODC02 Lancaster Read Only

RODC03 Lebanon Read Only

RODC04 York Read Only

Global Catalog Placement

Global catalogs provide a partial view of every object in the forest. In a multi-

domain forest, global catalog placement comes in to play as replication from each

domain must occur to each domain controller in the forest in order to build this partial

view. In most scenarios, it is still appropriate to make each domain controller a global

catalog, however with highly distributed deployments with complex WAN

considerations, this is a decision that often requires further research.

In a single domain forest, there is no additional data stored in the global catalog

and thus every domain controller should be marked as a global catalog. With this in


HACC

of 38

mind, every domain controller in the ad.hacc.edu Active Directory forest will also

function as a global catalog.

Read Only Domain Controller Placement

Windows Server 2008 Active Directory introduces a new type of domain

controller known as the Read Only Domain Controller (RODC). RODCs function in the

same ways as a normal domain controller with the distinct difference that by default

they store no passwords and in no case do they perform outbound replication. This is a

key security enhancement over a traditional writeable domain controller (RWDC).

If a writeable domain controller is physically compromised, an attacker could

either a) obtain copies of password hashes from the domain controller or b) inject

changes directly into the Active Directory database which would allow the directory to

be compromised.

RODCs are designed for deployment in branch office scenarios and other

situations where the physical security of the domain controller could be called in to

question. Deployment to HACC remote locations are a perfect scenario for deployment

of RODCs.

When deploying RODCs, one key consideration to make is ensuring that

applications will be able to adapt to working with RODCs. Since RODCs are read-only,

when an application tries to write to the RODC, it will receive an LDAP referral

pointing it to a writeable domain controller. In the event the application is unable to

follow the referral, it will fail.

There are a number of compatibility issues with Windows which can hinder the

deployment of RODCs. Microsoft published a compatibility fix package for Windows

XP and Windows Server 2003 to resolve these issues and it is recommended that this

package be installed on servers and clients prior to the deployment of RODCs. The

package is available at http://support.microsoft.com/kb/944043. Note that while many

http://support.microsoft.com/kb/944043


HACC

of 38

of these issues exist in Windows 2000, the fixes were not backported to Windows 2000.

Filtered Attribute Set

In addition to the differences highlighted earlier with regard to RODCs,

functionality exists to limit the replication of certain attributes to an RODC. This

functionality is known as the filtered attribute set (FAS). Attributes in the FAS are

excluded from replication to RODCs. If there is a custom attribute in the schema which

stores sensitive information, that attribute can be marked as filtered.

Based on HACC’s requirements, there were no custom schema extensions

identified which meet the criteria for inclusion in the filtered attribute set.

Password Replication Policy

Since by default RODCs don’t cache passwords, they must traverse the WAN to

contact a writeable domain controller any time a client needs to be authenticated. It’s

also important to note that in this case, the definition of a client is either a user or a

computer. This behavior, whereby the WAN must be crossed each time, is not desirable

in most cases, and it defeats the point of placing a domain controller at a local site for

WAN resiliency.

The solution to this problem is to define Password Replication Policies (PRPs).

PRPs define what passwords an RODC can cache locally in its database. This removes

the need to cross the WAN except for initial population of the password cache or in the

event a password is changed. Note that it defeats the point of the RODC to allow the

caching of passwords for administrative accounts, and by default Active Directory

denies members of the various built-in administrative groups from having their

passwords cached anywhere.

Each RODC computer account has four Active Directory attributes which are

used to manage the PRP.

msDS-RevealOnDemandGroup - This is the list of principals that the RODC


HACC

of 38

can cache the password for. This list is often referred to as the allowed list.

msDS-NeverRevealGroup - This is the list of principals that the RODC is never

allowed to cache the password for. This list is often referred to as the denied list.

msDS-RevealedList - This is a list of principals whose passwords are currently

cached on the RODC.

msDS-AuthenticatedAtDC - This is a list of principals who have authenticated

to the RODC. This list is often referred to as the Auth-2 list.

In order to cache a user or computer’s password, the user or computer must be directly

or indirectly linked to the RODC via the msDS-RevealOnDemandGroup attribute.

While it is possible to link directly to users and computers, it is recommended that

global groups containing the users and computers in question are used instead. If

possible these groups should be populated via an automated process such as through

an identity management system.

FSMO Placement

FSMO role placement is a source of common debate for Active Directory

administrators. Flexible Single Master Operators (FSMOs, pronounced “fizmo’s”) are a

collection of five roles which Active Directory requires to happen only in one place in

order to ensure consistency. There are two roles which exist on a per forest basis, and

three roles which exist on a per domain basis.

The schema master is a per forest role which is the sole location for making

changes to the schema. The domain naming master is the second per forest role which

serves as the gatekeeper for adding and removing domains from the forest as well as

the addition and removal of application partitions and their replicas.

The PDC Emulator is a per domain role which historically existed to permit

replication with down-level Windows NT BDCs. In addition to this, the PDC emulator

is responsible for a number of other functions. Most importantly, the PDC emulator


HACC

of 38

participates in password chaining and serves as the root of the time sync hierarchy for

the domain.

The RID Master is a per domain role which issues batches of unique identifiers to

domain controllers for use when creating security principals. If the RID Master is

unavailable and a domain controller depletes its pool of RIDs, that domain controller

will be unable to create additional security principals. If there is a central location where

the majority of objects in a domain are created (such as where an identity management

system exists), it is a good idea to consider placing the RID Master in this location as

well.

The Infrastructure Master is the final domain role. The Infrastructure Master is

responsible for maintaining references to objects in other domains in the forest. In a

single domain forest, the infrastructure master has no purpose. While the Infrastructure

Master ordinarily cannot be collocated with a Global Catalog, this is permissible in

either a single domain forest, or a multi-domain forest in which every domain controller

is a global catalog.

As a general best practice, it is recommended that a secondary role holder be

identified so that in the event a FSMO role holder needs to be taken offline (such as for

patching), the FSMO role can be transferred ahead of time. This negates the possibility

that a catastrophic failure could occur leading to the need to seize FSMO roles. In the

event that certain FSMO roles are seized (namely the Schema Master and RID Master),

those domain controllers must not be brought back online and instead must be erased

and rebuilt.

Taking in to consideration HACC’s requirements and network topology, the

following domain controllers in the ad.hacc.edu forest were identified as hosts for

FSMO roles.

Role Domain Primary Holder Secondary Holder


HACC

of 38

Role Domain Primary Holder Secondary Holder

Schema Master ad.hacc.edu RWDC01 RWDC02

Domain Naming Master ad.hacc.edu RWDC01 RWDC02

Infrastructure Master ad.hacc.edu RWDC01 RWDC02

RID Master ad.hacc.edu RWDC01 RWDC02

PDC Emulator ad.hacc.edu RWDC01 RWDC02


HACC

of 38

Name Resolution

Active Directory is highly dependent on a functioning name resolution

infrastructure. While DNS is the sole requirement for Active Directory, many networks

continue to rely on short name resolution that creates an ongoing need for WINS.

Active Directory will register legacy records in WINS as well if WINS servers are

provided to domain controllers.

DNS Namespace Design

At a minimum, any DNS service which is used with Active Directory must

support RFC2052 - A DNS RR for specifying the location of services (DNS SRV).

Additionally it is recommended that the DNS service support RFC2136 - Dynamic

Updates in the Domain Name System (DNS UPDATE) and RFC1995 - Incremental Zone

Transfer in DNS. Windows DNS includes the necessary functionality to support all of

these requirements as well as DNS replication via Active Directory which greatly

decreases the administrative effort requirements for managing Active Directory’s DNS

dependencies.

In order to support the ad.hacc.edu Active Directory forest, two DNS zones will

need to be hosted on each DNS server:

_msdcs.ad.hacc.edu

ad.hacc.edu

These zones will host all of the records necessary for the forest to operate as well as any

dynamic registrations from clients and member servers.

In order to provide efficient local name resolution, each domain controller will

host a copy of all the DNS zones in the forest. Clients should be configured to use their

local domain controller as the first entry in their DNS server search order, followed by

two domain controllers in a central datacenter.


HACC

of 38

The zones listed in the following table will be hosted in the new Active Directory

environment. Each domain controller will be configured to use root hints to resolve

names not defined locally.

Name Type Scope

_msdcs.ad.hacc.edu Active Directory Integrated

Primary

All DNS Servers in

Forest

ad.hacc.edu Active Directory Integrated

Primary

All DNS Servers in

Forest


HACC

of 38

Time Sync

Critical to the operation of Kerberos and many enterprise applications is a

properly functioning time sync system across the network. Active Directory provides a

built-in time synchronization mechanism which extends to every machine joined to the

domain by default.

Best Practices

While it is possible to disable the built-in time synchronization system on

domain controllers or clients, this is not a recommended scenario. If time sync is not

functioning, clients will be unable to access Active Directory, leading to service

interruption. By default, the only time sync configuration necessary is on the domain

controller acting as the PDC Emulator in the forest root domain.

As a best practice, it’s recommended that the external time source be configured

on any domain controller which could become the PDC Emulator, such as in a DR

scenario or as part of a scheduled role transfer. This mitigates the need for the

administrator to remember to make the configuration change any time the role is

transferred.

Time Sync Design

Since HACC is implementing a single domain forest, an external authoritative

time source must be configured only on the PDC Emulator role holder and the

designated secondary role holder. The time service configuration on all clients, member

servers, and domain controllers should be left in the out-of-box default configuration.

The following table shows the time service configuration for all domain

controllers.

Domain Controller Sync Type Source


HACC

of 38

Domain Controller Sync Type Source

RWDC01 External <<External NTP Source>>

RWDC02 External <<External NTP Source>>

RODC01 NT5DS Active Directory


HACC

of 38

Disaster Recovery

Given the critical nature of Active Directory in most organizations, it’s extremely

important that a plan exist for the rapid recovery of the directory service in the event of

a failure. While Active Directory is an extremely resilient service, it is still important to

plan for the ability to recover in the event of a problem.

Backup

The distributed nature of Active Directory affords a great deal of flexibility from

the perspective of backup requirements. In the event of a single domain controller

failure, the domain controller can be re-promoted and it will replicate all of the

necessary data from other domain controllers. This does not however mitigate the need

for a sound Active Directory backup strategy.

Active Directory is typically backed up as part of a Windows System State

Backup. The System State backup includes all of the necessary files with relation to the

Active Directory database, Group Policy, and operating system configuration. Any tool

which is aware of Windows Backup APIs should be capable of backing up the System

State. The Windows Server Backup tool included with Windows also supports Critical

Volume and Full Volume backup types which are also suitable.

Only “Full” System State backups can be performed. Windows does not support

the concept of “Differential” or “Incremental” System State backups. When determining

the backup process for Active Directory, it is important to consider what drives the

need to backup domain controllers, what domain controllers will be backed up based

on these needs, and when.

When considering backup needs, there are simple ones such as the need to

restore deleted objects or recover the domain or forest in the case of a serious

catastrophe. There is also the more complex scenario whereby in the event of a domain


HACC

of 38

controller failure in a remote site it may not be feasible to replicate a new copy of the

domain and/or Global Catalog over the network. In these scenarios it is important to

have a local backup available for restore.

One common strategy is to backup two to three domain controllers per

datacenter plus any remote sites which would need to be recovered from backup

instead of over the network.

The following table details the Active Directory backup schedule for HACC:

Server Tool Frequency

RWDC01 Commvault Daily

RWDC02 Commvault Daily

Restore

Ideally it will never be necessary to perform a restore of an Active Directory

backup in a production environment. Unfortunately this is not generally the case and

consequentially it is very important to be prepared. Any restore of Active Directory

begins with a restore of the System State and booting in to Directory Services Restore

Mode (DSRM).

There are two types of Active Directory restores. The first is a non-authoritative

restore. A non-authoritative restore simply restores Active Directory to the state of the

backup. Any changes subsequent to the backup are re-replicated to the domain

controller. This type of restore is commonly performed when it is not feasible to

replicate a full copy of the domain over the network. An authoritative restore is

performed when one or more objects in the backup needs to be recovered. The most

common scenario for this is an accidental deletion or unrecoverable modification of one

or more objects.

Since Active Directory administrators do not typically perform restores on a day-

to-day basis, practicing these procedures is a critical part of the disaster recovery


HACC

of 38

planning process. Backups and restore procedures should be tested on a quarterly basis

in the lab at a minimum.

Active Directory Recycle Bin

Windows Server 2008 R2 introduces a new feature called the Active Directory

Recycle Bin. The Recycle Bin allows administrators to recover deleted objects without

restoring them from a backup. By default, deleted objects are retained for 180 days

during which an administrator can restore the object.

The Active Directory Recycle Bin is an optional feature which must be enabled in

order for deleted objects to be preserved in a recoverable state. It is recommended that

HACC enable the Active Directory Recycle Bin optional feature.


HACC

of 38

Administrative Model

The central objective of the new administrative model for the HACC Active

Directory environment is to achieve an efficient distribution of centralized and

decentralized management of the Windows environment. This objective will be

accomplished through the design and implementation of specific Organizational Unit

(OU) structures, Group Policy Objects (GPOs), and delegated permissions. The specific

goals of this design include:

EFFICIENCY: Centralize the management of Active Directory infrastructure and

core services (e.g., administration of domain controllers and user account

provisioning);

SECURITY: Ensure baseline and best practice security standards for HACC’s

Windows desktops, servers and accounts;

FLEXIBILITY: Promote the delegation of administrative authority to college and

division administrators for local management and support of the Windows

environment.

Organizational Unit Design

Standard organizational unit (OU) templates should be used to improve levels of

security and operational efficiency while also providing the flexibility and tools

required for college and division administrators to manage and support their resources.

An effective OU design will include privilege delegations to Central IT and site

administrators that enable them to perform their jobs effectively but also limit access so

as to maintain the standard configuration over the long term.

The OU design is comprised of three (3) key areas:

1. Top-Level Design

2. Enterprise Support Design


HACC

of 38

3. Site-Level Design

The following diagrams detail a representative OU structure which has been deployed

in organizations similar to HACC. The permissions model and precise structure are

typically generated based on a series of planning workshops and meetings with all of

the stakeholders involved.

Top-Level OU Design

In addition to the standard containers that are by default part of the top-level

structure (e.g., Builtin and Computers) as well as those added to the top-level through

domain prep or schema extensions (e.g., Microsoft Exchange System Objects), it is

recommend that the top-level OU structure include:

1. An OU for enterprise support objects, including:

Administrative accounts;

Enterprise/centrally managed servers;

Security Groups and Distribution Lists (for those groups administered

centrally by IT [both automated and manual]);

2. A shared OU for administrative departments, users and directory objects;

3. Site OUs for each college campus.

A diagram of the Top-Level OU Design is presented below.


HACC

of 38

ad.hacc.edu

Central

Administration

Gettysburg

York

Lebanon

Enterprise

Support

Lancaster

Harrisburg


HACC

of 38

Enterprise Support OU

The Enterprise Support OU will contain directory objects (user accounts,

machine accounts, and groups) that provide enterprise services (i.e., those services not

constrained to a single campus) and/or are managed by Central IT. The proposed OUs

and objects to be included under Enterprise Support include:

Users

o Administrative accounts for enterprise support as well as the local Site

Administrator accounts;

o Service accounts (for centrally administered applications and services);

o Resource accounts (for centrally administered resources such as

resource mailboxes);

Enterprise/centrally managed servers – OUs will be created to contain

servers based upon their functional groups. These OUs should be named

according to the server function codes identified later in this document;

Security Groups and Distribution Lists for enterprise groups (i.e., those

groups administered centrally by IT [both automated and manual]).

A diagram of the Enterprise Support OU design is presented on the following

page.


HACC

of 38

ad.hacc.edu

Enterprise

Support

Users

Groups

APP

Servers

Admin

Service

DBS

Domain Admin

Site Admin

Exchange

SRV

Resource

Security

Distribution

WEB


HACC

of 38

Site-Level OU Design

The Site-Level OU design is intended to address the organizational and

administrative needs of HACC:

1. Organize all user accounts under the Users OU;

2. Organize all workstations under the Workstations OU;

3. Provide multiple tiers of security for workstations and servers (i.e., standard

and high security configurations);

4. Establish sufficient flexibility to allow individual site administrators to

create, manage, and use OUs and objects within critical areas (e.g., Guests).


HACC

of 38

Recommended Site-Level OU Design

Sample Campus

Users

Groups

High Security

Workstations

Faculty-Staff

Guests

Students

Labs

Lab 2

Lab 1

Security

Distribution

Contacts

Resource

Kiosks

Service

ad.hacc.edu

Laptops

Staging

Servers


HACC

of 38

Object Lifecycle Management

As part of the lifecycle of an Active Directory environment, stale objects must be

cleaned up to prevent endless growth. The most common type of object which grows

without bound is computer objects. In organizations where a clear provisioning and

deprovisioning system is not in place, user objects tend to never be cleaned up

following employee termination. In addition to the security risks posed by this, email

storage is also never reclaimed, thus increasing the cost of hosting email.

Fortunately, Active Directory has inherent timestamps which can be used as

indicators to clean up these types of objects on a regular basis. Active Directory

domains operating at the Windows Server 2003 domain functional level (or higher)

track a last logon timestamp attribute which is accurate to within approximately ten to

fourteen days. This attribute exists on both user and computer objects. Additionally

password changes are tracked by way of the last password set timestamp.

For computer objects, it is recommended that HACC implement a nightly

scheduled task which disables and subsequently deletes any computer object which has

not logged on to the domain in 90 days or longer. After a 14 day waiting period,

disabled computers should be deleted. In order to accommodate computers which may

be powered down for long periods of time in inactive storage, a group managed by

local administrators containing exempt computers should be provisioned. Membership

of this group should be reviewed on an annual basis to determine if any machines can

be removed from the exemption list.

For user objects, it is recommended that the HACC invest in an identity

management solution that is tied to live Human Resources and/or Payroll information.

In the short term a semi-annual process to compare those databases to the Active

Directory should be implemented in order to clean up users that have been terminated.


HACC

of 38

Summary

This document represents the recommendations of Moran Technology

Consulting (MTC) for a new Active Directory environment for HACC. These

recommendations are based upon MTC’s formidable experience and understanding of

higher education. Substantial time and effort was spent collecting requirements and

feedback from the HACC community in an effort to ensure that all of the stakeholders

needs were represented and taken in to consideration.

rfp12-03 microsoft active directory design

Documents