Welcome to IT Free Training’s next free video. In this video I will look at the group
strategy AGDLP.
AGDLP is a role based strategy which when used in your organization can simplify day
to day administration. Role based means that permissions are granted based on what role or
roles the user has in the organization.
Since it is a role based strategy, it does not require the administrator to have knowledge
of how permissions have been assigned to the resources that are being controlled. This
allows access for a user to be easily changed, for example, if they change jobs in the organization.
Also, AGDLP provides easy auditing. If you want to know who has access to what, you simply
need to look at who is a member of the group that provides that access.
AGDLP is a strategy that is generally used in medium sized networks. Microsoft defines
this as a network with greater than 500 users. This strategy is also mainly used in a single
domain single forest environment, although it could be used throughout the forest. If
you have a larger environment, the next video discusses another strategy that is often used
in multiple domain environments.
Both of the strategies are designed for large networks. If you are looking after a small
network it may be better to keep things simple. As we will see in this video, the extra complexity
this strategy adds to your network also adds additional flexibility. It is up to you to
decide if your network is big enough and complex enough for the extra work to provide any real
advantages.
When looking at these group strategies they appear overly complicated at first and often
difficult to understand. As I go through each part I will explain the reasoning behind the
groups used. It is important to remember that different groups have different scopes, different
availability and different membership requirements. For these reasons, group strategies like AGDLP
which take advantage of each of the different groups’ characteristics.
AGDLP works like this: accounts go into global groups which go into domain local groups which
get applied to permissions. Seems overly complex, doesn’t it? Let’s start with the resource
we want to allow access to and work our way back and see why each group is used.
First you have the resource, in this case, let’s say a colour printer. You want to
control who can use the color printer since color printing is expensive and you want to
limit its use.
Following this group strategy you would create a domain local group and apply it to the printer.
Remember that domain local groups are only available in the domain that they are created
in. In this strategy the domain local group is used to provide access to the resource.
In this case I will call the group ColorPrintingAllowed.
The advantage of using a domain local group for permissions like this is that you can
be assured that the group will not be used in another domain. Why is this important?
If your company decides to audit who has access to what, you can look inside the ColorPrintingAllowed
group to determine who is able to print to the color printers in your domain. If the
group was available for use in another domain by other administrators, you would not know
what resources this group was used on and even if the group was used at all. In a moment
this will make a lot more sense. The next group is the global group. A global
group is created and put into the domain local group. In this case I will call the group
SalesUsers. I could also create another group called MarketingUsers and put this group in
the domain local group ColorPrintingAllowed. Remember that global groups only allow users,
computers and other global groups to be put in them that come from the domain that the
global group was created in. This may seem like a limitation but let’s consider what
we have done when the permissions for the color printers are audited.
We can now say with confidence that only sales and marketing users from this company have
access to the color printers. Why? Because the global group contains only users from
the domain they are created in so we know by design another user from another domain
could not be put into this group. We also know that the domain local group scope is
limited to only this domain and thus can only be used on resources in this domain. We can
say with confidence that the domain local group has not been used in another domain.
This is important because when audited you want to be able to say with confidence who
has access to what.
Some of you may be thinking, “In a single domain single forest, could I not just use
other group types? For example, could I not just use all the same type of groups? Using
only domain local groups would work; however, you could never be sure that only users from
your domain are being put into the domain local group. Today you may have one domain
and one forest so you can say this, but tomorrow another domain may be added either to the
forest or as an external domain and you will not be able to say this with confidence unless
you check the membership of each group.
The next point is could you use only use global groups. This is possible as well, but this
would limit access to the resource to only members from that domain. At present you may
only have the one domain, but if another domain is added later this will limit you. Also remember
that global groups only allow other global groups from the same domain to be used as
members in that group. That is, if you were using domain local group or universal group
in that domain, you could not use these groups to grant access to the resource. In order
to get global groups to work, you would need to use only global groups. To put it simply,
if you use only global groups, you could only use global groups and you could not provide
access to users outside your domain.
The next question is could you use universal groups? The answer is yes you could. Universal
groups are replicated to all global catalog servers in the forest. This means that as
soon as you use a universal group you require access to a global catalog server. If all
your domain controllers are global catalog servers this won’t present a problem. If
all your domain controllers are not global catalog servers, in order to work out group
membership, a global catalog server needs to be contacted and if the global catalog
server is over a WAN link this will slow everything down.
You can see that if you use the wrong groups in a single domain single forest environment
Active Directory is fairly forgiving. Let’s look at what happens when I add an extra domain
in the mix and use AGDLP.
If you wanted to provide access to a user or group from another domain the only place
this could be added would be the domain local group. Following the strategy let’s say
that the sales global group from the High Costing Training domain is added to the domain
local group that controls color printing access.
When it comes time to audit who has access to color printing, we now know that sales
and marketing from this domain and also the sales staff from high cost training domain
are able to use the color printers. You can see that AGDLP can be used in a single domain
and multiple domain environment to control access. Access can be quickly changed and
audited.
Let’s review what was covered in this video. AGDLP is a group strategy that can be used
in your organization to simplify group administration. It is a role based authorization strategy
so permissions are assigned to users based on their role in the organization. Using role
based authorization makes it simple to change permissions when a user requires different
permissions.
Using AGDLP, accounts are placed into global groups. Global groups allow membership only
from users and computers in that domain and other global groups in that domain. This means
that when the group is used in your organization you can say with confidence that only users
from your domain are in that group.
Global groups are placed into domain local groups. Domain local groups can only be used
in the domain that they were created in. Thus you can say with confidence that the group
is only being used to provide access to resources in that domain.
Domain local group also allows users, computers, global groups and universal groups to be added
from other domains. This allows easy auditing of the group. If you want to know who has
access to a particular resource, look at the members of the domain local group and this
will tell you.
Lastly the domain local group is assigned to the resource. For example if you had a
public share, you could create two groups called Public_Share_Read and Public_Share_Modify.
If you were now asked who had access to the public share, you look inside these groups
and can say which groups have access. If the sales group was in the read only group and
needed modify access, you could simply move the sales group from the read group to the
modify group. Notice that using this approach does not require the administrator to have
any knowledge of which servers the public shares are located on.
In the next video I will look at another group strategy called AGUDLP. If you have not guessed
already, this is the same strategy but uses universal groups as well. This strategy is
used in a multi-domain environment. Using universal groups gives you some additional
flexibility and features that are not available using AGDLP. As always, thanks for watching.