AD Group Management

These materials are the copyright of John Wiley & Sons, Inc.
and any dissemination, distribution, or unauthorized use is strictly prohibited.

Active Directory®
Group Management
IMANAMI SPECIAL EDITION
by Jonathan Blackwell
with Steve Clines
Active Directory® Group Management For Dummies®, Imanami Special Edition
Published by
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774
www.wiley.com
Copyright © 2013 by John Wiley & Sons, Inc., Hoboken, New Jersey
Published by John Wiley & Sons, Inc., Hoboken, New Jersey
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,
except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the
prior written permission of the Publisher. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, the Wiley logo, For Dummies, the Dummies Man logo, A Reference for the Rest
of Us!, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are
trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United
States and other countries, and may not be used without written permission. Active Directory is a
registered trademark of Microsoft Corporation. Imanami and the Imanami logo are trademarks of
Imanami Corporation. All other trademarks are the property of their respective owners. John Wiley
& Sons, Inc., is not associated with any product or vendor mentioned in this book.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE

NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETE-
NESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES,
INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE.
NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS.
THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITU-
ATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT
ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PRO-
FESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL
PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE
FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS
REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER
INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE
INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT
MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN
THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRIT-
TEN AND WHEN IT IS READ.
For general information on our other products and services, or how to create a custom For Dummies
book for your business or organization, please contact our Business Development Department in the
U.S. at 877-409-4177, contact info@dummies.biz, or visit www.wiley.com/go/custompub. For
information about licensing the For Dummies brand for products or services,
contact BrandedRights&Licenses@Wiley.com.
ISBN 978-1-118-64504-8 (pbk); ISBN 978-1-118-64553-6 (ebk)
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
About This Book......................................................................... 1
How This Book Is Organized..................................................... 1
Icons Used in This Book............................................................. 3
Where to Go from Here.............................................................. 3
Chapter 1: Introduction to Active Directory. . . . . . . . . . . 5

Getting a Grip on Active Directory........................................... 5
Understanding Active Directory Objects................................. 6
Getting to Know the Structure of AD........................................ 6
Defining Trusts............................................................................ 9
Chapter 2: Active Directory Groups and Security. . . . . 11

Defining Active Directory Groups........................................... 11
Exploring AD Group Types...................................................... 12
Understanding Active Directory Security.............................. 14
Chapter 3: Managing Active Directory Groups . . . . . . . 17

Using the Built-in Active Directory Management Tools....... 17
Managing Groups with Imanami GroupID.............................. 22
Providing a Complete Group Life Cycle Solution.................. 23
Chapter 4: Dynamic Groups. . . . . . . . . . . . . . . . . . . . . . . . 27

Understanding Dynamic Group Membership....................... 27
Using Smart Groups.................................................................. 32
Managing Hierarchical Groups with Dynasties..................... 35
Chapter 5: Ten Group Management Best Practices . . . 41

Create Dynamic AD Security Groups...................................... 41
Empower End-Users................................................................. 41
Join AD Groups.......................................................................... 42
Include Restrictions.................................................................. 42
Require Group Descriptions.................................................... 42
Set Group Expiration Dates..................................................... 42
Use Hierarchies to Build Distribution Lists........................... 42
Ensure Accuracy....................................................................... 43
Enable Temporary Membership............................................. 43
Stay Group Healthy................................................................... 43
Publisher’s Acknowledgments
We’re proud of this book and of the people who worked on it. For details on how to
create a custom For Dummies book for your business or organization, contact info@
dummies.biz or visit www.wiley.com/go/custompub. For details on licensing the
For Dummies brand for products or services, contact BrandedRights&Licenses@
Wiley.com.
Some of the people who helped bring this book to market include the following:
Acquisitions, Editorial, and Composition Services

Vertical Websites Senior Project Coordinator: Kristie Rees
Senior Project Editor: Zoë Wykes Layout and Graphics: Jennifer Creasey
Acquisitions Editor: Kyle Looper Proofreader: Susan Moritz
Editorial Manager: Rev Mengle Special Help from Imanami:
Business Development Representative: Rick Probst, Charles Orlando
Kimberley Schumacker
Custom Publishing Project Specialist:
Michael Sullivan
Publishing and Editorial for Technology Dummies

Richard Swadley, Vice President and Executive Group Publisher
Andy Cummings, Vice President and Publisher
Mary Bednarek, Executive Director, Acquisitions
Mary C. Corder, Editorial Director
Publishing and Editorial for Consumer Dummies
Kathleen Nebenhaus, Vice President and Executive Publisher
Composition Services
Debbie Stailey, Director of Composition Services
Business Development
Lisa Coleman, Director, New Market and Brand Development
Introduction
I n any Active Directory environment, groups and their
proper management are key to providing both security and
productivity in your Windows-based IT environment. Your
organization wants to provision users into Active Directory
(AD) and keep that data accurate. As part of provisioning an
Active Directory user, IT will want the user automatically added
to the correct AD security groups and Microsoft Exchange
Server distribution lists. Membership in the correct security
groups gives users access to the appropriate group policies
and systems. Membership in the right distribution lists gives
them immediate access to information.
Although Microsoft provides tools and methods for managing

groups, Imanami provides improvements on these tools so
that you can manage groups more proactively and with less
effort than with the Microsoft-provided tools.
About This Book

Active Directory Group Management For Dummies, Imanami
Special Edition, provides an overview of Active Directory and
Active Directory groups. It also explores what the Microsoft
toolset can do with groups and how Imanami solves these
group management issues with their toolset. The book is
written for nontechnical readers in medium-sized to large
enterprises.
How This Book Is Organized

This book consists of five chapters that are chock-full of infor-
mation about Active Directory and all things related. Here’s a
brief synopsis of what we talk about in each one.
2 Active Directory Group Management For Dummies
Chapter 1: Introduction
to Active Directory
In this chapter, you get the basics of Active Directory and the
components and terminology that surround it.
Chapter 2: Active Directory

Groups and Security
Here, you find out how Active Directory groups are leveraged
to provide security. You also spend some time looking at
Windows security and how authentication and authorization
work.
Chapter 3: Managing Active

Directory Groups
This chapter talks about the common and traditional tools
used to manage groups, as well as Imanami’s GroupID group
management tool.
Chapter 4: Dynamic Groups

This chapter discusses how to use Imanami’s GroupID tool to
create and manage groups with dynamic membership, as well
as hierarchical dynasties.
Chapter 5: Ten Group

Management Best Practices
Presented for your reading enjoyment in that familiar For
Dummies “Part of Tens” style, this chapter gives you ten best
practices that will grow your Active Directory world.
Introduction 3
Icons Used in This Book

Throughout this book, you occasionally see special icons that
call attention to important information. Here’s what you can
expect.
This icon points to some information that you should really

keep in mind when you are working with Active Directory
group management.

Sometimes we present a quick technical topic calling attention
to it with this icon. This stuff is separated out so if you don’t
care to get too technical, feel free to skip it.

This icon points to some useful information that can save you
time or trouble when working with Active Directory groups.
This icon appears when we want to caution you about a par-

ticular point. This is typically when you are performing Active
Directory administrative tasks that could be catastrophic if
you are not careful. So fair warning!
Where to Go from Here

You have two choices as to where to go next. If you have
experience with Active Directory and Windows security, you
can certainly jump over to Chapters 3 and 4 to find out about
Imanami’s approaches to group management. If you’re a novice
or don’t know anything about Active Directory, we recommend
starting with Chapter 1.
Regardless of where you start or how often you come back to

the pages of this book, it’s here for your reading pleasure!
Chapter 1
Introduction to Active
Directory
In This Chapter
▶ Becoming familiar with Active Directory
▶ Understanding what Active Directory objects are
▶ Getting to know about the structural components of Active Directory
▶ Defining what Active Directory trusts are
B efore we can talk about managing groups in Active

Directory, which is the overarching topic of this small
book, we need to spend a bit of time talking about Active
Directory itself. For the purpose of this book, this chapter
sticks to the basics of Active Directory so that we can talk
about Active Directory group management that much sooner!
Getting a Grip on
Active Directory
Active Directory (AD) is a directory service created by Microsoft
for use primarily in Windows environments. Its main purpose is
to provide central authentication and authorization services for
Windows-based computers. Active Directory also allows admin-
istrators to assign policies, deploy software, and apply critical
updates to an organization.
Active Directory’s other primary function is to provide a service

that stores information and settings in a central database. A
single Active Directory database, known as the directory store,
can vary from a small installation with a few hundred objects

to a large installation with millions of objects.
Understanding Active
Directory Objects
The data stored in Active Directory, such as information
about users, contacts, printers, servers, databases, groups,
computers, folders, and security policies, is organized into
objects. Objects fall into three broad categories: resources
(for example, printers), services (such as e-mail), and users
(meaning user accounts, contacts, and groups). In addition to
storing objects, AD also provides ways to organize and con-
trol access to these objects.
Each object represents a single entity — a user, a contact,

a computer, a printer, or a group — and has its own set of
associated attributes. Each object in AD is uniquely identi-
fied by its name and its set of attributes. The characteristics
and information that the object can contain are defined by a
schema, which also determines the kind of objects that can be
stored in the AD.
The Active Directory schema defines the list of objects that

can exist within AD and the list of attributes that are associ-
ated with each type of object.

Object attributes are characteristics of objects in the direc-
tory. For example, the attributes of a user account object might
include the user’s first name, last name, and logon name,
while the attributes of a computer account object might include
the computer name and description.
Getting to Know the

Structure of AD
Now that you know what an object is, you need to understand
how these objects are arranged within Active Directory. While
it is certainly possible to simply have all AD objects as peers to
each other, that isn’t very interesting — and more importantly,
Chapter 1: Introduction to Active Directory 7
it doesn’t allow for objects to be grouped together based on
common traits, such as who should be able to administer that
object versus who can simply read it. In fact, the way the IT
organization is going to administer AD (the administrative
model) is the primary driver for how the structure of AD ends
up. So here’s a look at the options you have for structuring
AD. See Figure 1-1.
Figure 1-1: The components of Active Directory structure.
Using domains, trees, and forests

Here, we talk about the major components that make up any
AD structure: domains, trees, and forests.
Domains
Active Directory domains are the primary containers within
Active Directory. Every instance of Active Directory must have
at least one domain within it. You can think of a domain as being
an administrative boundary, which means that each domain
has its own unique set of administrators. Domains are also
hosted on their own unique set of servers (known as domain
controllers). We talk more about containers in just a bit.
Trees
Trees are a hierarchical way to group domains that you create
by adding one or more child domains to an existing parent
domain. The domains share a hierarchical naming structure

with the child domain name appended to the parent name in
the fully qualified domain name.
Forests
A forest is a collection of one or more Active Directory trees,
organized as peers and connected by two-way, transitive trust
relationships. All domains in the Active Directory forest share
a common schema and configuration partitions, which form a
contiguous namespace. The first domain in the forest is called
the root domain. Forests also share a common quick-search
database known as the Global Catalog. The Global Catalog has
a copy of each object within every domain in the forest and is
optimized for quick searches.
Looking at containers and

organizational units
The last part of AD structures we cover is found within each
domain. There are two types of structure components to look at.
Containers
Containers are objects that contain other objects. Every
domain comes with a default set of built-in containers that
exist in every Active Directory domain.
Built-in: Holds a number of default groups that each

✓
domain comes with.
Computers: Contains computer accounts, which represent
✓
Windows computers that are members of this domain.
Domain controllers: Lists domain controllers hosting
✓
this domain.
Foreign security principles: Shows trust relationships
✓
with other domains.
Users: Lists Windows users.
✓
Organizational units
An organizational unit (OU) is similar to a container except that
OUs are created by the administrator as opposed to contain-
ers that come with a domain by default. An OU is a container
Chapter 1: Introduction to Active Directory 9
that is used to organize objects within a domain into logical
administrative groupings.
As an administrator, you may create an OU structure to reflect

your company’s organization. For example, you can create an
OU structure for each of the departments in your company,
such as Accounts, Network Operations, Customer Support,
and similar.
OUs can contain other OUs. This is known as nesting OUs. When
designing Active Directory, Microsoft recommends as few
domains as possible in AD by using nested OUs to produce
structure and improve the implementation of policies and
administration. The OU is the common level at which to apply
group policies. Group policies are AD objects themselves
called Group Policy Objects (GPOs), although policies can also
be applied to domains or sites. The OU is the level at which
administrative powers are commonly delegated, but granular
delegation can be performed on individual objects or attributes
as well.
Defining Trusts
Trusts are the last major component of Active Directory.
Trusts define relationships between domains.
Transitive trusts
Transitivity determines whether a trust can be extended out-
side of the two domains with which it was formed. You can
use a transitive trust to extend trust relationships with other
domains.
Each time you create a new domain in a forest, a two-way,

transitive trust relationship is automatically created between
the new domain and its parent domain. If child domains
are added to the new domain, the trust path flows upward
through the domain hierarchy, extending the initial trust path
created between the new domain and its parent domain.
Transitive trust relationships flow upward through a domain

tree as it is formed, creating transitive trusts between all
domains in the domain tree.
Authentication requests follow these trust paths so that

accounts from other domains in the forest can be authenti-
cated. With a single logon process, accounts with the proper
permissions can access resources in all domains in the Active
Directory forest.
Shortcut trusts and forest trusts are two types of transitive

trusts.
Shortcut trust
A shortcut trust is between a child domain in the same
domain tree or forest and is used to shorten the trust path in
a large and complex domain tree or forest structure.
Forest trust
A transitive one-way or two-way trust is established between
two root domains that belong in two separate forests. You use
a forest trust to share resources between forests. If a forest
trust is a two-way trust, then authentication requests made in
either forest can reach the other forest, as well.
Non-transitive trusts
A non-transitive trust is restricted by the two domains in the
trust relationship and does not flow to any other domains in
the forest. A non-transitive trust can be either a one-way or a
two-way trust.
Non-transitive trusts are one-way by default, although you can

also create a two-way relationship by creating two one-way
trusts.

Chapter 2
Active Directory Groups

and Security
In This Chapter
▶ Defining what an Active Directory group is
▶ Exploring everything about Active Directory groups
▶ Understanding how Active Directory security works
T his chapter introduces the concept of what an Active

Directory group is and how it relates to security within a
Windows Server environment. The chapter also delves into
the difficulties of managing groups along with some solutions
for doing so.
Defining Active Directory Groups

Within Active Directory, a group is a method for collecting
users, contacts, computers, and even other groups’ objects
(see Chapter 1) so that you can manage the objects in the
group as a single unit. Objects that belong to a particular
group are referred to as group members.
Using groups can simplify administration by assigning a set of

permissions to a group once, rather than assigning permissions
and rights to each group member individually.
While groups can be either directory based or local to a par-

ticular computer, the focus of this book is Active Directory
groups. Groups in Active Directory are directory objects that
reside within a container or organizational unit inside of a
domain. Active Directory provides a set of default groups
upon installation and also gives you the option to create groups.
You can nest Active Directory groups, which means that

you can add a group as a member of another group. Nesting
groups allows you to grant common sets of permissions to
multiple groups. So, say that you have a Human Resources
group and a Finance group and you want to give them access
to a file share. While you could certainly give the HR and
Finance groups access to the file share directly, you can sim-
plify this effort by creating a group called FileShare. Because
FileShare has file share access, you can then nest the HR and
Finance groups into the FileShare group. With this solution,
you only have to grant permissions to the file share once
rather than twice.
Exploring AD Group Types

Active Directory groups come in two types: distribution
groups and security groups. You use distribution groups to
create e-mail distribution lists and security groups to assign
permissions to shared resources.
Distribution groups
Distribution groups are designed to combine users together
so that you can send e-mails (via Microsoft Exchange Server)
collectively to a group rather than individually to each user
in the group. Distribution groups are designed to be used for
e-mail specifically and cannot be granted Windows permissions.
Objects in AD that can have permissions granted to them

are known as a security principal. For example, users are an
example of a security principal because a user can be granted
rights. Security groups, as discussed in the next section, are
also security principals. Distribution groups are not security
principals, however, because rights cannot be granted to a
distribution group. Why? Because the Active Directory schema
(see Chapter 1) does not give distribution groups this ability.
The terms “distribution groups” and “distribution lists” tend

to be used interchangeably, particularly if you work with
Microsoft Exchange Server administrators. Don’t let this trip
you up!
Chapter 2: Active Directory Groups and Security 13
Security groups
Used with care, security groups provide an efficient way to
assign access to resources on your network. Using security
groups, you can
Assign user rights. User rights are assigned to security

✓
groups to determine what members of that group can do
within the scope of a domain (or forest; see Chapter 1).
User rights are automatically assigned to built-in security
groups at the time Active Directory is installed to help
administrators define a person’s administrative role in
the domain.
For example, a user who is added to the built-in Backup
Operators group has the ability to back up or restore
files and directories located on each domain controller in
the domain. Therefore, by being a member of this group,
you inherit the user rights assigned to the group. You
should always use discretion when assigning delegated
rights because an untrained user who is assigned too
many rights to a security group can potentially cause
significant harm to your network.
Assign permissions to resources. Permissions are assigned
✓
to the security group for a shared resource. This is dif-
ferent from user rights because user rights apply across
an entire domain versus permissions that are directed to
a specific entity. Permissions determine who can access
the resource and the level of access, such as Full Control
or Read-only. Some permissions that are given domain
objects are automatically assigned to allow various levels
of access to built-in security groups, such as the Account
Operators group or the Domain Admins group.
Every object in AD and every Windows computer resource
has a Discretionary Access Control List (DACL) associated
with it. The DACL is the list of groups (and/or users)
that have some level of permission against the object
or resource. When assigning permissions to resources
(file shares, printers, and so on), administrators should
assign those permissions to a security group. Each
Active Directory account added to a group receives
the rights assigned to that group and the permissions
defined for that group.
So, why not put individual users into resource DACLs rather
than use security groups? The reason is manageability.
Imagine that you have ten users in the Human Resources

team that you need to grant resource permissions to. Rather
than add each user’s permission to the resource DACLs
separately, you can simply create an HR security group,
grant the group permission within each DACL, and be done
with it. Also, if an individual HR user changes their role (say
to Finance), now all you have to do is remove the user from
the HR group rather than edit each DACL individually.
Security groups can also be used as a distribution group in

Exchange. These are known as security-enabled distribution
groups.

Understanding Active
Directory Security
The Active Directory service plays several major roles in pro-
viding security. Among these roles is the efficient and effective
management of user logon authentication and user authoriza-
tion. In this section, we also take a look at other aspects of AD
security, including access tokens and access control lists.
Understanding group scope

Groups, whether security groups or but not universal groups. Can be
distribution groups, are defined by a a member of global groups of the
definition that identifies the scope to same domain, domain local groups,
which the group is applied in a domain or universal groups of any domain
or forest. There are three group scopes: in the forest or trusted domains.
universal, global, and domain local.
✓ Domain local: Can contain users,
✓ Universal: Can contain users and computers, global groups, and uni-
groups (global and universal) from versal groups from any domain in
any domain in the forest. Universal the forest and any trusted domain,
groups don’t care about trust and as well as domain local groups
can be a member of domain local from the same domain. Can be a
groups or other universal groups member of any domain local group
but not global groups. in the same domain.
✓ Global: Can contain users, comput-
ers, and groups from same domain
Chapter 2: Active Directory Groups and Security 15
User authentication
Active Directory user authentication confirms the identity of
any user trying to log on to a domain and lets users access
resources (such as data, applications, or printers) located
anywhere on the network. A key feature of AD’s user authen-
tication is its single-sign-on capability, which makes multiple
applications and services available to the user over the net-
work without the user having to provide credentials more
than once.
User authorization
Whereas user authentication is a process of identifying the
user, Active Directory user authorization is the process of
determining what that user can access as well as securing
resources from unauthorized access. After a user account has
received authentication, it can potentially access the object;
however, the type of access actually granted to the user is
determined by what rights are assigned to the user and which
access control permissions are attached to the objects the
user wishes to access.
Access tokens
Each time that a user logs on and successfully authenticates
to Active Directory, Windows creates an access token. This
token is used in the authorization process when the user
accesses a resource. The access token is a representation of
the user account and contains the following elements:
User SID. The security identifier (SID) represents the

✓
logged-on user. The SID is a numerical value that repre-
sents the user to the Windows security system.
Group SIDs. Like users, every security group has its own
✓
unique SID. The access token includes a list of the SIDs
representing the logged-on user’s group memberships.
User rights. Privileges (associated with each SID) are
✓
granted to the user or to groups to which the user belongs.
When the user tries to access an object, Windows compares

each SID in the user’s access token to entries in an object’s
DACL to determine whether the user has permission to access

the object and, if access is allowed, what type of access it
is. In some cases, user rights in the user’s access token may
override the permissions listed in the DACL and access may
be granted that way.
Access Control Lists (ACLs)

Although we cover Discretionary Access Control Lists (DACLs)
earlier in this chapter, we need to look at access control lists
in a bit more detail. Each Active Directory object (as well as
each file, registry key, and so on) actually has two associated
ACLs:
DACL: The Discretionary Access Control List is a list of

✓
user accounts, groups, and computers that are allowed
(or denied) access to the object.
SACL: The System Access Control List defines which
✓
events (such as file access) are audited for a user or
group.
Access Control Entry (ACE)

A DACL or SACL consists of a list of Access Control Entries
(ACEs) in which each entry lists the permissions granted or
denied to the users, groups, or computers listed in the DACL
or SACL. Each ACE contains either a user or group SID with an
associated permission, such as Read access or Write access.
When determining whether or not a user can access a resource,

Windows combines all of the ACEs on the object before
determining what level of access (if any) the user has to the
resource. For example, if you have Read access to an object
because you are a member of Group A and if you have Write
access because you are a member of Group B, you have both
Read and Write access to the object. However, if you are not a
member of Group A or B, you will not have access to the object.
Chapter 3
Managing Active
Directory Groups
In This Chapter
▶ Using the AD group management tools that Microsoft provides
▶ Managing groups using Imanami GroupID
▶ Providing a complete group life cycle management solution
M anaging Active Directory, specifically groups, can be

accomplished with a variety of different types of tools.
This chapter introduces you to a couple of the tools that
come with Active Directory as well as an attractive alternative
that is available from Imanami.
Using the Built-in Active

Directory Management Tools
This section takes a look at the tools that Microsoft provides
with Active Directory. Although these tools are very good,
they have some limitations, especially in the AD group man-
agement area.
Active Directory Users

and Computers
Active Directory Users and Computers (ADUC), as shown
in Figure 3-1, is a legacy Microsoft Management Console
(MMC) snap-in that has been a standard feature of Microsoft
Windows Server operating systems ever since Active
Directory was first released.
Figure 3-1: The Active Directory Users and Computers console.
With ADUC, administrators can create, delete, and update

groups within Active Directory. It is common for the IT help
desk to use this tool to accomplish the needs of managing
groups.
As the saying goes, “With great power comes great responsi-

bility.” This also is true when using a tool like ADUC. Because
the tool is very powerful, it should be used only by a trained
technical staff that is aware of the dangers of changes made in
the directory.
ADUC allows an administrator to create common AD objects,

such as containers/OUs, groups, users, computers, and con-
tacts along with the attributes associated with those objects.
Chapter 3: Managing Active Directory Groups 19
Follow these steps to create a group with ADUC. Note: You
must be a member of the Account Operators group, the
Domain Admins group, or the Enterprise Admins group in
Active Directory.
1. Click Start➪Programs➪Administrative Tools➪Active

Directory Users and Computers.
2. In Active Directory Users and Computers window,
expand <domain name>.com.
3. In the console tree, right-click the folder in which
you want to add a new group.
4. Click New, and then click Group.
5. Type the name of the new group.
Use a name that you can easily associate with the role
or service for which you are creating it.
The New Object – Group dialog box appears.
6. In Group scope, click Global scope.
7. In Group type, click Security.
8. Click Finish.
9. Repeat Steps 3 through 8 for all remaining groups.
Once the group is created, you can add and remove members
of the group. Members may be other AD objects such as
another group (nesting), computers, users, contacts, and so on.
Here are the steps for doing so.
1. Open Active Directory Users and Computers.

2. In the console tree, click the folder that contains the
group to which you want to add a member.
3. In the Details pane, right-click the group, and then
click Properties.
4. On the Members tab, click Add.
5. In Enter the Object Names to Select, type the name
of the user, group, or computer that you want to add
to the group, and then click OK.
An administrator needs to be aware that as employees change

roles within the organization, they should remove the employ-
ees from the distribution groups and security groups that
they no longer need to access. Failing to do this can create
a situation where users maintain membership in groups
that they no longer have a business need for and therefore
can access resources they no longer have a business need to
access.
Active Directory Administrative

Center
As with ADUC, Active Directory Administrative Center (ADAC)
is another Microsoft tool introduced with Windows Server
2008 R2 as a complementary tool to ADUC. In Windows Server
2012, this tool (see Figure 3-2) becomes the default tool with
IT-level delegation capabilities and is a graphical front end
to PowerShell commands. It is an excellent example of how
Microsoft drives the actual administration of AD through
PowerShell and when necessary, provides a GUI to drive
changes via those same PowerShell commands.
Figure 3-2: The Active Directory Administrator Center tool.
The implication with ADAC is that you can do any AD admin-
istrative task, including group management, through the
use of PowerShell. The real advantage of PowerShell is that
you can script administrative tasks that you execute repeti-
tively, which greatly eases the work of an AD administrator.
Unfortunately, PowerShell is such a huge topic that we don’t
have the space to cover it in this small book.
ADAC can be installed only on computers running Server 2008

R2 and is available with Windows Server 2008 R2 Standard,
Enterprise, and Datacenter Editions but not with the Itanium
and Web Server Editions.
ADAC is installed by default when you install the Active Directory

Domain Services (AD DS) server role on a Windows server. ADAC
is also included in the Remote Server Administration Tools
(RSAT) feature.
How ADAC differs from ADUC

ADAC offers administrators an alternative to ADUC. As with
ADUC, administrators can use ADAC to perform common AD
user, computer, group, and organizational unit (OU) object
management tasks.
The key difference is that ADAC is a very task-oriented admin-

istration tool that can help you manage AD in fewer steps. The
ADAC interface focuses on key AD administration tasks.
ADUC is, foremost, a data-oriented tool that shows you how

the data in AD is organized. ADAC supports this data-oriented
view of AD objects as well.
The classic hierarchical view of AD content is available from

ADAC’s tree view. The ADAC interface focuses on key adminis-
tration tasks. Two other important differences you will notice
in the interface are that ADAC is much more customizable,
and it lets you simultaneously connect to other domains; it
allows you to simultaneously connect to different domain con-
trollers (DCs) in different domains to manage objects across
multiple domains within the same ADAC instance.
The other big difference between ADUC and ADAC lies in

ADAC’s underlying architecture. ADAC is not MMC-based but
uses an Explorer-like interface instead. Under the hood, ADAC
leverages Windows PowerShell and the new Active Directory
Web Services (ADWS). ADWS is a new Windows service that
provides a web service interface to AD.
Managing Groups with

Imanami GroupID
Managing Active Directory group membership and user
attributes is a tedious job for administrators. Providing a self-
service option allows administrators to delegate active direc-
tory administration to end-users. Imanami’s GroupID enables
end-users to update their own directory information and
manage groups based on controls that the AD administrators
set. Group management is enhanced because users can create
and manage their own groups and opt in and out of groups
based on the security setting for that group. Group renewals
and expirations are administered and controlled within the
GroupID Self-Service console. See Figure 3-3.
Figure 3-3: The Imanami GroupID Self-Service console.
GroupID Self-Service is a web-based portal that gives an intui-
tive front end to Active Directory. Providing this tool through
a web interface eliminates the need to distribute the tool
to the user’s computer. Through this web portal, users and
administrators can update user attributes and create distri-
bution lists and security groups based on permissions and
workflow designed by IT. GroupID Self-Service also improves
on Active Directory in that it allows for multiple owners of
groups, workflow on any attribute changes, security settings
on view/edit with field-level security, customizable branding,
and differing security settings on groups.
The administrative interface allows IT to create multiple por-

tals, manage workflow and group life cycle, and easily brand
the self-service portal. Giving access and control of user data
to the users helps the organization become more nimble and
productive; having control of who can do what helps to keep
the organization more secure. The beauty of Imanami GroupID
Self-Service is that it gives you both of these abilities in a
single tool.
Providing a Complete Group

Life Cycle Solution
One of the issues of opening groups to users is the prolifera-
tion of groups, something we call group glut. If there are no
controls in place, too many groups are created or worse yet,
once-useful groups are left “cobwebbed” in Active Directory.
The solution to these issues is to provide a group life cycle
solution.
A group’s useful life has four stages:
Creation. You first must provide a predefined workflow

✓
process to ensure that the group is approved and/or
meets naming conventions.
Use. During a group’s useful life, you need to allow group
✓
owners to manage groups and to opt in and opt out users
to and from groups.
Expiration. A time frame for group renewals should be

✓
established and enforced so that the group owner has
to actively renew a group to continue to use it. Group
owner(s) are notified before the expiration, giving them
time to renew the group or let it expire.
Deletion. Once a group has expired and the owner has
✓
not renewed it, you can define a set period of days before
the group is actually deleted, giving the owner a chance
to “get it back.”
GroupID Self-Service gives IT a complete group life cycle solu-

tion, allowing users to manage their own groups but giving IT
the control to keep it from getting out of hand. This group life
cycle solution allows you to control group glut on both secu-
rity groups and distribution lists.
When you expire a security group, GroupID will back up the

membership and then remove all members, effectively dis-
abling the group until the group owner(s) renew it. When you
expire a distribution list, the group is disabled from being
used for e-mail so that messages sent to the group will bounce
to the sender of the e-mail. In both cases, the name of the
group is appended with an exp- prefix and hidden from the
ability to opt in or out. See Figure 3-4.
Figure 3-4: The GroupID group renewal/expiration process.
Chapter 4
Dynamic Groups
In This Chapter
▶ Finding out about dynamic group membership
▶ Using Smart Groups
▶ Managing Hierarchical groups using Dynasties
P reviously in this book, we have looked at AD groups

and the tools to manage them. The one problem with
these tools, however, is that group memberships are static.
In this chapter, we take a look at the idea of having member-
ships that can change dynamically along with some tools that
enable this functionality.
Understanding Dynamic
Group Membership
Active Directory groups are as dynamic as their members:
they need to change as users switch responsibilities, roles,
and locations. The problem is that distribution lists and secu-
rity groups are often manually maintained by the Exchange
or Active Directory administrator. Because this is a manual
process, keeping up with the number of changes to group
memberships is prone to human error and in most cases the
changes don’t get adequately documented.
Dynamic groups remove the traditional manual process of

assigning group membership. Dynamic group membership
helps solve these typical pain points:
As users move around in an organization, they are added

✓
to new security groups but are rarely taken out of exist-
ing ones. This dynamic results in users having access to
resources they no longer have a business need to access.

This scenario creates security risks with security group
membership as users increasingly become a potential
threat to the network should a user account become
compromised. Even with distribution groups in which
security isn’t a factor, users will continue to receive e-mail
messages that are not intended for them, so they become
a source of wasted productivity or, even worse, they
receive information that isn’t intended for them to see.
AD groups grow in number as the IT environment
✓
increases in size. Because of the lack of documentation,
groups are rarely deleted because of the unknown impact
that removing a group may have. Not removing unneeded
groups creates an environment of group glut (refer to
Chapter 3). In addition to this, users with too many group
memberships create a situation called token bloat, where
the user’s access token is needlessly large and therefore
negatively impacts user performance.
AD group management tools do not do a good job of
✓
managing membership in rapidly changing organizations.
Something had to be done to automate the process. We iden-

tify two ways that companies commonly address this problem.
PowerShell scripting
Scripting from within PowerShell is a powerful means to
achieve group membership control based on roles estab-
lished in AD user attributes. Expert knowledge of PowerShell
and the related AD commands is required to accomplish this
task. This process does become tedious if the number of
groups becomes substantial and the sophistication and com-
plexity of the group membership is wide. An understanding of
LDAP query language is also required to make the best use of
this form of scripting.
LDAP stands for Lightweight Directory Access Protocol. Most

directory services, including Active Directory, support this
protocol. Through LDAP you can read and write to Active
Directory.
If your organization is willing to manage sophisticated scripts

and dedicate engineering resources to maintain the ever chang-
ing needs of the business based on the development of these
Chapter 4: Dynamic Groups 29
scripts, this may be a good option for you. This type of solution
is typically used in the smallest of companies as the number of
scripts that are required become too numerous for more than a
few hundred employees. Most companies will turn to purpose-
built tools in order to offload the manual task of script writing
and management in order to achieve the quickest ROI for the
effort involved to accomplish intelligent group membership.
Here’s a look at a PowerShell script that will create a group

and add members to that group. First, we create the group.
The following script creates a group with a name based on a
PowerShell argument.
$groupName = $args[0]
$domainName = ([System.DirectoryServices.
ActiveDirectory.
Domain]::GetCurrentDomain()).Name
$domainName = $domainName -replace “\.”,
“,dc=”
$ou = [ADSI] “LDAP://cn=Users,dc=$domainName”
$group = $ou.Create(“group”, “cn=$groupName”)
$group.Put(“SamAccountName”, $groupName)
$group.Put(“groupType”, -2147483640)
$group.SetInfo()
After creating the group, we can then add members to the

group with the following script, where the first argument is
the name of the group and the second argument is the user-
name to be added to the group.
$groupName = $args[0]
$username = $args[1]
$group = Get-Group $groupName
$user = get-user $username
$userdn = $user.distinguishedName
$newgroupmembers = $group.members | Where-
Object { $_.name -eq “$username” }
$groupdn = $group.distinguishedName
$fqgroup = [adsi]”LDAP://$groupdn”
$fqgroup.Member.Add($userdn)
$fqgroup.setInfo()
Query-Based Distribution List

As with the scripts based on PowerShell, Query-Based
Distribution List (QBDL) may be used to create a simple dynamic
distribution group whose group membership is based on user
objects that share a common value for a particular attribute.

This is accomplished by leveraging features included in
Microsoft Exchange Server 2010 along with Active Directory.
Figure 4-1 shows the Conditions panel from the properties

of a simple QBDL designed group. In this example, the QBDL
contains all users that have their Department attribute set to
either Marketing or Engineering.
Figure 4-1: The Conditions settings of a Query-Based Distribution List.
The default precanned filters available to the GUI tools for

creating a QBDL are quite limited. If you wish to extend a
QBDL to leverage additional attributes, you must include
them in a custom filter via PowerShell.
New-DynamicDistributionGroup -Name
“California Engineering” -RecipientFilter
{(RecipientType -eq ‘UserMailbox’) -and
(Title -like ‘Director*’ -or Title -like
‘Manager*’) -and (StateOrProvince -eq
‘CA’) -and (StateOrProvince -eq ‘CA’) –and
(manager –like ‘CN=Amy Henderson,OU=Operat
ions,OU=Democorp,DC=gidemo,DC=local’) –and
(userAccountControl:1.2.840.113556.1.4.803:
-eg ‘65536’) –or (employeeType –like ‘INTERN’
–or employeeType –like ‘EMPLOYEE’)}
When using a QBDL, you have to be careful because you can
get into trouble with it. Unlike static address lists, the query-
based DL is resolved each time it is used with an actual LDAP
query against Active Directory; specifically, it requires access
to a Global Catalog server. This means that the query needs to
be efficient. Used enough, a poorly designed query for the DL
could severely impact Exchange and Active Directory perfor-
mance. You will want to use indexed attributes and avoid bit-
wise operators, the NOT operator, and medial search strings.
As an alternative to a QBDL that allows for the benefit of
endless complexity and that of enumeration of a static group,
consider instead the best practice of using a Smart Group (see
the following section, “Using Smart Groups”).
There are some drawbacks to this method of group manage-

ment that you should be aware of:
Groups created in this manner are distribution groups

✓
only and can only be used with Exchange Server. If using
an older version of Exchange Server (2007 or earlier), this
option isn’t available. You also cannot use this method of
DL for non-Exchange environments such as Google Apps.
Membership is based only on AD attributes. For example,
✓
you cannot use external data such as a SQL, Oracle, or
any other database type.
Each time a message in Exchange Server uses this list, a
✓
domain controller is triggered to enumerate membership
of the QBDL, taxing the domain controller and potentially
affecting performance of other authentications.
The membership cannot be expanded by users to verify
✓
the details of the group membership from client software.
There is no possibility of creating security groups using
✓
this method. This implementation is limited to distribu-
tion groups only.
You cannot leverage mail-enabled security groups, which
✓
is a common implementation of groups for many orga-
nizations. If you have security group needs that mirror
your distribution group needs, you will need to imple-
ment the same query logic in a QBDL as well as leverag-
ing external scripts.
A QBDL requires that the available filtering options are

available. A basic set of options is available out of the box.
Extending the basic set of options, however, requires the

availability of additional LDAP-based filtering, which is likely
to be an overly difficult implementation for most administrators.
Using Smart Groups

Rather than take the PowerShell or QBDL routes to manag-
ing group memberships, a better solution exists using Smart
Groups. Smart Groups are implemented using purpose-
built group management tools such as Imanami’s GroupID
Automate. Leveraging similar AD attribute logic found in both
PowerShell scripting and QBDL style language in addition to
other accessible data, this type of tool lifts away the complex-
ity of script writing and allows an IT administrator to quickly
implement security and/or distribution groups with high
levels of sophistication from a wizard-driven GUI interface.
Smart Groups can be used to easily create
Shadow groups. These are groups whose membership

✓
reflects the member of another AD object. For example, if
you wanted a distribution or security group membership
to exactly reflect the users included in a specific OU, you
could create a shadow group to accomplish this.
AD attribute or DB value-based group. These are Smart
✓
Groups whose membership is based on AD attributes and/
or database (such as SQL Server) values. For example, you
could define a Smart Group whose membership includes
all user objects in AD that have the same department attri-
bute value. Similarly, you could create a Smart Group in
which the membership is defined through querying a SQL
database to look for certain values. See Figure 4-2.
Active Directory groups are as dynamic as their members and

need to change their membership as users switch respon-
sibilities, roles, and locations. The problem is that distribu-
tion lists and security groups are often manually maintained
by the Exchange Server or Active Directory administrator.
GroupID Automate puts an end to this chain of manual pro-
cesses by automating the creation and management of these
groups and their memberships.
Figure 4-2: Basing Smart Group memberships on AD attributes or

database values.
When user information changes, GroupID Automate automati-

cally updates the appropriate distribution lists and security
groups. Your AD groups will never be out of date again. Your
AD groups become Smart Groups. Smart Groups are designed
to be viewed as static within AD with regular updates scheduled
in such a way by the administrator that group updates minimize
impact on your domain controllers.
Why do IT and help-desk organizations need to make changes in

group memberships? As users’ roles at the company change —
by changing locations, departments, and so on, the resources
they need access to and the information they need to receive
in the form of distribution group inclusion changes. In today’s
world, the access to certain network resources should change
when a person’s job changes. The problem is that most com-
panies don’t handle those changes in an efficient manner.
This leads to group glut, token bloat, and accidental elevation
of permissions over time.
Use Active Directory’s group

structure to your benefit
ACME Corporation has a new product these groups in or out without
coming to market next year. The mar- IT involvement, and even so, IT
keting team in San Francisco is going is burdened with hand-crafting
to head up the task of launching the exceptions to their scripts. At the
product. They have asked IT to create end of the project, these groups
a security group so that they can each may stay around because people
share files on a file server. They also forget about them, staff changes,
want to leverage the AD group to and so on.
control access to sensitive informa-
✓ Option 2: IT staff uses purpose-
tion in Microsoft SharePoint Server.
built tools like Imanami’s GroupID
For internal and external communica-
Automate to create the groups
tions, the manager seeks a few distri-
based on the business case logic,
bution groups based on this project.
leveraging AD attributes and, if
The IT department could accomplish
necessary, external database
the goals of this project by doing one
sources. IT staff then delegates
of two possibilities.
further group management to
✓ Option 1: IT staff uses PowerShell the group owner who can create
scripts to create security groups exceptions to the role-based
based on attributes in AD. They group membership with a work-
leverage location, department, flow triggered to those who need
and job title to determine mem- oversight on changes to the
bership. They cannot, however, group. Changes are automati-
leverage database values unless cally logged into a database for
they add additional complexity compliance. The group is set to
to the script. For a distribution expire after 120 days but may be
group, they repeat the process renewed by the group owner. If
again in scripts or build a QBDL in the group is no longer needed, the
Exchange with similar sets of cri- group expires, becoming unus-
teria. The manager of the project able and eventually is deleted.
has no way of opting users from
GroupID Automate solves a real problem for today’s business.

Employees depend on distribution lists and security groups
to do their jobs every day. If distribution groups aren’t accu-
rate, e-mails go out to the wrong employees and are eventu-
ally abandoned. If security groups aren’t accurate, employees
either don’t have access to the systems and resources they
need or worse yet, they do have access to the systems and
resources that they are not supposed to have.
Groups are generally managed one of three ways: negligently,
IT-centric, or user-centric. This means that these people or
departments that are tasked with group management either
don’t manage groups, have a highly paid administrator
manually manage groups, or have end-users manage groups.
All of these solutions have a cost that far outweighs creat-
ing dynamic groups. By automating these Active Directory
groups, you can
Ensure that they will always be accurate.

✓
Increase productivity by giving employees access to the
✓
right systems and information immediately upon hiring
or promotion.
Increase security by granting access to only the systems
✓
you want and denying access immediately upon any
change in status.
Managing Hierarchical
Groups with Dynasties
Smart Groups are a great way of managing the membership
of an individual group in a dynamic fashion. But what if you
wanted to create a series of separate groups whose member-
ships are defined on some common criteria (for example,
manager, department, location, and so on) and that criteria
has some sort of hierarchy related to it? That is where dynas-
ties come in handy.
Issues with managing

hierarchical groups
Imagine that you want to create location-based groups for
every country, state, city, and office location value that you
have defined in Active Directory. If you were to do this with
manually created groups, you would have a country-based
group that contains a list of nested state-based groups. Then,
each state-based group would contain a number of nested
city-based groups. Then lastly, each city-based group would
contain a number of nested office-location groups.
Nesting groups does come with risks when done manually.

In many cases, membership in group nesting can lead to a
condition in which tokens carried by an identity can cause per-
formance issues. Along with performance issues, you also can
have cracks in your security when membership in a group is
inherited. These often unforeseen problems come as a result of
group nesting with inherited security. In most cases, the mem-
bership in these groups comes as a result of a transient need to
allow users to access resources. Also, membership in a group
is needed only for a specific period of time or for only a small
subset of people who have a specific purpose. Those needs
change, and as a result, the membership should change with it.
Those responsible for managing directory services are slow

to make changes, even small changes, for fear of breaking a
critical business process. This becomes an even more complex
matter of discovery when group membership and the existence
of a group itself are buried within another group for which
there may be no documentation or stated purpose. Removal
is almost always certain to cause some pain for a percentage
of these nested groups, however. Nesting of groups is also for
many a hidden security risk or performance obstacle.
Nested groups do serve an important role when delegating

access. Architecturally, the hierarchal nature of a nested
group makes sense. It certainly solves the problem where
groups of directory objects (people, typically) have a shared
need for specific access. Within those groups of people, it is
easy to define sub-roles through other groups that gain access
through inheritance. What happens over time, however, is
that the clean layout of your nested groups quickly becomes
messy because your business needs change and certainly, the
people change in job function/role and the people themselves
change. The more complex your needs, the more challenging
it can be to manage those scenarios. Having to troubleshoot
these groups is a very reactive approach.
Imanami Group Dynasties

to the rescue
Imanami has a more proactive method of building nested
groups. With some added intelligence based on your business
needs, you can build groups based on the dynamic changes in
your organization. The fluidity and nimbleness of your organiza-
tion will not be hamstrung by your corporate directory services.
Imanami’s GroupID Automate does this through the concept
of Dynasties. A Dynasty is based on the nesting or grouping of
groups dependent on the hierarchal nature of your business.
This could be a top-down look from a departmental point of
view, managerial point of view, physical location point of view,
or any other method of hierarchy that makes sense to you. It is
certainly an excellent way to resolve the accidental hijacking of
a security group or distribution list. Membership of a group is
based on rules you set forth. The nesting of one group within
another is further defined by the hierarchal grouping as defined
by business need. As your organization changes, your nested
groups and their membership dynamically change to match.
Here’s a look at the steps involved with creating a dynasty in

GroupID.
1. Define the container, group name, and type of

Dynasty you want to create. In our example, shown in
Figure 4-3, we’ve created a distribution list.
Figure 4-3: Step 1. Defining the Dynasty name, container, and type of group.
2. Define a predefined template or customize group-

ing values that define the type of hierarchy that
the Dynasty is to follow. In our example, we use a
predefined template based on geography. See
Figure 4-4.
Figure 4-4: Step 2. Selecting the Dynasty hierarchy template to be used.
3. Confirm the template defaults for AD attributes to

nest the groups. We can further customize these to
include other geographical details such as building
number, floor, and so on (see Figure 4-5).
Figure 4-5: Step 3. Selecting the attributes to build the hierarchy on.
4. Leverage the query designer to include or exclude

user objects from query. In our example, we probably
do not need to do this as we are creating an all-
inclusive list. Check out Figure 4-6.
Figure 4-6: Step 4. Using the Query Designer.
5. Set up scheduling parameters for automatic updates

or execute now and schedule updates later. See
Figure 4-7.
Figure 4-7: Step 5. Setting up the Scheduling Parameters.
And with that, the process is finished!
Chapter 5
Ten Group Management

Best Practices
In This Chapter
▶ Getting acquainted with Active Directory best practices
T hird-party tools are available to help IT keep the business

users happy by properly managing Active Directory groups.
Imanami’s GroupID is a great example of one of those tools.
Since Imanami is an expert in Active Directory group manage-
ment, it makes sense to share some of their best practices,
which is what this chapter is about.
Create Dynamic AD
Security Groups
Create dynamic AD security groups whenever possible. Any
group membership that you can define by a query against
either Active Directory or any other data source should be a
dynamic group. This eliminates the business user’s complaint
that a group isn’t up-to-date.
Empower End-Users
Empower end-users to manage their own groups through an
Active Directory self-service tool like Imanami’s GroupID.
Seriously, who knows who should have access to the group
more than the business owner who requested it?
Join AD Groups
Allow end-users to request membership in AD groups (which
is another feature of Imanami’s GroupID tool). Note: This isn’t
easy to do on your own without GroupID because you have to
have the correct workflows in place or things can get out of
control.
Include Restrictions
Restrict nested groups when offering self-service creation of
groups. Want to get your permissions into a big mess? Allow
nested groups without some sort of IT oversight.
Require Group Descriptions

Always. Without them, nobody will ever be able to decipher
what SG-OntBkClb means.
Set Group Expiration Dates

When a user needs only temporary access to a group, set the
access to automatically expire after a fixed period of time. Allow
the group owner to renew membership before the expiration
date for groups that are needed for a longer period of time.
Use Hierarchies to Build

Distribution Lists
Build your distribution lists on a hierarchy using child-parent
dynasty relationships. Do the same with logical and physical
organized nested security groups.
Chapter 5: Ten Group Management Best Practices 43
Ensure Accuracy
Ensure accuracy of your Active Directory Users and Contact
attributes by synchronizing important information from a
source you trust, such as an HR database.
Enable Temporary Membership

Using a tool such as Imanami’s GroupID Self-Service allows
you to add users to a group on a temporary basis with a fixed
date of expiration. This enables you to address a transient
need to include a user in a group in a way that isn’t perma-
nent. Temporary memberships automatically remove users
from the group at the end of their prescribed periods.
Stay Group Healthy

Imanami GroupID includes sophisticated HealthMeters, which
among other AD health checks also look at the number of
groups that do not have any descriptions. See Figure 5-1.
Figure 5-1: A health report from Imanami GroupID.
Imanami GroupID HealthMeters also report the ratio of groups

to users. If your ratio is unhealthy, group expiration will be of
great benefit. See Figure 5-2.
Figure 5-2: Set group expiration dates.

AD Group Management

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AD Group Management

Transféré par

Droits d'auteur :

Formats disponibles

These materials are the copyright of John Wiley & Sons, Inc.

and any dissemination, distribution, or unauthorized use is strictly prohibited.

IMANAMI SPECIAL EDITION

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE

Chapter 1: Introduction to Active Directory. . . . . . . . . . . 5

Chapter 2: Active Directory Groups and Security. . . . . 11

Chapter 3: Managing Active Directory Groups . . . . . . . 17

Chapter 4: Dynamic Groups. . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 5: Ten Group Management Best Practices . . . 41

Acquisitions, Editorial, and Composition Services

Publishing and Editorial for Technology Dummies

Although Microsoft provides tools and methods for managing

About This Book

How This Book Is Organized

Chapter 2: Active Directory

Chapter 3: Managing Active

Chapter 4: Dynamic Groups

Chapter 5: Ten Group

Icons Used in This Book

This icon points to some information that you should really

This icon appears when we want to caution you about a par-

Where to Go from Here

Regardless of where you start or how often you come back to

B efore we can talk about managing groups in Active

Active Directory’s other primary function is to provide a service

can vary from a small installation with a few hundred objects

Each object represents a single entity — a user, a contact,

The Active Directory schema defines the list of objects that

Getting to Know the

Figure 1-1: The components of Active Directory structure.

Using domains, trees, and forests

domain. The domains share a hierarchical naming structure

Looking at containers and

Built-in: Holds a number of default groups that each

As an administrator, you may create an OU structure to reflect

Each time you create a new domain in a forest, a two-way,

Transitive trust relationships flow upward through a domain

Authentication requests follow these trust paths so that

Shortcut trusts and forest trusts are two types of transitive

Non-transitive trusts are one-way by default, although you can

Active Directory Groups

T his chapter introduces the concept of what an Active

Defining Active Directory Groups

Using groups can simplify administration by assigning a set of

While groups can be either directory based or local to a par-

You can nest Active Directory groups, which means that

Exploring AD Group Types

Objects in AD that can have permissions granted to them

The terms “distribution groups” and “distribution lists” tend

Assign user rights. User rights are assigned to security

Imagine that you have ten users in the Human Resources

Security groups can also be used as a distribution group in

Understanding group scope

User SID. The security identifier (SID) represents the

When the user tries to access an object, Windows compares

DACL to determine whether the user has permission to access

Access Control Lists (ACLs)

DACL: The Discretionary Access Control List is a list of

Access Control Entry (ACE)

When determining whether or not a user can access a resource,

M anaging Active Directory, specifically groups, can be

Using the Built-in Active

Active Directory Users

Figure 3-1: The Active Directory Users and Computers console.