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
- 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")?
- 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.ILT Items and Collections
the user is a member of the security group "Site A"
[AND] the site is "SiteA"
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:
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.