module 9: designing an active directory infrastructure
TRANSCRIPT
Module 9: Designing an Active Directory Infrastructure
Overview
Conducting an Organizational Analysis
Designing an Active Directory Structure
Creating a Functional Specification
Designing a Microsoft® Windows® 2000 Active Directory™ directory service infrastructure involves planning the logical and physical aspects of the environment. You will start by gathering information about the current structure within the organization. Your design should incorporate the architectural elements of Active Directory to best address the business and administrative needs of the organization. Then, you will complete the design and ensure that it is inclusive and flexible enough to support your organization's needs.
In this lesson you will learn about the following topics:
Conducting an organizational analysis.
Designing an Active Directory structure.
Creating a functional specification.
Conducting an Organizational Analysis
Assembling the Central Planning Team
Identifying the Vision and Scope of the Project
Performing Risk Management
Documenting the Current Physical Network
Analyzing Current Business Practices
Projecting Growth and Reorganization
To create an Active Directory directory service for an enterprise, you should first assemble a central planning team. The central planning team will gather data about the organization's structure and business locations. This data will provide key information about how the organization manages people, information, and resources. At the same time, the central planning team must also examine the enterprise's business practices to determine how best to meet the business needs of an organization.
In this lesson you will learn about the following topics:
Assembling the central planning team.
Identifying the vision and scope of the project.
Performing risk management.
Documenting the current physical network.
Analyzing current business practices.
Projecting growth and reorganization.
The Central Planning Team Will
Obtain approval from upper management
Identify and consult with all systems and operations administrators
Gather information about current network
Assembling the Central Planning Team
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTesting
LogisticsManagement
LogisticsManagement
UserEducation
UserEducation
ProductManagement
ProductManagement
Communication
The central planning team is responsible for gathering necessary information about an enterprise, and organizing the information so it can guide the Active Directory design from conception to implementation. The planning team should work closely with all aspects of the organization to ensure that the organization's needs are being met effectively and efficiently. The planning team members must also communicate openly with each other to ensure that all aspects of the organization's needs are being addressed in the design of Active Directory.
The central planning team is responsible for the following activities:
Obtaining approval from upper management and the authority to represent the needs of the entire organization.
Identifying all systems and operations administrators for the entire organization so that you can gather information from the people who will be using the final network. Administrators can provide details about the network that may be missed in a high-level overview of the network.
Gathering information about the organization's current internal administrative structures, locations, resources, users, and security policies.
Team Roles
There are six general roles on a complete planning team. These roles may be performed by one or more persons, depending on the size of the organization, and include:
Program Manager. The program manager provides technical support for the project and secures resources the team needs to complete the project.
Product Manager. Product Management articulates a vision for the design. The product manager identifies requirements of the organization, develops and maintains the business reasons for initiating the project, and manages expectations of the organization. Product Management owns the vision statement.
Development Manager. Development builds or implements the design. The development manager is typically an experienced implementation architect or developer who is able to understand and appreciate the key issues in all technical areas of the project. An important aspect of this role is active participation in creating the functional specification.
Testing. Testing ensures all issues are known before the release of the design. Testing prepares the test plan, test specifications, and test cases.
User Education. User Education strives to make the final design as beneficial and easy to use as possible. User Education develops training systems, and is also responsible for reducing support costs by making the product easier to understand and use. User Education participates in the design as a user advocate.
Logistics Management. The Logistics team ensures a smooth distribution, installation and migration of the product to the operations and support groups. The logistics manager works with the development manager to ensure that the necessary data is packaged to facilitate installation and administration.
Scaling the Team
Depending on the project size, each role may be assigned to a single individual or to a team of people with a team lead. Alternatively, one person may take responsibility for more than one role. Because some roles can be combined, use the following table to determine how roles may be combined, with P for possible, U for unlikely, and N for no.
TitleTitle PRMPRM PMPM DEVDEV TESTES UEUE LMLM
Product Manager (PRM) N N P P U
Program Manager (PM) N N U U P
Development (DEV) N N N N N
Testing (TES) P U N P P
User Education (UE) P U N P U
Logistics (LM) U P N P U
Identifying the Vision and Scope of the Project
Vision
Defines clear direction
Scope
Encourages discussion
Sets expectations
Provides initial assessment of risk
Baselines design and deployment
Executive SummaryPositionProblem StatementVision
Project ScopeScopeProject User ProfilesProject AssumptionsProject RequirementsProject Success FactorsProject Team StructureRoles and ResponsibilitiesProject ScheduleProject Risk AssessmentDocument Sign off
Vision/Scope Document
A planning team should define the vision and scope of the project prior to beginning the design. The vision and scope of the project will help the team to design an Active Directory structure that fulfills the needs of the enterprise.
Vision
The vision of a project establishes the primary goals. The vision can be used to inspire the team for the long-term success of the project and also help establish short-term objectives.
Each organization will have its own business vision. By collecting information on the vision or goals of the organization and keeping those goals in mind while creating the project vision, you can ensure that the product aligns with the long-term vision of the organization.
Scope
The scope defines which features the team must address, and in what priority, according to the needs of the organization. It establishes a baseline for making trade-off decisions in terms of resources, features, and schedule. Using scope to attain the vision in achievable segments allows you more flexibility to adjust the course of the project should the business vision change.
Vision/Scope Document
The vision/scope document broadly describes the project to the organization. The document clearly defines the business problem or opportunity, the solution, and the organization or group that benefits from the solution.
Once the vision/scope document is developed, the organization and the members of the project team have achieved a common understanding and agreement on:
The overall vision of the project.
The order in which to address the business requirements.
The time frame when the functionality is required.
Any risks and assumptions associated with the project.
Any business constraints that may affect the project.
The level and effort required to complete the planning phase.
Performing Risk Management
Proactive Risk Management
Prevents Risk
Lessens Impact
Risk Document
Calculates Probability, Severity, and Exposure
Lists Mitigation and Contingency Plans
Risk DocumentRisk Management
Problem StatementRisk Assessment CategoriesRisk Assessment for
OrganizationRisksProbabilityRisk Owner
Risk MitigationContingency Plans & TriggersSeverity
The risk in a project is possible damage resulting from diminished quality of a solution to increased cost, missed deadlines, or project failure. Risk is inherent in any project.
Proactive risk management involves identifying risks ahead of time and minimizing the likelihood that a loss will occur. For example, if the risk is that users will be unable to log on to the network, you can add additional domain controllers and global catalog servers available in each site. Risk reduction also attempts to minimize the impact should loss occur. For example, if the risk is a corrupted Active Directory database, you can maintain a backup of the directory information tree.
Risk Assessment Document
Create a risk assessment document to document the initial identification and analysis of risks. A risk assessment document helps the team create and clarify mitigation plans for reducing the likelihood of risk. The document also lists a contingency plan for coping with the results of risk should it occur.
The risk assessment document should contain:
Risk statements that list the types of risks that have been identified.
Risk probability calculations that estimate the likelihood of a risk occurring.
Risk severity calculations that identify the scope of potential damage.
Risk exposure calculations that identify the cost of an actual loss.
Mitigation plans for reducing the likelihood of a given risk.
Contingency plans and triggers for decreasing damage if a problem does occur.
Documenting the Current Physical Network
Physical locations can be cities, buildings, floors within a building, network segments, and so on. Identifying details about each location provides the necessary data to design an Active Directory site structure that meets the needs of its users. Knowing how and where a company locates itself geographically is important and addresses the following implementation issues of the Active Directory structure:
Site placement and structure.
Domain controller and global catalog server placement.
Replication requirements.
To determine pertinent location details you should consider the following:
The total number of physical locations, including remote sites, subsidiaries, and international offices.
Where the offices are located geographically. For example, are they located in cities, counties, states, or countries/regions?
The number of buildings in each geographic location and the number of floors in each building.
The business functions performed at each location.
Analyzing Current Business Practices
The NetworkThe Network
Resources
Mobile Users
Users
Groups
To design the Active Directory structure that meets the needs of the organization's users, it is necessary to know certain characteristics about them. For example, to design a domain and site structure, you need to know how many users are in the enterprise network.
The following table specifies the type of user information you need to complete the Active Directory structure and describes how the information impacts the design.
Existing Business ConditionExisting Business Condition AffectsAffects
Number of users per location The number of user objects
Number of remote users The number of user objects that require remote access
Number of users added and deleted each year
Replication traffic
Frequency of users moving from one division or location to another
Replication traffic
Frequency modifying user account properties
Replication traffic
Number of offsite users from joint ventures or trusted partners
Database size, replication traffic, domain controller placement
Organization of users, by division, business unit, group, job function, or product line, for example
The Active Directory hierarchy
Projecting Growth and Reorganization
Growth Potential
Reorganization Potential
Merger and Acquisition Potential
Marketplace Changes
New Technology Demands
Changes that affect a company's administrative model and enterprise network include growth, reorganization, downsizing, mergers, acquisitions, competitive markets, and new technology demands. When an organization's administrative model and enterprise network change, they impact Active Directory design, domain and organizational unit (OU) structure, schema, and site topology. A well planned design should accommodate changes that might occur within a three to five year time span.
To identify growth and reorganization factors that may influence your Active Directory plan, you should consider:
The growth projections for the organization. Are specific divisions, business units, or locations within the company being reduced or expanded and is this trend expected to continue?
Whether growth will affect the entire organization, or just certain divisions, business units, or locations. Is growth expected to continue?
The potential for reorganization. If reorganization occurs, will divisions simply be renamed, or will users within divisions be reorganized into completely new divisions? Will the administrative model change?
Whether the organization will merge with or acquire other organizations, and, if so, whether the acquired company will become a new division within the existing organization.
Whether there are new competitors in the marketplace compelling the company to partner with suppliers, customers, and so on.
Whether users within the organization demand to use technology such as the Internet. Will use of such technology cause changes in network communications?
Designing an Active Directory Structure
Designing for Delegation of Administrative Authority
Designing for Group Policy
Designing a Domain Structure
Designing a Schema Policy
Designing Site Topology
Designing a Naming Strategy
Your Active Directory design should mirror your organization's administrative model and Group Policy design. You need to plan carefully because changes in the overall domain architecture, such as domain restructuring, can require increased Information Technology (IT) resources to support the changes. Also, adding domains later could increase server hardware costs because it also requires adding domain controllers. You will need to create a schema policy to govern any proposed changes to the Active Directory schema. You will need to plan the physical aspect of Active Directory and design an efficient site topology for your network. Finally, the name you choose for the Active Directory structure should accommodate the organization's current and future Internet plans.
In this lesson you will learn about the following topics:
Designing for delegation of administrative authority.
Designing for group policy.
Designing a domain structure.
Designing a schema policy.
Designing site topology.
Designing a naming strategy.
Designing for Delegation of Administrative Authority
Delegate at the Highest Possible Level
Use a Small Number of Domain Administrators
Create a Hierarchy to Support Delegation
Delegate OU Administration
Domain
nwtraders.msft
mfg.nwtraders.msftdistrib.nwtraders.msft
OU
manufacturingmanufacturingmanufacturingmanufacturing
engineeringengineeringengineeringengineering purchasingpurchasingpurchasingpurchasing
researchresearchresearchresearch
Delegate authority by assigning control at the highest-level OU possible rather than on individual objects. Managing permissions will be easier and more efficient. This creates a simple audit trail, and there is less chance for disaster if an administrator makes a mistake while logged on with an administrative account. Allow inherited permissions to flow down to child objects whenever possible.
If possible, avoid granting permissions at the attribute level to simplify administration. Consider placing objects in separate OUs based on how they will be managed before you decide to manage properties with separate access control lists for objects in a single OU .
Using a Small Number of Domain Administrators
The Domain Admins group has special abilities within a domain, including the ability to take ownership of any object in the domain and define domain-wide security policies, such as account lockout and password complexity. When administrator privileges need to be restricted, be sure to control access to the Domain Admins account. For example, you could require Smart Card logon for the Domain Admins account and then use physical security to restrict access to the Smart Card.
Creating a Hierarchy to Support Delegation
The hierarchies in Active Directory at the domain and OU level are designed to support the administrative needs of an enterprise, not to reflect the organizational structure of an enterprise. Identify the type of IT format used in your organization and design your hierarchy to reflect the IT role.
Delegating OU Administration
Consider the following points as you develop a delegation plan for OU administration:
Assign control at the OU level whenever possible. Assigning control at the OU level allows for easier tracking of permission assignments. Tracking permission assignments becomes more complex at the object and object attribute levels.
When an object is moved between OUs, the following happens• Security assignments made directly to the object are retained.• OU-level security assignments are inherited from the destination OU.
Document the delegation of administration assignments. Documenting assignments allows for maintaining records and easily reviewing security settings.
Designing for Group Policy
Designing Active Directory for Inheritance
Creating OUs for Group Policy
Designing Group Policy Objects
When you design for Group Policy, you design the Group Policy objects (GPOs) themselves, including their placement, function, and administration. Also, you design the Active Directory infrastructure to optimize the administration and function of the GPOs.
Designing Active Directory for Inheritance
When possible, set a Group Policy as high as you can in a hierarchy and let it flow down by inheritance. This will simplify administration and speed the logon process. Consider the following when applying Group Policy:
Limit the number of layers of OUs in the OU hierarchy within a domain if applying Group Policy at all levels. Multiple OU levels increase Group Policy processing, thus slowing down user logons and increasing the complexity of Group Policy administration.
Assign permissions in Active Directory conservatively to ensure that users do not have greater access than required to perform their job functions.
Restrict the ability to create and modify Group Policy objects to only those users who are required to perform these functions.
Creating OUs for Group Policy
Inheritance of GPOs can become complex, especially if a high degree of filtering becomes necessary to prevent GPOs from being applied to undesired users or computers. To precisely target GPOs to a specific group, create an OU containing the intended users and computers, and then apply a GPO specifically to that OU.
Designing Group Policy Objects
Group Policy is generally designed to affect security, applications, computer settings, and user environment settings. Group Policy covering these areas can be applied to various targets, including domains, domain controllers, servers, client computers, and individual users.
The most common Group Policy settings and their targets are shown in the following table.
TitleTitle DomainDomain Domain Domain controllercontroller
ServersServers Client Client computerscomputers
UsersUsers
SecuritySettings PasswordsAccountsKerberos
User rightsFile & registry DACLsAudit & Event logsLocal
User rightsFile & registry DACLsAudit & Event logsLocal
User rightsFile & registry DACLsAudit & Event logsLocal
EFS Policy
Applications Administrative tools
Administrative tools
Mandatory core applications
Published optional applications
ComputerSystem Disk quotas Printer movingDisk quotas
Start up/shut down scriptsDisk quotasOffline files
UserEnvironment Disable standard user desktop settings
Disable standard user desktop settings
Logon scriptsIE settingsFolder re-directionDesktop lockdown
Designing a Domain Structure
nwtraders.msftnwtraders.msft
AsiaAsiaAsiaAsiaAfricaAfricaAfricaAfrica
Child Domain
Name
africa.nwtraders.msftafrica.nwtraders.msft
Root Domain
Name
Root Domain
Name
Child Domain
Name
asia.nwtraders.msftasia.nwtraders.msft
nwtraders.msft
??
Using a single domain lowers administrative costs and lessens the need for adjustment during times of growth and reorganization. However, there are situations where your organization may require multiple domains.
The following questions can help you to design a hierarchical tree structure:
How many entities handle the administrative functions for the organization?
What operating systems are being used? (For example, Microsoft Windows NT®, UNIX, and so on.)
If you are considering the need to implement multiple domains, the following questions can help you make your decision: Will you need to enforce different domain-level GPOs, such as
user account policy for different domains? Do you want to limit the scope of administrative control? Are you in a partnership with another organization that
requires separate control of resources? Do you have slow wide area network (WAN) links that will be
saturated by replication traffic within a single domain?
Designing a Schema Policy
Modification Policy Should Include
Schema Modification Committee
Representatives from Each Domain
Criteria for Acceptable Changes
Agreement on Proposed Changes
Control of Schema Admins Group
Schema
Occasions that require schema modifications are rare; however, modifying the schema has implications for the entire directory. Create a schema modification policy to manage proposed schema changes. A schema modification should provide for the following:
A schema modification committee to approve proposed changes.
Administrative representation from each domain to participate on the schema modification committee.
Criteria that must be met before the schema is modified to establish that a change is necessary.
Agreement on the modification policy before finalizing the Active Directory design.
Control of schema modification permissions.
Designing Site Topology
Define Sites That Mirror Topology of Fast Network Connections
You Can Have Multiple Sites at a Single Physical Location
Use Sites to Control Replication Traffic
The simplest site structure is a network that consists of a single site. However, connectivity and available bandwidth may force you to implement multiple sites. Keep in mind the following when you are planning your sites:
Sites can be used to control logon traffic. However, if a domain controller is unavailable during the logon process, a domain controller from another site can be used to authenticate the user.
You can use sites to have greater control over when and how replication occurs.
Site-awareness is a feature of the Distributed file system (Dfs). If you are trying to access a Dfs share, you will be directed to an available server in your site, thereby reducing file transfer traffic over slow links.
Designing a Naming Strategy
Domains
Objects
DNS
Domains
Servers
RootRoot
????
nwtraders.msft
corp.nwtraders.msft
ad.nwtraders.msft
When you design the name of your Active Directory structure, ask yourself the following questions.
Does the organization currently have access to or a presence on the Internet? If so, is the Domain Name System (DNS) name that is used on
the Internet the same as the root domain name that will be used for Active Directory?
If not, are there plans for Internet access or a presence on the Internet in the future?
How have you deployed DNS in your organization? Is a DNS name hierarchy already designed and in use? If a DNS naming hierarchy is already designed, will the name of
the Active Directory structure be a part of the existing name or will a new name be used?
Does the company have more than one name registered on the Internet?
Creating a Functional Specification
Establishes Agreement and Deliverables
Provides Blueprint for Team Members
Must Be Sufficiently Complete Before Development Begins
Undergoes Revisions Before Final Version
Functional SpecificationExecutive Summary
PositionProblem StatementVision Statement
Project ScopeScopeAudienceContactsBusiness
RepresentativesOverviewRequirementsAssumptionsRisksDesignToolsProduct
A functional specification is a document that establishes an agreement between the project team and key project stakeholders within the organization. The functional specification clearly states expectations and deliverables, and documents these items for future referral.
Begin by creating a draft of the functional specification that provides a definition of the design. In the document, the team should broadly describe all functionality. The team will work out specific details during the design process. The completed specification will act as the blueprint for development, testing, user education, and logistics management to begin laying out project plans for the deployment of the design.
No specification is ever a complete description of the design. However, the functional specification must be complete enough to be tested against and to secure agreement among stakeholders on the desired functionality. If development proceeds without adequate testing, poor decisions can result in an inadequate design that fails to meet the needs of the organization.
Lab A: Designing an Active Directory Infrastructure
Review
Conducting an Organizational Analysis
Designing an Active Directory Stucture
Creating a Functional Specification