Creating and Managing Active Directory Groups

Groups are security principals with a security identifier (SID) that, through their member attribute, collect other security principals (users, computers, contacts, and other groups) to facilitate management.

Use the buttons below to navigate through the lesson


Imagine that all 100 users in the sales department require read-level access to a shared folder on a server: It is not manageable to assign permissions to each user individually.
When new salespeople are hired, you will have to add the new accounts to the access control list (ACL) of the folder. When accounts are deleted, you will have to remove the permissions from the ACL. Imagine now that all 100 users in the sales department require access to 10 shared folders on three servers. The management challenges just increased significantly.

You have learned that although assigning permissions to a resource to an individual user or computer is possible, the best practice is to assign a single permission to a group and then to manage access to the resource simply by changing membership of the group.

So you should create a group called Sales and assign the group the Allow Read permission on the 10 shared folders on the three servers. Now, you have a single point of management. The Sales group effectively manages access to the shared folder. You can add new sales users to the group, and they will gain access to the 10 shared folders. When you delete an account, it is automatically deleted from the group, so you will not have irresolvable SIDs on your ACLs.

To create a group by using the Active Directory Users And Computers snap-in, simply right click the OU in which you want to create a group, choose New, and select Group. The New
Object>Group dialog box enables you to specify fundamental properties of the new group.

The first properties you must configure are the group’s names. A group, like a user or computer, has several names. The first, shown in the Group Name box is used by Windows 2000 and later systems to identify the object it becomes the cn and name attributes
of the object. The second, the pre-Windows 2000 name, is the sAMAccountName attribute, used to identify the group to computers running Microsoft Windows NT 4.0 and to some
devices such as network attached storage (NAS) devices running non-Microsoft operating systems.
The cn and name attributes must be unique only within the container (the OU) in which the group exists. The sAMAccountName must be unique in the entire domain. Technically, the sAMAccountName could be a different value than the cn and name, but it is highly discouraged to do so.

Right click the OU and select New>Group. Type in Group name. Select Group Scope. Select Group Type. Click OK to create the group.

You can convert the group type at any time by changing the selection in the Group Type section of the General tab. Be cautious, however. When you convert a group from security to distribution, any resources to which the group had been assigned permission will no longer be accessible in the same way. After the group becomes a distribution group, users who log on to the domain will no longer include the group’s SID in their security access tokens.

You can change the group scope in one of the following ways:

  • Global to universal
  • Domain local to universal
  • Universal to global
  • Universal to domain local

The only scope changes that you cannot make directly are from global to domain local or domain local to global. However, you can make these changes indirectly by first converting to universal scope and then converting to the desired scope, so all scope changes are possible.

Select Group Scope. Select Group Type.

The Dsmod command, introduced earlier, can be used to change group type and scope by using the following syntax:
dsmod group GroupDN -secgrp { yes | no } -scope { l | g | u }
The GroupDN is the distinguished name of the group to modify. The following two parameters affect group scope and type:

  • -secgrp { yes | no } specifies group type: security (yes) or distribution (no).
  • -scope { l | g | u } determines the group scope: domain local (l), global (g), or universal (u).

Earlier in this lesson, you learned which types of objects can be members of each group scope. Now it is time to identify which types of objects should be members of each group scope. This leads to the best practice for group nesting, known as AGDLA.

  • Accounts (user and computer identities) are members of
  • Global groups that represent business roles. Those role groups (global groups) are members of
  • Domain Local groups that represent management rules—which have Read permission to a specific collection of folders, for example. These rule groups (domain local groups) are added to
  • Access control lists (ACLs), which provide the level of access required by the rule.

AGDLA

Add local users to global groups. Add Global groups to domain local group. Assign Domain Local Group the required permissions on the shared folder.