In our “Tips from the Pros” series, we’ll be the presenting interviews we’ve conducted with working IT professionals. These are the admins and managers responsible for security, access, and control of human-generated data—the fast growing digital element in organizations today. In this inaugural post, we spoke recently with one of our customers about managing large file shares and permissions.
Q: How many users do you have?
A: About 40,000
What is your domain like?
We have 3 forests with 5 domains in each, with some trusts between domains across forests.
How much CIFS shared data do you have?
We have about 1.5 Petabytes of shared data on CIFS.
That’s a lot of data. How many folders have unique permissions in your environment?
We now have 5500 managed folders and 2000 data owners, who do about 1600 access approvals each month and about 1000 revocations each month. Every folder with unique permissions that contains business data is managed by a data owner using DataPrivilege.
Where and how do you apply share permissions (as opposed to NTFS permissions)?
Share permissions are all set so that administrators have full access and authenticated users have modify access. The real control is done with NTFS permissions.
Do you have any nested shares (not counting the administrative shares)?
Yes. Sometimes there can be nested business shares, and sometimes this can cause confusion, as there are multiple logical paths for the same physical path.
Why do have them?
Sometimes end users want a shorter logical path. Also, by being more direct, you’re hiding non-relevant information from end users that don’t need it.
What’s the process like for creating a new share?
Shares are created upon end user request, with an approval process.
Do you have owners for shares?
No, we’re only tracking ownership on the folders themselves.
How do you handle inter-departmental collaboration?
We create folders & shares when needed. If there’s a project, they’ll have a dedicated site or folders. When users are just sharing a few files they will sometimes use email. When it becomes a project, they will make request for a SharePoint site or shared folder.
So let’s talk about NTFS permissions. Where do you block inheritance?
We block inheritance on every folder with unique permissions. Every managed base folder or managed subfolder has inheritance blocked.
Why is that?
Since we’re delegating access control to the business via managed groups, it would be too difficult for them to differentiate between the groups that are inherited and those that are directly applied. Any folder that has unique permissions should be protected in our environment– folders never have a mix of directly applied and inherited permissions.
How did you get to that point?
We programmatically identified every unique folder and all the groups and permissions that were applied to them. Then we turned off inheritance and directly applied any groups that were on their ACL’s.
Then, we added new groups (DataPrivilege groups) with the same masks as the original groups and added all the users from the corresponding old groups. Later we removed the old groups from the ACL. This left with us with only DP groups on each managed folder.
Who decides when a subfolder needs protection/unique permissions?
Ideally, the folder owner decides.
Which permissions masks do you use?
In general, we use two masks for non-admin groups: read+execute and read+write.
Do you use AGLP/UGLY?
For shared folders, by default we use ALP, but on request if owner approves and acknowledges the potential risks we will also use AGLP
Do you use domain local/global/universal groups?
We use either global or universal for the G in AGLP
How do you deal with the traverse permissions?
We let DataPrivilege deal with it for us. Traverse permissions are set automatically all the way up to the administrative share.
Do you run into Kerberos token size issues? If so, what do you do about them?
We have. We did increase the token size capacity. We also removed users who were in both read and modify groups for the same folder. Now when it happens, we work with users to remove unnecessary memberships. Interestingly, the vast majority of the offenders are in technology.
For example, some service desk groups were permissioned to many folders—these people had token size issues.
How do you deal with mapped drives?
This is one of the biggest end user challenges we have – the bane of our existence. The amount of work that has to happen to figure out what someone’s T drive is is ridiculous.
They’re managed by login script. The service desk has a way of figuring out what login script someone gets and then figures out what their mappings are from that script.
Do you use DFS?
Yes, for both replication and for logical name spaces.
Do you ever apply users to ACLs?
What would be your top tips for someone designing a file sharing infrastructure?
1. You need to have owners and a life cycle management processes for everything. If the owners can manage the right things by themselves, the infrastructure will evolve in the right way.
2. When everything was visible and managed by the owners, it is much more rational. End users are more informed about and aligned with the hierarchy.
3. End user communication strategy is critical. One of the biggest lessons we learned was that when you’re rolling out self-service, it’s better to present it as an option rather than enforcing its use. If you advertise it as a faster way to get access, people will adopt it more quickly and be happier.
4. If you use AGLP, only use it when the global groups are already there for a business purpose— don’t create them just to follow the AGLP model. If you get into this mentality of needing to follow AGLP everywhere you wind up having global groups as resource groups, and you end up having a domain local group for every domain.
David Gibson has more than 20 years of technology and marketing experience. He frequently speaks about cybersecurity and technology best practices at industry conferences, and has been quoted in The New York Times, USA Today, The Washington Post and numerous security news sources.