Windows - Group Policy - Numerous Share Drives w/ Item-Level Targeting

Overview

We have been working on getting our numerous sites to map share drives for each user that needs access to their sites. We have no way of standardizing this from within their AD profile as some users move around a lot and end up not telling IT until they need access to a particular site share drive. In turn we have created security groups for each site and will be using this as an item-level target within a Group Policy at the root of our AD structure for the sites, hoping it will trickle down and give only those in the security groups the drives they need.

System Information

Operating System: Windows Server 2016

The following relates to four machines across two DCs

Domain Controllers (GPO, Active Directory)

Operating System: NetApp which will be replaced in the near future with Nutanix Files.

Share Drives for each of our sites under the root and no sub-share's as the users will be populating these shared folders with whatever files they use/create

Structure

We map a drive to our users that connects to our NetApp appliance. The NetApp appliance has subfolders based on each site name, which in turn have whatever the users put in these folders. The structure looks similar to the following:

NetApp Shares
├── Site 1
├── Site 2
├── Site 3
├── Site 4
├── Site 5

We have multiple Security Groups, such as the following:

Site1-ShareDrive
Site2-ShareDrive
Site3-ShareDrive
Site4-ShareDrive
Site5-ShareDrive

Within said security groups we have users who might not natively be in that Site's OU, as some manage multiple sites, or move around often and need multiple sites within their division.

Example:

Site1-ShareDrive
├── User13
├── User20
├── User33
├── User42
├── User51

Site4-ShareDrive
├── User13
├── User22
├── User23
├── User1
├── User5
├── User3
├── User100

Site9-ShareDrive
├── User13
├── User22
├── User23
├── User1
├── User53
├── User54
├── User545

AD Structure:

All Sites
├── Division-1
|   ├── Site 1
|   ├── Site 2

├── Division-2
|   ├── Site 3
|   ├── Site 4
|   ├── Site 5

├── Division-3
|   ├── Site 6
|   ├── Site 7
|   ├── Site 8

├── Division-4
|   ├── Site 9
|   ├── Site 10

For Group Policy we would like to place the policies at the "All Site" level to theoretically trickle down to the entire structure, but only have them applied based on if the users are in the security group being targeted

Issue

Within Group Policy we are creating new policies for each site that have an item-level target to that specific site's security group

For example:

User1 belongs to the following groups:

Managers
Site1-ShareDrive
Site9-ShareDrive

User 13 belongs to the following groups:

Partner
Site1-ShareDrive
Site4-ShareDrive
Site9-ShareDrive

Logically, the following should be our setup:

• User1 should only have access to \\example.com\Shares\Site1 and \site9
• User13 should only have access to \\example.com\Shares\Site1, \site4 and \site9

Unfortunately, this problem exists on a much larger scale when you add in the fact that some users who might be managers only need one site, where as other managers might need more sites and partners access to their division they are in charge of. The other issue we are running into is some sites are a cooperation between divisions, which is why some users outside their division OU need access to another division sites share drives. Aside from adding them to these security groups going down to the file level for NTFS permissions at this time will be a nightmare, as we are using an old NetApp appliance that actually is being EOL soon by our vendor. We have no timeline on when we will be migrating to a new platform yet.

Additionally

We would prefer to hide any folders that users don't have access to. In the example above, for example, User1 would not even know about the existence of \example.com\Shares\Site8 since the user doesn't belong to the respective security groups

We would like to be able to apply some security groups according to the site the user needs. Along with placing an item-level target on that security group. Our current OU structure resembles the following:

Example OU structure

All Sites
    Site 1
      User13
    Site 4
      User1
    Site 9
      User545

Questions

1. How can we ensure that our structure works with Item-Level Targeting? (i.e. GP: 'Site1-ShareDrive Access' would have "\example.com\shares\Site1" drive being mapped via "Update" and "Reconnect" Checked, along with "Run in user security context" and "Item-Level Target" set to "Site1-ShareDrive", with it linked to "All Sites")?
2. If some of the above are not possible, how can we ensure ease-of-use for our users, while increasing IT productivity?

A few things:

Hiding files and folders without permissions:
To hide folders that users don't have access to, you can enable "Access Based Enumeration" on the shares. That said, it's not recommended to do so unless you have a strict requirement for it. ABE can cause a significant increase in CPU usage on file shares, as each file's ACL needs to be enumerated whenever a directory is traversed.

Linking GPOs to AD logical sites:
You could save some Group Policy Preference processing time by applying a GPO for mapped drives directly to your Active Directory logical sites, if you have a logical AD site that represents each physical location. (Note, this requires using the AD Sites and Services management console or the AD PowerShell module to map subnets to specific sites.) The only challenge with this approach is the handful of users who need to access multiple sites' shares, regardless of which site they are at. This can be accomplished by creating some redundancy across the site-specific GPOs for drive mapping, but again...it gets less efficient.

Back to group policy preferences:
It sounds like you have a good starting understanding of how to use item-level targeting for this job. Here's a potential ILT layout for a hypothetical "Share 1" at "Site A":

Edit the GPO and expand through the User Configuration > Preferences > Windows Settings, and then click on Drive Maps.

1. Configure your general drive map settings for Share 1 at Site A.
2. Go to the Common tab, enable Item-level targeting, and click the Targeting... settings button.
3. Now you'll want to make use of ILT multiple collections to group targeting conditions.From what you've described, I would create something that looks like this:

ILT Items and Collections

1. Add a collection where 'this collection is true'

• Add a condition that states the user is a member of the security group "Site A"
• Add a condition [AND] the site is "SiteA"

2. Add a second collection (where this collection is true) and set the collection's Item Options to OR

• In the second collection, add an item to include managers who need access to multiple site shares. Use a security group and set the item to `the user is a member of the security group "Site Managers" (assuming this group has access to multiple site shares.

Click OK to save and close the current drive map item. This example could solve your challenge.

Dynamic Access Control
You may also want to look into using the Dynamic Access Control feature on your file server. This feature makes ACLs (access control lists) on a file system much more powerful by enabling two new features:

• The ability to use both OR and AND operators in ACLs
• The ability to add claims-based permissions, or conditions to the permissions. Claims can be based on 3 types of objects: user attributes, device attributes, or transformation claims (typically from rules created in a policy).

User and device claims can be based on most attributes of user or device objects in AD, so you could hypothetically go as far as creating a DAC rule that says: grant access to the user if they are in 'Group A' and are not on a mobile device and if they are using a computer that is in 'Site A' (this would be based on the IP address subnet being mapped in AD). You can furthermore use data classification policies to apply different dynamic access control rules, depending on user or device claims...but that's the next level! I would recommend looking into DAC, but just know that it has more complex dependencies than simply working through a good item-level targeting configuration.