<p>Designing a Resource Authorization Strategy</p><p>C H A P T E R 1 5 Authenticated users need access to shared resources such as file shares and printers. An authorization </p><p> strategy based on security groups enables you to effectively manage users’ access to these resources. To create a resource authorization strategy, you need to decide what types of security groups to use and plan how to manage and maintain these groups. In This Chapter Overview of Designing a Resource Authorization Strategy...... 704 Establishing a Resource Authorization Method...... 708 Defining Policies for Security Group Management...... 714 Delegating Security Group Maintenance...... 724 Additional Resources...... 727 Related Information  For more information about domain and forest functional levels, see “Enabling Advanced Active Directory Features” in this book and the Directory Services Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Directory Services Guide on the Web at http://www.microsoft.com/reskit).  For more information about authentication, see “Designing an Authentication Strategy” in this book and the Distributed Services Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). 192 Chapter 15 Designing a Resource Authorization Strategy</p><p> For more information about authorization and access control, see the Distributed Services Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). Additional Resources 193 Overview of Designing a Resource Authorization Strategy How you choose to give and manage appropriate access to individual users and groups of users is the key to your resource authorization strategy. Logging on does not automatically give users access to the resources they require. Users must be authorized to access specific resources, but only at the level of access they need. Moreover, many users have identical needs for access to a network resource. For example, all users in the accounting department might need access to a specific color printer, so you can easily manage access by putting every member of the accounting department into a security group that is authorized to access that printer. Because security groups are so critical to efficiently controlling access, they form the main component of your authorization strategy. Consequently, you need to know what security group types are available and how they should be used. Before you design a resource authorization strategy, you also need to be familiar with trust relationships, domain and forest functional levels, and basic security principles. By applying this information appropriately for your organization, you can design a resource authorization strategy that is scalable, easy to maintain, and cost-effective. 194 Chapter 15 Designing a Resource Authorization Strategy</p><p>Process for Designing a Resource Authorization Strategy Designing a resource authorization strategy involves selecting the best resource authorization method or methods for your environment. You must also consider and implement policies for security group management that determine who is allowed to create security groups, how security groups are named, how they can be nested, and how they are administered. Figure 15.1 shows the process for designing a resource authorization strategy. Figure 15.1 Designing a Resource Authorization Strategy Additional Resources 195</p><p>Background Information for Designing a Resource Authorization Strategy Before you design your resource authorization strategy, it is important that you understand security group types and scope, domain and forest functional levels, group nesting, and trust relationships between domains and forests. Security Groups Security groups are used to combine user accounts, computer accounts, and other groups of accounts into manageable units. Rights or permissions are then assigned to the security groups, rather than to individual accounts. Security groups are classified according to scope. In the Microsoft® Windows® Server 2003 operating system, these scopes include:  Local  Domain local  Global  Universal It is important that you understand group scopes and how these groups can be used before you design your resource authorization strategy. For more information about group scope and group usage, see the following topics in Help and Support Center for Windows Server 2003:  Group types  Group scope  Understanding Local Users and Groups  Where groups can be created  Nesting groups  Accessing resources across domains For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only checkbox. 196 Chapter 15 Designing a Resource Authorization Strategy</p><p>Domain and Forest Functional Levels The security group options that are available depend on the domain and forest functional levels at which your organization is operating. For example, if your domain is operating at the Microsoft® Windows® 2000 mixed functional level, then you can only add global groups to local groups. However, if your domain is operating at the Windows Server 2003 functional level, you can nest global groups within other global groups, giving you much greater flexibility in managing your security groups. If your forest is operating at the Windows Server 2003 functional level, you can also enable cross-forest trusts. These two-way trusts enable you to authorize users to access resources across forests. You can also enable external trusts between single domains in different forests. For more information about domain and forest functional levels, group nesting, domain trusts, and cross- forest trusts, see the following topics in Help and Support Center for Windows Server 2003:  Domain and forest functionality  Nesting groups  Understanding trusts Terms and Definitions It is important to be familiar with the following terms as you design your resource authorization strategy. Account Group An account group is a security group whose members are user or computer accounts, all of which require the same permissions for a resource. Resource Group A resource group is a security group that has been added to the access control list (ACL) of a resource and granted a specific set of access permissions. Principle of Least The principle of least access states that users must have access to the software, data, and devicesAcces required to perform their daily duties, but must not have access to local or network resources that are not required for their job tasks. This minimizes potential security risks. Additional Resources 197 Establishing a Resource Authorization Method You can select one of three resource authorization methods to enable users to access shared resources in your organization. It is important to select the method that is the most appropriate for your environment and for the specific resource. Figure 15.2 shows the steps in this process. Figure 15.2 Establishing a Resource Authorization Method</p><p>Selecting a Resource Authorization Method Depending on the resource and the needs of your organization, you can choose to apply any or all of the following authorization methods to enable access to shared resources:  User/ACL method  Account Group/ACL (AG/ACL) method  Account Group/Resource Group (AG/RG) method  Role-based authorization 198 Chapter 15 Designing a Resource Authorization Strategy</p><p>User/ACL Method In the user/ACL method, the resource owner adds security principal accounts directly to the resource ACL. For example, Bob creates a file share and adds Alice as an authorized user, giving her read-only permission to the share. Individual resource owners often use this method. Adding individual user accounts to individual resource ACLs might work for small organizations with few users and minimal resources. However, this approach does not scale well and is impractical for larger organizations. Adding a large number of users to a large number of ACLs creates the following problems:  Access to resources is inconsistent from one user to the next. For example, one engineer might have access to a laser printer, a plotter, a backup device, and many file shares. Another engineer in the same group might need access to the same resources, but have access to only a subset of those resources.  The IT staff must handle a large volume of requests for updated or corrected access. In the previous example, Alice, the engineer who does not have sufficient access, might send individual requests to the IT group as she discovers that access to various resources is denied to her.  There is no way to know which resources a specific user has access to without extensive tracking, and, therefore, permissions cannot be easily revoked when a user changes positions or leaves the organization.  In very large organizations, unmanaged security descriptors waste disk space. In most environments, it is better to use the AG/ACL or AG/RG methods rather than the limited user/ACL method. The general guideline is to assign permissions to groups, rather than to individual accounts. However, if a resource is sensitive for security reasons, it might be advisable to assign permissions to individual accounts.. For instance, suppose that you want to share a database of employee data and that you cannot control or easily determine which users belong to various account groups. In this case, rather than adding an account group to the database ACL or to the database’s resource group, you might choose to add specific users directly to the database ACL. This requires more maintenance, but security concerns might outweigh maintenance requirements. Additional Resources 199</p><p>AG/ACL Method In the Account Group/ACL (AG/ACL) method, security groups, rather than individual user accounts, are added to the resource ACL, and the group is given a set of access permissions. For example, Bob might grant the group Everyone access to his public file share. This method is more scalable and more easily maintained than the user/ACL method. Typically, domain users are added to various global groups when they join an organization. Members of these global groups usually have something in common. They might work in the same building or on the same team or they might have the same job function. Rather than adding individual accounts to a resource ACL, the resource owner simply gives the domain global group access permissions. When a user joins or leaves the organization and is thus added or deleted from domain security groups, she or he is granted or denied access to the resource without any modification of resource permissions. The AG/ACL method is scalable in that security groups can be nested if your domain is configured for Windows 2000 native or Windows Server 2003 functional level. Groups from multiple domains, or from multiple forests (if forest trusts are enabled) can be grouped together into one encompassing security group, and this security group can be added to the resource ACL. This method can scale without modification to the resource ACL, assuming that all the users require the same permissions. This method requires more administrative effort from the resource owner, however, if different groups require different access permissions. Some groups might require read-only access, while others might require read-write access or full access. In this case, each group must be added to the ACL separately, and access permissions must be granted to each group. Even more administrative effort from the resource owner is required if your domains are configured for Windows 2000 mixed functional level. At this functional level, group nesting is limited. Global groups can join only local groups, and global groups cannot be nested within other global groups. In this situation, neither the user/ACL nor the AG/ACL methods are typically acceptable. If your domains are all at either Windows 2000 native or Windows Server 2003 functional level and if group nesting is allowed by your group nesting policy, then you might use either the AG/ACL method or the AG/RG method. If you have many account groups that must be given different access permissions, then the AG/ACL method might be advisable, especially if account groups and the permissions they require change frequently. Using the AG/RG method requires that you create a different resource groups for each combination of special permissions. 200 Chapter 15 Designing a Resource Authorization Strategy</p><p>AG/RG Method In the Account Group/Resource Group (AG/RG) method, users with similar access requirements are grouped into account groups, and the account groups are added as members to a resource group that has been granted specific resource access permissions. The AG/RG method is often most appropriate for large organizations with many shared resources because it is scalable and maintainable in all environments, at all domain functional levels. For example, suppose Bob maintains a print server that controls 50 printers that are used by 5,000 engineers. Bob might use the AG/RG method in several ways, but for this example he creates a local group on the printer server called Color Printer-Mail Room and gives this resource group permission to print to this print server. The group of 50 engineers working on the second floor needs access to this printer, and they are all members of an account group called Second Floor Engineers. All Bob needs to do is add the Second Floor Engineers account group to the Color Printer-Mail Room resource group. All 50 engineers now have access to the printer. Bob can use the AG/RG method for all 50 printers. In this example, however, Bob could have used the AG/ACL method just as easily. The scalability of the AG/RG method is more apparent when Bob needs to add 25 different account groups to the printer. If he uses the AG/ACL method, he has to add 25 groups to the printer ACL and set permissions for each one. If he uses the AG/RG method, he only needs to add the account groups to the resource group. The AG/RG method is also appropriate if a group of related resources are being shared to multiple account groups. For example, Bob might have a group of printers that are all shared to the same account groups. Suppose all of the printers on the sixth floor are used by five separate accounting teams. Rather than creating a separate local group for each printer, Bob creates one domain local group called Sixth Floor Printers. He adds this same resource group to the ACL for each printer and assigns permission to print. Now he can add the five global groups containing the five accounting team members to Sixth Floor Printers, and all five account groups gain access to all the printers on the sixth floor. If a new accounting team is formed and needs access to the printer, an account group containing the accountants’ user accounts is added to the Sixth Floor Printers domain local group with no need to modify the ACLs of any printers. Applying the AG/RG method facilitates the process of revoking users’ access to one set of resources and granting them access to other resources. As users join, leave, or move within the organization, simply adding the user to or deleting the user from an account group allows or removes access to resources without the need to modify resource ACLs. For example, if engineers move to new offices on the third floor of their building, the resource owners can update printer access by removing the Engineering Users group from the Sixth Floor Printers group, and adding it to the Third Floor Printers group. In this way, all engineers receive immediate access to all of the printers near their new offices. Additional Resources 201</p><p>This method can be used in any environment. However, it is especially useful if your domains are at Windows 2000 mixed functional levels or if you need to share resources with Microsoft® Windows NT® 4.0 operating system domains. Without the ability to nest groups, it is easier to create a resource group with the appropriate permissions and to add account groups to the resource group rather than assigning individual permissions directly to each account group. The AG/RG method is also preferable if your resources require a stable set of common permissions. For example, a file share typically requires full permissions for very few people, read-write permission for more people, and read-only permission for most people. In this situation, you might create three resource groups, one for each of the three common access levels. Account groups can be added to each resource group as needed to grant the correct access level. The AG/RG method is also a good choice if you need to share groups of related resources that have the same access permissions, as described earlier in this section.</p><p>Role-based Authorization Role-based authorization uses scripts called authorization rules to enable users with similar roles to be authorized to perform predefined sets of tasks in specific applications. This allows fine-grained control over the mapping between access control and the structure and tasks performed in your organization. In order to take advantage of role-based authorization, however, applications must be written to take advantage of this capability. In addition, the organization’s Active Directory® directory service must be at the Windows Server 2003 domain functional level. For more information about role-based authorization, see “Authorization Manager and role–based administration overview” in Help and Support Center for Windows Server 2003; also see “Role-based Access Control” in the Microsoft® Platform Software Development Kit (SDK). Selecting Local Groups or Domain Local Groups as Resource Groups In both the AG/ACL and the AG/RG methods, you can select as resource groups either local groups on the computer that controls the resource or domain local groups in the computer’s domain. This choice is typically relevant for administrators who manage network resources. If Bob shares a printer, he might create a local group to act as the resource group rather than ask a domain administrator to create a domain local group and grant him permission to manage it. Network resource managers, however, can choose either type of group as a resource group. 202 Chapter 15 Designing a Resource Authorization Strategy</p><p>One advantage of using domain local groups as resource groups is that domain local groups can be managed anywhere in the domain. Creating local groups requires the resource manager to access the specific computer where the local group is to be created. Another advantage of using domain local groups as resource groups is that domain local groups are visible in Active Directory. Assuming that the domain local group is named in a meaningful way, it is relatively easy to locate the resource group and modify it to add or remove account groups. However, there are also significant disadvantages to using domain local groups as resource groups. For example, suppose Bob is managing a file server with 500 shares, each of which has three resource groups to define the three common access levels. If Bob uses domain local groups for the resource groups, 1,500 groups will be displayed in Active Directory Users and Groups in the Microsoft Management Console (MMC). Furthermore, suppose that Bob has 50 file servers. Even with a meaningful group naming policy, it is not going to be easy to find the right resource group among 75,000 group names. In this case, Bob is much more likely to choose local groups as resource groups. Another disadvantage of using domain local groups as resource groups is the relative difficulty of group retirement. As resources are changed, moved, or retired, the resource groups associated with the resource also must be changed, moved, or retired. A resource manager is more likely to keep up with the management of local groups than of domain local groups that are managed by another administrator. The closer the resource groups are to the actual resource, the more likely they are to be maintained or retired properly. Security access token size also can be an issue if users are members of too many groups. A user’s access token is built primarily from the security identifiers (SIDs) of the groups to which the user belongs. The default maximum token size for the Microsoft® Windows XP Professional operating system and Windows Server 2003 is 12,000 bytes. This token size enables users to belong to approximately 120 groups. If a user belongs to more than 120 groups, the buffer allocated for the user’s token is exceeded. The result is that the user is unable to log on to the network or is otherwise denied access to network resources. The maximum token size can be modified if necessary. With token-size modification, users can successfully belong to hundreds of groups. If you choose to use domain local groups as resource groups, token size issues are more likely to arise than if you use local groups on the computer where the resource is shared.</p><p>Note For more information about token size and default group membership limits, see article Q327825, “New Resolution for Problems That Occur When Users Belong to Many Groups” in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at www.microsoft.com/windows/reskits/webresources. Additional Resources 203 Defining Policies for Security Group Management Policies for security group management are a significant part of your resource authorization strategy. For example, you need to establish a policy defining who can create security groups and when they should be created. You also need policies for security group naming, security group nesting, and security group retirement. Figure 15.3 shows the tasks for defining security group policies.</p><p>Note For the purposes of this chapter, “security group policies” refers to policies for security group management and is not related to Group Policy or Group Policy objects. For more information about Group Policy, see “Designing a Group Policy Infrastructure” in Designing a Managed Environment of this kit, and see “Group Policy” in Help and Support Center for Windows Server 2003.</p><p>Figure 15.3 Defining Policies for Security Group Management 204 Chapter 15 Designing a Resource Authorization Strategy</p><p>Defining a Security Group Creation Policy You need to define which members of your organization are allowed to create new security groups, and you need to identify the process that they use to create new security groups. Delegating Security Group Creation Rights Windows Server 2003 does not place any constraints on the ability to delegate permission to create security groups. You can edit the ACL of any security group and give any user in the forest permission to update the group’s membership. This enables you to simplify the administration of groups in your organization. By default, members of the Domain Admins, Enterprise Admins, and Account Operators groups have the Create Group Objects and Delete Group Objects permission. If it is appropriate for Account Operators in your organization to be responsible for managing the creation of security groups, there is no need to delegate this ability to others. If there is a need for individuals other than members of the Administrators, Domain Admins, Enterprise Admins, or Account Operators groups to create security groups, you can delegate the ability to create and to delete new security groups within an organizational unit (OU) to individuals or groups in your organization. You might need to create a separate security group, such as Group Admins, and add the appropriate user accounts to this group. If the Group Admins have authority only within a single domain, this is a domain local group. For more information about delegating the right to create security groups by using the Active Directory Delegation Wizard, see “Delegating administration” in Help and Support Center for Windows Server 2003. Defining a Security Group Request Process You need to define a process by which requests for the creation of security groups are submitted and approved. Requiring users to submit requests for the creation of new security groups and approving those requests before the groups are created limits the unnecessary proliferation of security groups in your organization. A request for a new group should include the following information about the group:  Purpose and scope  Proposed membership  Relationship to other groups  Expected lifetime  Group owner Be sure that your IT staff keeps these requests on file or in a database as a source of information for various security maintenance tasks. This information is especially useful in identifying potentially obsolete groups. For more information about identifying obsolete security groups, see “Defining a Security Group Retirement Policy” later in this chapter. Additional Resources 205</p><p>Defining a Security Group Naming Policy Establishing a forest-wide or enterprise-wide naming convention for security groups helps to ensure that secure access control in your organization is not compromised. Without a universal naming convention, the potential for user error when adding or removing members and selecting the correct group increases substantially. For example, when adding or removing members to groups, users select from a list of all groups in the forest, but cannot view information about the groups, such as membership or scope. Groups with similar or cryptic names might be selected accidentally. The consequences of granting access to the wrong group can be serious, causing members to have access to restricted resources or to be denied access to resources that are necessary for job tasks. When establishing a security group naming convention for your organization, ensure that it does the following:  Provides for the inclusion of information about the group’s scope, purpose, and owner in its name and its description. This helps to differentiate each group from similar groups.  Conforms to a hierarchy of standard labels to be used in a fixed order, beginning with the most general labels and ending with the most specific labels. This allows group names to be sorted alphabetically into an organized list. In addition, consider the following when creating group names and descriptions:  Both the name and description of a security group can include up to 256 characters.  The first 20 characters of the name are usually visible in a list of security groups without resizing columns and scrolling. When viewing the Properties dialog box of the group, about 50 characters of the group name are viewable. You might want to abbreviate the organizational labels used in the group name to ensure that the distinguishing portion of the group name can be viewed in these environments. You can apply any naming strategy that works for your organization, as long as group names provide enough information to distinguish them from other groups. A common approach is to create a security group naming standard that organizes groups according to the business structure of your organization. In this way, group names are composed of labels that represent your company’s organization, such as division, department, team, and task. 206 Chapter 15 Designing a Resource Authorization Strategy</p><p>Without descriptive labels, it is possible to create confusing group names. Three divisions, for example, might have similar group names for their sales groups. If someone searches for the sales group, it is difficult to know if “Sales,” “Sales Group,” or “AllSales” is the correct group. Adding more organizationally descriptive labels can take time and planning, but user group searches and rights assignments are more accurate as a result. These labels are placed in order from most general to most specific, with the final label reflecting the purpose or content of the group, thus distinguishing the group name from similar names. For example, the following three group names represent different sales teams within the Avionics Division Sales Department of a corporation:  Avionics Sales GovtContracts  Avionics Sales RetailSales  Avionics Sales TeleSales Some organizations are based on domain membership. The following are examples of typical group names, where “Con” represents a domain in the fictional company “Contoso.”  Con-Sales-Clerical-Users  Con-Sales-Mgmt-Users  Con-Support-HelpDesk-Users  Con-Support-HelpDesk-Resources  Con-Support-Shipping-Users Some organizations are based on geographical location. The following group names might represent printer resources in the Boston and Seattle remote offices:  BOS-Printers-Floor3-Laser  BOS-Printers-Floor3-Color  SEA-Printers-Reception-Laser  SEA-Printers-Lab-LargeFormat An organized system for naming groups makes it easy to locate the correct security group, and helps protect against duplicate naming. Users can search for related groups by entering the first few letters of the group name in the Select Users, Contacts, Computers or Groups dialog box. For example, they can filter the list for “Avionics Sales” groups. Additional Resources 207</p><p>The list of group names in the Select Users, Contacts, Computers or Groups dialog box also displays each group’s description string. This added field can be used to include other attributes of the group, such as the group scope, the name of the person who maintains the group, and a brief statement of the group’s purpose. The following are examples of group descriptions:  Avionics Support HelpDesk Resources: Domain local resource group for help desk resource ACLs, maintained by Bjones x2344.  Avionics HumanRes AllUsers: Global account group of all human resources user accounts, maintained by Ssmith x9488.</p><p>Important Windows Server 2003 does not provide any software support for enforcing a naming standard. Establish your naming policy and communicate it to all employees in your organization who have been delegated the right to create security groups. Defining a Security Group Nesting Policy Security group nesting occurs when one security group is made a member of another security group, and the nested group inherits all of the privileges and permissions that are granted to the parent.</p><p>Note A domain must be configured at the Windows 2000 native or Windows Server 2003 functional level in order for global groups to be nested within global groups or for domain local groups to be nested within domain local groups.</p><p>Unrestrained group nesting can result in access token size problems because the token contains the SIDs for each group of which the user is a member, either directly or indirectly. The default group membership limitation is 120 groups. For more information about issues related to group membership and access token size, see “Selecting Local Groups or Domain Local Groups as Resource Groups” earlier in this chapter. Additionally, if group nesting is not constrained by a nesting policy, it becomes difficult to know exactly which permissions might be inherited by members of a security group that is nested within another, or several other, security groups. 208 Chapter 15 Designing a Resource Authorization Strategy</p><p>If your enterprise is organized according to the AG/RG model, you need to allow for some degree of nesting without allowing nested groups to proliferate. Design and follow an explicit nesting strategy so that nesting relationships among security groups are predefined and well understood. This helps to guard against including users in too many groups. If you choose to apply a security group nesting policy in your organization, consider drafting specific guidelines for that policy and communicating them to all employees who have permission to add members to a group. </p><p>Creating a Hierarchy of Nested Security Groups Nested groups allow you to provide company-wide or department-wide access to resources with minimum maintenance. Placing every team account group into a single company-wide resource group is not an effective solution because it requires the creation and maintenance of a large number of membership links. To use nested groups, administrators create a series of account groups that represent the managerial divisions of the company. The top account group might be called “All Employees,” and would be attached to a resource group that gives access to resources and shared directories. The next level might contain account groups that represent major divisions of the company. Each group at this level is a member of All Employees, and is attached to a resource group giving access to shares and other resources appropriate to the division it represents. Within a division, the next level of account groups might represent departments. Shared resources for the department might include project schedules, meeting schedules, vacation schedules, or any network information appropriate to the whole department. The department account groups are all members of the division account group. Within a department, the management structure can be organized into security groups to any required level of specificity. These might be team account groups, and might represent leaf nodes in the organization’s hierarchical tree. With this group hierarchy in place, you can give a new employee instant access to the resources of the team, the department, the division, and the company as a whole by placing him or her in a team account group. This system supports the principle of least access because the new employee cannot view the resources of adjacent teams, other departments, or other divisions. Figure 15.4 shows an example of the nested security group hierarchy for the Avionics Division group of an organization; the vertical arrows represent group membership. Additional Resources 209</p><p>Figure 15.4 Nested Account Group Hierarchy</p><p>Modifying a Nested Security Group Hierarchy The hierarchical structure of nested security groups gives the broadest access to users in the leaf nodes of the tree, the team account groups. You can modify the structure to allow department managers full access to all team resources, for example, or to allow the company’s CEO access to all company resources. Figure 15.5 shows how the nested security group hierarchy illustrated in Figure 15.4 might be modified to allow all managers full access to all team resources; the arrows represent group membership. 210 Chapter 15 Designing a Resource Authorization Strategy</p><p>Figure 15.5 Modified Nested Security Group Hierarchy</p><p>To support this type of access, you create another hierarchical series of account groups, with the membership links going in the opposite direction. For example, you might create a group called Avionics Sales Managers, and add the appropriate users to the group, then add this group to the membership of all Sales team account groups. In this way, the Avionics Sales Managers are able to view the files of all Avionics Sales teams. You can apply this model all the way up the organizational chart, giving the CEO complete access to every file in the forest. This approach, however, is problematic for two reasons. First, high-ranking executives are priority targets for attackers and do not need access to thousands of files scattered throughout the forest. An intruder who intercepts the password of the CEO can cause unlimited damage. Second, in a large organization this strategy can fill user access tokens with hundreds of group SIDs, leading to significant logon delays, denial of access to resources, or the inability to log on. For more information about issues related to group membership and access token size, see “Selecting Local Groups or Domain Local Groups as Resource Groups” earlier in this chapter. Additional Resources 211</p><p>Defining a Security Group Retirement Policy When security groups become obsolete due to personnel changes, project completion, or corporate reorganizations, they need to be identified and retired (deleted) to minimize security risks. This task usually falls to the organization’s IT department. It is important to create a policy for the retirement of security groups. In this policy, include procedures for:  Gathering information about security groups, especially information related to the expected lifetime of the group or the group’s renewal interval. For more information about sources for this information, see “Defining a Security Group Creation Policy” earlier in this chapter.  Identifying potentially obsolete security groups.  Deleting obsolete security groups from Active Directory. </p><p>Important Deleting a security group from Active Directory is non-reversible because access to resources is based on the group’s unique SID. If the wrong group is deleted, or if a group is deleted because it is thought to be obsolete when it is not, the IT department must create a new group in place of the deleted group and reintegrate it into the domain. Identifying Obsolete Security Groups Although account groups for very small teams might not change frequently, large account groups experience almost constant turnover in membership. If an account group’s membership has not changed at all for some time, the group might be obsolete. The Active Directory Users and Computers snap-in allows you to search for potentially obsolete groups by entering a Lightweight Directory Access Protocol (LDAP) query for a list of security groups whose definitions, including membership, have not changed since a specified date. A query in the format (&(objectCategory=group)(whenChanged<=YYYYMMDDHHMMSS.0Z)) returns groups that have not been modified past the specified date. For example, to query for groups that have not been modified since midnight on December 31, 2002 in Pacific Standard Time, the query is (&(objectCategory=group)(whenChanged<=20021231240000.0-8)). The last portion of the query (0-8) signifies the Pacific Standard time zone, which is eight hours less than Greenwich Mean Time. 212 Chapter 15 Designing a Resource Authorization Strategy</p><p>Note For more information about building LDAP queries and about generalized time, see the Windows Platform SDK link on the Web Resources page at www.microsoft.com/windows/reskits/webresources.</p><p>After you have identified groups whose membership has not changed for a period of time, you can verify the status of each group by querying the group owner, the group members, or the appropriate departmental administrators. Be sure to keep a record of your investigation for future reference. Resource groups typically become obsolete when the resource is no longer needed, perhaps because projects requiring the resource have ended or because the hardware resource is moved or retired. Because resource groups are often configured as local groups on the computer that controls the resource, identifying obsolete resource groups is often a task for the computer owner or the resource manager. Finding obsolete local groups configured as resource groups is more challenging than finding domain-based account groups. Computers controlling resources are typically not domain controllers, so Active Directory is not available, and LDAP queries for unmodified local groups are not possible. One approach is not to track local resource groups because local groups do not populate Active Directory. If your reason for identifying obsolete groups is to reduce the number of Active Directory objects, monitoring domain-based account and resource groups might be all that you require. Another approach is to document and create a database of shared network resources. Typically, this database would include information about corporate resources rather than file shares or similar resources shared from a user’s desktop, for instance. If the share type, location, owner, creation date, and any other relevant information are recorded, then periodic reviews can be conducted to verify that resources and their associated resource groups are needed or obsolete. Deleting Obsolete Security Groups When you have identified an obsolete group, you can disable it for a trial period before deleting it from your domain. You can disable a security group by changing it into a distribution group for a set period of time, such as two months. Changing a security group into a distribution group does not alter its SID, scope, or membership; however, it effectively disables all access provided by the group because SIDs of distribution groups are not included in a user’s access token. If you do not receive any notification that a user’s access permissions have changed after the established wait period has expired, you can safely delete the group. You must have the appropriate permissions to delete a security group. By default, Account Operators, Domain Admins, and Enterprise Admins have the ability to delete security groups. This permission can be granted to other individuals or administrative groups by editing the ACLs of OUs and containers.</p><p>Caution Group deletion is immediate and permanent. Limit the number of persons to whom you delegate the ability to delete groups. Additional Resources 213 Delegating Security Group Maintenance In large organizations, it is not possible for IT staff to be responsible for performing routine membership maintenance on large numbers of account groups, or to administer the ACLs and resource groups for resources in all departments. After a security group has been created and named, you can delegate the management of the group to other members or your organization. This can relieve the burden on your IT department. Figure 15.6 shows the tasks for delegating security group maintenance. Figure 15.6 Delegating Security Group Maintenance 214 Chapter 15 Designing a Resource Authorization Strategy</p><p>Identifying Individuals to Maintain Security Groups By delegating security group maintenance to the appropriate individuals, you can ensure that requests for changes in membership are evaluated by individuals who can judge the appropriateness of the request, have the authority to make the change, and are motivated to keep group membership and access permissions correct and up-to-date. Ideally, an employee who is familiar with the personnel, such as a department administrative assistant, is responsible for managing the membership of an account group. Because security groups in Windows Server 2003 can also be used as Microsoft® Exchange 2000 mailing lists, it is both convenient and cost- effective to have an individual maintain the account group for both purposes. This requires delegating read and write permissions for the group to the selected individual. It is recommended that resource owners set ACLs because they are best able to supervise access to the resource. For example, the file server operator who maintains a department’s shared directories is the logical candidate to be responsible for adding resource groups to the ACLs of the shares. Similarly, the person who is responsible for departmental printers is the best choice to manage the membership of the applicable printer resource groups. Delegating Account Group Maintenance To delegate permission to maintain account group memberships, you can apply the account group/resource group/admin group model, by which you extend the AG/RG model to accommodate a third kind of security group, the departmental admin group. Admin groups are usually domain local groups that consist of members of the local business unit, such as managers or trusted clerical workers. A departmental admin group has permission to manage the membership of the department’s security groups, and sometimes manages other department resources as well. The departmental admin group is added to the ACL of a business unit’s OU, or to the ACLs of the individual user and resource groups. Although the departmental admin group has permission to manage group membership, it cannot create and delete groups. Each department has its own departmental admin group with specific permission to change membership of the department’s account groups. Because membership in the departmental admin group gives a user the ability to add any forest user to departmental account groups, the departmental administrators must be highly trusted employees. Consequently, you also must carefully determine who controls the membership of the admin group itself. Allowing departmental administrators to self-administer their admin groups is a security risk, because such delegated authority can be misused. Relatively little effort is required to maintain the departmental admin groups, so it is more secure to have the central IT department administer them. In this way, the IT department can delegate account group maintenance to specific individuals in each department, and these assignments cannot be changed without IT participation. Additional Resources 215</p><p>Delegating Resource Group Maintenance In the AG/RG model, related resources are collected into resource groups, although the resources themselves are not members of the resource groups. Instead, the ACLs of the individual resources are edited to grant the resource group appropriate access, and then account groups are added as members of the resource group, which gives the members of the account group access to the resources. If you have adopted this model for your organization, you need to decide who sets the ACLs on the resources, and who controls the membership of the resource groups. In some cases, the departmental administrators (who maintain departmental account groups) have control over both the resources and resource groups in their departments. In large organizations, however, the departmental admin group can become overwhelmed with requests for resource access or with other resource management duties. One solution to this problem is to enable resource owners to control access to their resources. The resource owner has full knowledge of the resource and is motivated both to make the resource available to legitimate users and to protect it from unauthorized access. Resource owners have control over access to their resources by default in Windows Server 2003. For resource owners to have full control over access to their resources, they also must control the membership of the resource group. In this way, they control which account groups can become members of their resource groups. In some cases, you must delegate resource group maintenance to resource owners. To do so, you must establish that the resource owner is responsible for editing the ACLs of the resource in order to grant appropriate access to specific resource groups. By default, the owner of a file or directory, a Server Operator, a Domain Admin, or an Enterprise Admin has permission to edit the ACLs of a resource. You must also grant resource owners control over the membership of the resource groups (but not the right to create or delete the resource groups) that must access their resource. For more information about editing ACLs, see “” in Help and Support Center for Windows Server 2003. 216 Chapter 15 Designing a Resource Authorization Strategy Additional Resources These resources contain additional information related to this chapter. Related Information  The Directory Services Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Directory Services Guide on the Web at http://www.microsoft.com/reskit) for more information about Active Directory functional levels.  The Distributed Services Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit) for more information about authorization, access control, domain and forest trusts, and logon and authentication.  “Designing an Authentication Strategy” in this book.  “Enabling Advanced Active Directory Features” in this book.  The TechNet link on the Web Resources page at http://windows.microsoft.com/windows/reskits/webresources. Related Help Topics For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only checkbox.  “Group types”  “Group scope”  “Understanding Local Users and Groups”  “Where groups can be created”  “Nesting groups”  “Accessing resources across domains”  “Domain and forest functionality”  “Nesting groups”  “Understanding trusts”  “Authorization Manager and role–based administration overview” in or more information about role-based authorization.  “Group Policy” in Help and Support Center .  “Delegating administration” in Help and Support Center for more information about delegating the right to create security groups by using the Active Directory Delegation Wizard.  “Access control” in Help and Support Center for more information about editing ACLs. </p>