Upload
lequynh
View
222
Download
2
Embed Size (px)
Citation preview
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
Active Directory Design
HACC
Page 2 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
Active Directory Design
HACC
Page 3 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
Active Directory Design
HACC
Page 4 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
Active Directory Design
HACC
Page 5 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.
Active Directory Design
HACC
Page 6 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.
Active Directory Design
HACC
Page 7 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.
Active Directory Design
HACC
Page 8 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
Active Directory Design
HACC
Page 9 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?
Active Directory Design
HACC
Page 10 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
Active Directory Design
HACC
Page 11 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.
Active Directory Design
HACC
Page 12 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
Active Directory Design
HACC
Page 13 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
Active Directory Design
HACC
Page 14 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
Active Directory Design
HACC
Page 15 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
Active Directory Design
HACC
Page 16 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
Active Directory Design
HACC
Page 17 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
Active Directory Design
HACC
Page 18 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
Active Directory Design
HACC
Page 19 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
Active Directory Design
HACC
Page 20 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
Active Directory Design
HACC
Page 21 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
Active Directory Design
HACC
Page 22 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
Active Directory Design
HACC
Page 23 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.
Active Directory Design
HACC
Page 24 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
Active Directory Design
HACC
Page 25 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
Active Directory Design
HACC
Page 26 of 38
Domain Controller Sync Type Source
RWDC01 External <<External NTP Source>>
RWDC02 External <<External NTP Source>>
RODC01 NT5DS Active Directory
Active Directory Design
HACC
Page 27 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
Active Directory Design
HACC
Page 28 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
Active Directory Design
HACC
Page 29 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.
Active Directory Design
HACC
Page 30 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
Active Directory Design
HACC
Page 31 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.
Active Directory Design
HACC
Page 32 of 38
ad.hacc.edu
Central
Administration
Gettysburg
York
Lebanon
Enterprise
Support
Lancaster
Harrisburg
Active Directory Design
HACC
Page 33 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.
Active Directory Design
HACC
Page 34 of 38
ad.hacc.edu
Enterprise
Support
Users
Groups
APP
Servers
Admin
Service
DBS
Domain Admin
Site Admin
Exchange
SRV
Resource
Security
Distribution
WEB
Active Directory Design
HACC
Page 35 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).
Active Directory Design
HACC
Page 36 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
Active Directory Design
HACC
Page 37 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.
Active Directory Design
HACC
Page 38 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.