Module 6: Designing an Active Directory Domain v
Customization Information
This section identifies the lab setup requirements for a module and the
configuration changes that occur on student computers during the labs. This
information is provided to assist you in replicating or customizing Microsoft
Official Curriculum (MOC) courseware.
The lab in this module requires students to use Visio 2000 to document their
designs. Visio 2000 is demonstrated in course 1561B, module 3, Designing
Active Directory to Delegate Administrative Authority. If Visio has not been
previously demonstrated to students, refer to module 3 for instructions on
demonstrating Visio 2000.
The lab in this module includes a script to be run at the beginning and end of
the lab, creating and returning the computer to the default configuration for the
course. As a result, there are no lab setup requirements or configuration changes
that affect replication or customization.
Module 6: Designing an Active Directory Domain 1
Overview
!
Identifying Business Needs
!
Designing the Initial Active Directory Domain
!
Planning for Security Groups
!
Planning for OUs
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:
!
Identify business needs that determine domain and OU design.
!
Design the initial Active Directory domain.
!
Plan security groups to support control of objects within OUs.
!
Plan a hierarchical OU structure within a domain.
Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
how to design a domain
structure.
2 Module 6: Designing an Active Directory Domain
Identifying Business Needs
Before Designing a Domain, You Should:
!
Identify Administrative Strategy
!
Identify Security Needs
!
Plan for Growth and Flexibility
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
domain-level 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:
Identify Administrative Strategy
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.
Identify Security Needs
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.
Plan for Growth and Flexibility Within the Organization
Make sure the domain name and OU structure you choose will accommodate
possible growth, acquisitions, or reorganizations.
Slide Objective
To show that the
administrative structure and
security needs of an
organization should
determine domain and OU
design.
Lead-in
When preparing a domain
design, carefully consider
the administrative structure
and the authority of
delegation of the business
or organization.
Key Points
The administrative model of
a business should
determine the domain
design, rather than the
actual organizational
structure of the business.
For more information about
the reasons why a business
or organization could require
multiple domains, direct
students to module 7,
“Designing an Multiple-
Domain Structure” in course
1561B, Designing a
Microsoft Windows 2000
Directory Services
Infrastructure.
Module 6: Designing an Active Directory Domain 3
Designing the Initial Active Directory Domain
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
First Domain
First Domain
nwtraders.msft
Active Directory
Active Directory
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.
Naming the Domain
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.
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.
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.
Slide Objective
To illustrate the design of a
domain structure in Active
Directory.
Lead-in
The domain is the core
administrative unit in Active
Directory.
Key Points
The first domain is the root
of the forest. Choose a
name that is permanent
enough to reflect the
organization adequately and
flexible enough to be
included in the names of
possible child domains.
Choose the administrative
strategy to use prior to
creating the first domain.
Note
4 Module 6: Designing an Active Directory Domain
#
##
#
Planning for Security Groups
!
Deciding Which Security Group to Use
!
Planning for Nested Groups
!
Design Guidelines
!
Discussion: Designing Security Groups
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.
Slide Objective
To identify how security
groups are used to support
OU designs.
Lead-in
Security groups allow you to
set permissions.
Module 6: Designing an Active Directory Domain 5
Deciding Which Security Group to Use
Domain Local Group
Domain Local Group
Domain Local Group
!
Members from any domain in the forest
!
Use for access to resources in one domain
!
Members from any domain in the forest
!
Use for access to resources in one domain
Global Group
Global Group
Global Group
!
Members from own domain only
!
Use for access to resources in any domain
!
Members from own domain only
!
Use for access to resources in any domain
Universal Group
Universal Group
Universal Group
!
Members from any domain in the forest
!
Use for access to resources in any domain
!
Members from any domain in the forest
!
Use for access to resources in any domain
Windows 2000 uses the following types of security groups:
!
Universal groups are used to group users and grant permissions across an
entire forest.
!
Global groups organize domain user objects across domains.
!
Domain local groups grant permissions to users to gain access to network
resources, such as folders, files, or printers in a single domain.
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.
Planning for Universal Groups
Universal groups can contain members from any domain in the forest and can
be used in a discretionary access control list (DACL) or system access control
list (SACL) on any object in the forest. When creating and updating universal
groups in your organization, consider the following:
!
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.
!
Avoid adding individual users to universal groups, as they reduce the need
for membership changes.
Slide Objective
To explain how to plan for
security groups.
Lead-in
Security groups are the
single most important
method of securing
resources.
Key Points
Security groups are the
units for assigning and
maintaining permissions.
In order to take advantage
of all groups available in
Windows 2000, you should
set the domain to native
mode.
Choosing the appropriate
group scope is critical to
efficient management and
replication.
Delivery Tip
Review the types of groups
shown on the slide. Ask the
students where each group
type can be used, and who
can be a member of each
type. Draw examples of
possible members on the
whiteboard.
6 Module 6: Designing an Active Directory Domain
!
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 called nesting.
!
Keep the total number of objects within a universal group small to help
reduce replication traffic.
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.
Planning for Global Groups
Global groups contain user objects from the same domain. When planning for
global groups, consider the following:
!
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, inter-
domain replication traffic is less.
!
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.
!
Global groups can only contain other global groups or individual users from
the domain in which they exist.
!
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.
Nesting of global groups is available only when a domain has been
converted to native mode.
Planning for Domain Local Groups
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.
When planning for domain local groups, consider the following:
!
Domain local groups are replicated throughout a domain. Therefore, you
will want to keep membership size small and take advantage of nested
groups.
!
Permissions should be assigned to domain local groups.
!
Domain local groups can contain members from any domain, but can only
be referenced in DACLs or SACLs from within the same domain.
Note
Note
Module 6: Designing an Active Directory Domain 7
Planning for Nested Groups
!
When Nesting, You Should:
$
Minimize Levels of Nesting
$
Document Group Membership
Worldwide
Managers
Group
Worldwide
Managers
Group
Northeast Managers
Mid-Atlantic Managers
Southwest Managers
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.
Guidelines for nesting groups include:
!
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.
!
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.
The nesting of groups is only supported when a domain is in native
mode.
Slide Objective
To illustrate how new
groups are nested within
existing groups.
Lead-in
Nesting of security groups
reduces the number of times
permissions need to be
applied.
Key Points
Nesting is used to create
groups within groups, which
allows for fewer members in
each group, and fewer
groups on which to assign
permissions.
Note
8 Module 6: Designing an Active Directory Domain
Design Guidelines
Payroll Clerks
Human Resources
C
h
a
n
g
e
HR Clerks
Benefits
HR Managers
HR Admins
Full Control
!
Add Users to Global
Groups
!
Add Global Groups to
Domain Local Groups
!
Assign Permissions to
Domain Local Groups
When designing security groups, remember the following:
!
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.
!
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.
!
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.
!
Grant rights and assign permissions to domain local groups, instead of
global or universal groups, for greater flexibility and less complex
administration.
!
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.
Slide Objective
To identify guidelines for
designing security groups.
Lead-in
When designing security
groups, try the AGDLP
model.
Delivery Tip
Use the whiteboard and
repeat the AGDLP model by
placing user accounts into
global groups and global
groups into Domain local
groups, and then granting
resource permissions to the
domain local groups.
For more information on the
AGDLP model, refer to
module 6, Administering
Active Directory, from
prerequisite course 1560B,
Updating Support Skills from
Microsoft Windows NT 4.0
to Microsoft Windows 2000.
Remember to delegate the
ability to manage group
memberships.
Không có nhận xét nào:
Đăng nhận xét