Tips From the Pros: Sharing 250 Million Folders With 100,000 Users
Q: How many users and how much data are you managing?
We have in excess of 100,000 actual people, 1.5 million accounts in AD, and 250,000,000 data folders.
Q: Can you describe your overall strategy for designing shared folders?
For us, everything is based on Active Directory group membership. Every “share,” or “root folder,” has AD groups for read-only access, read-write access, and full control. When a root folder is created, groups are created and assigned and the NTFS permissions never change. All subfolders are set to inherit the same permissions. All root folders are created at the same level in the folder hierarchy. If a subfolder needs different permissions, it has to be moved and made into its own root folder. By the way, even though we call these folders “shares,” in reality they are not the actual SMB/CIFS shared folder but rather folders directly under an actual SMB/CIFS share. Under the actual share we’ll have up to 100 root folders, and these are what users will map to.
Q: How many root folders do you have?
We have about 10,000 roots—I’m not sure how many we add per week.
Q: What happens when someone needs a new share?
We have an internal request system where anyone can request a new share. When we get the request, a new root folder is created, along with 3 new AD groups based on project name. The person that requests the share will be set as the “owner” in the groups’ “managedby” AD fields, and a DFS link is created for the folder.
Q: Who usually makes a share request?
It could be anybody, but any amount of data will be charged back to the business. Someone in the business unit that has financial authority needs to approve the storage cost.
Q: How do you decide when a folder is no longer needed?
Pre-Varonis, someone needed to tell us. Now our records management team is working to tie in Varonis stale data reports with our retention policies.
Q: How are the share permissions set?
Authenticated users have modify access on all shares. The NTFS permissions on the SMB shared folder are set to Everyone RWL—this set-up means we don’t need to worry about handling traverse permissions, because everyone can see the root folders.
Q: What about group nesting?
We don’t nest groups for end user access; we only nest groups for IT system admin access, and we nest them based on geographical scope. For example, a group will grant admin access to NY servers, nested in that group will be North America admins, and nested in that will be world admins.
Q: How do you deal with mapped drives?
We use DFS to abstract paths. Everyone has a drive letter that is mapped to their local DFS name space. This is set by login script. DFS paths are grouped by region, and we have replication between DFS name spaces. People see all the roots underneath their region, but NTFS permissions restrict what they can access.
Q: Who deals with the login scripts?
These are maintained by desktop team.
Q: Do you ever apply users to ACLs?
No.
Q: How often do people review permissions?
Group memberships are reviewed whenever a user leaves us or changes departments. Important folders are also recertified annually. We use DatAdvantage to make sure permissions are set according to standard and watch permissions for changes. We plan to use DatAdvantage recommendations to help data owners identify stale group memberships during their reviews.
