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.
