Group Policies and Security Groups

This section of the document will briefly unite the idea of Organisational Units, Group Policy Objects and NTFS permissions together.

Carrying on from the last post:

Using Security Groups has it’s benefits as well; if you restrict NTFS permissions to certain directories based on a group, you can use the same group (I.E. Sales-Staff) to map the drive, have permissions, and install the correct software in the same GPO.

One of the most useful points to Security Groups is using them to also be your NTFS permissions for File Servers. Why is this topic so important? This is where Active Directory “git gud” (I am so hip). To clarify, you can use a security group (or Organisational Unit) to perform a number of functions against a GPO; and trust me, this is helpful.

Let’s use the following example:

  1. Joe is part of the “Admin Staff” security group
    1. Joe needs access to \\loc.fs\adm\files;
    2. Joe needs Java 7 Update 71 on his PC and;
    3. Joe needs his folders redirected to \\loc.usr.fs\adm\usr\joe

By implementing a policy using a security group “Admin Access” we can configure points 1.1, 1.2 and 1.3 in the same policy, allowing Joe to have the mapped drive, application installed and his folder redirected to the desired location.

The term Group Policy is a bit misleading; one policy may have many configured policies under it; for example, a Default Domain User policy should have a number of configured policies to apply across all domain-joined users, to configure Windows to a SOE.

Before creating thousands of groups, try an approach where one group can serve many purposes; in this example, we could also deploy printers, restrict NTFS permissions and edit other Windows Components for these staff.