Module 6 Designing an Active Directory Domain Overview

  • Slides: 51
Download presentation
Module 6: Designing an Active Directory Domain

Module 6: Designing an Active Directory Domain

Overview n Identifying Business Needs n Designing the Initial Active Directory Domain n Planning

Overview n Identifying Business Needs n Designing the Initial Active Directory Domain n Planning for Security Groups n Planning for OUs

n The ongoing administrative tasks of an organization can be simplified by initially planning

n The ongoing administrative tasks of an organization can be simplified by initially planning how to organize objects in the domain. Within an Active Directory domain, you can create a hierarchical structure of administrative units, or organizational units(OUs), and then group objects into these units. Understanding domains and organizational units, and how you can control objects within each, will help you to plan a structure that fits into your administrative model.

At the end of this module, you will be able to: n Identify business

At the end of this module, you will be able to: n Identify business needs that determine domain and OU design. n Design the initial Active Directory domain. n Plan security groups to support control of objects within OUs. n Plan a hierarchical OU structure within a domain.

Identifying Business Needs Before Designing a Domain, You Should: n Identify Administrative Strategy n

Identifying Business Needs Before Designing a Domain, You Should: n Identify Administrative Strategy n Identify Security Needs n Plan for Growth and Flexibility

n The administrative structure of an organization will determine the domain design. When designing

n The administrative structure of an organization will determine the domain design. When designing a domain, you should always begin by assuming that a single domain can accommodate your organization's administrative model. Unless there is an important business reason, such as the need for distinct domainlevel policies, one domain should suffice for most organizations. Within a domain, your OU design should reflect the organization's administrative hierarchy of authority. Prior to designing the domain, you should do the following:

u. Identify Administrative Strategy n The administrative structure in your organization and the associated

u. Identify Administrative Strategy n The administrative structure in your organization and the associated plan for delegation of administrative authority together will form the basis for the organization of the domain. Determine if you will use a locational, organizational, functional, or a hybrid structure for your hierarchy design. You must create the plan for delegation of administrative authority prior to creating the domain and OU structure.

u. Identify Security Needs n You will need to identify different levels of security

u. Identify Security Needs n You will need to identify different levels of security that are needed within different areas of the organization. Your OU design will reflect these differing security needs. You can also use security groups to grant groups or individuals access to particular resources. Begin by identifying the groups that require access, the location of the resources to be accessed, and any other restrictions, such as organizational rules that may prohibit access by certain departments.

u. Plan for Growth and Flexibility Within the Organization n Make sure the domain

u. Plan for Growth and Flexibility Within the Organization n Make sure the domain name and OU structure you choose will accommodate possible growth, acquisitions, or reorganizations.

Designing the Initial Active Directory Domain nwtraders. msft Active Directory First Domain OU OU

Designing the Initial Active Directory Domain nwtraders. msft Active Directory First Domain OU OU OU

n The first domain created in Active Directory is the root domain of the

n The first domain created in Active Directory is the root domain of the entire forest. The first domain is also referred to as the forest root. The forest root contains the configuration and schema information for the forest. The life of a domain should range from three to five years. To ensure the longevity of your domain structure, include your organization's growth projections and reorganization plans in the Active Directory design.

1. Naming the Domain n Transitive trusts are established between the forest root and

1. Naming the Domain n Transitive trusts are established between the forest root and root domains of other domains in the forest, and therefore, it is important to plan easy-to-use and descriptive name for the forest root. The name of the first domain cannot be altered once it is created.

n The domain name should broadly identify your organization, because if you create additional

n The domain name should broadly identify your organization, because if you create additional domains in the future, any child domains created from the root domain will derive their names from the initial root domain. For example, if you create a root domain named contoso. msft and add a domain under the root domain named Marketing, the new domain will be named marketing. contoso. msft. Note: Remember that the OU structure should reflect the administrative structure and not the organizational structure of the organization because the organizational chart will be of no use to the administrators who will be using the OU structure.

u Planning for Security Groups n Deciding Which Security Group to Use n Planning

u Planning for Security Groups n Deciding Which Security Group to Use n Planning for Nested Groups n Design Guidelines n Discussion: Designing Security Groups

n Security groups organize individual user or computer objects for security purposes. The scope

n Security groups organize individual user or computer objects for security purposes. The scope of a group dictates who can belong to the group and what permissions that group can be assigned. When designing your OU structure, you will need to consider placement of resources within the OU and the creation and placement of security groups to grant access to these resources.

n In this lesson you will learn about the following topics: l Deciding which

n In this lesson you will learn about the following topics: l Deciding which security group to use. l Planning for nested groups. l Design guidelines. l Designing security groups.

Deciding Which Security Group to Use Universal Group n n Members from any domain

Deciding Which Security Group to Use Universal Group n n Members from any domain in the forest Use for access to resources in any domain Global Group n n Members from own domain only Use for access to resources in any domain Domain Local Group n n Members from any domain in the forest Use for access to resources in one domain

n Windows 2000 uses the following types of security groups: l Universal groups are

n Windows 2000 uses the following types of security groups: l Universal groups are used to group users and grant permissions across an entire forest. l Global groups organize domain user objects across domains. l Domain local groups grant permissions to users to gain access to network resources, such as folders, files, or printers in a single domain.

n You use security groups to secure resources. Security groups allow you to assign

n You use security groups to secure resources. Security groups allow you to assign the same permissions to large numbers of users in one operation, ensuring consistent permissions across all members of a group. An important part of planning resource and administrative security is deciding when to use each type of security group.

u. Planning for Universal Groups n Universal groups can contain members from any domain

u. Planning for Universal Groups n Universal groups can contain members from any domain in the forest and can be used in adiscretionary access control list(DACL) or system access control list(SACL) on any object in the forest.

u. Planning for Universal Groups… n When creating and updating universal groups in your

u. Planning for Universal Groups… n When creating and updating universal groups in your organization, consider the following: l Design universal groups with memberships that will remain static over time. Keep group modification to a minimum, because when you update the membership of a universal group, the complete membership of that universal group is replicated to all of the global catalog servers in the forest. This replication can create a significant amount of traffic on the network. l Avoid adding individual users to universal groups, as they reduce the need for membership changes. l Create universal groups within other universal groups when possible to reduce the number of members in each group. Adding groups to existing groups of the same type is callednesting. l Keep the total number of objects within a universal group small to help reduce replication traffic. l Note: Universal security groups are only available in native mode. Domains are created in mixed mode by default to permit compatibility with backup domain controllers (BDCs) in Microsoft Windows NT 4. 0. In an environment without BDCs, there is no need to remain in mixed mode. To use full functionality with groups, ensure that the domain is in native mode.

u. Planning for Global Groups n Global groups contain user objects from the same

u. Planning for Global Groups n Global groups contain user objects from the same domain. When planning for global groups, consider the following: l Unlike universal groups, replication of global group membership is within a domain and not throughout the forest. Only the group name is replicated to the global catalog servers, not the group membership. Therefore, interdomain replication traffic is less. l Global groups appear in the global catalog, which stores a full replica of every object in that server domain, and partial attributes of all objects in other domains. All other users and members from trusted domains can view and access global groups for assignment to either domain local or universal groups for security purposes. l Global groups can only contain other global groups or individual users from the domain in which they exist. l Consider having small group sizes. Having a larger number of small-sized groups is preferable to having a small number of large-sized groups; it will aid in easier membership management. Consider breaking large global groups into smaller global groups, and then nesting the global groups as needed. l Note: Nesting of global groups is available only when a domain has been converted to native mode.

u. Planning for Domain Local Groups n Domain local group memberships are valid only

u. Planning for Domain Local Groups n Domain local group memberships are valid only in the domain where they are defined and are not replicated to the global catalog. You can use domain local groups to combine individual users and global groups from your domain, other trusted domains, and universal groups. n When planning for domain local groups, consider the following: l Domain local groups are replicated throughout a domain. Therefore, you will want to keep membership size small and take advantage of nested groups. l Permissions should be assigned to domain local groups. l Domain local groups can contain members from any domain, but can only be referenced in DACLs or SACLs from within the same domain.

Planning for Nested Groups n When Nesting, You Should: l Minimize Levels of Nesting

Planning for Nested Groups n When Nesting, You Should: l Minimize Levels of Nesting l Document Group Membership Worldwide Managers Group Northeast Managers Southwest Managers Mid-Atlantic Managers

n Nesting can reduce the number of times permissions need to be assigned. You

n Nesting can reduce the number of times permissions need to be assigned. You can create a hierarchy of nested groups that will meet the requirements of the organization. Nesting groups in a multiple domain environment can reduce network traffic between domains and simplify administration. For example, global regional groups can contain managers specific to each region. Then all of the regional groups can be added to a Worldwide Managers global group. In places where all managers have identical access needs, permissions need to be assigned only once to the Worldwide Managers group.

n Guidelines for nesting groups include: l Minimize levels of nesting to simplify permissions

n Guidelines for nesting groups include: l Minimize levels of nesting to simplify permissions tracking. One level of nesting is most effective because it reduces the number of permission assignments and therefore makes it easier to track permissions. l Document group membership to track permission assignments. For example, a temporary employees group can be created within a group for a particular project. However, if the project group is then added to a group that has access to the organization's confidential information, the temporary employees would have access to that confidential information as well. By documenting group memberships, undesired effects of nesting can be revealed and prevented. l Note: The nesting of groups is only supported when a domain is in native mode.

Design Guidelines n Add Users to Global Groups n Add Global Groups to Domain

Design Guidelines n Add Users to Global Groups n Add Global Groups to Domain Local Groups n Assign Permissions to Domain Local Groups ge n ha C Full Control HR Managers HR Clerks Payroll Clerks Benefits HR Admins Human Resources

n When designing security groups, remember the following:

n When designing security groups, remember the following:

l Add user accounts to global groups rather than universal or local domain groups.

l Add user accounts to global groups rather than universal or local domain groups. Try to create a global group within each domain for each job description. Create further groupings by nesting the global groups within other global groups. These groupings will minimize the replication time, because only the base global group memberships should change on a regular basis.

l Add global groups to universal groups. Because universal group membership is replicated to

l Add global groups to universal groups. Because universal group membership is replicated to all global catalog servers every time a member changes, try to keep the universal group membership static. Instead of creating redundant universal groups, use nesting whenever possible.

l Add global and universal groups to domain local groups as needed. Usually, you

l Add global and universal groups to domain local groups as needed. Usually, you only need to add global groups to the domain local groups. Placing global groups into a universal group and then adding the universal group to a domain local group is possible. However, creating a universal group solely for this purpose is not recommended, because the security needs of each global group may change.

l Grant rights and assign permissions to domain local groups, instead of global or

l Grant rights and assign permissions to domain local groups, instead of global or universal groups, for greater flexibility and less complex administration.

l Delegate the authority to manage group memberships. This allows the resource owners to

l Delegate the authority to manage group memberships. This allows the resource owners to manage access to their resource in the domain local groups, and assistant administrators to manage the membership of global groups. However, only Enterprise Admins can manage the membership of universal groups.

Discussion: Designing Security Groups chicago. nwtraders. msft Benefits Database Employee Database paris. nwtraders. msft

Discussion: Designing Security Groups chicago. nwtraders. msft Benefits Database Employee Database paris. nwtraders. msft Employee Database HR Users

Scenario n Northwind Traders uses two domains: one for all resources in their Chicago

Scenario n Northwind Traders uses two domains: one for all resources in their Chicago office and another for all resources in their Paris operation. The human resources organization in each location maintains separate databases for employee information. HR users in each domain should have change permissions to the employee database in their own domain, and all HR users in both domains should have read permissions on both employee databases. All HR users in both domains should have change permissions to the benefits database in Chicago.

u Planning for OUs n Planning Upper-Level OU Strategies n Planning Lower-Level OU Strategies

u Planning for OUs n Planning Upper-Level OU Strategies n Planning Lower-Level OU Strategies n Design Guidelines

n Plan your OU structure around your network administration model. The OU structure is

n Plan your OU structure around your network administration model. The OU structure is useful only to administrators. A well-designed OU structure comprised of upper- and lower-level OUs will allow administrators to delegate authority and apply Group Policy. Your OU structure should also accommodate future reorganizations so that minimum object movement would be required.

In this lesson you will learn about the following topics: n Planning upper-level OU

In this lesson you will learn about the following topics: n Planning upper-level OU strategies. n Planning lower-level OU strategies. n Design guidelines.

Planning Upper-Level OU Strategies nwtraders. msft Root Domain First Level Second Level Third Level

Planning Upper-Level OU Strategies nwtraders. msft Root Domain First Level Second Level Third Level North America Mexico Sales HR Asia Canada Mfg Japan HR Sales HR China IT HR

n When you design an OU structure, it should reflect your Active Directory administrative

n When you design an OU structure, it should reflect your Active Directory administrative model. An administrative model defines who in your organization is responsible for managing specific users and resources across the organization's network, and the level of control each administrator maintains.

u. Upper Levels of OUs n Do not try to copy the organizational chart

u. Upper Levels of OUs n Do not try to copy the organizational chart when you design the OU structure, because the purpose is to make administration easier, which might not be achieved by using political divisions in the OU structure. You do not need to organize the OU hierarchy for ease-of-client access. Instead, create a hierarchy that mirrors the administrative and security needs of the business. Use names in the hierarchy that are meaningful to the administrative staff. You should also keep the design simple to minimize the need for constant management.

n When designing upper-level OUs, remember the following: l Base the first level OUs

n When designing upper-level OUs, remember the following: l Base the first level OUs on a static aspect of the organization. This will help prevent the need to restructure your first level OUs due to company reorganization. For example, you might choose to have different OUs for separate countries to allow for differences in administrative policies, because geographies are much less likely to change than divisions of an organization. l Consider making first-level OUs standard throughout an organization. Although OU structures may be unique to each domain, you should consider having a standard first level in the OU structure. You may have a standard first level regardless of whether it is required or not. For example, you could create first-level OUs for groups, printers, and applications within each domain. OUs do not have replication or costs and this first-level structure will keep administration for the domains consistent throughout the forest. This provides consistency for organization-wide support.

Planning Lower-Level OU Strategies nwtraders. msft Root Domain First Level Second Level Third Level

Planning Lower-Level OU Strategies nwtraders. msft Root Domain First Level Second Level Third Level North America Mexico Sales HR Asia Canada Mfg Japan HR Sales HR China IT HR

n Lower-level OUs should represent more detailed levels of administrative authority within your organization.

n Lower-level OUs should represent more detailed levels of administrative authority within your organization. Create lower-level OUs to delegate authority over objects to specific groups of users, and to accommodate Group Policy needs. For example, you could create an OU to include users who need a certain application, and then create a Group Policy for that particular OU. You can design a hierarchical OU structure in which new lower-level OUs are created, or nested, within existing OUs. This will prevent readjustment of your administration model, and is similar to the nesting that can be done with groups.

n When planning lower-level OUs, consider the following: l OUs can be administrated independently;

n When planning lower-level OUs, consider the following: l OUs can be administrated independently; however, when you create an OU within an existing OU, it inherits the properties of the OU in which it is created by default. l Only nest OUs as needed to provide a clear and accurate representation of the organization's administrative model. OUs nested too deeply can be more confusing than beneficial. l Group Policy is applied to objects in OUs from the domain root. An OU nested within another OU may have multiple levels of Group Policy to be applied. The response time depends upon the number of policies that need to be applied, and the size of those policies. l An OU cannot contain objects from another domain. Note: If Group Policy must travel over slow links in a wide area network (WAN) to be applied to computer or user objects, performance may be impacted if the Group Policy objects (GPOs) are stored in deeply nested OUs.

Design Guidelines n When Designing the OU Structure: l Choose Stable Upper-Level OU Names

Design Guidelines n When Designing the OU Structure: l Choose Stable Upper-Level OU Names That are Meaningful to Administrators l Create Lower-Level OUs to Support Group Policy l Test the OU Structure and Make Changes Based On Evaluation

u. Choose Stable Upper-Level OU Names n Choose the upper-level OU design strategy based

u. Choose Stable Upper-Level OU Names n Choose the upper-level OU design strategy based on a stable aspect of the organization, such as location. When naming OUs, remember that users do not see the OU structure, so choose names that are meaningful to administrators.

u. Create Lower-Level OUs to Support Group Policy n Design lower levels of your

u. Create Lower-Level OUs to Support Group Policy n Design lower levels of your OU structure to reflect your organization's administrative structure. Designing lowerlevel OUs to support your Group Policy plan can optimize Group Policy implementation.

u. Test the OU Structure n When you have completed your OU design, develop

u. Test the OU Structure n When you have completed your OU design, develop administrative scenarios to test your proposed OU design. These scenarios can be written or performed in a lab. You should test your OU structure against the existing administrative model of your business or organization. Based on your evaluations, make any necessary changes to your OU design so that it supports all administrative needs of your organization.

Lab A: Designing a Group and Organizational Unit Strategy

Lab A: Designing a Group and Organizational Unit Strategy

Review n Identifying Business Needs n Designing the Initial Active Directory Domain n Planning

Review n Identifying Business Needs n Designing the Initial Active Directory Domain n Planning for Security Groups n Planning for OUs