Security Groups

[アーティクル]
07/18/2012

Windows 2000 allows you to organize users and other domain objects into groups for easy administration of access permissions. Defining your security groups is a major task for your distributed security plan.

The Windows 2000 security groups let you assign the same security permissions to large numbers of users in one operation. This ensures consistent security permissions across all members of a group. Using security groups to assign permissions means the access control on resources remains fairly static and easy to control and audit. Users who need access are added or removed from the appropriate security groups as needed, and the access control lists change infrequently.

How Security Groups Work

Windows 2000 Active Directory supports security groups and distribution groups. The security groups can have security permissions associated with them and can also function as mailing lists. The distribution groups are used for mailing lists only. They have no security function.

When you create a new user, you can add the user to an existing security group to completely define the user's permissions and access limits. Changing a permission for the group affects all users in the group. Windows 2000 comes with several predefined security groups, and it is easy to create your own.

Security Group Types

Windows 2000 supports four types of security groups, differentiated by scope:

Domain local groups are best used for granting access rights to resources such as file systems or printers that are located on any computer in the domain where common access permissions are required. The advantage of domain local groups used to protect resources is that members of the domain local groups can come from both inside the same domain and outside the domain. Typically, resource servers are in domains that have trust to one or more Master User Domains, or what are known as account domains (A domain local group can be used to grant access to resources on any computer only in native mode domains. In mixed mode, domain local groups must be on domain controllers only.)
Global groups are used for combining users who share a common access profile based on job function or business role. Typically, organizations use global groups for all groups where membership is expected to change frequently. These groups can only have as members user accounts defined in the same domain as the global group. Global groups can be nested to allow for overlapping access needs or to scale for very large group structures. The most convenient way to grant access to global groups is by making the global group a member of a resource group that is granted access permissions to a set of related project resources.
Universal groups are used in larger, multidomain organizations where there is a need to grant access to similar groups of accounts defined in multiple domains. It is better to use global groups as members of universal groups to reduce overall replication traffic from changes to universal group membership. Users can be added and removed from the corresponding global group within their account domains and a small number of global groups are the direct members of the universal group. Universal groups are easily granted access by making them a member of a domain local group used to grant access permissions to resources.
Universal groups are used only in multiple domain trees or forests that have a global catalog. A Windows 2000 domain must be in native mode to use universal groups. A domain model that has only a single domain does not need or support universal groups.
Computer local groups are security groups that are specific to a computer and are not recognized elsewhere in the domain. If a member server is a file server and hosts 100 gigabytes (GB) of data on multiple shares, you can use a local server group for administrative tasks performed directly on that computer or for defining local access permission groups.

Default Permissions of Security Groups

For member servers and client computers, the default Windows 2000 access control permissions provide the following levels of security:

Members of the Everyone and Users groups (normal users) do not have broad read/write permission as in Windows NT 4.0. These users have read-only permission to most parts of the system and read/write permission only in their own profile folders. Users cannot install applications that require modification to system directories nor can they perform administrative tasks.
Members of the Power Users group have all the access permissions that Users and Power Users had in Windows NT 4.0. Power Users have read/write permission to other parts of the system in addition to their own profile folders. Power users can install applications and perform many administrative tasks.
Members of the Administrators group have the same level of rights and permissions as they did for Windows NT 4.0.

For servers configured as domain controllers, the default Windows 2000 security groups provide the following security:

Members of the Everyone and Users groups do not have broad read/write permission as in Windows NT 4.0. Normal users have read-only permission to most parts of the system and read/write permission in their own profile folders. However, normal users can only access domain controllers over the network — interactive logon to domain controllers is not granted to users as in Windows NT 4.0.
Members of the Account Operators, Server Operators, and Print Operators groups have the same access permissions as in Windows NT 4.0.
Members of the Administrators group have total control of the system as in Windows NT 4.0.

Prerequisites for Implementing Security Groups

Security groups are a built-in feature of Active Directory. No special installation or prerequisite is required.

Implementing Security Groups

To create new users and place them in Security groups, use the Active Directory Users and Computers snap-in of MMC. For more information about creating new users, see Windows 2000 Server Help.

Considerations About Security Groups

When designing potential security groups, a good strategy is for project or resource owners to define their own local groups based on required access permissions, and to delegate the ability to manage the group memberships, which itself is a permission of groups. This strategy allows the resource owners or project leads to manage access by updating the appropriate group.

A security group is composed of people who have similar roles in the department or in the enterprise. The group is often named after the role, such as the Windows 2000 built-in groups for Account Operators, Administrators, and Backup Operators Personnel who naturally belong on the same project or department mailing list probably belong in the same security group in Active Directory. Windows 2000 security groups have a secondary role as mailing lists, so this analogy is not a coincidence.

Using groups that correspond to project teams or responsibilities is an effective way to grant access appropriately. Everyone in a department needs access to the department printers. The engineers on a software project need access to the common source directories. These are natural groups.

Note that the system has to determine all of a user's universal and global group affiliations at logon time. When a user is a member of many groups, this has some impact on performance while the system determines all the group memberships.

There is an upper limit on the number of groups a user can enroll in. For an individual user operating in a single domain, the total sum of universal, global, domain local, and local computer groups cannot exceed 1,000 groups. The user is not strictly limited to 1,000 groups, however, because the limit applies from the point of view of an individual domain. In a multiple domain model, a user could hypothetically be a member of 500 universal and global groups in their account domain, in 400 domain local groups in one resource domain, in 400 domain local groups in another resource domain, in 50 local groups in one server, and 100 local groups on another server. For most practical purposes, the 1,000-group limit is very generous.

Use nested groups to make it easier to manage group membership for large groups. (A large group might have 5,000 members in it.) Do not list every employee individually in your whole-company group. The whole-company group will be easier to administer if defined as the group that contains your department groups. The department groups can be nested within the whole-company group.

This is especially important if your whole-company group is a universal group. An organization with a single local area network (LAN) site can use universal groups with no performance degradation. However, an organization with a wide area network (WAN) needs to consider the impact of frequent changes to universal group membership on replication traffic across links between sites. If a universal group contains only other groups as members, it does not change very often and replication traffic is essentially nothing. A universal group containing thousands of individual users is likely to require frequent updates across multiple WAN links as each change replicates to all Global Catalog servers in the enterprise. Defining universal groups as groups of groups reduces this network activity.

You might find that your Windows 2000 Server does not permit nested groups. Windows 2000 Server initially operates in mixed mode, which means that Windows 2000 and Windows NT 4.0 Servers can interoperate in the same network. Mixed mode places some restrictions on security groups. When all servers have been upgraded to Windows 2000, you can switch to native mode. This is a one-way transition that enables advanced features such as nesting of security groups.

For a specific computer, the users in the local administrator security group have full rights and permissions for that computer. When a Windows 2000 computer is joined to a domain, the Domain Administrators group is added as a member of the local administrator group. Local users of the computer generally do not need to be members of the administrators group. The full-privilege administrator group must be used for local administration activities, such as changing the system configuration.

Your network security deployment plan describes your strategies for security groups. Include the following information in your deployment plan:

Identify the universal and global security groups you want to create in addition to the built-in groups.
Identify membership requirements for universal, global, and local security groups, including the built-in groups.

Security Groups and Replication Conflicts

If administrators at two different two domain controllers in different site change group membership simultaneously, one of the changes might be lost. This situation can occur only if you are making group membership changes faster than the system can replicate them. When an administrator adds or removes members from a group, the entire group membership is replicated, not just the changed members. If two administrators change group membership on two different domain controllers and replication takes place on the second domain controller before the first domain controller completes replication, only one of the changes remain after the Active Directory resolves the replication conflict. The other change is lost. As a result, a user might unexpectedly retain access to a resource.

One way to minimize this problem is to use nested groups. Create site-specific groups and make them members of a parent group that will be used to grant or deny access to a resource. Administrators in a site can then change the membership of a site-specific group and not lose changes as long the membership of the site-specific group is not updated on multiple domain controllers faster than intra-site replication can complete. Also, if you delegate responsibility for group membership changes to one administrator per site, all changes will be made on a single domain controller and no replication conflicts will occur.

note-icon Note

Within a single Active Directory site, the amount of time it takes for a change to reach all of the domain controllers will increase as the number of domain controllers increases with a maximum latency of approximately three times the replicator notify pause interval. Generally, replication will finish quickly within a single site. Replication between two or more Active Directory sites generally takes longer, and is dependent on the replication schedule configured by the administrator as well as whether or not the administrator configures inter-site replicator notifications.

To avoid this situation completely, make all group membership changes on a single domain controller. This will prevent changes from being lost due to replication conflicts. For more information about both the multimaster conflict resolution policy for Active Directory and how to configure Active Directory to minimize replication latency, see "Active Directory Replication" in the Microsoft Windows Server Resource Kit Distributed Systems Guide .

次の方法で共有