Sharing Resources

This article continues the Networking for Beginners series by explaining how to make resources available on a network.

In the previous article, I talked about the OSI model and how it serves as a model for implementing abstraction between the hardware and the software. In this article, I had originally intended to talk about how protocol stacks are related to the OSI model. After giving it some thought I decided that the topic was relatively confusing, and that it didn't have a whole lot of real world value for new network administrators. That being the case, I want to talk about making resources available on a network instead. If you want to read about protocol stacks and how they relate to the OSI model, there are several good articles available on the Internet.

With that said, I want to turn my attention to making resources available over a network. If you really stop and think about it, the whole reason for building a network in the first place is so that resources can be shared among multiple computers. Resources come in a lot of different forms. Often, sharing resources means sharing files or folders, but not always. At the time that I first got started in networking, printers were very expensive, and it was not uncommon to see companies build networks so that a single printer could be shared by multiple employees. This saved the company from having to purchase and maintain a printer for every single employee.

Even small, home networks are all about sharing resources. The most common type of home network involves a wireless access point that also serves as an Internet router. On these types of networks, the Internet connection is the resource that is being shared. There is simply no reason to have a separate Internet connection for every computer, when the Internet connection can easily be shared.

As you can see, there are many different types of resources that can be shared on a network. The actual process for sharing the resource varies depending on the type of resource that is being shared and on the network operating systems that are being used. That being the case, I will begin my discussion by talking about how you can share files and folders on a network.

Before I Begin

Before I get started, I want to quickly mentioned that the information that I'm about to give you is based on Windows Server 2003. Windows Server 2003, Windows XP, and every previous version of Windows handle file and folder sharing in basically the same way. The actual steps that you use in the sharing process varies slightly from one Windows operating system to another, but the basic underlying concepts are the same. Windows Vista takes a different approach to sharing files than its predecessors do. That being the case, I will talk about filesharing and Windows Vista later on in this series. For right now though, just keep in mind that most of what I'm about to show you doesn't apply to Vista.

Creating A File Share

If you want to share in the files that are stored on a server, you'll have to first create a file share. A file share is essentially a designated entry point through which users can access the files. The reason why a file share is necessary is because it would be a huge security risk to share the full contents of the server.

Creating a file share is simple. To do so, begin the process by creating a folder in the location where you want the shared data to reside. For example, many file servers have a designated storage array or a data drive whose sole purpose is to store data (as opposed to program files and operating system components).

In most cases, you'll probably have quite a few folders worth of data that you need to share. It is also common for each of these folders to have its own unique security requirements. You can create a separate share for each folder, but doing so is usually considered to be a bad idea unless each share resides on a different volume. There are exceptions to every rule, but in most cases you will only want to create one file share per volume. You can place all of your folders within this single file share, and then assign the necessary permissions on a per folder basis. As this discussion progresses, you'll begin to understand why creating multiple file sharers is such a bad idea.

If you've already got a bunch of folders in place, and don't worry about it. You can easily create a new folder and then move your existing folders into the new folder. Another option is to create a file share at the volume level, in which case you would not have to move the existing folders.

For the purposes of this article, I'm going to assume that you've created a folder that will contain subfolders beneath it, and that you will be sharing this top level folder. Once you have created your folder, right-click on it and choose the Sharing and Security command from the resulting shortcut menu. When you do, you will see the folder's properties sheet, as shown in Figure A.

Figure A: The Sharing tab gives you the option of sharing the folder

As you can see in the figure, the Sharing tab allows you to control whether or not the folder is shared. When you select the Share this Folder option, you will be prompted to enter a share name. The name that you choose is very important. Windows isn't nearly as picky as it used to be about share names, but even so, I would recommend that you keep the share name under 16 characters and avoid using spaces or symbols for backward compatibility purposes. I should also mention that if you were to make the last character of the share name a dollar sign, then the share that you are creating becomes invisible. This is known as a hidden share. Windows offers several different hidden shares by default, and I will talk more about hidden shares later in the series.

The Comment field allows you to enter a comment about what the share is used for. This is purely for administrative purposes. Comments are optional, but documenting shares is never a bad idea.

Now take a look at the User Limit section. You will notice in the figure that the user limit is set by default to Maximum Allowed. Anytime that you deploy a Windows server, you must have the necessary client access licenses in place. You have the option of either a purchasing licenses for each individual client, or licensing the server to support a specific number of connections. Assuming that you have multiple servers, it is usually less expensive to license clients rather than an individual servers. At any rate, when the user limit is set to Maximum Allowed, it means that an unlimited number of clients can connect to the share until the number of connections meets the number of licenses that you have purchased. If you're using a per client licensing model, then access to the share is technically unlimited, but it's still up to use make sure that you have a license for every client.

Your other option is to allow a specific number of users to connect to the share. This option has a lot less to do with licensing than it does performance. Lower end hardware may not be able to support a large number of client connections. Therefore, Microsoft gives you the option of limiting the number of simultaneous connections to the share, so as not to overwhelm your hardware.

The OSI Model

How the OSI model is used to help applications to communicate across a network.

In last month’s article, I talked about the way that Windows (and other network operating systems) use a process called abstraction to allow applications to be developed without the vendor having to worry about creating drivers for specific hardware components. Although this concept is widely used throughout the Windows operating system, it is especially important when it comes to networking.

To see why this is the case think about what I talked about in the previous article in regard to hardware abstraction. Suppose that an application needs to be able to communicate across the network. The application developer does not build network drivers into the application, they merely write the application in a way that allows it to make certain calls to the Windows operating system. The manufacturer of the machine’s network adapter provides a driver that also links to Windows, and Windows performs the necessary match ups that allow the application to communicate with the network adapter.

Of course that is just the quick and dirty version. Things are actually quite a bit more complex than that. After all, the network adapter is just a device that is designed to send and receive packets of data. The card itself knows nothing of Windows, the application, or even of the protocols that are being used.

The example that I provided a moment ago implies that there are three layers at work; the application, the operating system, and the physical hardware. While these layers do exist (but not necessarily by those names), they can be subdivided into several more layers.

Before I explain what these layers are and what they do, I want to point out that the concepts that I am about to teach you are not abstract. In fact, if you open the Local Area Connection properties sheet, shown in Figure A, you can see that a network connection is made up of several different components, such as the network client, the network adapter driver, and the protocol. Each of these components corresponds to one or more individual layers.

Figure A: The Local Area Connection properties sheet offers a glimpse at the way that the various network layers are implemented in Windows

The network model that Windows, and most other network operating systems use is called the OSI Model. The term OSI Model is short for Open System Interconnection Basic Reference Model. The OSI Model consists of seven different layers. Each layer of the model is designed so that it can perform a specific task, and facilitate communications between the layer above it and the layer below it. You can see what the OSI Model looks like in Figure B.

Figure B: The OSI Model

The Application Layer

The top layer of the OSI model is the Application layer. The first thing that you need to understand about the application layer is that it does not refer to the actual applications that users run. Instead, it provides the framework that the actual applications run on top of.

To understand what the application layer does, suppose for a moment that a user wanted to use Internet Explorer to open an FTP session and transfer a file. In this particular case, the application layer would define the file transfer protocol. This protocol is not directly accessible to the end user. The end user must still use an application that is designed to interact with the file transfer protocol. In this case, Internet Explorer would be that application.

The Presentation Layer

The presentation layer does some rather complex things, but everything that the presentation layer does can be summed up in one sentence. The presentation layer takes the data that is provided by the application layer, and converts it into a standard format that the other layers can understand. Likewise, this layer converts the inbound data that is received from the session layer into something that the application layer can understand. The reason why this layer is necessary is because applications handle data differently from one another. In order for network communications to function properly, the data needs to be structured in a standard way.

The Session Layer

Once the data has been put into the correct format, the sending host must establish a session with the receiving host. This is where the session layer comes into play. It is responsible for establishing, maintaining, and eventually terminating the session with the remote host.

The interesting thing about the session layer is that it is more closely related to the application layer than it is to the physical layer. It is easy to think of connecting a network session as being a hardware function, but in actuality, sessions are usually established between applications. If a user is running multiple applications, several of those applications may have established sessions with remote resources at any time.

The Transport Layer

The Transport layer is responsible for maintaining flow control. As you are no doubt aware, the Windows operating system allows users to run multiple applications simultaneously. It is therefore possible that multiple applications, and the operating system itself, may need to communicate over the network simultaneously. The Transport Layer takes the data from each application, and integrates it all into a single stream. This layer is also responsible for providing error checking and performing data recovery when necessary. In essence, the Transport Layer is responsible for ensuring that all of the data makes it from the sending host to the receiving host.

The Network Layer

The Network Layer is responsible for determining how the data will reach the recipient. This layer handles things like addressing, routing, and logical protocols. Since this series is geared toward beginners, I do not want to get too technical, but I will tell you that the Network Layer creates logical paths, known as virtual circuits, between the source and destination hosts. This circuit provides the individual packets with a way to reach their destination. The Network Layer is also responsible for its own error handling, and for packet sequencing and congestion control.

Packet sequencing is necessary because each protocol limits the maximum size of a packet. The amount of data that must be transmitted often exceeds the maximum packet size. Therefore, the data is fragmented into multiple packets. When this happens, the Network Layer assigns each packet a sequence number.

When the data is received by the remote host, that device’s Network layer examines the sequence numbers of the inbound packets, and uses the sequence number to reassemble the data and to figure out if any packets are missing.

If you are having trouble understanding this concept, then imagine that you need to mail a large document to a friend, but do not have a big enough envelope. You could put a few pages into several small envelopes, and then label the envelopes so that your friend knows what order the pages go in. This is exactly the same thing that the Network Layer does.

The Data Link Layer

The data link layer can be sub divided into two other layers; the Media Access Control (MAC) layer, and the Logical Link Control (LLC) layer. The MAC layer basically establishes the computer’s identity on the network, via its MAC address. A MAC address is the address that is assigned to a network adapter at the hardware level. This is the address that is ultimately used when sending and receiving packets. The LLC layer controls frame synchronization and provides a degree of error checking.

The Physical Layer

The physical layer of the OSI model refers to the actual hardware specifications. The Physical Layer defines characteristics such as timing and voltage. The physical layer defines the hardware specifications used by network adapters and by the network cables (assuming that the connection is not wireless). To put it simply, the physical layer defines what it means to transmit and to receive data.

It works both ways

So far I have discussed the OSI Model in terms of an application that needs to transmit data across the network. The OSI Model is also used when a machine receives data. When data is received, that data comes in through the Physical Layer. The remaining layers work to strip away the encapsulation, and put the data into a format that the application layer can use.

In this article, I have explained how Windows uses the OSI model to implement networking. It is important to understand that the OSI model is only a guide as to how networking should be implemented. In the real world, protocol stacks sometimes combine multiple layers into a single component. I will show you how protocol stacks fit into the model in the next article in the series.

The Windows Operating System's Role in Networking

Last month I received an e-mail message from a reader who wanted to know why most of the articles in this series have focused on Windows. It was not so much that the person who sent me the message hated Microsoft, or preferred Linux, or anything like that, but wondered why Windows was necessary. As he correctly pointed out, networking has been around since long before Windows. To make a long story short, I thought that the message made a good point, so I wanted to take the opportunity to talk about the role that Windows plays in networking.

Before I Begin

Before I get started, there are a couple of things that I need to say up front. First, I am going to be spending some time talking about the early days of Windows. There are a lot of rumors alleging that Microsoft “borrowed” parts of the Windows Operating System from companies like IBM and Apple. Personally, I do not know if these rumors are true or not, and to be perfectly frank, I do not really care. I just wanted to acknowledge the point up front in an effort to reduce the number of e-mail messages that I receive in response to this article.

The other thing that I want to clarify up front is that today, every operating system implements networking in roughly the same way. Although one operating system might be more efficient than another, the end result is basically the same. After all, it is no coincidence that Windows, Macintosh, Linux, and UNIX can all communicate across the same Internet, using the same protocols.

By writing about Windows, I am not trying to start an operating system war, as I seem to have inadvertently done so many times in the past. I just choose to write about Windows because it is the most commonly used operating system, and articles about Windows would therefore theoretically benefit the largest number of people, and this is primarily a Windows focused website.

What Windows did for the World?

Now that I have hopefully appeased most of the haters, let us get down to business. The reason why Windows became such a dominant operating system was because it solved two major problems that plagued the IT industry.

The first of these problems is that prior to the creation of Windows, PCs were relatively difficult to use (at least for the lay person anyway). Prior to Windows 3.x, most PCs ran a Microsoft operating system known as MS-DOS. DOS was an acronym that stood for Disk Operating System.

The DOS operating system actually worked pretty well, but it did have some serious shortcomings. For starters, the operating system was text based. This meant that if you wanted to launch an application, you could not just point and click on an icon, you had to know the command or commands needed to launch that application. If you wanted to know how much free disk space you had, you could not just right click on a disk icon, you had to use the CHKDSK or DIR command.

The average person was intimidated by DOS. After all, using DOS even for the basics required learning quite a few commands. Many of those commands could do significant damage to your data if you accidentally used them incorrectly, so that added to the problem.

There is no denying that PC use was already becoming widespread before Microsoft introduced the graphical operating system, but Windows helped to make PCs much easier to use.

The second thing that Windows accomplished was far more important. Windows provided a level of abstraction that allowed device drivers to be separated from applications.

In the days of DOS, it was an application developer’s responsibility to include device drivers as a part of an application. For example, when I was in high school, the best word processor on the market was a now defunct product known as PFS Write. One of the things that made PFS Write such a good product was that it supported numerous printers. Even so, I recall purchasing a copy and installing it onto my computer, only to find out that it did not include a driver for my printer. As a result, I had to buy a new printer, just to be able to use a word processor.

Keep in mind that my previous printer was not junk. The problem was that most applications at the time shipped on floppy disks, which had an extremely limited capacity. As a result, application developers would typically only include drivers for the most commonly available hardware. At the time, it was not at all uncommon to find that some applications (especially video games) did not support particular video cards, sound cards, etc.

The way that drivers were tied to applications was bad for both application developers and for consumers. It was bad for application developers, because they had to spend time writing a zillion device drivers, which increased development cost and increased the amount of time that it took to get their product to market. Because an application could only support a limited set of hardware, the developer inevitably alienated some would be customers by not supporting their hardware.

Having device drivers tied to applications was bad for consumers as well. Typically, older hardware was not supported, often forcing consumers to purchase new hardware along with their new application. At the same time though, cutting edge hardware was not usually supported either. Application developers needed to create drivers that would work for the largest number of people possible, so it was rare for an application to contain drivers for the latest hardware. Often the new hardware was backward compatible with device drivers for older hardware, but it might take years for the cutting edge hardware’s full potential to be widely utilized by applications.

When Microsoft created Windows, they created an environment in which any application can interact with any hardware. Sure, applications still have minimum hardware requirements, but hardware brands and models do not really matter anymore. For example, if I wanted to print this document, it would not really matter what kind of printer I have, as long as I have a printer driver installed.

Windows is built in layers. Every Windows application generates print jobs in exactly the same way, regardless of what the application is, or what type of printer the job is being sent to. The Windows operating system then uses the specified print driver to translate the job into something that the printer can understand. The actual process is a little bit more complicated than this, but I wanted to convey the basic idea rather than going into a lot of boring architectural details.

The point is that abstracting applications from device drivers helps everyone. Application developers no longer suffer the burden of writing device drivers, and consumers are now free to use any hardware they want (so long as it meets minimum standards) without having to worry about whether or not it will work with a particular application.

As you can see, Microsoft was able to design Windows in a way that allowed applications to be abstracted from device drivers. In the next part of this article series, I will continue the discussion by showing you how this architecture assists with networking.

Universal Groups & Group Nesting

This article continues the discussion on Universal Groups and the concept of group nesting.

In the previous article in this series, I introduced you to the concept of using groups to manage network access control, rather than granting permissions directly to users. I then went on to explain that Windows Server 2003 supports a few different types of groups, and that each of these types of groups has its own strengths and limitations.

In that article, I talked a lot about local groups, domain local groups, and global groups. You could easily manage your entire network using only these types of groups. Even so, there is one more type of group that Windows Server 2003 supports; universal groups.

For those of you who found local groups, domain local groups, and global groups to be confusing or overly restrictive, then universal groups will initially seem like an answer to prayers. Universal groups are essentially groups that are not subject to the restrictions that apply to the other types of groups. For example, in the previous article, I mentioned that you can’t place a local group or a domain local group into another local group. You can however, put a universal group into a local group. The rules that apply to other types of groups simply don’t apply to universal groups.

Of course, this raises the question of why you would ever use any of the other types of groups if they have limitations that universal groups can overcome.

One of the reasons why there are so many different types of groups is because Windows Server is an evolutionary product. Universal groups were introduced in Windows 2000 Server, along with the Active Directory. Previous versions of Windows Server (namely Windows NT Server) supported the use of groups, but universal groups had not been invented yet when these versions were current. When Microsoft released Windows 2000 Server, they chose to continue to support other types of groups as a way of maintaining backward compatibility with Windows NT. Likewise, Windows Server 2003 also supports the use of legacy group types for backward compatibility reasons.

The fact that universal groups didn’t exist in the days of Windows NT Server, means that Windows NT doesn’t support universal groups. This presents a bit of a problem if you happen to have any Windows NT servers in your forest.

Windows 2000 Server was such a dramatic change from Windows NT Server that a number of the new features would only work on networks with no Windows NT Server domain controllers. To get around this problem, Microsoft created the concept of native mode. I will talk a lot more about native mode in Part 17, but the basic idea is that when Windows 2000 Server is initially installed, it is operating in something called mixed mode. Mixed mode is fully backward compatible with Windows NT, but many of Windows 2000’s features can’t be used until you get rid of the Windows NT domain controllers and switch to native mode. Although the terminology is a bit different, the same basic concept also applies to Windows Server 2003.

Universal groups are one of those features that is only available if your domain controllers are operating in Windows 2000 Server Native Mode or higher. That’s one reason why you can’t use universal groups in every situation.

Even if all of your servers are running Windows Server 2003, and your forest is fully native, it is still a bad idea in most cases to use universal groups exclusively.

Earlier in this series, I introduced you to the concept of global catalog servers. As you may recall, global catalog servers are domain controllers that have been assigned the task of keeping track of every object in the forest. Typically, each Active Directory site contains its own copy of the global catalog, which means that any time a global catalog is updated, the updated information must be replicated to the other global catalog servers.

When you create a universal group, both the group name and the group’s membership list are written to the global catalog. This means that as you create more and more universal groups, the global catalog becomes more bloated. As the global catalog becomes larger, the amount of time that it takes to replicate the global catalog from one global catalog server to another also increases. If left unchecked, this can lead to network performance problems.

In case you are wondering, other types of groups don’t place nearly as much of a load on the global catalog. For example, global groups are listed in the global catalog, but their membership list isn’t. Therefore, Microsoft’s basic rule of thumb is that it is OK to create universal groups, but you should use them sparingly.

Group Nesting

One last group related concept that I want to discuss is that of nesting. The easiest way that I can think of to explain nesting is to compare it to Russian matryoshka dolls, like the ones shown in Figure A. These types of dolls are designed so that they can all be placed inside of one another. The smallest goes into the second smallest, the second smallest goes into the third smallest, and so on. This idea of placing an object inside of a similar object is called nesting.

Figure A: Russian matryoshka dolls illustrate the concept of nesting.

There are many different reasons for nesting groups. One of the most common reasons involves matching up resources with departments. For example, a company might start by creating a group for each department. They might create a Finance group, a Marketing group, an IT group, and so on. Next, they would place users into the group that corresponds to the department that the user works in.

The next step in the process would be to create groups that correspond to the various resources that you need to grant access to. For example, if you knew that everyone in the finance department was going to need access to an accounting application, you could create a group that grants access to the application, and then place the finance group into that group. You don’t have to nest groups, but doing so sometimes allows you to keep things a little bit better organized, while saving a little bit of work in the process. For instance in the previous example, you didn’t have to manually place individual user accounts into the group for the accounting application. Instead, you just reused a group that already existed.

Keep in mind that not every group can be nested into every other type of group. The table below shows which types of groups can be nested into other groups.

Group Type	Can Be Nested into Local	Can Be Nested into Domain Local	Can Be Nested into Global	Can Be Nested into Universal
Local	No	No	No	No
Domain Local	Yes	Yes, if in the same domain	No	No
Global	Yes	Yes	Yes, if in the same domain	Yes
Universal	Yes	Yes	No	Yes

Table 1

Caveats

If Windows is operating in Windows 2000 mixed mode, the following limitations apply:

• Universal groups cannot be created
• Domain local groups can only contain global groups
• Global groups can not contain other groups

In this article, I have explained that it is sometimes advantageous to nest one group within another group. I then went on to discuss under which situations it is possible to do this.

In the next part of this article series, I am going to take a step back and talk about the role that the Windows operating system plays in networking.

Security Groups

The various types of security groups that Windows allows you to create.

In the previous article, I showed you how to create security groups in Windows Server 2003. When I walked you through the process though, you might have noticed that Windows allows you to create a few different types of groups, as shown in Figure A. As you might have guessed, each of these group types has a specific purpose. In this article, I will explain what each type of group is used for.

Figure A: Windows allows you to create a few different types of groups

If you look at the dialog box shown above, you will notice that the Group Scope area provides you with the option of creating a domain local, global, or universal group. There is also a fourth type of group that is not shown here, it is simply called a local group.

Local Groups

Local groups are groups that are specific to individual computer. As you know by now, local computers can contain user accounts that are completely separate from those accounts that belong to the domain that the computer is connected to. These are known as a local user accounts, and they are only accessible from the computer on which they reside. Furthermore, local user accounts can only exist on workstations and on member servers. Domain controllers do not allow for the existence of local user accounts.

With this in mind that should come as no surprise that local groups are simply groups that are specific to a particular member server or workstation. A local group is often used to manage local user accounts. For example, the local Administrators group allows you to designate which users are administrators over the local machine.

Although a local group can only be used to secure resources residing on the local machine, it doesn't mean that the group's membership must be limited to local users. While a local group can, and usually does, contain local users, it can also contain domain users. Furthermore, local groups can also contain other groups that reside at the domain level. For example, you could make a universal group a member of a local group, and the universal group’s members will basically become members of the local group. In fact, a local group can contain local users, domain users, domain local groups, global groups, and universal groups.

There are two caveats that you need to be aware of though. First, as you might have noticed, a local group cannot contain another local group. It would seem that you should be able to drop one group into another, but you can’t. Someone at Microsoft once told me that the reason for this is to prevent a situation in which two local groups become members of each other.

The other caveat that you need to be aware of is that local groups can only contain domain users and domain level groups if the machine containing the local group is a member of the domain. Otherwise, local groups can only contain local users.

Domain Local Groups

Given what you've just learned about local groups, the idea of a domain local group probably sounds contradictory. The reason why domain local groups exist though, is because domain controllers do not contain a local account database. This means that there are no such things as local users or local groups on a domain controller. Even so, domain controllers have local resources that need to be managed. This is where domain local groups come into play.

When you install Windows Server 2003 onto a computer, the machine typically begins life as either a standalone server or as a member server. In either case, local user accounts and local groups are created during the installation process. Now suppose that you wanted to convert the machine into a domain controller. When you run DCPROMO, the local groups and local user accounts are converted into domain local groups and domain user accounts.

It is important to keep in mind that all of the domain controllers within a domain share a common user account database. This means that if you add a user to a domain local group on one domain controller, the user will be a member of that domain local group on every domain controller in the entire domain.

The most important thing to keep in mind about domain local groups is that there are two different types. As I mentioned, when DCPROMO is run, the local groups are converted to domain local groups. Any domain local groups that are created by running DCPROMO are placed into the Builtin folder in the Active Directory Users and Computers console, as shown in Figure B.

Figure B: Domain local groups created by DCPROMO reside in the Builtin container

The reason why this is important to know is because there are some restrictions imposed on these particular domain local groups. These groups cannot be moved or deleted. Likewise, if you cannot make these groups members of other domain local groups.

These restrictions do not apply to domain local groups that you create though. Domain local groups that you create typically began life in the Users container. From there, you are free to move or delete them to your heart’s content.

I have to be perfectly frank and tell you though that in all the years I have been working with Windows Server, I have yet to find a good argument for creating domain local groups. In fact, domain local groups are basically identical to global groups, except that they are restricted to an individual domain.

Global Groups

Global groups are by far the most commonly used type of group. In most cases, a global group simply acts as a collection of Active Directory user accounts. The interesting thing about global groups is that they can be placed inside of each other. You can make one global group a member of another global group, so long as both global groups exist within the same domain.

Keep in mind, the global groups can only contain Active Directory resource. You cannot place a local user account or a local group into a global group. You can however, add a global group to a local group. In fact, doing so is the most common way of granting domain users permissions to resources stored on a local computer. For example, suppose that you wanted to give the managers in your company administrative rights to their workstations (not that I recommend doing that, this is just an example). To do so, you could create a global group called Managers, and place each of the manager’s domain user accounts into it. You could then add the Managers group to the workstation’s local Administrators group, thus making the managers administrators on those workstations.

In this article, I've explained that Windows supports the use of four different types of security groups. So far, I have explained the differences between local, domain local, and global groups. In the next part of this article series, I will continue the discussion by discussing universal groups. I will then go on to discuss the concept of group nesting

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.