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.
No comments:
Post a Comment