Windows Server 2008 R2 Unleashed (43 page)

Defining Organizational Units in AD DS

An organizational unit is an administrative-level container, depicted in Figure 6.1, that is

used to logically organize objects in AD DS. The concept of the organizational unit is

derived from the Lightweight Directory Access Protocol (LDAP) standard upon which AD DS

was built, although there are some conceptual differences between pure LDAP and AD DS.

Organizational Units

Los Angeles

Chicago

New York

FIGURE 6.1

Examining AD DS organizational unit structure.

ptg

Objects within Active Directory can be logically placed into OUs as defined by the admin-

istrator. Although all user objects are placed in the Users container by default and

computer objects are placed in the Computers container, they can be moved at any time.

NOTE

The default Users and Computers folders in AD DS are not technically organizational

units. Rather, they are technically defined as Container class objects. It is important

to understand this point because these Container class objects do not behave in the

same way as organizational units. To be able to properly utilize services such as

Group Policies, which depend on the functionality of OUs, it is recommended that you

move your user and computer objects from their default container locations into an

OU structure.

Each object in the AD DS structure can be referenced via LDAP queries that point to its

specific location in the OU structure. You will often see objects referenced in this format

when you’re writing scripts to modify or create users in AD DS or simply running LDAP

queries against AD DS. For example, in Figure 6.2, a user named Paul Cochrane in the SF

sub-OU of the Locations OU would be represented by the following LDAP string:

CN=Paul Cochrane,OU=SF,OU=Locations,DC=companyabc,DC=com

Defining Organizational Units in AD DS

177

companyabc.com

Locations

Paul

Cochrane

Syndey

London

SF

FIGURE 6.2

Viewing the LDAP structure of a user object in AD.

NOTE

The OU structure can be nested, or include sub-OUs that are many layers deep. Keep

ptg

in mind, however, that the more complex the OU structure, the more difficult it becomes

to administer and the more time consuming directory queries become. Microsoft rec-

6

ommends not nesting more than 10 layers deep. However, it would be wise to keep the

complexity significantly shorter than that number to maintain the responsiveness of

directory queries.

OUs primarily satisfy the need to delegate administration to separate groups of administra-

tors. Although there are other possibilities for the use of OUs, this type of administration

delegation is, in reality, the primary factor that exists for the creation of OUs in an AD

environment. See the “Starting an OU Design” section of this chapter for more details on

this concept.

THE NEED FOR ORGANIZATIONAL UNITS

Although there is a tendency to use organizational units to structure the design of AD

DS, OUs should not be created to just document the organizational chart of the

company. The fact that the organization has a Sales department, a Manufacturing

department, and a Marketing department doesn’t suggest that there should be these

three AD DS OUs. An administrator should create OUs if the departments will be

administered separately and/or policies will be applied differently to the various depart-

ments. However, if the departments will all be administered by the same IT team, and

the policies being applied will also be the same, having multiple OUs is not necessary.

Additionally, OUs are not exposed to the directory, meaning that if a user wants to send

an email to the members of an OU, he would not see the OU structure nor the

members in the OU grouping.

178

CHAPTER 6

Designing Organizational Unit and Group Structure

To see members of an organizational structure, AD DS groups should be created.

Groups are exposed to the directory and will be seen when a user wants to list mem-

bers and groups in the organization.

Defining AD Groups

The idea of groups has been around in the Microsoft world for much longer than OUs

have been. As with the OU concept, groups serve to logically organize users into an easily

identifiable structure. However, there are some major differences in the way that groups

function as opposed to OUs. Among these differences are the following:

.
Group membership is viewable by users—
Whereas OU visibility is restricted to

administrators using special administrative tools, groups can be viewed by all users

engaged in domain activities. For example, users who are setting security on a local

share can apply permissions to security groups that have been set up on the domain

level.

.
Membership in multiple groups—
OUs are similar to a file system’s folder struc-

ture. In other words, a file can reside in only one folder or OU at a time. Group

membership, however, is not exclusive. A user can become a member of any one of a

ptg

number of groups, and her membership in that group can be changed at any time.

.
Groups as security principles—
Each security group in AD DS has a unique secu-

rity identifier (SID) associated with it upon creation. OUs do not have associated

access control entries (ACEs) and consequently cannot be applied to object-level

security. This is one of the most significant differences because security groups allow

users to grant or deny security access to resources based on group membership.

Note, however, that the exception to this is distribution groups, which are not used

for security.

.
Mail-enabled group functionality—
Through distribution groups and (with the

latest version of Microsoft Exchange) mail-enabled security groups, users can send a

single email to a group and have that email distributed to all the members of that

group. The groups themselves become distribution lists, while at the same time

being available for security-based applications. This concept is elaborated further in

the “Designing Distribution Groups” section later in this chapter.

Outlining Group Types: Security or Distribution

Groups in Windows Server 2008 R2 come in two flavors: security and distribution. In

addition, groups can be organized into different scopes: machine local, domain local,

global, and universal.

Security Groups

The type of group that administrators are most familiar with is the security group. This

type of group is used to apply permissions to resources en masse so that large groups of

users can be administered more easily. Security groups can be established for each depart-

Defining AD Groups

179

ment in an organization. For example, users in the Marketing department can be given

membership in a Marketing security group, as shown in Figure 6.3. This group is then

allowed to have permissions on specific directories in the environment.

ptg

6

FIGURE 6.3

Examining security group permission sharing.

As previously mentioned, security groups have a unique security identifier (SID) associated

with them, much in the same way that individual users in AD DS have an SID. The

uniqueness of the SID is utilized to apply security to objects and resources in the domain.

This concept also explains why you cannot simply delete and rename a group to have the

same permissions that the old group previously maintained.

Distribution Groups

The concept of distribution groups in Windows Server 2008 R2 was introduced in

Windows 2000 Server along with its implementation of Active Directory. Essentially, a

distribution group is a group whose members are able to receive Simple Mail Transfer

Protocol (SMTP) mail messages that are sent to the group. Any application that can use

AD DS for address book lookups (essentially LDAP lookups) can utilize this functionality

in Windows Server 2008 R2.

Distribution groups are often confused with mail-enabled groups, a concept in environ-

ments with Exchange 2000/2003/2007/2010. In addition, in most cases distribution

groups are not utilized in environments without Exchange Server because their functional-

ity is limited to infrastructures that can support them.

180

CHAPTER 6

Designing Organizational Unit and Group Structure

NOTE

In environments with Exchange Server, distribution groups can be used to create email

distribution lists that cannot be used to apply security. However, if separation of securi-

ty and email functionality is not required, you can make security groups mail-enabled.

Mail-Enabled Groups

AD DS includes a concept called mail-enabled groups. These groups are essentially security

groups that are referenced by an email address, and can be used to send SMTP messages to

the members of the group. This type of group is primarily used with Exchange Server, but

can also be used with foreign mail systems integrated with AD DS.

Most organizations will find that mail-enabled security groups satisfy most of their needs,

both security-wise and email-wise. For example, a single group called Marketing that

contains all users in that department could also be mail-enabled to allow Exchange users

to send emails to everyone in the department.

Understanding Group Scope

There are four primary scopes of groups in AD DS. Each scope is used for different

purposes, but they simply serve to ease administration and provide a way to view or

ptg

perform functions on large groups of users at a time. The group scopes are as follows:

. Machine local groups

. Domain local groups

. Global groups

. Universal groups

Group scope can become one of the most confusing aspects of AD DS. However, if

certain design criteria are applied to group membership and creation, the concept

becomes more palatable.

Machine Local Groups

Machine local groups are essentially groups that are built in to the operating system and

can be applied only to objects local to the machine in which they exist. In other words,

they are the default local groups such as Power Users, Administrators, and the like created

on a stand-alone system. Before networking simplified administration, local groups were

used to control access to the resources on a server. The downside to this approach was that

users needed to have a separate user account on each machine that they wanted to access.

In a domain environment, using these groups for permissions is not recommended

because the administrative overhead would be overwhelming.

Domain Local Groups

Domain local groups, a term that might seem contradictory at first, are domain-level

groups that can be used to establish permissions on resources in the domain in which

they reside. Essentially, domain local groups are the evolution of the old Windows NT

local groups.

Defining AD Groups

181

Domain local groups can contain members from anywhere in an AD DS forest or any

trusted domain outside the forest. A domain local group can contain members from any

of the following:

. Global groups

. User accounts

. Universal groups

. Other domain local groups

Domain local groups are primarily used for access to resources because different domain

local groups are created for each resource and then other accounts and/or groups are added

to them. This helps to readily determine which users and groups have access to a resource.

Global Groups

Global groups are the reincarnation of the legacy Windows NT global group, but with

slightly different characteristics. These groups can contain the following types of objects:

. User accounts

. Global groups from their own domain

ptg

Global groups are primarily useful in sorting users into easily identifiable groupings and

6

using them to apply permissions to resources. What separates global groups from universal

groups, however, is that global groups stop their membership replication at the domain

boundary, limiting replication outside the domain.

Universal Groups

The concept of universal groups was new with the release of Windows 2000 and is still