Networking Basics: Part 13 – Creating Groups

If you would like to read the other parts in this article series please go to:

In the previous article in this series, I showed you how to use the Active Directory Users and Computers console to create and manage user accounts. In this article, I want to continue the discussion by teaching you about groups.

In a domain environment, user accounts are essential. A user account gives a user a unique identity on the network. This means that it is possible to track the user’s online activity. It is also possible to give a user account a unique set of permissions, assign the user a unique e-mail address, and meet all of the user’s other individual needs.

Although custom tailoring a user account to meet a user’s individual needs sounds like a good idea, it isn’t really practical in a lot of cases. Setting up and managing user accounts is a time consuming task. It isn’t a big deal if you’ve only got a couple dozen users in your organization, but if your organization has thousands of users, then account management can quickly become an overwhelming burden.

My advice is that even if you manage a very small network, you should treat the small network as if it were a big network. The reason for this is that you never know when the network will grow. Using good management techniques from the very beginning will help you to avoid a logistical nightmare later on.

I have actually seen the consequences of unexpected, rapid growth in the real world. About fifteen years ago, I was hired as a network administrator for an insurance company. At the time, the network was very small. There were only a couple dozen workstations attached to the network. The woman who was in charge of the network had no prior IT experience and was thrown to the wolves, so to speak. Not having an IT background, and not knowing any better, she had configured the network so that all of the configuration settings existed on a per user basis.

At the time, this was no big deal. There weren’t many users, and it was easy to manage the various accounts and permissions. Within a year there were over two hundred PCs on the network. By the time I left the company a couple of years later, there were well over a thousand people using a network that was only initially designed to handle a few dozen.

As you can imagine, the network experienced some severe growing pains. Some of these growing pains were related to hardware performance, but most were related to the inability to effectively manage that many user accounts. Eventually, the network became such a mess that all of the user accounts had to be deleted and recreated from scratch.

Obviously, rapid unexpected growth can cause problems, but you are probably wondering why in the world things became so unmanageable that all of the accounts had to be deleted so that we could “just start over”.

As I mentioned before, all of the configuration and security settings were user based. This meant that if a department manager came to me and asked me to tell him who had access to a particular network resource, I would have to look at every account individually to see whether or not the user had access to the resource. When you only have a couple dozen users, checking every account to see which users have access to something is tedious and disruptive (at the time, checking took about 20 minutes). When you’ve got a couple hundred users checking every user account can take most of the day.

Granted, the events that I just described happened well over a decade ago. As the IT industry goes, these events might as well have occurred in prehistoric times. After all, the network operating systems that were in use at the time are now extinct. Even so, the lessons learned back then are as relevant today as they were then.

All of the problems that I just described could have been prevented if groups had been used. The basic idea behind groups is that a group can contain multiple user accounts. Since security settings are assigned at the group level, you should never manually assign permissions directly to a user account. Instead, you would assign permission to a group, and then make the user a member of the group.

I realize that this might sound a little confusing, so I will demonstrate the technique for you. Suppose that one of your file servers contains a folder named Data, and that you need to grant a user read access to the Data folder. Rather than assigning the permission directly to the user, let’s create a group.

To do so, open the Active Directory Users and Computers console. When the console opens, right click on the Users container, and select the New | Group commands from the resulting shortcut menus. Upon doing so, you will see a screen similar to the one that is shown in Figure A. At a minimum, you must assign a name to the group. For ease of management, let’s just call the group Data, since the group is going to be used to secure the Data folder. For right now, don’t worry about the group scope or the group type settings. I will teach you about these settings in the next part of this series.


Figure A:
Enter a name for the group that you are creating

Click OK, and the Data group will be added to the list of users, as shown in Figure B. Notice that the group’s icon uses two heads, indicating that it is a group, as opposed to the single headed icon used for user accounts.


Figure B:
The Data group is added to the list of users

Now, double click on the Data group, and you will see the group’s properties sheet. Select the properties sheet’s Members tab, and click the Add button. You are now free to add user accounts to the group. The accounts that you add are said to be group members. You can see what the Members tab looks like in Figure C.


Figure C:
The Members tab lists all of the group’s members

Now it’s time to put the group to work. To do so, right click on the Data folder, and select the Properties command from the resulting shortcut menu. When you do, you will see the folder’s properties sheet. Go to the properties sheet’s Security tab, and click the Add button. When prompted, enter the name of the group that you just created (Data) and click OK. You are now free to establish a set of permissions for the group. Whatever permissions you apply to the group, also apply to group members. As you can see in Figure D, there are some other rights that are applied to the folder by default. It is best to remove the Users group from the access control list to prevent any accidental contradictions of permissions.


Figure D:
The Data group is added to the folder’s access control list

Remember earlier when I mentioned how much work it was to try to figure out which users had access to a particular resource? Well, when groups are in use, the process becomes simple. If you need to know which users have access to the folder, just look to see which groups have access to the folder, as shown in Figure D. Once you know which groups can access the folder, determining who has rights to the folder is as simple as checking the group’s membership list (shown in Figure C). Any time additional users need access to the folder, just add their names to the list of group members. Likewise, you can remove permissions to the folder by deleting a user’s name from the list of group members.

Conclusion

In this article, I have shown you how to create security groups in a Windows Server 2003 environment. In the next article in the series, I will continue the discussion by showing you the impact of selecting a different group type.

 

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top