Objective 4.1.3: Designing the Appropriate Group Strategy for Accessing Resources

Just imagine if the concept of Active Directory groups did not exist. Managing your network resources would be an extremely complicated task, indeed. For example, imagine a folder that contained many subfolders where you had to manage a complex ACL with many different entries. Without groups, every time a user needed access to a subfolder, you would need to browse to that folder and add or remove the individual user . Take this one step further and imagine working with thousands of users and millions of files and folders ”what a huge mess that would be!

Groups organize users, computers, and other objects and make them easier to manage, so that in the previous scenario you would add groups to the folder ACLs, rather than individual users. Since you ll have far less turnover in the names and types of groups on your network than you will with individual user objects, you can simply control membership to the groups to determine which user has access to what folder. When a new user needs to access a folder, he or she is added to a security group, and when access needs to be revoked , the user is removed. Rights and permissions can be assigned to groups, which will in turn apply these settings to all members of that group.

Three group scopes exist in Windows Server 2003 (these are identical to the group scopes that were introduced in Windows 2000):

Global groups This type of group is used to group users or computers that are members of the same domain. When in Native mode, a Global group can contain other Global groups. It cannot contain users or groups in other domains. It can be used to regulate access to resources in any domain.
Domain Local groups This type of group is used to secure resources that exist on servers that reside in the same domain as the group does. It cannot regulate permissions on resources that exist in domains outside the domain in which the group was created. Domain Local groups can contain users from any domain forest wide. It can contain other Local groups, Global groups, or Universal groups.
Universal groups This type of group can contain any user or group from any domain in an entire forest. They can be used to regulate access to any resource on any domain. This combines the best of the Global and Domain Local groups. Its disadvantage , though, is that it writes every object into the Global Catalog (GC) server. Therefore, if you had a universal group with 1000 users, then these users would have to be written to the GC and then replicated to other GCs, which can place a heavy load on replication. This is workable for small to medium- sized networks, but you will find it highly uncommon and not recommended in large businesses because it will negatively affect network replication.

Objective 4.1.4: Designing a Permission Structure for Data

Designing a permission structure for data can be a challenging task and should be thought out carefully , because rectifying it later and making changes can be a complicated and very time-consuming task. For this reason, a well thought out design plan should rely on Microsoft recommended best practices for permission structure.

The Microsoft strategy for this kind of structure is known as the AGDLP, which is a strategy you should be familiar with from the core 4 requirements. The AGDLP calls for:

A dding domain users to G lobal groups
Adding global groups to D omain L ocal groups
Assign domain local groups P ermissions on resources

With the introduction of Universal groups in Windows 2000 and Windows Server 2003, you can now expand this best practice strategy to accommodate the new group type. The new strategy is known as the AGUDLP and calls for:

A dding domain users to G lobal groups
Adding global groups to U niversal groups
Adding universal groups to D omain L ocal groups
Assigning domain local groups P ermissions on resources

Using Global Groups

The first step in implementing the AGDLP is to assign users in every domain to Global groups in their domain. Users can only be added to a Global group in the same domain; therefore, Global groups cannot contain membership from users residing in a domain other than the one in which the group was created.

Using Domain Local Groups

The second step in the AGDLP strategy is to add Global or Universal groups to Domain Local groups. Domain Local groups are recommended for assigning permissions to resources in the most secure way. Domain Local groups can contain users and groups from any domain in the forest, but can only be assigned permissions on resources that reside in the domain where the group was created. For example, if you had a forest that has domains A, B, C, and D, you can create a Domain Local group in domain A and add users from any other domain. However, you can only assign permissions to resources (such as printers, files, and folders) located in domain A.

Using Universal Groups

In some instances, you might need to use Universal groups instead of Global groups. Universal groups are available in domains operating in at least Windows 2000 native mode, and are typically ideal when more than one domain exists, because Global groups are restricted in terms of user memberships to the domain in which they were created. Universal groups can accept user memberships from any domain. Universal groups can then be added to Domain Local groups, which in turn get assigned permissions over resources.

As appealing as Universal groups might seem, they do have a drawback. Each object in a Universal group is written in the GC and subsequently stored on all GC servers in your forest. In circumstances where there are thousands of Active Directory objects in Universal groups, replication traffic can quickly become an issue, especially when you have many DCs decentralized across a large WAN.

Exam Warning

The main difference between Universal groups and Domain Local groups is that Universal groups can be assigned permissions on any resource in any domain in the forest, whereas Domain Local groups are limited to the domain in which they were created.

Combining and Nesting Groups

When designed properly, nesting or combining groups can greatly reduce administrative overhead and reduce network traffic. However, like anything else, if configured without proper planning, it can be very complicated and hard to troubleshoot. Here are some tips you should keep in mind while designing a nesting strategy:

Try to keep the number of nested groups to a maximum of two or three levels. This can keep it within a manageable scope for assigning permissions and troubleshooting any issues. It also minimizes the chances of adding groups that obtain excessive permissions through nesting and inheritance.
Based on our discussion of group functions, design your nesting strategy so that you are using the most appropriate group for the task at hand. This would reduce the level of nesting required.
Document every group s description and functionality. This would help you troubleshoot permission conflicts and other issues.

Domain Local groups can be nested in other Domain Local groups, but cannot be nested in Global or Universal groups. Global groups, however, can be nested within other Global groups, Domain Local groups, or Universal groups. Universal groups can be nested in other Universal groups and can contain Global groups but cannot be added to Global groups.

Consider this scenario for implementing AGDLP in an enterprise environment. EK Properties is a real estate company that specializes in acquiring shopping malls throughout the United States and in some parts of Europe. Currently, the company owns and operates 200 shopping malls spread out in every state. The company is headquartered in Chicago, Illinois, and has hired you to draw up the design plan for computerizing their current and future growth potential. The company also wants to deploy applications accessible only via Terminal servers that are located in HQ and want to give users access to these applications. All IT support staff will be located at the headquarters office with no technicians on site. The various malls will be connected to the headquarters office through WAN links of varying speeds, most of which will not be faster than 128K. Management is concerned about security at the mall locations because of the increased risk of employee turnover, and wants to place stricter security requirements on mall users in terms of passwords and account lockouts. How would you design the group structure to give access to users data and printers, and how would you design the permissions structure for users who require access to application via Terminal servers?

Since the mall locations are separated by fairly slow links, your plan calls for a decentralized physical model in which you deploy a DC that also acts as a file and print server at every site to service the needs of the local users. User data and network printers will be configured on the local server. The DCs will be remotely administered via Remote Desktop since there will not be IT staff on location in the malls. Because of the differing security requirements, your design calls for one forest with two domains, one for the corporate headquarters and one for all the malls in the United States. User accounts should be created in the appropriate domain, either the headquarters domain or the mall users domain. You create a separate OU for each mall location, and every mall should have a Global group that hosts all the users of that site. This Global group should then be placed in a Domain Local group and assigned permissions to local resources such as folders and printers.

Now, to allow users at all the malls access to applications running on the Terminal servers at HQ, you ll need to add users from the mall domain into a group in the HQ domain, and then assign that group right to access applications. To accomplish this, you ll use the Global groups you created for the mall users, and add those Global groups to a Domain Local group at HQ. You can then assign that the ability to access application via Terminal Services.

Domain and Forest Functional Levels

The concept of domain and forest level functional levels began with Windows 2000 to accommodate interoperability and backward compatibly with Windows NT. Windows 2000 offered two functional levels, Mixed mode and Native mode. Mixed mode had limited Active Directory features, and was backward compatible with Windows NT, which meant NT DCs could co-exist and function. Native mode enabled more Active Directory features such as Universal groups, but required that all DCs be running Windows 2000.

With the introduction of Windows Server 2003, Microsoft built on this idea and introduced new domain and forest functional levels. Each functional level has certain Active Directory feature limitations, with higher levels having the full features and power of Windows Server 2003. Let s look at the old and new functional levels that are available with Windows 2000 Server and now Server 2003:

Windows 2000 Mixed mode This is the default functionality level in Windows 2000 and accepts DCs from Windows NT, Windows 2000, and Windows Server 2003 in the domain.
Windows 2000 Native mode This level represents the highest level that was available in Windows 2000 and accepts only Windows 2000 and Windows Sever 2003 DCs.
Windows Server 2003 Interim This domain functional level specifically allows co-existence between Windows NT DCs and Windows Server 2003 machines. Interim mode does not support Windows 2000 DCs.
Windows Server 2003 This type of domain functional level allows only Windows Server 2003 DCs. Once you raise the domain functional level to Windows Server 2003, you can no longer add any Windows 2000 or NT4 DCs to the domain. You will, however, enable the full features of Active Directory that were introduced with Windows Server 2003.

Similar to domain-level functionality, Windows Server 2003 also offers forest-level functionality that enables features across all the domains that are available in your forest. Windows Server 2003 offers three types of forest functionality:

Windows 2000 This is the default level at which the forest is set to, and this level accepts domains that have Windows NT ,Windows 2000, and Windows Server 2003 DCs.
Windows Server 2003 Interim This type of forest-level functionality supports Windows NT4 and Windows Server 2003 DCs.
Windows Server 2003 This is the highest level of forest functionality and allows only Windows Server 2003 DCs.

The Interim level that is available in both the domain- and forest-level functionality is provided by Microsoft to those clients who skipped the Windows 2000 upgrade and want to upgrade from Windows NT directly to Windows Server 2003.

Once you raise the level of your forest to Windows Server 2003, you will no longer be able to add any DCs except Windows Server 2003 across all the domains in the forest.