Creating Groups

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.

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.

User Account Management

Creating a User Account

One of the most common uses for the Active Directory Users in Computers console is to create new user accounts. To do so, expand the container corresponding to the domain that you are attached to, and select the Users container. When you do, the console's details pane will display all of the user accounts that currently exist in the domain, as shown in Figure A

Figure A: Selecting the Users container causes the console to display all of the user accounts in the domain.

Now, right click on the Users container and select the New command from the resulting shortcut menu. When you do, you will see a submenu that gives you the choice of many different types of objects that you can create. Technically, the Users container is just a container and you can put pretty much any type of object in it. It is generally considered bad practice though to store objects other than user objects in the Users container. That being the case, select the User command from the submenu. When you do, you will see the dialog box shown in Figure B.

Figure B: The New Object – User dialog box allows you to create a new user account.

As you can see in the figure, Windows initially only requires you to enter some very basic information about the user. Although this screen asks for things like first name and last name, these are not technically required. The only piece of information that is absolutely required is the User Logon Name. Although the other fields are optional, I recommend filling them in anyway.

The reason why I recommend filling in as many fields as you can is because a user account is nothing more than an object that will reside within the Active Directory. Things like first name and last name are attributes of the user object that you are creating. The more attribute information that you fill in, the more useful the information stored in the Active Directory will be. After all, the Active Directory is a database that you can query for information. In fact, many applications work by extracting the various attributes from the Active Directory. When you have filled in the various fields, click the Next button, and you will be taken to the screen shown in Figure C.

Figure C: You will be prompted to assign a password to the new user account.

As you can see in the figure, assigning a password is fairly simple. All you really have to do is type, and retype the password. By default, the user is required to change the password at the next logon. You can prevent this behavior by clearing the User Must Change Password at Next Logon check box. There is another check box allowing you to prevent the user from changing their password at all. You also have the option of setting passwords to never expire, or disabling the account completely.

Although there is nothing overly complex about the password screen, there is one important thing to keep in mind. When you assign a password to a new user account, the password must comply with your corporate security policy. If the password that you use does not meet the requirements dictated by the applicable group policies, then the user account will not be created.

Click next and you will see a screen displaying a summary of the options that you have chosen. Assuming that everything looks good, click Finish and the new user account will be created.

Editing User Account Attribute

Earlier, I discussed the importance of filling in the various attributes as you create a new user account. You might have noticed that the screens involved in creating a new user account did not really have many attributes that you were able to fill in. However, the Active Directory contains dozens of built in attributes related to user accounts.

I am not saying that you have to go through the console and populate dozens of attributes for every single user account. There are some attributes that do come in handy. I recommend populating attributes that are related to basic contact information. In fact, some corporations create corporate directories that are based solely on information stored in these Active Directory attributes. Even if you are not interested in building applications that extract information from your Active Directory, it is still a good idea to populate the Active Directory with user contact information. For example, suppose that you need to reboot a server, and a user is still logged into an application that resides on the server. If you have the user's contact information stored in the Active Directory, then you can simply look up the user's phone number, and call the user to ask them to log out.

Before I show you how to populate the various Active Directory attributes, I want to mention that the same technique can also be used for modifying existing attributes. For example, if a female employee were to get married, she might change her last name. You could use the techniques that I am about to show you to modify the contents of the Last Name attribute.

To access the various user account attributes, simply right click on the user account of choice and select the Properties command from the resulting shortcut menu. Upon doing so, Windows will display the screen shown in Figure D.

Figure D: The user's properties sheet is used to store attribute and configuration information for the user account.

As you can see in the figure, the properties sheet's General tab allows you to modify the user’s first name, last name, or display name. You can also fill in (or modify) a few other fields such as Description, Office, Telephone Number, E-mail, or Web Page. If you are interested in storing more detailed information about the user, then check out the Address, Telephones, and Organization tabs. These tabs all contain fields for storing much more detailed information about the user.

Resetting a User's Password

You probably noticed in Figure D that there are a lot of different tabs on the user’s properties sheet. Most of these tabs are related to the security and configuration of the user account. One thing that most new administrators seem to notice right away when exploring these tabs is that there is no option on any of the tabs to reset the user’s password.

If you need to reset a user’s password, then close the user’s properties sheet. After doing so, right click on the user account and select the Reset Password command found on the resulting shortcut menu.

In this article, I have walked you through the processes of creating a user account, populating the various Active Directory attributes related to that account, and resetting the account password. In the next article in the series, I will continue the discussion by demonstrating more of the Active Directory Users and Computers console’s capabilities.