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 Active Directory Design
HACC
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
Page 2 of 38
Active Directory Design
HACC
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
Page 3 of 38
Active Directory Design
HACC
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
Page 4 of 38
Active Directory Design
HACC
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.
Page 5 of 38
Active Directory Design
HACC
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.
Page 6 of 38
Active Directory Design
HACC
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.
Page 7 of 38
Active Directory Design
HACC
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
Page 8 of 38
Active Directory Design
HACC 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?
Page 9 of 38
Active Directory Design
HACC
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
Page 10 of 38
Active Directory Design
HACC
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.
Page 11 of 38
Active Directory Design
HACC
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
Page 12 of 38
Active Directory Design
HACC
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- Harrisburg 15 Always 15 Gettysburg Gettysburg Harrisburg- Harrisburg 15 Always 15 Lancaster Lancaster Harrisburg- Harrisburg 15 Always 15 Lebanon Lebanon Harrisburg- Harrisburg 15 Always 15 York York 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
Page 13 of 38
Active Directory Design
HACC 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, [317-4112] 1 HT, 1066MHz Max Memory
Page 14 of 38
Active Directory Design
HACC
Description P/N Qty. Memory: 12GB Memory (6x2GB), 1333MHz Dual Ranked RDIMMs [317-7388] 1 for 1 Processor, Optimized 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 [342-2014] 2 plug Hard Drive 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® [430-1764] 1 NetXtreme II 5709 Gigabit Ethernet NIC
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
Page 15 of 38
Active Directory Design
HACC 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
Page 16 of 38
Active Directory Design
HACC
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
Page 17 of 38
Active Directory Design
HACC 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
Page 18 of 38
Active Directory Design
HACC 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
Page 19 of 38
Active Directory Design
HACC
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
Page 20 of 38
Active Directory Design
HACC 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
Page 21 of 38
Active Directory Design
HACC
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
Page 22 of 38
Active Directory Design
HACC
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.
Page 23 of 38
Active Directory Design
HACC
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 All DNS Servers in Primary Forest ad.hacc.edu Active Directory Integrated All DNS Servers in Primary Forest
Page 24 of 38
Active Directory Design
HACC
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
Page 25 of 38
Active Directory Design
HACC
Domain Controller Sync Type Source RWDC01 External <
Page 26 of 38
Active Directory Design
HACC
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
Page 27 of 38
Active Directory Design
HACC 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
Page 28 of 38
Active Directory Design
HACC 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.
Page 29 of 38
Active Directory Design
HACC
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
Page 30 of 38
Active Directory Design
HACC
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.
Page 31 of 38
Active Directory Design
HACC
ad.hacc.edu
Central Administration
Gettysburg
Harrisburg
Enterprise Support
Lancaster
Lebanon
York
Page 32 of 38
Active Directory Design
HACC
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.
Page 33 of 38
Active Directory Design
HACC
ad.hacc.edu
Enterprise Support
Users
Admin
Domain Admin
Service
Site Admin
Resource
Groups
Distribution
Security Servers
APP
DBS
Exchange
SRV
WEB
Page 34 of 38
Active Directory Design
HACC
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).
Page 35 of 38
Active Directory Design
HACC
Recommended Site-Level OU Design ad.hacc.edu
Sample Campus
Users
Contacts
Students Groups
Faculty-Staff
Distribution
Guests
Security
Resource Workstations
Service
High Security Servers Labs
Lab 1
Lab 2
Kiosks
Laptops
Staging
Page 36 of 38
Active Directory Design
HACC
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.
Page 37 of 38
Active Directory Design
HACC
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.
Page 38 of 38