Lesson 1: Designing Microsoft Windows 2000 Security Groups
When designing your network's security, consider how you must deploy groups to assist in providing access to network resources. Your choice of security group type and scope will determine your network's security and manageability levels.
After this lesson, you will be able to
- Determine the best strategies for creating custom groups in Windows 2000 to provide secure access to Windows 2000 resources
Estimated lesson time: 30 minutes
Windows 2000 Groups
In a Windows 2000 network, access to network resources is authorized through the inspection of the user Security Identifier (SID) and any group SIDs for the user account. To allow auditing of security access and to simplify the administration of network resources, use groups when you design security assignments.
When you create a custom group, you must define the group type and the group scope for the custom group, as shown in Figure 5.2.
Figure 5.2 Configuring the group scope and group type for a new group
NOTE
While it's critical to select the proper group scope and group type for a newly created group, you may change these properties once a group has been created. Of course, this is subject to the rules of membership for the group scope.
Windows 2000 Group Types
You can define two different types of Windows 2000 groups: security groups and distribution groups. Use security groups for entries in discretionary access control lists (DACLs) and system access control lists (SACLs) to define security and auditing settings for an object. Membership in a security group provides the equivalent rights and permissions assigned to that group. Use distribution groups for such applications as e-mail distribution lists. When an access token is built for a user, security group SIDs are included in the access token but distribution group memberships are ignored. If a group's purpose is to define security for a resources, always make sure that you define the group type to be security.
Do Distribution Groups Have SIDs?
Yes. Even though you can't assign a distribution group permissions to an object, you can still convert the distribution group into a security group in Active Directory Users And Computers. Because you can convert group types, SIDs are automatically assigned to newly created distribution groups in case they are converted to security groups.
You can identify the SID of a distribution group by using the Active Directory Administration Tool (Ldp.exe) that's included with the Windows 2000 Support Tools. This tool allows you to bind to Active Directory and query objects in Active Directory by issuing Lightweight Directory Access Protocol (LDAP) commands. Figure 5.3 shows the details of the Distribution Group named OfficeMail.
Figure 5.3 Distribution groups with SIDs
Note that the OfficeMail distribution group has been assigned the SID S-15-1C6DFF84-64D5D18F-8078A22-46D.
Windows 2000 Group Scopes
Once you've selected the group type, you must set the scope for the group. The scope defines where the group can be used, where the membership of the group is maintained, and how the group can be used.
NOTE
By implementing native mode in a Windows 2000 domain, you increase your options for setting security group scopes. Mixed-mode domains may contain Windows NT backup domain controllers (BDCs) that limit the types of groups you can create because they don't recognize the newer Windows 2000 scopes (domain local and universal groups) and don't recognize new functionality, such as nesting global groups within other global groups. (Unless otherwise noted, "Windows NT" refers to versions 3.51 and 4.0.)
When Windows 2000 Active Directory is configured to run in native mode, you can select four group scopes for a Windows 2000 group. These are
- Domain local groups. Use domain local groups to grant permissions to resources. You can use a domain local group on any computer that's a member of the domain in native mode. The advantage of using domain local groups for permission assignments is that a domain local group may contain groups from other domains in its membership. This allows you to simply add new groups to the existing domain local group instead of modifying the DACL to provide additional users or groups access to the resource. Membership of domain local groups is maintained in the domain where the domain local group exists.
NOTE
In a mixed-mode environment, domain local groups can only be used on domain controllers (DCs), much like local groups in a Windows NT environment. - Global groups. Use global groups to combine users (and other global groups) who have similar business requirements. For example, it's common to create global groups for each department or project team within an organization. Instead of assigning permissions directly to a global group, make the global group a member of a domain local group so that members of that global group inherit the permissions assigned to the domain local group. Global groups may only contain user accounts and global groups from the same domain as members. Membership of global groups is maintained in the domain where the domain local group exists.
- Universal groups. Use universal groups to collect similar groups that exist in multiple domains. The key difference between universal groups and other security groups is that memberships are stored both in the domain where the universal group exists and in the global catalog. If the membership is stored in the global catalog, membership can be verified without contacting a DC where the universal group is defined. Storing membership in the global catalog may also be a disadvantage because any change to universal group membership will result in modification and replication of the global catalog. Instead of assigning permissions directly to a universal group, make the universal groups members of domain local groups and assign the necessary permissions to the domain local group.
TIP
To reduce the replication traffic associated with changes in universal group membership, assign global groups as members of the universal group instead of as user accounts. This way, you can modify the membership within the composite global groups without adding or removing global groups from within the universal group. - Computer local groups. Windows 2000–based computers that aren't DCs maintain their own user accounts database. Within these databases, you can create computer local groups to define permissions for resources stored at that computer. Computer local groups aren't shared between computers; you must define them at each computer where they must exist.
Assessing Group Usage
When designing your network's security, consider how you will assign permissions to resources. This process includes the creation of custom groups to provide the permissions to protect these resources.
To create the necessary groups, you must understand the way you can set group memberships. Table 5.1 outlines the memberships that are allowed within groups.
Table 5.1 Group Membership in a Windows 2000 Domain
| Group Scope | Mixed Mode Membership | Native Mode Membership |
|---|---|---|
| Domain Local | User accounts from any domain Global groups from any domain | User accounts from any domain Global groups from any domain Universal groups from any domain Domain local groups from the same domain |
| Global | User accounts from the same domain | User accounts from the same domain Global groups from the same domain |
| Universal | N/A | User accounts from any domain Global groups from any domain Universal groups from any domain |
| Computer Local | Local user accounts Domain user accounts from any domain Global groups from any domain | User accounts from any domain Global groups from any domain |
The next step is to design a methodology of using groups to provide access to resources on the network. As Table 5.1 shows, it's possible to place user accounts into each of the four group types. While it's possible, however, it's often not desirable because doing so can lead to difficulties in determining the correct group membership.
One of the more common strategies, known as A-G-DL-P, is shown in Figure 5.4.
Figure 5.4 Assigning permissions by using A-G-DL-P
In this strategy you place accounts only into global groups to simplify administration. In native mode, global groups may also have other global groups as members. You then make these global groups members of a domain local group, which may be a member of additional domain local groups. You assign permissions to the domain local group. The permissions assigned affect all members of the domain local group.
TIP
You most often use A-G-DL-P in a forest that has a single domain. You don't need to use universal groups if the forest has only a single domain.
The A-G-DL-P strategy simplifies the troubleshooting of permissions because you only have to inspect domain local groups. Within any listing of Access Control Entries (ACEs), there should only be domain local groups.
Another strategy you can use in a Windows 2000 native domain is to integrate universal groups into the assignment of permissions, as shown in Figure 5.5.
Figure 5.5 Assigning permissions by using A-G-U-DL-P
As in the previous strategy, you assign users only to global groups, which can be made members of other global groups. The difference with this methodology is that you can collect global groups from multiple domains into a single universal group. You then add the universal group as a member of a domain local group. Finally, you assign the domain local group permissions to the object to which it requires access.
The key to this strategy is to have only global groups and other universal groups as the membership of a universal group. By not placing user accounts directly into the universal group, you can minimize changes to group membership of the universal group and subsequent changes to the global catalog. By reducing the changes in membership of the universal group, you then reduce replication traffic related to global catalog replication.
You must determine the appropriate methodology for protecting each resource. When a resource requires multiple levels of access, the result is the creation or usage of multiple groups.
Making the Decision
When you design custom groups to provide access to Windows 2000 resources, consider the following criteria:
- Determine if an existing group meets your requirements. Over time, several custom groups will be created within your Windows 2000 forest. You should always determine if you can use an existing group to secure the new resource on the network, rather than creating a group that duplicates functionality on the network.
- Define what purpose the group will serve. Defining the purpose of the group helps determine the appropriate group type and group scope. For example, if the group will be used to assign permissions to a resource, the group must be a security group and not a distribution group. If the group must cross domain boundaries, you can't set the group scope to domain local.
- Determine if additional groups are required. If you're using A-G-DL-P or A-G-U-DL-P, you probably have to create more than one group. Determine all required groups so that you're optimizing network traffic and following your permission assignment strategy.
- Don't assign excess permissions. Never assign permissions that would allow users to intentionally or accidentally perform an undesirable task. For example, if the members of the domain local group require only the ability to read a document, don't provide them with permissions that could allow them to delete or modify it.
NOTE
For additional information on assigning permissions to file resources, see Chapter 6, "Securing File Resources." - Document the new groups. Be sure to document the group's name, the initial group membership, memberships of the new group in other groups, and what purpose the group serves. By including the purpose of the group, you may avoid the creation of groups that duplicate the functionality of existing groups.
Applying the Decision
Based on the scenario, Hanson Brothers needs to make the following decisions for the deployment of Exchange Server and the creation of custom security groups:
- Determine existing groups. Hanson Brothers requires custom groups to be created for the deployment of the Outlook 2000 client software. No default group has the necessary access permissions required for the distribution share, "Outlook 2000," on the software server, so you must deploy custom security groups.
- Determine the number of groups using A-G-DL-P. If Hanson Brothers uses A-G-DL-P to create security groups, you must create the groups shown in Table 5.2 to meet the requirements for the deployment of the Outlook 2000 software.
Table 5.2 Groups Required to Deploy Outlook 2000 Using A-G-DL-P
Group Name Group Scope Membership Corporate\OutlookUsers Global Group All users who require the Outlook 2000 software at the Warroad, Calgary, or Boise offices Quebec\OutlookUsers Global Group All users who require the Outlook 2000 software at the Hull office Corporate\OutlookAdmins Global Group All Outlook administrators who need to configure the Outlook 2000 client software Corporate\OutlookRead Domain Local Group Corporate\OutlookUsers
Quebec\OutlookUsers
Corporate\OutlookWrite Domain Local Group Corporate\OutlookAdmins - Determine the number of groups using A-G-U-DL-P. If Hanson Brothers uses A-G-U-DL-P to create security groups, you must create the groups shown in Table 5.3 to meet the requirements for the deployment of the Outlook 2000 software.
Table 5.3 Groups Required to Deploy Outlook 2000 Using A-G-U-DL-P
Group Name Group Scope Membership Corporate\OutlookUsers Global Group All users who require the Outlook 2000 software at the Warroad, Calgary, or Boise offices Quebec\OutlookUsers Global Group All users who require the Outlook 2000 software at the Hull office Corporate\Outlook Universal Group Corporate\OutlookUsers
Quebec\OutlookUsers
Corporate\OutlookAdmins Global Group All Outlook administrators who need to configure the Outlook 2000 client software Corporate\OutlookRead Domain Local Group Corporate\Outlook Corporate\OutlookWrite Domain Local Group Corporate\OutlookAdmins - Choose a methodology. Either methodology will work for the deployment of the Outlook 2000 software for Hanson Brothers. The best decision may depend on the company's growth. If they don't expect much more growth, A-G-DL-P will meet their security needs and won't require additional security groups to be created. A-G-DL-U-P is more beneficial if you can foresee the use of the Outlook universal group for additional security assignments. Rather than having to add the OutlookUsers global groups from each domain to a Domain Local group, you can simply add the single universal group, Outlook, to the Domain Local group.
- Document the newly created groups. After you've created all the groups, you must document why the group was created, the initial membership of the group, and any permissions assigned directly to the groups.
Lesson Summary
To design Windows 2000 security group memberships, you must know how security groups can interact with each other. When designing security group memberships, determine the methodology that your organization will use for assigning permissions to resources. Typically, the decision comes down to A-G-DL-P or A-G-U-DL-P. You'll make that decision based on the number of domains in your organization, whether the domains are in native mode, and the amount of replication traffic related to universal group membership changes.
EAN: 2147483647
Pages: 172