Presentation on theme: "Module 9: Designing an Active Directory Infrastructure."— Presentation 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 Program Management Program Management Development Testing Logistics Management User Education Product Management 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.
TitlePRMPMDEVTESUELM Product Manager (PRM)NNPPU Program Manager (PM)NNUUP Development (DEV)NNNNN Testing (TES)PUNPP User Education (UE)PUNPU Logistics (LM)UPNPU
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 Summary Position Problem Statement Vision Project Scope Scope Project User Profiles Project Assumptions Project Requirements Project Success Factors Project Team Structure Roles and Responsibilities Project Schedule Project Risk Assessment Document 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 Document Risk Management Problem Statement Risk Assessment Categories Risk Assessment for Organization Risks Probability Risk Owner Risk Mitigation Contingency Plans & Triggers Severity
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 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 Condition Affects Number of users per locationThe number of user objects Number of remote usersThe 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.msft distrib.nwtraders.msft OU manufacturingmanufacturing engineeringengineeringpurchasingpurchasing researchresearch
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.
TitleDomain Domain controller Servers Client computers Users SecuritySettingsPasswords Accounts Kerberos User rights File & registry DACLs Audit & Event logs Local EFS Policy ApplicationsAdministrative tools Mandatory core applications Published optional applications ComputerSystemDisk quotasPrinter moving Disk quotas Start up/shut down scripts Disk quotas Offline files UserEnvironmentDisable standard user desktop settings Logon scripts IE settings Folder re- direction Desktop lockdown
Designing a Domain Structure nwtraders.msft AsiaAsia AfricaAfrica Child Domain Name africa.nwtraders.msft Root Domain Name Root Domain Name Child Domain Name asia.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 Root ???? 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 Specification Executive Summary Position Problem Statement Vision Statement Project Scope Scope Audience Contacts Business Representatives Overview Requirements Assumptions Risks Design Tools Product
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