AGDLP

Transcription

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.