Determining Group Requirements for Resource Access

There are two group types within Active Directory: security and distribution. When creating a group, you will need to determine exactly what the group will be used for. Distribution groups are used for e-mail. An e-mail program such as Microsoft Exchange Server can use distribution groups as distribution lists once they have been mail-enabled. Security groups are used to grant the members of the group access to objects and resources. You will create security groups to allow users with the same resource access needs to be grouped together.

When using groups, you cannot assign access to resources using a distribution group; only a security group has that functionality. A security group can be mail-enabled, however, so the members of a security group can have access to resources and be members of a distribution list all at the same time. So why would you want to use a distribution group? Distribution group membership is not considered when a user logs on, so it does not affect the generation of the access token for resource access. If users need to be grouped together for the sole purpose of receiving the same mail messages, create a distribution group and add the user accounts to it.

Identifying User Access and Group Strategies

Just like the forests, domains, and OUs that we have been discussing, groups can be categorized as account groups and resource groups. Account groups are used to organize user accounts that need the same level of access to resources. Resource groups are used to grant access to a resource to the members of the account groups or user accounts that are added to the membership of the resource group. You can use one of three strategies when assigning permissions to accounts, and these two types of groups are used differently with each one.

Account/Discretionary Access Control List (A/DACL)

Using the account/discretionary access control list (A/DACL) strategy, user accounts are added directly to the DACL of the resource. Because groups are not used, the administrator will have to add the user s account to the DACL of every resource that the user needs to work with. In large organizations with several resources, the administrator may mistakenly omit an account from a resource s DACL, thus keeping the user from working effectively. This will also generate one of those nasty phone calls that we administrators love to receive.

When adding users directly to the DACL, the administrative staff who is responsible for maintaining user access to resources will have to document the permission assignment carefully . When a user leaves the company or moves to another position where they do not need to have access to the resources they formerly had, the account will have to be removed from each DACL individually. This can be time consuming, and if any DACLs were missed, the user could have access to resources they should not have access to.

Even though we are warning you against using the A/DACL strategy, there are times when it is a viable solution. Take, for instance, the scenario where the administrator of a resource wants to allow a user to have permission to access the resource, but not to view the membership of groups. If you are unsure of whether or not there are additional members of the group that should not have access to the resource, from a security standpoint, it may be best to add the individual user account to grant permissions.

Account Group/Discretionary Access Control List (AG/DACL)

The account group/discretionary access control list (AG/DACL) strategy allows groups to be created that will be used to organize user accounts that have the same resource access requirements. These account groups are then assigned permissions that let them access the resources by adding the group account to the DACL of the resource and then setting the appropriate permissions.

In some cases, this strategy may work very well. If a user account needs to have access to a resource, the account can be added to the account group. If the permissions need to be revoked from a user, their account can be removed from the group, thus stripping them of their ability to access the resource. Administrators only need to document the access granted to the groups and add or remove the user accounts to the membership of the group to control the user s access.

The proper AG/DACL strategies are as follows :

Accounts ”Local group ”permissions (ALP) This strategy uses Local groups to which permission are applied, and then adds the user s account to the membership of the Local group. Using this strategy, the administrator for a server could create the Local group and maintain the membership. The Local group is only on the local system, however, and is not an object within Active Directory, so the group can only be used on the server where it was created.

Accounts ”Domain Local group ”permissions (ADLP) This strategy uses the Domain Local group type, which is located in Active Directory. As with the Local group, the permissions are applied to the Domain Local group and users who need to access the resource are added to the group membership. In Native mode and higher functional levels, the domain local group can be used for accessing any resource within the domain; however, if the domain is in mixed mode, you can only use Domain Local groups for resources on the domain controllers.

Account ”Global group ”permissions (AGP) The Global group type is another Active Directory “based group. Permission to access resources can be granted to this group type and the users who need access to the resource are added to the group membership. The disadvantage to using this group type to assign permission to resources is that the membership can only include accounts from the domain in which the group resides. Accounts from other domains will have to be added to another group in order for it to have access.

Account Group/Resource Group (AG/RG)

Using the Account group/Resource group (AG/RG) strategy allows the administrative staff the most flexibility, but it is also the most time consuming, and sometimes the most confusing of the strategies. Plus, this strategy employs the most groups and may become unwieldy when you try to identify the proper groups to which you need to grant permission or add user accounts.

When you are using this strategy, the Resource group is added to the ACL and the proper level of permissions is applied. A Resource group is a group that you use to allow permission to objects. User accounts that need the same level of resource access are organized as members of the Account group . Account groups are used to organize users and other groups (in native mode and higher) that have the same resource access needs. Once the Account group is made a member of the Resource group, all of the members of the Account group are granted the proper level of access to the resource. Although this may seem like a simple concept here on paper, some mechanisms in Active Directory can cause confusion when you are designing the group strategy.

The first limitation is the functional level of the domains where the groups are needed. If a domain is not at the Windows 2000 Native mode or higher, you won t be able to use universal security groups. At first, this may not seem like such a drawback because you still have the ability to use Domain Local security and Global security groups, in a large forest. However, you will soon find that you may be performing too many group administration tasks . Universal groups can alleviate some of the group management you will have to perform.

Windows 2000 Native mode functional level or higher is also required for some of the security group nesting options. If you are not at one of these functional levels, Global security groups can only be made members of Local or Domain Local security groups. If the functional level has been raised for the domain to the Windows 2000 Native mode or Windows Server 2003 levels, then Global security groups can be made members of other Global security groups.

When using the AG/RG strategy, administrators have a choice of several nesting options. As mentioned earlier, which functional level the domain is at will dictate whether or not some of the nesting options are available. When implementing an AG/RG strategy, the groups with a scope of Global or Universal are considered account groups. Security groups with the scope of Domain Local or Local are considered Resource groups.

The AG/RG strategies are:

Accounts ”Global group ”Local group ”permissions (AGLP) All domains, even those in the mixed mode functional level are able to use the AGLP nesting strategy. As with all of the AG/RG strategies, the accounts that need access to the resource are added to the appropriate Global security group. As shown in Figure 7.3, the Local security group is added to the DACL of the resource and the proper permissions are specified. Once the Global group is added as a member of the Local security group, the user accounts that are members of the Global security group can then access any resources for which they have granted permissions to the Local security group.

Figure 7.3: Example of AGLP

Note	You still have the ability to use Universal Distribution groups within a Mixed mode domain. The limitation only applies to Universal security groups.

The limitation to this strategy is that the local account can only be accessed on the local machine. Local groups are not part of Active Directory and will not show up in Active Directory queries. For users to have control over Local groups, they will need to have administrative authority to the local system where the Local group resides.

Accounts ”Global group ”Domain Local group ”permissions (AGDLP) All domains, even those in the mixed mode functional level, are able to use the AGDLP nesting strategy. As with all of the AG/RG strategies, the accounts that need access to the resource are added to the Global security group. As shown in Figure 7.4, the Local security group is added to the ACL of the resource and the proper permissions are applied. Once the Global security group is added as a member of the Domain Local security group, the user accounts that are members of the Global security group are then given the permissions of the Local security group.

Figure 7.4: Example of AGDLP

Domain Local groups are part of Active Directory and will show up in Active Directory queries. Users can be delegated control to manage group accounts within Active Directory. Because these accounts are part of Active Directory, additional groups will appear in queries making it more confusing when you are trying to locate the proper groups.

Accounts ”Global group ”(Global group) ”Universal group ”Domain Local group ”permissions (AGUDLP) Universal security groups and the ability to nest Global security groups are only available when the domain is at the Windows 2000 Native mode functional level or higher. Once the domain is at one of these functional levels, you can use the AGUDLP nesting strategy. This strategy, as seen in Figure 7.5, is usually only employed when several domains are within the forest. Using this method, users are still made members of a Global group, and the Domain Local group is added to the DACL of the resource.

Figure 7.5: Example of AGUDLP

The benefit of using the Universal group comes from the fact that you can add many Global groups from any domain in the forest to the Universal group, which in turn is made a member of the Domain Local group. Now if another Global group from another domain needs access to resources, you can add that Global group to the membership of the Universal group, which will give the members of the Global group the access they need to all of the resources from all of the Domain Local groups of which the Universal group is a member.

Note	Using nesting, you could keep stacking the groups, such as AGGUDLP or AGGUDLDLP.

Real World Scenario ”Laid-Back Admin

Ron is an administrator in a large enterprise network. He is one of the administrators in charge of network printers; that are available to factory users. The print server that he manages contains 50 printers. 35 of the printers are located on the shop floor. They print reports and job details for the shop foremen. All foremen should be able to print to all printers on the shop floor so that they can print reports anywhere in the factory. Ten of the printers are located in the administration area and are available to all members of the administrative groups. 5 printers are defined for management only, and all 5 should be available to all members of the management groups.

Ron implemented an AG/RG. He created three printer groups: one called DL-ShopPrinters, one called DL-AdminPrinters, and one called DL-ManagementPrinters. He then added user account groups to these printer groups to define access to the printers. The DACL on each printer only has to be edited one time.

Recently, the company decided to implement a new application that the administration staff will use to send reports out to the foremen. Ron now needs to add the 10 users from the administration staff to all 35 printers.

Because Ron implemented an AG/RG authorization method, he simply added the account group that includes the user accounts of the administration staff to the DL-ShopPrinters resource group. All users from the administration staff instantly had access to all 35 printers located in the shop.

Identifying Group Creation Options

By default, members of the Domain Admins, Enterprise Admins, and Account Operators groups have the ability to create groups. In some cases, these groups will suffice. For instance, a centralized administrative group that is responsible for all account creation, user, and group accounts could have their accounts added to the Account Operators group and have the ability to perform their job.

There are occasions when this strategy will not suffice. The Account Operators group may have too many rights associated with it for the job responsibilities of users who need to maintain groups. Account Operators also allows user accounts to be created and maintained . If maintaining user accounts is a separate job responsibility from the users who maintain group accounts, you will have to create groups based on job functions.

The preferred method of delegating the ability to maintain group accounts is to create an OU in which the group accounts will reside. Then you should create a group that will be granted the ability to maintain group accounts. This group should reside in an OU other than the OU that the users manage. That will keep them from having the ability to change the functionality of their group. Once the OU and the group exists, run the Delegation of Control Wizard to assign the proper permissions to the group.

Design Scenario ”Designing Resource Access for the Forest

Carl has a large number of users who need to access a domain-based DFS root. All of the users are from throughout the two-tree, 12-domain Active Directory design he is working on. He wants to make the administration of the user access and group management as easy as possible.

Question: Which of the strategies should he employ ? Answer: Account Group/Resource Group (AG/RG).
Question: Which of the nesting options would make administration easiest for Carl? Answer: Accounts ”Global Group ”(Global Group) ”Universal Group ”Domain Local Group ”Permissions (AGUDLP).
Question: How is this nesting option implemented? Answer: Global groups from each domain are created and user accounts that have the same resource access needs are made members of the group. A Domain Local group is created. This Domain Local group is added to the ACL of the resource and the appropriate permissions are applied. A Universal group is created and added to the membership of the Domain Local group. The Global groups from all of the domains are added to the membership of the Universal group to complete the chain.

Tip
Make sure that you document your changes. There isn t a tell me what I did wizard or a take it back wizard .

The OU that you create to hold groups will really only be used to hold the groups and delegate permissions to those users who need to maintain them. GPOs do not affect groups; they only affect computers and users, so this OU will be for administrative purposes only.

After you have decided who will have permission to create and maintain the groups, make sure that those users understand the policies you have set forth concerning the naming conventions for groups. Other administrators will need to find the groups when adding them to the DDACL of the resources for which they maintain access. If the naming convention is followed, maintaining access to resources should be easy to control.

In the Designing Resource Access for the Forest Design Scenario, you will learn how to design a resource access for a forest.