The organization of users, computers, and other objects within the Windows Server 2003 Active Directory (AD) structure gives administrators great flexibility and control over their environments. Both organizational unit (OU) and group structure design can be tailored to fit virtually any business need. There is, however, a great bit of confusion among administrators in the design and use of OUs and groups. Often, OUs are indiscriminately used without reason, and group structure is ineffectual and confusing. With the proper preparation and advance knowledge of their use, however, a functional OU and group design can do wonders to simplify a Windows Server 2003 Active Directory environment.
In addition to the lessons learned from OU and group use in Windows 2000, Windows Server 2003 introduces several functional advantages and improvements to OU and group structure and replication that fundamentally change their design method. Universal Group Membership caching, incremental group replication, and other enhancements have increased the flexibility of OU and group design, and have given administrators greater tools to work with.
This chapter defines organizational units and groups within Windows Server 2003’s Active Directory and describes methods of integrating them into various Active Directory designs. Specific step-by-step instructions and “best practice” design advice are given as well. In addition, functional OU and group design models are detailed and compared.
An organizational unit is an administrative-level container, depicted in Figure 6.1, that is used to logically organize objects in Active Directory. The concept of the organizational unit is derived from the Lightweight Directory Access Protocol (LDAP) standard upon which Active Directory was built, although there are some conceptual differences between pure LDAP and Active Directory.
Objects within Active Directory can be logically placed into OUs as defined by the administrator. Although all user objects are placed in the Users container by default and computer objects are placed in the Computers container, they can be moved at any time.
Note
The default Users and Computers folders in Active Directory are not technically organizational units. Rather, they are technically defined as Container class objects. It is important to understand this point because these Container class objects do not behave in the same way as organizational units. To be able to properly utilize services such as Group Policies, which depend on the functionality of OUs, it is recommended that you move your user and computer objects from their default container locations into an OU structure.
Each object in the Active Directory structure can be referenced via LDAP queries that point to its specific location in the OU structure. You will often see objects referenced in this format when you’re writing scripts to modify or create users in Active Directory or simply running LDAP queries against Active Directory. For example, in Figure 6.2, a user named Andrew Abbate in the San Jose Users OU would be represented by the following LDAP string:
Note
OU structure can be nested, or include sub-OUs that are many layers deep. Keep in mind, however, that the more complex the OU structure, the more difficult it becomes to administer and the more time-consuming directory queries become. Microsoft recommends not nesting more than 10 layers deep. However, it would be wise to keep the complexity significantly shorter than that number to maintain the responsiveness of directory queries.
OUs primarily satisfy the need to delegate administration to separate groups of administrators. Although there are other possibilities for the use of OUs, this type of administration delegation is, in reality, the primary factor that exists for the creation of OUs in an AD environment. See the “Starting an OU Design” section of this chapter for more details on this concept.
The idea of groups has been around in the Microsoft world for much longer than OUs have been. As with the OU concept, groups serve to logically organize users into an easily identifiable structure. However, there are some major differences in the way that groups function as opposed to OUs. Among these differences are the following:
Group membership is viewable by users—. Whereas OU visibility is restricted to administrators using special administrative tools, groups can be viewed by all users engaged in domain activities. For example, users who are setting security on a local share can apply permissions to security groups that have been set up on the domain level.
Membership in multiple groups—. OUs are similar to a filesystem’s folder structure. In other words, a file can reside in only one folder or OU at a time. Group membership, however, is not exclusive. A user can become a member of any one of a number of groups, and her membership in that group can be changed at any time.
Groups as security principals—. Each security group in Active Directory has a unique Security ID (SID) associated with it upon creation. OUs do not have associated Access Control Entries (ACEs) and consequently cannot be applied to object-level security. This is one of the most significant differences because security groups allow users to grant or deny security access to resources based on group membership. Note, however, that the exception to this is distribution groups, which are not used for security.
Mail-enabled group functionality—. Through distribution groups and (with the latest version of Microsoft Exchange) mail-enabled security groups, users can send a single email to a group and have that email distributed to all the members of that group. The groups themselves become distribution lists, while at the same time being available for security-based applications. This concept is elaborated further in the “Distribution Group Design” section later in this chapter.
Groups in a Windows Server 2003 come in two flavors: security and distribution. In addition, groups can be organized into different scopes: machine local, domain local, global, and universal.
The type of group that administrators are most familiar with is the security group. This type of group is used to apply permissions to resources en masse so that large groups of users can be administered more easily. Security groups can be established for each department in an organization. For example, users in the Marketing department can be given membership in a Marketing security group, as shown in Figure 6.3. This group is then allowed to have permissions on specific directories in the environment.
This concept should be familiar to anyone who is used to administering down-level Windows networks such as NT or Windows 2000. As you will soon see, however, some fundamental changes in Windows Server 2003 change the way that these groups function.
As previously mentioned, security groups have a unique Security ID (SID) associated with them, much in the same way that individual users in Active Directory have an SID. The uniqueness of the SID is utilized to apply security to objects and resources in the domain. This concept also explains why you cannot simply delete and rename a group to have the same permissions that the old group previously maintained.
The concept of distribution groups in Windows Server 2003 was introduced in Windows 2000 along with its implementation of Active Directory. Essentially, a distribution group is a group whose members are able to receive Simple Mail Transfer Protocol (SMTP) mail messages that are sent to the group. Any application that can use Active Directory for address book lookups (essentially LDAP lookups) can utilize this functionality in Windows Server 2003.
Distribution groups are often confused with mail-enabled groups, a concept in environments with Exchange 2000/2003. In addition, in most cases distribution groups are not utilized in environments without Exchange 2000/2003 because their functionality is limited to infrastructures that can support them.
Members of Active Directory groups can be easily sent emails through the concept of mail-enabled groups. These groups are essentially security groups that are referenced by an email address, and can be used to send SMTP messages to the members of the group. This type of functionality becomes possible only with the inclusion of Exchange 2000 or higher. Exchange 2000/2003 actually extends the forest schema to allow for Exchange-related information, such as SMTP addresses, to be associated with each group.
Most organizations will find that mail-enabled security groups satisfy most of their needs, both security-wise and email–wise. For example, a single group called Marketing that contains all users in that department could also be mail-enabled to allow Exchange users to send emails to everyone in the department.
There are four primary scopes of groups in Active Directory. Each scope is used for different purposes, but all simply serve to ease administration and provide a way to view or perform functions on large groups of users at a time. The group scopes are as follows:
Group scope can become one of the most confusing aspects of Active Directory, and it can often require a doctorate degree in Applied BioGroupology to sort it all out. However, if certain design criteria are applied to group membership and creation, the concept becomes more palatable.
Machine local groups are essentially groups that are built into the operating system and can be applied only to objects local to the machine in which they exist. In other words, they are the default local groups such as Power Users, Administrators, and the like created on a standalone system. Before networking simplified administration, local groups were used to control access to the resources on a server. The downside to this approach was that users needed to have a separate user account on each machine that they wanted to access. In a domain environment, using these groups for permissions is not recommended because the administrative overhead would be overwhelming.
Note
Domain controllers in an Active Directory forest do not contain local groups. When the dcpromo command is run on a server to promote it to a domain controller, all local groups and accounts are deleted in favor of domain accounts. Essentially, the local groups and users are replaced with a copy of the domain groups and users. Any special permissions using local users must be reapplied using domain accounts.
Domain local groups, a term that may seem contradictory at first, are domain-level groups that can be used to establish permissions on resources in the domain in which they reside. Essentially, domain local groups are the evolution of the old Windows NT local groups.
Domain local groups can contain members from anywhere in an Active Directory forest or any trusted domain outside the forest. A domain local group can contain members from any of the following:
Domain local groups are primarily used for access to resources because different domain local groups are created for each resource and then other accounts and/or groups are added to them. This helps to readily determine which users and groups have access to a resource.
Global groups are the reincarnation of the NT global group, but with slightly different characteristics. These groups can contain the following types of objects:
User accounts
Global groups from their own domain (Native mode only)
Global groups are primarily useful in sorting users into easily identifiable groupings and using them to apply permissions to resources. What separates global groups from universal groups, however, is that global groups stop their membership replication at the domain boundary, limiting replication outside the domain.
The concept of universal groups was new with the release of Windows 2000 and has become even more useful in Windows Server 2003. Universal groups are just that—universal. They can contain objects from any trusted domain and can be used to apply permissions to any resource in the domain.
Universal groups are available only in Windows Server 2003 or Windows Native 2000 domain functional modes and cannot be used in the Windows Server 2003 Interim or Windows 2000 Mixed mode. This is because Windows NT4 backup domain controllers (BDCs) cannot replicate the functionality present in universal groups.
Although simply making all groups within a domain into universal groups may seem practical, the limiting factor has always been that membership in universal groups is replicated across the entire forest. To make matters worse, Windows 2000 Active Directory universal group objects contained a single multi-entry attribute that defined membership. This meant that any time membership was changed in a universal group, the entire group membership was re-replicated across the forest. Consequently, universal groups were limited in functionality.
Windows Server 2003 introduces the concept of incremental universal group membership replication, which accomplishes replication of membership in universal groups on a member-by-member basis. This drastically reduces the replication effects that universal groups have on an environment and makes the concept of universal groups more feasible for distributed environments. This functionality is not present, however, until the domain has been upgraded to Windows Server 2003 functional level.
Understanding the concepts used with Windows Server 2003 design is only part of the battle. The application of those concepts into a best-practice design is the tricky part. You can take heart in the fact that of all the design elements in Active Directory, OU and group structure is the most flexible and forgiving. You could theoretically completely revamp your entire OU structure in the middle of the day without affecting users of the network as OU structure is administrative in function and does not directly affect user operations. That said, care should be taken to ensure that group policies that might be in place on OUs are moved in before user or computer accounts move. Not taking this into account can lead to the application of unwanted group policies to various computer or user objects, often with adverse effects. Group membership is also readily changeable, although thought should be given to the deletion of security groups that are already in use.
Note
Because each group SID is unique, you must take care not to simply delete and re-create groups as you go. As with user accounts, even if you give a new group the same name as a deleted group and add the same users into it, permissions set on the old group will not be applied to the new group.
While keeping these factors in mind and after successfully completing your forest and domain design (see Chapters 4, “Active Directory Primer,” and 5, “Designing a Windows Server 2003 Active Directory”), it’s now time to start designing an OU and group structure.
As with Active Directory domain design, OU design should be kept simple and expanded only if a specific need makes the creation of an OU necessary. As you will see, compelling reasons for creation of OUs are generally limited to delegation of administration, in most cases.
As with domain design, it is important to establish a frame of reference and common design criteria when beginning design of the OU structure. Organizational units are often graphically represented by a folder that looks like the icon in Figure 6.4.
Another common method of displaying OU structure is represented by simple text hierarchy, as shown in Figure 6.5.
Whichever way is chosen, it is important to establish a standard method of illustrating the OU design chosen for an organization.
The first step in the design process is to determine the best method of organizing users, computers, and other domain objects within an OU structure. It is, in a way, too easy to create organizational units, and often domain designers create a complex structure of nested OUs, with three or more for every department. Although this approach will work, the truth of the matter is that it gives no technical advantages, and instead complicates LDAP directory queries and requires a large amount of administrative overhead. Consequently, it is better to start an OU design with a single OU and expand the number of OUs only if absolutely necessary.
OUs in Active Directory can essentially serve as a replacement for NT resource domains. In a nutshell, this factor alone could make it easier to redesign your network environment. For example, consider the fictional company, CompanyABC, whose NT environment was composed of numerous NT resource domains similar to those shown in Figure 6.6. Each domain is administered by a local IT team.
When migrating to Windows Server 2003, CompanyABC discovered the administrative advantages to organizational units, as shown in Figure 6.7, and restructured its environment with a single domain to take the place of the NT resource domains that previously existed.
The original purpose of resource domains in NT 4.0 was to separate groups of domain administrators from having control over each other’s environment. This, in addition to replication concerns, is what caused so many IT environments to administer an enormous quantity of NT domains. Active Directory allows for these domains to be collapsed into an equivalent OU structure, while allowing for a much greater amount of control for the central IT structure.
Administrators have heard conflicting reports for years about the use of organizational units in Active Directory. Books and resource guides and pure conjecture have fueled the confusion and befuddled many administrators over best practice for their OU structure.
The basic truth about OUs, however, is that you more than likely do not need as many as you think that you need. Add an OU to a domain if a completely separate group needs special administrative access to a segment of users. If this condition does not exist, and a single group of people administers the entire environment, there is often no need to create more than one OU.
This is not to say that there may be other reasons to create OUs. Application of Group Policy, for example, is a potential candidate for OU creation. However, even this type of functionality is better accomplished through other means. It is a little-known fact that Group Policy can be applied to groups of users, thus limiting the need to create an OU for this expressed purpose. For more information on how to accomplish this, see the section “Group Policies and OU Design” later in this chapter.
Domain designers are in no way locked in to an OU structure. Users can be moved back and forth between OUs during normal business hours without affecting domain functionality. This fact also helps designers to easily correct any design flaws that may have been made to the OU structure.
OUs were introduced as part of Active Directory with the release of Windows 2000. There are essentially no technical differences between the functionality of OUs in Windows 2000 and the functionality of OUs in Windows Server 2003. However, real-world experience with OU design has changed some of the major design assumptions that were previously made in Windows 2000.
As previously mentioned, one of the most important reasons for creating an OU structure in Active Directory is for the purpose of delegating administration to a separate administrator or administrative group. Whereas in NT 4.0 separate domains were necessary for this type of functionality, Active Directory allows for this level of administrative granularity in a single domain. This concept is further illustrated in this section.
Essentially, the role of the NT resource domain has been replaced by the concept of the organizational unit. A group of users can be easily granted specific levels of administrative access to a subset of users. For example, a remote IT group can be granted standard user creation/deletion/password-change privileges to its own OU. The process of delegating this type of access is quite simple and involves the following steps:
In Active Directory Users and Computers, right-click the OU where you want to delegate permissions and choose Delegate Control.
Click Next at the Welcome screen.
Click Add to select the group you want to give access to.
Type in the name of the group and click OK.
Click Next to continue.
Under Delegate the Following Common Tasks, choose the permissions you want—in the example shown in Figure 6.8, Create, Delete, and Manage User Accounts—and then click Next.
Click Finish to finalize the changes.
In fact, the Delegation of Control Wizard allows for an extremely specific degree of administrative granularity. If desired, an administrator can delegate a group of users to be able to modify only phone numbers or similar functionality for users in a specific OU. Custom tasks can be created and enabled on OUs to accomplish this and many other administrative tasks. For the most part, a very large percentage of all the types of administration that could possibly be required for delegation can work in this way. To use the phone administration example, follow these steps to set up custom delegation:
In Active Directory Users and Computers, right-click the OU where you want to delegate permissions and choose Delegate Control.
Click Next at the Welcome screen.
Click Add to select the group to which you want to give access.
Click Next to continue.
Under Delegate Control Of, choose Only the Following Objects in the Folder.
Check Users Objects and click Next.
Uncheck the Property-Specific check box.
Under Permissions, check Read and Write Phone and Mail Options, as shown in Figure 6.9, and click Next.
Click Finish to finalize the changes.
The possible variations are enormous, but the concept is sound. Active Directory’s capability to delegate administrative functionality to this degree of granularity is one of the major advantages inherent in Windows Server 2003.
Administrators create group policies to limit users from performing certain tasks or to automatically set up specific functionality. For example, a group policy can be established to display a legal disclosure to all users who attempt to log in to a system, or it can be set up to limit access to the command prompt. Group policies can be set on Active Directory sites, domains, and OUs but can also be configured to apply specifically to groups as well. This functionality increases the domain designer’s flexibility to apply group policies.
As previously mentioned in this chapter, creating additional OUs simply to apply multiple group policies is not an efficient use of OU structure and can lead to overuse of OUs in general. Rather, you can achieve a more straightforward approach to group policies by applying them directly to groups of users. The following procedure illustrates how you can apply a specific group policy at the domain level but enact it only on a specific group:
In Active Directory Users and Computers, right-click the domain name and choose Properties.
Select the Group Policy tab.
Select the group policy that you want to apply to a group and click the Properties button.
Select the Security tab.
Uncheck the Read and the Apply Group Policy check boxes from the Authenticated Users Group, if it exists.
Click the Add button to select a group to apply the policy to.
Type the name of the group into the text box and click OK.
Select the group you just added and check the boxes for Read and Apply Group Policy, as shown in Figure 6.10.
Repeat steps 6–8 for any additional groups to apply the policy.
Click OK and then Close to save the changes.
Repeat steps 1–10 for any additional group policies.
This concept of applying a specific group policy at the domain level but enacting it at a specific group in and of itself can reduce the number of unnecessary OUs in an environment and help to simplify administration. In addition, group policy enforcement becomes easier to troubleshoot as complex OU structures need not be scrutinized.
As with organizational unit design, it is best to simplify your group structure to avoid unnecessary administrative overhead. Establishing a set policy on how to deal with groups and which groups can be created will help to manage large groups of users more effectively and help troubleshoot security more effectively.
Group use can be simplified by remembering a simple formula: Use domain local groups to control access to resources and use global groups to organize similar groups of users. When this is done, the global groups created are then applied to the domain local groups as members, allowing those users permissions to those resources and limiting the effect that replication has on an environment.
To illustrate this type of use, consider the example shown in Figure 6.11. Users in the Marketing and Finance departments need access to the same shared printer on the network. Two global groups named Marketing and Finance, respectively, were created and all user accounts from each respective group were added. A single domain local group called Printer1 was created and granted sole access to the shared printer. The Marketing and Finance groups were then added as members of the Printer1 group. This simple formula works on a much larger scale as well and has been found to be best practice for effective use of groups without major replication concerns.
The concept of the universal group is also coming of age in Windows Server 2003. Now that the replication issue has been solved through incremental membership replication, it is more likely that this form of group will be possible in an environment. When necessary, a universal group can take the place of global groups or can potentially include global groups as members. Universal groups are most useful in consolidating group membership across domain boundaries, and this should be their primary function if utilized in Windows Server 2003.
Note
Even though universal groups can exist only in Native mode domains, they can theoretically include members from other Mixed mode domains in a forest. This is not recommended, however, because it makes troubleshooting access problems much more difficult. Since members from other domains cannot have an SID of the universal group added to their access token, a Mixed mode domain object is added as a link in a universal group, not as a direct object.
As with all objects in Active Directory, a group should be easily identifiable so that there is less ambiguity for both end users and administrators. Consequently, it is important to establish some form of naming convention for all groups to have and to communicate those naming conventions to the administrators who will create those groups. Using such conventions will help to alleviate headaches involved with determining what a certain group is used for, who owns it, and similar issues.
Groups can be nested, or included as members in other groups, to easily add multiple members of known groups as members of other groups. This added flexibility reduces the total number of groups necessary and helps to reduce administrative overhead.
If required by your organization, distribution groups can be set up to allow for SMTP mail to be sent to multiple recipients. Bear in mind that these groups do not have SIDs associated with them and consequently cannot be used for security permission assignments. In reality, it is rare that distribution groups will be designed in an organization that is not running Exchange 2000/2003. However, understanding their role and potential is important in determining proper group design.
Although the possibilities for OU and group design are virtually unlimited, often the same designs unfold because business needs are similar for many organizations. Over time, three distinctive models that influence OU and group design have emerged. The first model is based on a business function design, where varying departments dictate the existence of OUs and groups. The second model is geographical based, where remote sites are granted separate OUs and groups.
CompanyA is a clothing manufacturer based in St. Louis, Missouri. Facilities for the company are limited to a small group of locations in Dayton that are connected by T1 lines. A central IT department directly manages approximately 50% of the computer infrastructure within the company. The rest of the company is remotely managed by the following independent groups within the company:
Sales
Manufacturing
Design
Management
Historically, there have been five NT domains within the organization, as shown in Figure 6.12. Each domain was created to give each department autonomy and administrative control over its own environment.
The NT domains were connected via two-way trusts and were named as follows:
IT_NT
SALES_NT
MANUF_NT
DESIG_NT
MNGMT_NT
Although the culture of the company revolves around this decentralized business approach, the IT department wanted to consolidate these domains into a single AD domain, while at the same time preserving the administrative autonomy that the various departments had with the old environment. The result was a single Active Directory domain named companya.com that used five separate OUs, one for each department, similar to the structure shown in Figure 6.13.
To create this structure, the resource domains were collapsed into the single AD domain with the use of the Active Directory Migration Tool (ADMTv2). For more detailed analysis of this procedure, see Chapters 16, “Migrating from Windows NT4 to Windows Server 2003,” and 17, “Migrating from Windows 2000 to Windows Server 2003.”
Administrative rights were assigned to each OU by creating special global groups whose members included the local administrators for each department, as displayed in Figure 6.14. These groups were then delegated password change, user creation/deletion, and other typical administrative capabilities on their respective department’s OUs through use of the Delegation of Control Wizard (see the “Using OUs to Delegate Administration” section earlier in this chapter).
A group structure was created with five separate global groups that contained users from each department. The global groups were named as follows:
IT Global
Sales Global
Manufacturing Global
Design Global
Management Global
Resources were assigned domain local groups that followed a standard naming scheme, such as that represented in the following examples:
Security rights for all resources were then given to the appropriate domain local groups that were set up. The global groups were added as members to those groups as appropriate. For example, the printer named Printer3 was physically located in an area between both the Design and the Sales departments. It was determined that this printer should be accessible from both groups. Consequently, printing access was given to the Printer3 DL group, and both the Design Global and Sales Global groups were added as members to the Printer3 DL group, as shown in Figure 6.15.
This type of resource security allowed for the greatest amount of flexibility and reduced the replication of group membership needed in the domain. If, at a later time, the decision is made to allow the IT department to print off Printer3 as well, simply adding the IT Global group into the Printer3 DL group will do the trick. This flexibility is the main goal of this type of design.
As was the case with the business function–based design model, domain structures can easily be tailored to the needs of organizations with geographically dispersed locations, each with its own sets of administrators. It is important to understand that simply having sites in remote locations does not immediately warrant creation of an OU for each site. Some type of special local administration is required in those remote sites before OU creation should be considered.
Keeping this point in mind, consider the example of CompanyB. It is an international semiconductor producer that is centralized in Sacramento, California, but has worldwide remote branches in Malaysia, Costa Rica, Tokyo, Australia, Berlin, and Kiev, as shown in Figure 6.16.
Administration takes place on a continent-by-continent basis. In other words, Berlin and Kiev are both managed by the same team, and Tokyo and Malaysia use the same administrators. Australia administers its own users, as does Costa Rica.
The AD designers at CompanyB determined that the local administrative requirements of the branch offices were best served through the creation of OUs for each administrative region. A Europe OU was created for users in Berlin and Kiev, and an Asia OU was created for Tokyo and Malaysia. The three other sites were given individual OUs, as shown in Figure 6.17.
Domain local groups were created to grant access to each OU on a resource basis. For example, a domain local group named Europe OU DL was created for application of security to the Europe organizational unit. To apply this security, the Delegation of Control Wizard was run on each OU, and each corresponding domain local group was granted Administrative access to its own respective OUs.
Membership in the domain local groups was only the first step for allowing CompanyB’s administrators to manage their own environments. Global groups were created for each IT team, corresponding with their physical location. For example, Berlin IT Admins Global and Kiev IT Admins Global groups were created, and each IT admin user account for the remote locations was added as a member of its respective groups. The two global groups were then added as members of the Europe OU DL domain local group, as shown in Figure 6.18. The same process was applied to the other OUs in the organization. This solution allowed for the greatest degree of administrative flexibility when dealing with permissions set on the OUs.
Each administrative team was consequently granted a broad range of administrative powers over its own environment, allowing each team to create users, change passwords, and effectively administer its own environments without the need for broad, sweeping administrative powers over the entire domain.
The added advantage of this design is that it is completely flexible, and administrative control can be re-delegated on the fly, so to speak. For example, if a branch office opens in Paris, and IT administrators in that location need to have equivalent administrative control over the Europe OU, a simple global group can be created and added as a member to the Europe OU DL domain local group. Removing permissions is subsequently straightforward. In addition, entire OU memberships can effectively be collapsed into a different OU structure, as required by the changing needs of different organizations.
Without some form of logical organization of users within your network environment, chaos reigns and administration grinds to a halt. Administrators need some way to lasso groups of users together into logically identifiable groupings so that changes, security privileges, and administration can be accomplished en masse. Active Directory was specifically designed to be extremely scalable in regards to administrative functionality, and the flexibility of OU and group design is a testament to this strength. Proper design of both OU and group structure will go a long way toward helping gain control and reduce overhead in a domain environment.
Move your user and computer objects into an OU structure, as opposed to the default Users and Computers containers.
Keep the OU structure as simple as possible.
Do not nest OUs more than 10 layers deep, and preferably keep them less than 3 layers deep, if possible.
Keep the number of OUs to a minimum, and use them only when necessary.
Apply Group Policy to members of groups through Group Policy Membership Filtering where possible.
Use domain local groups to control access to resources, and use global groups to organize similar groups of users.
Use distribution groups or mail-enabled security groups to create email distribution lists in environments with Exchange 2000/2003.
Mail-enable security groups if separation of security and email functionality is not required.
Don’t simply delete and re-create groups on the fly because each group SID is unique.
Don’t include users from other Mixed mode domains in a forest in universal groups.
Don’t use local groups for permissions in a domain environment.