Jim Skamarakas

So riding up on the elevator from lunch, I was asked “What is the correct group that should be used to assign permissions to an application?” My answer, as I looked and saw that the door is about to open and my lunch companion depart was a very clear and concise “It depends.” In this particular case, I did not know the domain or forest model in place, where this application was located or the resources that would need access to the application.

So let’s take a minute and explain my detailed answer.

Groups serve a clear and primary purpose - they simplify administration by allowing permissions to be assigned to a collection of multiple users instead of a large number of individual users. As any experienced administrator knows, application usage grows and never shrinks. So even if a resource is only being used by one or two people today, it will be used by more in the future - so always use groups over assigning rights to multiple individuals.

So what can a group contain? A group contains members, and these can be computer accounts, or contacts, or user accounts. And to allow for larger environments and hierarchical organization, a group can also contain other groups, or group nesting. The group scope, type and the domains functional level all determine where a group can be used and what items it can contain.

Types of Groups
Windows 2003 Active Directory supports two group types.

Security - Security groups are used to control access to resources. They can also be used as e-mail distribution lists.

Distribution - Distribution groups can be used only for e-mail distribution lists, or simple administrative groupings. These groups cannot be used for access control because they are not “security enabled.”

Does the type make a difference?

In Native-mode domains, a group type can be converted at any time. In Mixed-mode domains, a group’s type is fixed at the time of creation and cannot be changed.

Types of Scope

Windows 2003 Active Directory supports three group scopes.

Universal - Universal groups can be used anywhere in the same Windows forest. They are only available in a Native-mode enterprise. Universal groups may be an easier approach for some administrators because there are no intrinsic limitations on their use. Users can be directly assigned to Universal groups, they can be nested, and they can be used directly with access-control lists to denote access permissions in any domain in the enterprise.

Universal groups are stored in the global catalog (GC); this means that all changes made to these groups engender replication to all global catalog servers in the entire enterprise. Changes to universal groups must therefore be made only after a careful examination of the benefits of universal groups as compared to the cost of the increased global catalog replication load. If an organization has but a single, well-connected LAN, no performance degradation should be experienced, while widely dispersed sites might experience a significant impact. Typically, organizations using WANs should use Universal groups only for relatively static groups in which memberships change rarely.

Global - Global groups are the primary scope of groups into which users are placed in Mixed-mode domains. Global groups can be placed only in the security descriptors of resource objects that reside in the same domain. This means that you cannot restrict access to an object based solely on user membership in a global group from another domain.

Global group membership for a user is evaluated when that user logs on to a domain. Because global group membership is domain-centric, changes in global group membership do not impose global catalog replication throughout an entire enterprise.

In a Native-mode domain, global groups can be nested within each other. This may be useful when administrators have nested organizational units, and want to delegate Organizational Unit (OU) administrative functionality in a gracefully decreasing manner down an OU tree. In this situation, a global group tree can be used as a parallel construct, for the assignment of such decreasing privileges

Domain Local - Domain Local groups can be used for the direct assignment of access policies on specific resources that are not directly stored in Active Directory, (such as file server shares, printer queues, and so on).

Domain Local groups should not be used to assign permissions on Active Directory objects, because Domain Local groups cannot be evaluated in other domains, and parts of most Active Directory objects get replicated to other domains in the form of the GC. Access restrictions placed on Active Directory objects that are based on Domain Local group membership have no effect on GC queries that take place in groups other than the domain in which the Domain Local group originated.

When you create a new group, it will be a security group with global scope by default. You can modify the group scope if the domain functional level is set to Windows 2000 native or Windows Server 2003. Changing a group scope in Windows 2000 mixed mode domains is not possible.

Does the type make a difference?
Opposite to domain local and global groups, universal groups are replicated to every global catalog in the entire forest. A universal group can be changed to a domain local group at any time. A universal group can be changed to a global group only if it does not have other universal groups as its members.

An administrator should have a written policy explaining the group types and scopes, a naming standard and examples of when to use each for their organization.

So an example is in order
The preferred method to use these group scopes is explained in the following example:

The marketing department on the 3^rd floor just purchased a new color laser printer, a shared resource for the entire department. It is located near conference room 322.

1. Create the printer object ColorLaser322
2. Create a domain local group for the marketing department - MarketingPrinters
3. Assign the domain local group MarketingPrinters permission to use ColorLaser322
4. Create a global group called Marketing
5. Add the users from the Marketing department to the global group called Marketing
6. Add the global group Marketing to the domain local group MarketingPrinters

Step up our example a notch
The corporate marketing department on the 3^rd floor 55 Wall Street office in New York City just purchased a new high speed color laser printer, a shared resource for the entire department. It is located near conference room 322.

1. Create the printer object NYC-322-ColorLaser
2. Create a domain local group for the marketing department - CorpMarketingPrinters
3. Assign the domain local group CorpMarketingPrinters permission to use NYC-322-ColorLaser
4. Create a global group called CorpMarketing in the Corp domain
5. Add the users from the Corporate Marketing department to the global group called CorpMarketing
6. Create a global group called EastMarketing in the Eastern division domain
7. Add the users from the Eastern division Marketing department to the global group called EastMarketing
8. Create a Universal group u-Marketing
9. Add the global groups CorpMarketing and EastMarketing to the Universal group u-Marketing
10. Add the universal group u-Marketing to the domain local group CorpMarketingPrinters

You can see from our example that be add individual resources to global groups in their own domain. If the resource is to be accessed from members in multiple domains, we use a universal group to aggregate all the individual global groups. We do not want to put individuals into Universal groups directly.

Local vs. Active Directory Groups
The group types and scopes outlined above are pertinent to Windows 2003 servers that are members or domain controllers in an Active Directory domain. They are stored in the Active Directory on domain controllers. However, groups also exist on a local machine level, even if ADS is not in use. You can create local groups on the local computer using the Local Users and Group MMC snap-in and the can be used for assigning permissions on that computer only.

Can I move groups in the MMC?
Yes, you can move a group to another container, from the Users container to a departmental OU for example, by right-clicking the group and selecting Move from the context menu. This can be done only within a single domain.

A note on universal groups - the can be moved from one domain to another. The member settings of the universal group will be retained. But you will have to reassign permissions and rights as they will be lost in the process.

What groups is a user a member of?
Look at a user objects properties, on the Member Of tab. This displays a list of groups the user is a member of. However, it does not show groups that reside in trusted domains but the user is a member of. To see this complete list, you can run a command line utility.

dsget user UserDN -memberof -expand

UserDN is the user’s distinguished name

-expand causes each group to be expanded to determine membership through nested groups

So an example:
dsget user “CN=Mary Smith,CN=users,dc=home,dc=local” -memberof -expand

So from here you can use command line utilities and third party products to see more information about a user’s group membership, but also to manage groups. This can include automating adding numerous users to groups with some basic scripting.

Popularity: 3%

Categories: technology
Tags: computers, groups, microsoft