Active Directory does add some layers of complexities
because of the nature of how applications and other functions of the
directory are handled. In this section, you will see some added
complexity regarding groups and the amount of properties users have by
default in a domain environment.
1. Learn Active Directory Users and Groups Terminology
When you create users in AD,
they are very similar to local users, except for the extended properties
and the ability to log on from any workstation in your infrastructure.
However, AD groups have
some additional capabilities and complexity. Understanding how the
groups work is key to working with permissions, rights, and even
applications in your environment. Creating groups in your AD environment
requires you to understand the basic terms and concepts. Before you
begin working with groups, you want to make sure you understand the
differences in the group types and group scopes listed in Table 1 and Table 2.
Table 1. AD Group Scopes
Group Type | Definition and Usage |
---|
Domain local | Domain
local groups can be assigned permissions only to resources in the
domain in which the group was created. Members in this group can be
global groups, universal groups, other domain local groups from the same
domain, and local user accounts. These groups are primarily used to
control access to resources in their local domain. |
Global | Global
groups are used to control access to resources in the domain in which
they are created, and they cannot travel outside the domain in which
they exist. It is preferred to use global groups over other groups
because they generate less replication traffic when you have groups with
frequent changes. Members of this group can be other groups and user
accounts located in the same domain in which the global group was
created. This group is also the default group selection when creating a
new group. |
Universal | Universal
groups are groups that can travel across domain and forest boundaries
and are used to assign members of the group access to resources outside
of their forest. Members of this group can be any other accounts and
groups from other domains or forests with the proper trusts. You want to
avoid making frequent changes to the membership to this group, because
each change will cause replication on the entire membership to all the
global catalog servers in the forest. You can avoid replication traffic
by nesting global groups in this group. |
Table 2. AD Group Types
Group Type | Definition and Usage |
---|
Security | Security
groups are used to assign permissions or user rights in order to
quickly grant the members of the group access to resources or abilities
in your network. These groups can also be used for email distribution,
much like the distribution group mentioned next. |
Distribution | Distribution
groups are used only for your email applications, like Exchange Server
or Lotus Notes. These groups are not security enabled and cannot be
assigned access to resources. |
1.1. Organize Your Users and Groups
As you begin to create your
users, groups, and computer accounts in AD, you are going to want to
organize your AD environment into logical containers. In AD, these
logical containers are called organizational units
(OUs). OUs are the way you can easily organize the various users,
groups, computer accounts, and so on, in your AD infrastructure. You
create OUs to provide a logical structure, and you can design them in a
variety of ways. You can create an OU structure following the business
functions of your business. For example, you could create OUs for
marketing, sales, finance, and so on. This is probably the most common
OU design structure. Another popular method is geographic; for example,
you create OUs where businesses reside, such as North America, Asia,
Europe, and so on. Additionally, you can nest OUs inside of each other
to logically represent your business. This logical design helps you
organize your AD environment, delegate administration, and provide a key
part to working with your Group Policy design.
1.2. Computer Accounts
Before you begin to learn
how to work effectively with AD groups and users, you need to understand
computer accounts. Computer accounts are the objects that represent the
client computers and servers in your domain. If a server or client
desktop does not have a computer account, the system will not be able to
be managed by the domain, and users will not be able to log on to the
domain from the system. Having computer accounts in your domain allows
additional auditing capability and network authentication services. You
manage, delete, reset, add, and do other administrative tasks for
computers similar to users. As you work with users and groups, you will
see computer accounts in your Active Directory structure.
2. Join an Active Directory Domain as a Member
Before your users can log on
and work in your AD domain, you need to join them to your domain. Each
server or client system in your domain requires a computer account in
your domain. To join a domain, all you need to do is configure the
system:
Right-click Computer, and select Properties.
Under Computer Name, Domain, And Workgroup Settings, click Change Settings.
In System Properties on the General tab, click Change.
Select the radio button for Domain, type in your domain name, and click OK.
Type in your administrative account ID and password.
In the Welcome To Domain box, click OK.
Click OK to acknowledge the reboot is required.
Click OK to exit System Properties, and click OK to reboot the system.
When the system reboots, you will then be able to log on with your domain credentials.
3. Work with Active Directory and Local Groups
You may be confused
about which groups to use and about the best way to work with groups and
manage them. More important, you may be wondering about the best way to
quickly grant access to user rights or permissions to the many objects
in your infrastructure. You will want to know the interrelationship
between your AD groups and the local groups on your servers that have
resources.
The preferred process for this can be summed up in a one-word acronym, UGLY:
- U is for users.
- G is for global groups.
- L is for local groups (where the resource resides).
- Y is for your permissions on the local resources.
You may be thinking that this
sums up the confusion, but learning this process will provide you with
an efficient and effective way to quickly manage and control access to
resources in your domain. When you access a resource in the same domain,
this is how UGLY can be applied:
Place your users in the global group for the domain on which they both reside.
Place the global group in the local group on the system with the resource.
Grant the local group your desired permissions, and grant members access to the resource.
If the resource is
another domain, you will have one more step, and the acronym changes a
little. UGLY becomes UGULY, but the basic premise is still the same:
Place your users in the global group for the domain in which they both reside.
Place the global group in the universal group in the same domain.
Place the universal group in the local group on the system with the resources.
Grant
the local group your desired permissions, and grant members access to
the resource. The reason you nest the global groups into the universal
groups is to avoid replication traffic that can occur when universal
groups change. This way, you can modify the global groups, and only
those groups are changed, which will allow the nested members to gain
access to resources.
For example, in a single domain,
if you wanted a user in your domain to back up a client desktop or
member server in your domain, after you created the user, you would
create a global group, called something like Global Backup. You would
place the user in Global Backup and place Global Backup into the local
group Backup Operators. In this case, you are using the built-in Backup
Operators group, which has already been assigned the necessary rights
and permissions to perform the backup on the system.