More from our Tips interviews with working IT professionals.
Tell me about your environment—how many users, how much data, etc.?
A: We have over 600 users and 15TB of shared CIFS data. We have a single domain that contains over 1000 security groups.
That’s a lot of groups–are they domain local/global/universal, and are they nested?
We try not to nest groups at all. We now create only domain universal groups, and they all share a common naming prefix.
Can you describe your overall strategy for designing shared folders?
About 10 years ago, HIPAA forced us to address our unstructured data. We eventually arrived at a tightly controlled hierarchical structure, where every user sees 5 mapped drives, all of which are mapped at logon via VB script:
- An “M drive” (stands for “My department”) that is open to all people in the user’s department, and only to those users.
- An “S drive” (stands for “Shared secure”) that is similar, but can be shared out to other users in other departments. This is managed by data owners using DataPrivilege.
- An “O drive” (stands for “Open”) that is readable by the entire company, but only modifiable by people in the user’s department. This is used when a department needs to publish data to the rest of the company.
- An “R drive” (stands for “Reports”) that is a temporary reporting folder to store reports produced by automated systems. Readable by the user’s department.
- A “Q drive” (stands for “personal”) which is the user’s home drive, open only to that user.
This minimizes the amount of administration we have to do. The logon script keys off the user’s OU in Active Directory, and we have a security group for each department that is only changed when employees are hired, transferred, or terminated.
How does this work with the transfers?
Transfers between divisions happen easily. Each division has its own OU, and when the user is moved to the new OU their login script automatically changes their drive mappings. If for some reason the transferred user hasn’t been put into the new departmental security group we hear about it really quickly because they can’t access what they need.
Intra-division transfers are spotted during entitlement reviews. DatAdvantage recommendations help us spot and remediate anyone with access rights leftover from their old positions.
Tell me about the owners and the entitlement reviews.
We have about 60 or 70 data owners that are required to do entitlement reviews on their managed folders twice a year, which they do through DataPrivilege.
How do you permission these managed folders in terms of inheritance and groups?
The majority of folders are protected/not inheriting because it’s less confusing that way. We have 2 groups on each folder’s ACL (in addition to the administrative groups): a read only and a read/write group. In terms of the UGLY/AGLP model, we’re mainly using domain global groups and we’re not nesting, so we’re using AUP.
Do you ever have individual user access control entries?
No, we never list individual users on an access control list.
How do you deal with the traverse permissions?
DataPrivilege takes care of this for us, setting traverse groups all the way up to the share.
Where do you apply share permissions?
We apply share permissions to the folders containing all the departmental folders, so for example, the folder containing all the M drives I mentioned before is shared, as is the folder containing all the S drives, O drives, etc.
Do you run into Kerberos token size issues? If so, what do you do about them?
We haven’t. The only issue we’ve had is the limitation with how Active Directory works in that when a user is added to a security group the user still needs to logoff and login again in so that their token can refresh and the changes take effect.
How do you go about deciding whether to create new shares or use existing ones when a new project & team forms?
Owners just create new managed folders in DataPrivilege, or have the security team assist to create them.
If you had to design your file sharing hierarchy all over again, what would you do different?
The “R drive” really hasn’t worked out right. Users often want to share reports with other users and departments, so we would probably put them in the S drive if we had it to do over again.