Generally, it is not recommended to use domain local groups for the purpose of managing access to individual resources that are not hosted on domain controllers. For example, if you have a file and print server , you would want to create local groups on that server, and determine who can access the files and printer queue by considering who is the member of those local groups. Extensive permissioning through domain local groups may result in overpopulating Active Directory with role-based groups that should really be located on servers hosting resources.
Global groups can contain security principals only from the domain where they were defined, and they should contain users that require the same level of access to certain resources. Global groups cannot nest domain local groups but can nest other global groups. Administrators in trusting domains can add global groups from trusted domains to domain local groups or directly into resource ACLs in their domains. To continue with our example, instead of adding users to the domain local group on an individual basis, the recommended practice suggests that you should add these users to a global group, then add the global group to a domain local group, and use this domain local group to define permissions in resource ACLs.
Universal groups can contain security principals from any domain and also be assigned permissions in any domain, provided there is a trust relationship between the domains in question.
Infrastructures of small organizations can use universal groups to simplify their group nesting and strategy. Access policies for domain local groups are not stored in Active Directory. This means that they do not get replicated to the global catalog and thus queries performed on the global catalog will not return results from domain local groups.
This is because domain local groups cannot be determined across domains. Use global groups to give users or groups access to resources according to how they have been organized. For instance, users from the Marketing or Development departments could be put in separate global groups in order to simplify administration of their need to access resources like printers and network shares.
Global groups can be nested in order to grant access to any domain in the forest. Universal groups have very few fundamental restrictions. Universal groups can be a tempting shortcut for administrators to use, because they can be used across domains in the forest. Memberships in universal groups can be drawn from any domain, and permissions can be set within any domain. However, using universal groups as your main method of grouping users, groups, and computers has a significant caveat.
Universal groups are stored in the global catalog, and whenever changes are made to a universal group, the changed properties must be replicated to other domain controllers configured as global catalog servers.
The replication of individual property changes rather than entire objects is an improvement for Windows Server that should allow wider use of universal groups without causing network bottlenecks or slowed performance during authentication and global catalog changes. There is a strategy in choosing when to use a group scope and which group scope to use. A common strategy is to organize user accounts into logical groups based on the permissions they need to access specific resources.
In a business model, this often can be determined according to the department the user belongs to. For instance, the Development department of a software business may put all their developers in a Dev group, and then assign permissions to a network share to the Dev group. On the other hand, in a Windows Server environment it becomes more complex than this, because there are different scopes for groups. These groups will include users who are alike in the sense that they are all a part of the same domain, since global groups cannot contain members from other domains.
The users will also probably have some other commonalities such as being in the same department, having the same manager, or some other similarity of that nature.
Due to the flexibility of their membership restrictions, domain local groups are ideal for granting permissions on resources. Specifically, these groups are used because groups from the parent domain as well as other domains and trusted forests can be added to them.
This allows for administrators to grant access to a resource for anyone in the environment should they need it. The use of domain local groups becomes especially important when you are dealing with situations involving trusted forests. In a case like this, chances are good that accounts in one forest will need access to resources in the other forest. If a global group was being used to grant access to a resource, there would be no way for accounts in the second forest to be given access to that resource, since accounts and groups cannot be nested into global groups from a different domain or forest.
See the graphical representation below for a simplified look:. The use of this model really depends on how much the global catalog is relied on in the organization. If there is a vested interest in having the global catalog be as complete as possible perhaps you have a large mobile workforce and rely heavily on employees being able to easily find each other in Outlook , then the AGUDLP model will help in this endeavor. However, for smaller environments that only have a single domain this model may add an unnecessary layer of complexity.
From a security perspective, if one was to use global groups to give users permissions to resources they would have to add users from other domains and forests into the domain where the resources reside. Generally, separate domains and forests exist for a reason and the delineations between domains and forests are not meant to be blurred.
By using domain local groups to grant permissions to specific resources, an admin can give members from other domains and forests access to the resource without needing to give them direct access to the rest of the domain where that resource lives. Too often we see organizations use global groups to define permissions on resources and end up over-provisioning access and rights as a result when users move in and out of the group. Resource permissions are set for domain local groups and do not need to change once they are determined, limiting how often it is necessary to go out to the resource to adjust these permissions.
By assigning these permissions to a group, instead of individual users, you can ensure that all members of the group receive the required permissions, unless they conflict with permissions that are assigned to the user explicitly or through another group.
Rights are a separate concept. Although they can relate to resources, more often rights relate to actions a user can perform involving the operating system. The right to log on locally at the server console or across the network are good examples. The ability to reboot a computer is also a right that must be granted to a user. Unlike group types, which are fairly simple to understand, group scopes can be confusing to those new to working with Windows Server and Active Directory.
The scope of the group identifies the extent to which the group can be applied throughout the domain or forest. Even this is not as simple as it sounds. The objects that can be members of a group, as well as the groups available, vary depending on the functional level of the domain. Domain and forest functionality is a new feature introduced in Windows Server By having different levels of domain and forest functionality available within your Active Directory implementation , you can make different features available to your network.
If all of your network's domain controllers are Windows Server and the domain functional level is set to Windows Server , then all domain features such as the ability to rename a domain controller become available. If your entire Active Directory forest is also set at the Windows Server functional level, then you also gain additional functionality such as the ability to rename entire domains. In a non-upgrade environment, there are three domain functional levels available:. Windows NT 4. It also enables some additional group nesting capability.
This level allows for Windows and Windows Server domain controllers. It provides the most features, and allows only Windows Server domain controllers. Once you have raised the domain functional level, domain controllers running earlier operating systems cannot be used in that domain.
As an example, if you raise the domain functional level to Windows Server , Windows domain controllers cannot be added to the domain. According to Microsoft, domain local groups DLGs are used when assigning permissions or user rights. While we've loosely mentioned this in regard to all groups, it is this specific group scope that Microsoft wants you to use when modifying the access control list ACL of an object such as a file, or assigning a user right.
Other groups will be added to a DLG to have their members receive the group's assigned permissions or rights. In a Windows mixed functional level domain, domain local groups can consist of users, computers, and global groups from the domain the DLG exists in, and any trusted domain. When the functional level of the domain is raised to Windows native or Windows Server , a DLG can also contain other domain local groups from its local domain, as well as universal groups.
Despite the fact that this group type can contain users and computers directly, it is important to remember that Microsoft recommends that you use it to contain other groups, which themselves contain users or computers.
0コメント