In the previous section, we covered the management of user and computer accounts. You learned how to create and manage these types of accounts. In this section, we're going to look at the purpose of groups and organizational units.

In large enterprise networks, assigning permissions to user accounts is impractical. Adding users and computers to specific groups and then assigning permissions to resources is the only correct approach. It's important to understand group types and how to use them properly in order to manage access to resources or to assign management rights.

This section will also cover how to work with organizational units in AD DS.

Like user and computer accounts, group accounts also need to be created. Once groups are created, they can be managed later. You can create groups using either of the MMC Snap-ins or PowerShell. You just need to know and define what group type and scope you need. Like all other objects covered in this chapter, Active Directory Users and Computers MMC Snap-in will give you the ability to create groups, but group configuration needs to be performed later, while the Active Directory Administrative Center MMC Snap-in allows you to configure more parameters at the same time.

If you decide to use Active Directory Users and Computers, you will see the following screen:

Active Directory Administrative Center is a little bit different. You will see the following screen:

If you want to use PowerShell for group creation, you need to use the New-ADGroup cmdlet:

New-ADGroup -Name "MCSA 2016" -GroupCategory Security -GroupScope Global -Path "OU=Packt,DC=mcsacertguide,DC=local"

Like user and computer accounts, group objects are not protected from accidental deletion by default. This needs to be configured, and the steps for MMC Snap-ins and PowerShell commands are the same as for user and computer accounts.

Groups nesting is the process in which we add groups to other groups. This process creates a hierarchy of groups that can be helpful in supporting your roles and management rules. Microsoft recommends using IGDLA for group nesting, which is an acronym for the following:

(I) Identities (G) Global groups (DL) Domain-local groups (A) Access:

• Identities (user and computer accounts): Members of global groups
• Global groups represent specific business roles: Members of domain-local groups
• Domain-local groups: Represent rules for access, such as Sales Read-Only
• Access: Resources in which domain-local groups have a specific type of access

In order to implement group nesting properly, knowing the scope of the group is important:

Although changing the group scope looks like an easy process, in general, it's not.

The following list defines which group scope changes are allowed:

• Global group to domain local group: Not allowed directly. The global group first needs to be converted to a universal group. It can then be converted to a domain local group.
• Global group to universal group: Allowed only if the global group is not a member of another global group.
• Domain local group to global group: Not allowed directly. The domain local group first needs to be converted to a universal group. It can then be converted to a global group.
• Domain local group to universal group: Allowed only if the domain local group doesn't contain another domain local group.

In the following screenshot, you can see that the group scope is Global. If you want to change the group scope to Domain local, the option is grayed out and you can't do that. You can only convert the group to Universal:

Once you have converted the group from Global to Universal, you will be able to convert the group to Domain local:

Sometimes, managing group memberships can be time-consuming. For example, let's say you need to add a group to the local Administrators or the Account Operator group on all client computers in the domain. In this case, you need to use Group Policy to speed up the task. Group Policy provides a setting, called Restricted Groups, that gives you the ability to control the membership of local groups on domain-joined computers. By default, there are no configured groups. You can find the Restricted Groups setting by going to Computer Configuration | Windows Settings | Security Settings:

Once you navigate to Restricted Groups, you need to create a new Restricted Group configuration in the GPO. In the following example, MCSA 2016 group will be a member of the Administrators on all computers where this policy is applied:

In a large-scale environment, enumerating group membership is often a regular task. The reasons why we need to enumerate group membership include security compliance and analyzing access to resources.

You can accomplish this task using either of the MMC Snap-ins by simply checking the Members tab in the group's object properties. If you decide to use Active Directory Users and Computers, you will see the following screen:

Active Directory Administrative Center is a little bit different:

This can also be done using the Get-ADGroupMember PowerShell cmdlet:

Get-ADGroupMember -Identity "MCSA 2016" | Format-Table Name

In the previous sections, we mentioned that PowerShell is the best native tool in Windows operating systems for automation. Although you can select more than one user in MMC Snap-ins and add them to the same group at one time, this approach has some limitations. Using PowerShell, you can make a query against AD DS with some filtering options, such as the company name or department name, and then add those accounts to the same groups.

The following command will show you how to add a member to a group based on their company name:

$Members = Get-ADUser -Filter {Company -eq "Packt"}

Add-ADGroupMember -Identity "MCSA 2016" -Members $Members

Users, groups, and computers are objects in AD DS that are stored in the OU. By default, all users and groups are stored in the Users container and the computers are stored in the Computers container. As mentioned earlier in the chapter, OUs need to be created to consolidate objects for simplified management using GPOs linking, or delegating administrative rights. One of the rights that you can delegate to a specific user or group is Create, delete and manage groups. With this delegate control, specific users or group members will be able to create, delete, and manage groups in the selected OU and all other OUs in the subtree:

Once you've configured the domain environment and installed the first domain controller in the root domain, many AD DS objects are created. Because of the AD DS design, these need to be stored in a container or in the OU. There are several container objects that are installed by default. They don't have the same properties as other generic Active Directory containers (such as sites, domains, and OUs). You can't delete the system container, nor can you create a new system container. And you can't link GPOs to those containers.

Creating OUs is straightforward, as is the case with other objects mentioned in this chapter. It can be done using the same tools: MMC Snap-ins and PowerShell. During the creation process, you need to define the name of the OU and it will be created. Unlike other objects covered in this chapter, OUs are, by default, protected from accidental deletion, regardless of what tool is used. Using Active Directory Administrative, you will see the following screen:

The Active Directory Users and Computers MMC Snap-in will give you a different look for the same task:

If you decide to use PowerShell, the New-ADOrganizationalUnit cmdlet needs to be used to create an OU:

New-ADOrganizationalUnit -Name Servers -Path "OU=Packt,DC=mcsacertguide,DC=local"