Planning To Manage User and Computer Accounts

MCT USE ONLY.
STUDENT USE PROHIBITED

6-1
Module 6
Designing AD DS Domain Administration
Contents:
Lesson 1: Planning the Delegation of AD DS Administration 6-3
Lesson 2: Designing the Structure of OUs 6-9
Lesson 3: Designing an AD DS Group Strategy 6-16

Lesson 4: Planning to Manage User and Computer Accounts 6-25
Lab: Designing AD DS Domain Administration 6-36

MCT USE ONLY. STUDENT USE PROHIBITED
6-2 Designing AD DS Domain Administration
Module Overview
You can use an Active Directory Domain Services (AD DS) domain to simplify the administration of your
IT resources, by creating a manageable structure under a network infrastructure that is based on the
Windows operating system.
If you want to design an effective administration structure for your AD DS domain, you first need to assess
the state of the AD DS environment, by collecting information about how your organization needs to
administer the various resources in your AD DS domain environment. This information provides the basis
on which you can design and build the AD DS domain structures that enable the most effective AD DS
domain-administrative methods, such as by using organizational units (OUs), AD DS groups, and account
objects for users and computers.
Objectives
After completing this module, you will be able to:
Plan for the delegation of AD DS administration.
Design the structure of OUs.
Design an AD DS group strategy.

Plan to manage user and computer accounts.
Designing Windows Server 2008 Active Directory Infrastructure and Services 6-3
Lesson 1
Planning the Delegation of AD DS Administration
The design and implementation of AD DS domain administration rely heavily on the planning process.
Your organizations structure and the methods by which your current environment operates are critical to
the design of your AD DS domain.
In order to establish the starting point for your design, gather and assess various pieces information from
your organization. This lesson identifies the key aspects of your organization that you need to assess.
Objectives
After completing this lesson, you will be able to:
Describe IT administrative models.
Gather information about current administrative structures.
Gather information about organizational resources.
Gather information about administrative processes.

IT Administrative Models
A key aspect of how you administer your AD DS domain is the administrative model that your domain
structure uses. The primary purpose of an administrative model is to define the categories and methods
that you use to support your organizations IT infrastructure.
Administrative models typically align with the organizational structure and availability of the people who
administer the AD DS domain. These people typically are dedicated IT staff, but they can include other
people as well.
The following table lists the most common types of administrative models.
Administrative model When to use

Centralized IT This model directs most of the administrative control to a dedicated,
centralized IT staff.
Use this model if the IT staff is located centrally and you do not need to
delegate control to anyone else.
Decentralized IT This model spreads administrative control to a decentralized set of IT staff

members, who typically are organized according to geographical location or
by branch structure.
Centralized IT with This model is like the centralized IT model. However, it also lets you delegate
delegation specific tasks to other users who are not IT staff members.
Use this model if you want to delegate a small subset of administrative tasks
to specific users. For example, you might want to let branch managers
administer their branchs user accounts.
Outsourced IT This model assigns administrative control to people who are external to the
organization or to an IT department that is not aligned directly with your
business model.
Use this model if your organization has no internal IT staff. In most cases, the
organizations that choose this model are either small or require a higher level
of IT administrative support than they can internally support.
Question: What other organizational requirements might influence the administrative model
that an organization chooses?
Guidelines for Gathering Information about Current Administrative

Structures
Before you begin designing the administrative structure of an AD DS domain, you first must collect
information about the existing administrative structures. Review the business requirements for the existing
directory structure, including:
Organizational-structure requirements. Your organizations structure heavily impacts the design of

your domain administration. Consider the departmental organization, the geographic locations, the
allocation of people, and similar factors.
Operational requirements. Organizations often have specific business requirements for security and
for the isolation of specific resources. Applications in the environment might require specific
restrictions or configurations that pertain to availability or security. Operational requirements are
common in military organizations, in hosting scenarios, and in organizations that use the same
directory internally and externally or that share the directory with other organizations.
Legal requirements. Many organizations have legal requirements that specify how they must function,
such as restricting access to certain information, as specified in a business contract. If the organization
fails to meet these requirements, it might lose the contract and could even face legal action. Legal
requirements apply to financial institutions, defense contractors, and other organizations that require
secrecy of data.
Anticipated requirements. Some requirements are not currently part of an organizations business
operations, but they might be in the future and you need to account for them as you design the
administration structure. These future requirements include organizational growth, changing business
needs, and business reorganization.
Guidelines for Gathering Information about Organizational Resources
When designing the administrative structure for the AD DS domain, you must gather information about
organizational resources. These resources comprise most of the items that require administration within
the domain structure. They correspond directly to AD DS objects, and your design needs to account for
them. If you thoroughly understand the organizational resources, you can ensure that the design of the
administrative structure of the AD DS domain is appropriate for your organization.
The following table lists key resources that you should gather information about.
Resources Corresponding AD DS objects

Physical devices, including servers, workstations, and printers Computers and printers
Employees, organization groups, project teams, and security OUs, users, groups, and permissions
requirements
Geographic locations and network topography OUs, sites, and replication
As you progress further into designing the structure of the AD DS domain, you need to group and
categorize these resources. Then you need to use these groups and categories to organize the objects
within the domain structure.
Groups and OUs

You should place resources that require common permissions sets into AD DS groups, and you should
place objects that require similar administration or that have common attributes into OUs. Later sections
of this module provide more detail about how to design and plan groups and OU structure.
Guidelines for Gathering Information about Administrative Processes
Your organizations administrative processes dictate how the people in your administrative model will
manage the AD DS environment. You can establish administrative processes by taking the information
that you gathered in the previous topics and applying it to a practical design for how your domain
administration will be structured, who will administer it, how the objects will be grouped, and what OU
structures you need to create in order to organize the objects.
Administrative processes include the following aspects of AD DS domain administration:
Who creates and maintains AD DS objects

How you manage and maintain AD DS objects
How you assign permissions and attributes to objects
Best Practices for Administrative Processes

When you gather information about administrative processes, compare the following best practices to
your current processes, and keep the best practices in mind as you implement or modify your
administrative processes:
Place objects that have common attributes in the same groups or OUs. This way, you can assign or
change those attributes for all objects in the group or OU simultaneously, rather than for each
individual object.
Place groups or OUs that have common attributes in a parent group or OU. This way, you can do
one-to-many administration as in the previous example, but on multiple groups or OUs and on the
objects within those groups or OUs.
Always assign permissions or modify attributes at the highest level within the AD DS domain
structure, so that you can take advantage of group and OU nesting in the hierarchy of the structure.
When you assign permissions to objects, always assign the least required privilege. Users and groups
should have only the privileges that they require on a specific object or OU, and nothing more.
Lesson 2
Designing the Structure of OUs
Organizational units are the basis for administering AD DS. The design of your OU structure dictates how
you perform important tasks, such as delegating administrative control and applying Group Policy Objects
(GPOs). If you design your OU structure properly, it helps to streamline administrative processes, and
ultimately saves you time in administering your AD DS domain.
Objectives
Describe strategies for designing OU structures.
Design OUs for delegating administrative control.
Design OUs for applying GPOs.

Design OU hierarchies.
Strategies for Designing OU Structures
OUs are your main tool for organizing the objects within your AD DS domain. You also can use OUs
to delegate permissions and to apply GPOs. The main purpose of designing and implementing an OU
structure is to ease administration, so the OU structure within your domain should align directly with how
you manage the objects.
These OU design strategies are the most common:
Location-based strategy. This strategy uses locations for each top-level OU in the root of the domain.
These location-based OUs are the main organizational element of the OU structure. For example,
Contoso might use a location-based strategy and create OUs for each of its physical locations, which
are in New York, Toronto, and Tokyo. Therefore, locate each AD DS resource, such as the users and
computers, in the OU that corresponds with the physical location of that resource.
This is a common strategy if each location operates relatively independently from the other locations.
This strategy also requires little or no movement of resources between top-level OUs, unless the
resources are moving physically. The location-based strategy also works very well for organizations
that are expecting geographic growth, because you can add new locations easily to the domain
structure by creating a new OU for the location and then placing resources in that OU.
Organization-based strategy. This strategy follows the structure of an organizations business logic.
Top-level OUs typically represent departments within the organization, such as Sales, Research, or
Finance.
This strategy works well if resources move frequently or are not affiliated with a physical location. For
example, an organization with a travelling sales team that accounts for 80 percent of employees
would benefit from an organization-based strategy. However, this strategy is not a good choice for
organizations that frequently realign their business model.
Resource-based strategy. This strategy is built around the functions of resources that are in the
OU structure. Typically, you separate resources by function, and you create OUs to represent these
functions. For example, some common, top-level OUs are Servers, Workstations, Printers, and Users.
You typically use this strategy in smaller organizations that have only one physical location or that
have departments that do not effectively align with the organization of all AD DS resources. You also
can use this strategy for large organizations, but OUs in large organizations typically are more specific
in their categorization of resources. For example, the Servers OU might contain child OUs named after
servers running the Microsoft SQL Server software, and servers running Microsoft Exchange Server,
among others.
Hybrid strategy. This strategy uses a combination of OUs based on location, organization, and
resources. A common hybrid strategy bases the top-level OUs on location, and the top-level OUs
contain child OUs that are based on resources. In the Contoso example, the top-level New York,
Toronto, and Tokyo OUs would all contain OUs named Servers, Workstations, Users, and other similar
names.
Question: What OU design strategy do you use in your environment? Is that strategy the
best fit for your organization?
Designing OUs for Delegating Administrative Control
Effectively delegating administration is important in almost every AD DS domain structure. Unless one,
and only one, person manages all aspects of your AD DS environment, you need to delegate
administrative control to other user accounts in the environment.
Methods of Delegating Control

Delegation of control with the AD DS environment involves two variables. The first variable is the
resources over which you are granting control, such as the computer and user accounts. You typically
assign delegation at the OU level so that you can allow administration of a collection of objects, rather
than of individual objects. The second variable is the users to whom you assign administrative privileges
so that they can administer resources. You need to define not only who has control, but also what kind of
control each person should have. Except in rare cases, you should always grant administrative control to
groups rather than to users.
The following are the two main ways to delegate administrative control over AD DS domain resources:
Object-type-based delegation. In object-type-based delegation, you can delegate various levels of

control to groups, based on the objects that the groups control. For example, if you delegate control
to the Toronto Admins group for objects within the Toronto OU, this is an object-type-based
delegation. In this case, the Toronto Admins are likely responsible for the majority of administration
within the Toronto OU.
You typically use object-type-based delegation if there are only a few administrators or if you require
little delegation. This type of delegation also works well if many administrators require the same level
of control, typically over most of the domain structure.
If you use object-type-base delegation in an environment where different users require various levels
of control over different objects, it can be difficult to determine which level of control is granted to
which users for a specific object.
Role-based delegation. Role-based delegation involves creating several specific groups, which you
delegate administrative control to. These groups typically relate to a specific resource or resources,
and you typically name them for the level of control that you assign to them. Rather than having
complete control over a group of objects, like in object-based delegation, role-based delegation
involves granting permissions to modify only some of the attributes of an object. For example, you
can create the role-based group Change Finance User Password and then assign permissions to
that group to change passwords for any users in the Finance OU. To ensure that your role-based
delegation is effective, all functions, or roles, within the domain structure should have an associated
group. This level of specificity makes it easy to determine which level of control you have assigned to
an individual user, because you simply examine the role-based groups that the user belongs to.
Role-based delegation can take longer to implement than object-type-based delegation. However, if
you design the OU and group structure properly, a design of role-based delegation saves
administrative effort and frustration, especially for larger organizations.
Designing the Delegation of Administrative Control

You should consider the following when you design your OU structure so that you can delegate
administrative control:
Delegate control as high in the OU structure as possible, to take advantage of inheritance. Design
your OU structure to reflect this, using nested OUs when appropriate.
Delegate only the administrative privileges that are necessary. This might require you to create more
OUs to further separate objects. For example, if all workstation computers in your organization are in
an OU called Workstations and you want to delegate control over joining computers to the domain
only for workstations in a single branch, you need to redesign your OU structure to separate
workstations by branch.
Consider using role-based delegation and a larger number of specific OUs, if you require many
administrators to have differing levels of control in the domain.
Designing OUs for Applying GPOs
Another important consideration in designing the OU structure is the application of GPOs. In the AD DS
domain structure, the OU is the most granular level that you can apply a GPO to. It is very important that
the design of your OU structure account for the use and application of GPOs.
In most cases, you design the OU structure at two levels. You use the first, and higher, level OUs to
delegate administration and to assign permissions to AD DS domain objects. You typically create these
OUs according to location, department, or resource.
If you use the location or department-based models, you commonly use a second level of OUs to separate
the resources into logical units that align with the IT structure. These OUs are where you typically apply
GPOs. For example, Contoso might have OUs for each of its locations: New York, Toronto, and Tokyo.
Within these OUs, you create a second level that separates resources by type. You then base the names
for these OUs on resources, such as Servers, Workstations, and Printers. For many organizations, these two
levels provide the necessary framework that enables you to delegate control and to apply GPOs.
If you need more granularity, you can break down resource-based OUs further: for example, the Servers
OU might have OUs named Exchange Servers, SQL Servers, Domain Controllers, and File Servers. You then
can apply GPOs that are specific to these different server types to the categorized OUs.
GPO application, by default, takes advantage of inheritance in the OU structure, so that if you apply a
GPO to the Servers OU (from the previous example), AD DS applies the GPO, by default, to the Exchange
Servers, SQL Servers, and File Servers OUs.
Designing OU Hierarchies
Although you should consider several specific aspects of AD DS functionality when you design an OU
structure, including delegation of administration and GPO application, you also should consider the
following high-level aspects of OU design:
The OU structure should align as closely as possible with your organizations business logic. This does
not mean that your OUs need to mimic your organizational chart, but it does mean that your OU
structure should easily accommodate business-level domain functionality requests. For example, a
sales manager might request that all laptops in the sales department have a specific home page set
for the Windows Internet Explorer browser. This change is easy to make if you apply a GPO, but
only if your OU structure separates computers by both department (Sales) and computer type
(Laptop).
Inheritance is an important aspect of OU functionality, both for delegation of control and GPO
application. You should design the OU structure to include objects that require the same control or
Group Policy settings within the same OU tree. This way, you can assign the delegation of control or
the GPO only once, at a higher level in the OU structure, rather than individually at each child level.
Remember that you can block inheritance for certain child OUs if you do not want AD DS to apply to
certain child OUs the settings that it applies at a higher OU level.
Design your OU structure to accommodate change. After you implement an OU structure, it
can be difficult to change, especially if you also change design strategies, such as changing from
organization-based to resource-based. Ensure that your OU structure leaves room for organizational
growth and a reasonable level of structural change.
Lesson 3
Designing an AD DS Group Strategy
AD DS groups are the fundamental objects that you use to control access to AD DS resources. As
you design the administration of an AD DS domain, group strategy is an important consideration. To
implement an effective AD DS group strategy, you should be aware of the available group types and
scopes, and how they interact. Also, observe naming and locations strategies so that you can make your
groups easy to administer and use. Finally, observe the various best practices, including group nesting.
Objectives
Explain AD DS groups in the Windows Server 2008 operating system.
Describe guidelines for developing a group-naming strategy.

Control access to resources by using groups.
Plan group administration.
Describe guidelines for designing an AD DS group strategy.

AD DS Groups in Windows Server 2008
A group is a collection of user and computer accounts that you can manage as a single unit. You can
locate a group in Active Directory or on an individual computer. Groups typically are characterized by
type and scope, which the following sections explain.
Group Types
Windows Server 2008 features two types of groups:
Security group. You can use a security group to assign user rights and permissions to a group of users
and computers.
Distribution group. You can use a distribution group with email applications so that you can send
email messages to a group of users.
Group Scope
The group scope defines whether the group spans multiple domains or is limited to a single domain. The
group scope also defines how you assign permissions to group members.
Groups can have the following scopes:
Global groups. You can use groups with a global scope to manage directory objects that require daily
maintenance, such as user and computer accounts.
Domain local groups. You can use groups with a domain local scope to define and manage access to
resources within a single domain.
Universal groups. You can use groups with a universal scope to consolidate groups that span
domains.
Guidelines for Developing a Group-Naming Strategy
Use a universal naming convention to ensure that people within your organization can identify groups
easily and that your organization names groups appropriately.
The names that you choose should help you manage the group, and the enterprise, daily. The best
practice is to follow a naming convention that identifies the type of group and its purpose, such as the
following:
Role groups. You typically use these to identify people who are grouped according to business logic.
Use a simple, unique name, such as Sales or Consultants.
Management groups. You typically use these to assign permissions to resources within the domain.
You should be able to identify the functionality of these groups by their name.
For example, ACL_Sales Folders_Read, has the following elements:
Prefix. This identifies the management purpose of group, such as ACL for groups that manage
access control lists for shared resources.
Resource identifier. This is a unique identifier of the resource the group is managing. The main
part of the name uniquely identifies the resource that the group is managing. In this example, its
Sales Folders.
Suffix. The suffix further defines what the group is managing. In the case of resource-access
management groups, the suffix defines the level of access that group members have. In this
example, its Read.
Delimiter. This should be a consistent marker, such as an underscore (_), that separates the prefix,
identifier, and suffix. Do not use the delimiter elsewhere in the nameuse it only as a delimiter.
Note that you do not use the delimiter between the words Sales and Folders. Group names can
include spaces, but you need to enclose those group names in quotes if you refer to them in
commands or scripts. You can facilitate auditing and reporting by creating scripts that use the
delimiter to deconstruct group names.
Keep in mind that nontechnical users often use role groups that define user roles. For example, you
might enable email for the Sales group, so that people in your organization can use the group as an email
distribution list. Therefore, keep your naming convention for role groups simple and straightforward. In
other words, your naming convention for role groups should not use prefixes or suffixes or delimiters
just a user-friendly, descriptive name.
It also is common for group names to include one or both of the following (depending on whether they
fit your organization):
Group scope (Sales_GG, where GG=global group)

Group location (NY_Sales)
Question: What naming conventions does your organization use? Have you used naming
conventions in the past that worked well? Have you used any group naming conventions
that didnt work well?
Controlling Access to Resources by Using Groups
Groups are the chief principal that you can use to control access to resources within your AD DS
environment. There are several aspects of group behavior within AD DS that you should take into account
when implementing groups.
Group Nesting
In almost all cases, you should use groups to control access to resources, instead of giving permissions
to user accounts. Placing groups within groupsalso called group nestingis an important part of
designing and using groups to control access to resources. If you nest groups, you can easily manage
multiple accounts and groups at once, and you can provide a more modular and flexible group structure.
Depending on the group scope (Global, Domain Local, or Universal), different methods of nesting are
available. The following table lists what each group can include as members.
Group scope Group can include as members

Global Accounts from the same domain as the parent global group
Global groups from the same domain as the parent global group
Domain Local Accounts from any domain

Global groups from any domain
Universal groups from any domain
Domain Local groups, but only from the same domain as the parent
Domain Local group
Universal Accounts from any domain within the forest in which this universal group
resides
Global groups from any domain within the forest in which this universal
group resides
Universal groups from any domain within the forest in which this universal
group resides
Group Nesting Best Practices

Group nesting best practices are commonly defined by the acronym AGDLP. AGDLP defines the order in
which group nesting should occur.
Accounts (user and computer accounts) are members of:
Global groups, which represent business roles. Global groups are members of:
Domain Local groups, which represent management rulesfor example, determining who has Read
permission to a specific collection of folders. Domain Local groups are granted:
Permission to access resources. In the case of a shared folder, access is granted by adding the Domain
Local group to the access control list (ACL) of the folder, with a permission that provides the
appropriate level of access.
AGDLP Example
This best practice for implementing group nesting translates well even in multidomain scenarios. Consider
the figure below, which describes usage of an AGDLP scenario:
This figure represents a group implementation that reflects not only the technical view of group
management best practices (AGDLP), but also the business view of role-based, rule-based management.
Consider the following scenario:
The sales force at Contoso has just completed its fiscal year. Sales files from the previous year are in a
folder, called Sales. The sales force needs Read access to the Sales folder. Additionally, a team of auditors
from Woodgrove Bank, a potential investor, require Read access to the Sales folder to perform an audit.
The following steps are required to implement the security that this scenario requires:
1. Assign users who have common job responsibilities or other business characteristics to role groups,
which you implement as global security groups. Do this separately in each domain. Add Contoso sales
people to the Sales role group and Woodgrove Bank auditors to the Auditors role group.
2. Create a group to manage access to the Sales folders with Read permission. You should implement
this in the domain that contains the resource that you are managing. In this case, it is the Contoso
domain in which the Sales folder resides. Additionally, create the rule group for resource access
management as a domain local group, ACL_Sales Folders_Read.
3. Add the role groups to the rule group for resource access management, so that you can represent
the management rule. These role groups can come from any domain in the forest or from a trusted
domain, such as Woodgrove Bank. Global groups from trusted external domains, or from any domain
in the same forest, can be members of a domain local group.
4. Assign the permission that implements the required level of access. In this case, grant the Allow Read
permission to the domain local group.
This strategy results in single points of management, reducing the management burden. There is one
point of management that defines who is in Sales and who is an Auditor. Those roles, of course, are likely
to have access to a variety of resources beyond simply the Sales folder. There is another single point of
management to determine who has Read access to the Sales folder, and the Sales folder might not just be
a single folder on a single server. It might be a collection of folders across multiple servers, each of which
assigns the Allow Read permission to the single domain local group.
Universal Groups and AGUDLP

A multidomain forest also has universal groups, which fit between global and domain local groups. AD DS
replicates universal groups throughout the forest, and they can contain members from anywhere within
the forest, so you often use universal groups to consolidate global groups from multiple domains. In the
group-nesting scenario, you can place that universal group into domain local groups in multiple domains.
You can remember the nesting as AGUDLP.
Planning Group Administration
Although the main function of groups in AD DS is to group users and to enable you to assign permissions
to access resources, you also must consider how you will administer the group objects themselves. This
includes how you will create and delete groups and how you will manage group membership and
permissions. In AD DS, designing a group management strategy is primarily about how you structure
group objects. You can use the following strategies:
Place group objects in the same OUs where accounts from the group exist. With this strategy, you can
delegate both user and group management under one OU.
Place group objects in the same OUs where resources exist. With this strategy, you can manage
resources and the access to resources under one delegation group. This method is not common, and
it has security implications.
Place all group objects centrally, in the same location in Active Directory. This strategy works well for
a small AD DS environment. This strategy places all of your groups in one container, but they are
separate from other AD DS resources. This strategy can be useful if you only want to delegate control
of groups to one or more users.
Place group objects in separate OUs. This is useful if the number of groups is large or if you delegate
the management of several groups to different administration teams.
Also, when deciding on the group placement, you should decide who will manage and administer
the groups. You can assign a group manager for each group, or you can leave this task to a domain
administrator or a designated account operator. The first approach provides more decentralized
administration, while the second one allows only specific privileged users to manage groups. In Windows
Server 2008, the Managed By tab in Active Directory Users and Computers includes a check box that the
group manager can use to update group membership.
Guidelines for Designing an AD DS Group Strategy
You should observe the following guidelines when you design an AD DS group strategy:
Grant permissions to groups only, not to individual users, even if there is only one user who needs
access. If you assign permissions directly to a user account and then the account is deleted, it leaves
orphaned entries in the ACLs for the objects to which the permissions apply.
Create groups based on administrative needs. If you create a group based on a job function and then
another person takes over that job, you need to change only the group membership. You do not
need to change all permissions that are granted to the individual user account.
If you have multiple groups to which you can add user accounts, add user accounts to the group that
is the most restrictive.
Use caution when using default groups. In most cases, these groups each have a predefined set of
rights and might permit more access than is necessary.
Use group nesting wherever possible to simplify administration.
Use the Authenticated Users group instead of the Everyone group to grant user rights and
permissions to most users. Authenticated Users limits the access to users who are logged in to the
AD DS domain, but Everyone can also include anonymous users.
Limit the number of users in the Administrators, Domain Admins, and Enterprise Admins groups. The
permissions set for these groups are far reaching, and one user seldom needs the entire set. For a
more secure environment, you can create separate administrative groups with only the necessary
permissions.
Lesson 4
Planning to Manage User and Computer Accounts
User and computer accounts are the most granular objects in the AD DS domain. They correlate directly
to the people and physical resources within your environment. Ultimately, the goal of your entire AD DS
domain administration design is to support and administer the user and computer objects.
This module covers several critical aspects of managing AD DS user and computer accounts. It explains
the various considerations and best practices that you should observe when you plan the management of
your organizations user and computer accounts.
Objectives
Describe considerations for designing a user-account strategy.

Describe considerations for designing a computer-account strategy.
Describe considerations for securing the management of user and computer accounts.
Explain the options for recovering deleted AD DS objects.
Describe considerations for implementing the Active Directory Recycle Bin.
Explain tools for automating the management of user and computer accounts.
Designing a User-Account Strategy
User accounts represent the people who use your AD DS domain, as well as the applications and services
that require access to AD DS resources. More than any other AD DS resource, user accounts change. As a
result, you need to plan and implement a user-account strategy for the AD DS domain in which the user
accounts are both easy to use and to manage.
Generally, you should place user accounts in OUs that best align with the AD DS design model. In a
location-based model, you might place accounts for users who have offices in New York in the New York
OU. In an organization-based model, you might place accounts for users in the Sales department in the
Sales OU.
The system and service accounts require special consideration in your user-account strategy. These
accounts should have greater security restrictions placed on them concerning password age, allowed
usage scenarios, and who is permitted to administer them. This typically requires that you apply one or
more GPOs, so you typically locate these accounts in a dedicated OU.
Because Group Policy settings typically affect user accounts, it is extremely important that you consider
the OU structure that you use to store user accounts. Location-based or organization-based placement
might seem to align nicely, but when you factor in travelling users, system accounts, and service accounts,
the lines are less clear. Many times, user accounts reside in their own top-level OU, which you can
subdivide in a way that best suits the administration model. This allows for AD DS to apply GPOs in one
place for organization-wide settings, and it simplifies the process of finding accounts within the domain.
Note In AD DS, user accounts are in the Users container, by default. In an AD DS domain
where you want AD DS to apply GPOs to user accounts, the Users container can cause a
problem because you cannot link GPOs to it. To solve this, create one or more OUs to store
user accounts, and then apply the GPOs there.
User-Account Naming Conventions

You can create a naming convention for user accounts, which the administrators can use to create new
objects easily. The naming convention helps the users and the administrators identify the role and
purpose of the object. When you create a naming convention for the user accounts, consider the
following guidelines:
The naming convention should be able to accommodate employees who have duplicate names or
similar names.
You should not use nicknames, initials, first names only, or last names only.
After you create the user name, you should modify it only to reflect a legal name change.
Names for domain user accounts must be unique within the domain in which you create the user
account.
Depending on the organizations security policies, naming conventions for email aliases can
correspond to conventions for user names.
Designing a Computer-Account Strategy
Computer accounts identify the workstations and servers within your AD DS domain. GPO settings
frequently affect computer accounts, so it is important where you locate computers within your OU
structure. This location is also important for computer-account administration. Computer accounts need
to be in OUs that facilitate GPO application and object administration.
You should place computer accounts to align with the AD DS design model, but special cases might
require that you create alternative OUs to facilitate administration and GPO application. For example,
domain controllers require special considerations within your AD DS domain environment.
Note Like user accounts, a dedicated Computers container stores all computer accounts,
except domain controllers, by default. Domain controllers have their own separate
container. In an AD DS domain where you want AD DS to apply GPOs to computer
accounts, the Computers container can cause a problem because you cannot link GPOs to
it. To solve this, create one or more OUs to store computer accounts, and then apply the
GPOs there.
Naming Conventions for Computer Accounts

Similar to user accounts, you can use computer accounts to authenticate and to audit computer access to
the network and to domain resources. If you create a naming convention for your computer accounts, you
can help the administrators troubleshoot and diagnose faults. When creating a naming convention for
your computer accounts, consider the following guidelines:
You should structure the names of workstations so that administrators can determine the type of
computer quickly and easily, and can retrieve additional information about the computer from the
asset register.
If you often relocate computers between departments or branches, the computer names should not
contain any reference to the location or the user name. This makes it easier to move computers
between locations and to assign the computers to different users as necessary.
If you use location-based naming, you should change the computer name each time you move the
computer or transfer it to another user.
The computer names should include an indication of the principal role or function of the server, to
help administrators troubleshoot faults. If you are using location-based naming, the computer name
should also include information that enables administrators and users to quickly determine the
location of the computer.
The characters that indicate the computer function can include a number to help identify Network
Load Balancing (NLB) or a failover cluster.
Securing the Management of User and Computer Accounts
Several built-in AD DS groups, by default, have the permissions that you need to manage user accounts
and computer accounts. These built-in groups include the Account Operators group, the Administrators
group, and the Domain Admins group. You should limit the membership in these groups and the ability
to administer membership in them to a small subset of administrators.
Administrators should not perform day-to-day operations with accounts in these groups. Rather, they
should use user accounts that have more restricted access, and they should use the User Account
Control and the Run as Administrator dialog boxes. This creates a more secure environment that has a
lower likelihood of compromising accounts.
For sensitive and administrative-level groups, you can use Restricted Groups in Group Policy to manage
group membership and to help ensure that these groups are adequately secured. Module 8 covers
Restricted Groups in more detail.
To help secure the user and computer accounts, you can refine the permissions on OUs that contain the
accounts, based on administrative requirements. This approach helps prevent the accidental addition of
extra privileges for a single account, and it helps to standardize the permission to manage accounts in
AD DS. You also should keep groups that have permissions to manage OUs outside of the managed OUs
themselves, preferably in a dedicated OU.
Options for Recovering Deleted AD DS Objects
An object that is deleted from AD DS can create problems for administrators, especially if it is deleted
inadvertently and you need to restore it to AD DS.
AD DS is, at its core, a hierarchical database, which holds information about the networks resources.
The AD DS database primarily is stored on domain controllers in a file called NTDS.DIT. You perform any
operations that modify AD DS objectsincluding recovering deleted objectson this database. If an
object is deleted from AD DS, what actually happens in the database is that the record for that object is
tombstoned in the database. Tombstoned means that the attributes for the deleted object are still in the
database, but AD DS treats them as inactive.
There are two native methods for restoring AD DS objects, including:
Restore a system-state backup from a domain controller. This method completely restores the objects
to the AD DS database, but it can be tedious and time-consuming. Because of the way tombstoning
works, you cannot restore a system-state backup if it is more than 180 days old.
Use the Active Directory Recycle Bin. New in Windows Server 2008 R2, you can use the Active
Directory Recycle Bin to reanimate tombstoned objects and to restore the objects as active in the
AD DS database. The next topic provides more detail about the Active Directory Recycle Bin.
Implementing the Active Directory Recycle Bin
Before Windows Server 2008 R2, if you wanted to recover objects that were removed from the AD DS
database, you needed to perform a disaster recovery. This meant that you needed to spend a lot of time
performing the restoration, and the restoration could introduce other issues.
In Windows Server 2008 R2, the Active Directory Recycle Bin makes it easier for you to recover and
preserve objects that are removed, either accidentally or maliciously, from the AD DS database.
If you enable the Active Directory Recycle Bin, it preserves all link-valued and non-link-valued attributes of
the deleted objects, and it restores the objects in their entirety to the same logical state that they were in
immediately before they were deleted. For example, restored user accounts automatically regain all group
memberships and corresponding access rights that they had before the deletion, both within and across
domains. The Active Directory Recycle Bin works for both AD DS and Active Directory Lightweight
Directory Services (AD LDS) environments.
Considerations for the Active Directory Recycle Bin

If you want to use the Active Directory Recycle Bin, consider the following:
By default, the Active Directory Recycle Bin is disabled. To enable it, you must first raise the forest
functional level of your AD DS or AD LDS environment to Windows Server 2008 R2. This in turn
requires that all domain controllers in the forest or all servers that host instances of AD LDS
configuration sets be running Windows Server 2008 R2.
In Windows Server 2008 R2, once you enable the Active Directory Recycle Bin, you cannot disable it.
Enabling the Active Directory Recycle Bin

The primary tool for configuring and using the Active Directory Recycle Bin is the Active Directory module
for the Windows PowerShell command-line interface. This module contains several cmdlets that perform
the functions of the Active Directory Recycle Bin. To enable the Active Directory Recycle Bin:
1. Raise the forest functional level to Windows Server 2008 R2. To do this, use the Set-ADForestMode
cmdlet from the Active Directory module for Windows PowerShell. For example, to raise the level for
Contoso.com, run the following command from a prompt for the Active Directory module for
Windows PowerShell:
Set-ADForestMode Identity contoso.com -ForestMode Windows2008R2Forest
2. Use the Enable-OptionalFeature cmdlet to enable the Active Directory Recycle Bin for the forest. To
enable the Active Directory Recycle Bin for Contoso.com, run the following command from a prompt
for the Active Directory module for Windows PowerShell:
Enable-ADOptionalFeature Identity CN=Recycle Bin Feature,CN=Optional

Features,CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=contoso,DC=com Scope ForestOrConfigurationSet
Target contoso.com
Finding and Restoring Deleted Objects

At this point, the Active Directory Recycle Bin is enabled. Deleted objects are now placed in the Deleted
Objects container, and you can interact with them by using the Get-ADObject and Restore-ADObject
cmdlets.
For example, the following command searches the Deleted Objects container for the Contoso.com
domain for any objects that have the display name of Mary, and the command returns the objects to the
screen:
Get-ADObject -Filter {displayName -eq "Mary"} -IncludeDeletedObjects
You can redirect this object to the Restore-ADObject cmdlet by using pipelining, so you can both find
and restore the object with a single command:
Get-ADObject -Filter {displayName -eq "Mary"} -IncludeDeletedObjects | Restore-ADObject

Tools for Automating the Management of User and Computer Accounts
To automate the management of user and computer accounts, you can use the following tools:
LDAP Data Interchange Format Data Exchange (LDIFDE)
Comma-Separated Value Data Exchange (CSVDE)
Windows PowerShell
Using LDIFDE
You can use LDIFDE to import and export Active Directory objects in the LDAP Data Interchange Format.
You typically use LDIFDE to import accounts from, or export accounts to, other directories that can use
the Lightweight Directory Access Protocol (LDAP).
Using CSVDE
You can use the CSVDE tool to import data from, and export data to, AD DS, by using files that store data
in the comma-separated value (CSV) format. You typically use CSVDE for importing accounts from, or
exporting accounts to, databases that do not support LDAP, such as an external human-resource
application or a SQL Server database.
Windows PowerShell
You can use Windows PowerShell scripts to automate user-management tasks. In Windows Server
2008 R2, Windows PowerShell contains a complete set of Active Directory-related cmdlets. The
Get-ADUser and the Set-ADUser cmdlets are the most commonly used for managing user accounts,
and you can use them to modify one or more user objects.
For example, you can use the Get-ADUser cmdlet to specify an existing user account (or multiple
accounts), and then you can pipe the results to the Set-ADUser cmdlet to modify attributes. The syntax is:
Get-ADUser UserName | Set-ADUser [-parameter value]

The UserName placeholder specifies the distinguished name of the user account that you want to modify.
The Set-ADUser parameters indicate the attributes to change and the new values. For example, the
following command changes the office attribute of Tony Krijnen:
Get-ADUser Tony.Krijnen | Set-ADUser office "Stockholm"
Modifying Attributes for Several Users at Once
You can use the Get-ADUser cmdlet to view several user accounts, based on specific criteria. To do this,
provide a filter parameter:
Get-ADUser Filter Name like * SearchBase OU=Production, DC=Contoso, DC=Com
This command displays all user accounts (indicated as an asterisk *) in the Production OU.
You can then pipe this information to the Set-ADUser cmdlet to modify the attributes:
Get-ADUser Filter Name like * SearchBase OU=Production, DC=Contoso, DC=Com|Set-

ADUser Department Production Company Contoso, Ltd
This command modifies the department and company attributes for all user accounts that are in the
Production OU.
For a list of parameters that you can set by using the Set-ADuser cmdlet, see the additional reading links
in the student companion content.
Note Computer and group accounts have cmdlets similar to Set-ADUser and
Get-ADUser. They are named Set-ADComputer, Get-ADComputer, Set-ADGroup, and
Get-ADGroup. One of the benefits of Windows PowerShell is that the syntax remains
almost identical for these cmdlets as for Set-ADUser and Get-ADUser.
Lab: Designing AD DS Domain Administration
Lab Setup
For this lab, you use the available virtual-machine environment. Before you begin the lab, do the
following:
1. On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.
2. In the Virtual Machines pane, click 6436B-NYC-DC1-B, and then, in the Actions pane, click Start.
3. To connect to the virtual machine, click 6436B-NYC-DC1-B, and then, in the Actions pane, click
Connect.
4. Log on by using the following credentials:
User name: Administrator
Password: Pa$$w0rd
Domain: Contoso
Lab Scenario
In the past, Contoso has used a highly centralized approach to managing its IT infrastructure. However,
because of the companys expansion, especially to other countries around the world, this centralized
approach is no longer efficient. As a result, IT management wants the AD DS design team to recommend
how to change the AD DS administration structure to meet several requirements, including:
A group of administrators in the New York office must be the only group of users who can make
domain-wide changes, such as configuring AD DS sites, creating top level OUs, managing domain
controllers, and creating and managing management user accounts and groups.
A single group of administrators, who are in the New York office, must be the only people who can
create and delete all regular user and group accounts in the Contoso.com domain.
Each remote office (other than the small sales offices that are planned for Europe) will have a local
administrators group, which will be responsible for troubleshooting local user and computer issues in
their respective regions. The local administrators must have full access to all servers in their offices
(other than domain controllers), and they must be able to address user issues such as password resets.
Contoso has several servers that host enterprise-wide applications. Contoso has a dedicated team that
is responsible for managing these servers, including role-based security and standardization. This
team also manages access to the applications and resources that these servers host. The organization
uses three rolesSQL, WEB, and APPfor these servers.
Users from the TreyResearch.com domain, as well as users from all other offices, need to be able to
access files on a file server that is in New York.
As the number of users at Contoso increases, the administrators are looking for ways to optimize the
processes for managing users and groups. They want to automate the processes for adding multiple
user accounts at one time, changing the attributes for a large number of user accounts and
computers, and managing groups.
Exercise 1: Creating and Implementing an OU Design

Scenario
The main tasks for this exercise are:
1. Summarize the requirements for the OU design.
2. Create the OU design.
3. Implement OUs for administrative delegation.
X Task 1: Summarize the requirements for the OU design

1. Read the lab scenario.
2. Identify important requirements that influence OU design, such as:
Which OU design models do you think would work in this situation?
How does centralized administration in New York affect the overall OU design?
How can you place AD DS objects within the OU structure?
X Task 2: Create the OU design

1. Create a design draft by answering the following questions:
Which OU design model should you use for the top-level OUs?
Which OUs do you need so that you can delegate administration?
Which OUs should you create so that you can manage the local servers?
Which OUs should you create for managing the enterprise application servers?
2. Create a drawing of your draft design.
X Task 3: Implement OUs for administrative delegation

1. Create the new OU structure in the Contoso domain on NYC-DC1.
2. Create a new computer object in the Tokyo\Servers OU, and name it TOK-SRV1.
3. Delegate full control for the Servers OU that is in Tokyo to Contoso\IT.
Results: After this exercise, you should have created and implemented an OU design.
Exercise 2: Creating and Implementing an AD DS Group Design

Scenario
1. Summarize the requirements of the AD DS group design.
2. Create the AD DS group design.
3. Implement part of the AD DS group design.
X Task 1: Summarize the requirements of the AD DS group design

Identify important requirements that influence group design, such as:
What groupings of users in the scenario might you need to represent as AD DS groups?
What groups do you need to create so that you can control access to resources?
How can you create these access control groups to conform to the principles of role-based group
management?
What factors affect the type that these groups should be?
What factors affect the scope of these groups?
Can groups contribute to optimizing the process for adding new users and groups?
X Task 2: Create the AD DS group design

1. Plan the draft AD DS group design by answering the following questions:
What groups should you create?

What is the scope and type of each group?
Where should the groups be located in the OU structure?
How does each group include or interact with the other groups in this design?
2. Using the answers to these questions, create the draft design by listing each group that you will
create, as well as the scope and location of that group.
X Task 3: Implement part of the AD DS group design

1. Log on to NYC-DC1-B as Contoso\Administrator with a password of Pa$$w0rd.
2. In Active Directory Users and Computers, create the global groups for the local administrators in each
location, as you have documented them in Task 2.
Results: After this exercise, you should have created and implemented an AD DS group design.
Exercise 3: Automating User and Group Management

Scenario
1. Run the Lab06Setup.cmd file.
2. Modify a script to create user accounts from a .csv file.
3. Modify a script to move accounts based on group membership.
4. Create a script that adds all members from an OU to an AD DS group.
X Task 1: Run the Lab06Setup.cmd file

On NYC-DC1, navigate to E:\Labfiles\Mod06\, and then run the Lab06Setup.cmd file.
X Task 2: Modify a script to create user accounts from a .csv file

1. On NYC-DC1, open and view the Philadelphia.csv file, which is in E:\Labfiles\Mod06.
2. Use Notepad to open the ImportUsers.ps1 file, which is in E:\Labfiles\Mod06.

3. Modify the script to create the user accounts and groups that are in the .csv file in the
Philadelphia OU.
4. Open the Active Directory module for Windows PowerShell, and then run the modified script.
5. Confirm that the new user accounts and groups are created in the Philadelphia OU.
X Task 3: Modify a script to move accounts based on group membership

1. Open the MovetoOUbyGroup.ps1 file, which is in E:\Labfiles\Mod06.
2. Modify the Windows PowerShell script to move the members from each of the following groups in
the Contoso.com domain to the corresponding OU. In the Active Directory module for Windows
PowerShell window, run the script for each group to:
Move the IT group to the New York\Users OU.

Move the Marketing group to the Toronto\Users OU.
Move the Production group to the Tokyo\Users OU.
Move the Research group to the Chennai\Users OU.

3. Confirm that user accounts are in the proper OUs.
X Task 4: Create a script that adds all members from an OU to an AD DS group

1. Use Notepad to create a new file named ADOUtoGroup.ps1 in E:\Labfiles\Mod06.
2. Create a line of script that uses the Get-ADUser cmdlet to place user objects in the New York OU in
a variable.
3. Create another line of script that uses Add-ADGroupMember to add the user objects that the
variable contains to the NYC_Admins_GG group.
4. Save the script.
5. Open the Active Directory module for Windows PowerShell, and then run the script.
6. Confirm that the users in the New York OU now belong to the New York Admins_GG group.
Results: After this exercise, you have automated user and group management.
X To prepare for the next module

When you finish the lab, revert the virtual machines to their initial state. To do this, complete the
following steps:
1. On the host computer, start the Hyper-V Manager.
2. In the Virtual Machines list, right-click 6436B-NYC-DC1-B, and then click Revert.
3. In the Revert Virtual Machine dialog box, click Revert.

Module Review and Takeaways
Review Questions
1. Which AD DS structures are most critical to administrative delegation, and why?
2. Which group-management method allows for more secure and efficient administration of AD DS
groups?
3. Why should you always observe the principle of least privilege when assigning permissions for AD DS
objects?
Best Practices Related to the Design of AD DS Domain Administration

Always assign the least privilege that an AD DS object requires.
Use OU hierarchy and inheritance when delegating administration over AD DS objects.
Use an AD DS structure that aligns with your organizations business logic. This makes your AD DS
environment more understandable to administrators and users.
When designing an AD DS domain-administration structure, assume that your organizations business

structure will change, and design for flexibility.
Tools
Tool Use to Where to find it
Active Directory Users and Create and manage AD DS Administrative Tools
Computers objects
LDIFDE Import and export data that has Type LDIFDE at the command
LDAPcapable directories prompt
CSVDE Import and export .csv based Type CSVDE at the command
data prompt
Active Directory module for Run scripts that automate tasks Administrative Tools
Windows PowerShell for AD DS

Planning To Manage User and Computer Accounts

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Planning To Manage User and Computer Accounts

Uploaded by

Copyright:

Available Formats

MCT USE ONLY.

STUDENT USE PROHIBITED

Lesson 2: Designing the Structure of OUs 6-9

Lesson 3: Designing an AD DS Group Strategy 6-16

Lab: Designing AD DS Domain Administration 6-36

Design the structure of OUs.

Design an AD DS group strategy.

Describe IT administrative models.

Gather information about current administrative structures.

Gather information about organizational resources.

Gather information about administrative processes.

Administrative model When to use

Decentralized IT This model spreads administrative control to a decentralized set of IT staff

Guidelines for Gathering Information about Current Administrative

Organizational-structure requirements. Your organizations structure heavily impacts the design of

Guidelines for Gathering Information about Organizational Resources

Resources Corresponding AD DS objects

Geographic locations and network topography OUs, sites, and replication

Groups and OUs

Guidelines for Gathering Information about Administrative Processes

Administrative processes include the following aspects of AD DS domain administration:

Who creates and maintains AD DS objects

How you assign permissions and attributes to objects

Best Practices for Administrative Processes

Design OUs for delegating administrative control.

Design OUs for applying GPOs.

Strategies for Designing OU Structures

Designing OUs for Delegating Administrative Control

Methods of Delegating Control

Object-type-based delegation. In object-type-based delegation, you can delegate various levels of

Designing the Delegation of Administrative Control

Designing OUs for Applying GPOs

Explain AD DS groups in the Windows Server 2008 operating system.

Describe guidelines for developing a group-naming strategy.

Plan group administration.

Describe guidelines for designing an AD DS group strategy.

AD DS Groups in Windows Server 2008

Groups can have the following scopes:

Guidelines for Developing a Group-Naming Strategy

For example, ACL_Sales Folders_Read, has the following elements:

Group scope (Sales_GG, where GG=global group)

Controlling Access to Resources by Using Groups

Group scope Group can include as members

Domain Local Accounts from any domain

Group Nesting Best Practices

Accounts (user and computer accounts) are members of:

Consider the following scenario:

Universal Groups and AGUDLP

Planning Group Administration

Guidelines for Designing an AD DS Group Strategy

Use group nesting wherever possible to simplify administration.

Describe considerations for designing a user-account strategy.

Explain the options for recovering deleted AD DS objects.

Describe considerations for implementing the Active Directory Recycle Bin.

Designing a User-Account Strategy

User-Account Naming Conventions

Designing a Computer-Account Strategy

Naming Conventions for Computer Accounts

Securing the Management of User and Computer Accounts

Options for Recovering Deleted AD DS Objects

There are two native methods for restoring AD DS objects, including:

Implementing the Active Directory Recycle Bin

Considerations for the Active Directory Recycle Bin