How do you handle network file share permissions

[robjduk]

Hello,

Following from my previous post HERE I wondered how you all handle staff and student file share permissions.

Do you grant full file access so you and the IT department can browse, move or delete files easily or do you lock them down? If you lock them down, do you sign into servers to delete or move files or is there a better way?

 

So far, any attempt to elevate my permissions to a user with admin rights has been met with error. I'm thinking we may need admin rights to files and folders to save signing into servers to do any housekeeping but want to keep my options open.

 

How do you all do it?

 

Thank you

[jthompson]

My regular user account has read privileges on student user areas and also read privileges on some other file shares that I'm not personally needing to write to. I've found that the majority of issues only need something to be looked at anyway.

 

If I need to do any file management tasks for somebody, I'll do that from a secure admin workstation using a higher privilege account, so not necessarily having to sign in to an actual file server.

[Chuckster]

This is how I had it set up at my previous place before I left for pastures new.

 

Let's say, for example, you have a network drive called Pastoral.

 

In AD, I would have 3 security groups

 

 

• Drive - Pastoral - Read
  
• Drive - Pastoral - Modify
  
• Drive - Pastoral - Full Access
  

 

Read: View contents only.

Modify: Add. edit and delete files, folders and sub folders.

Full acess: essentialy the NTFS permission of Full Control.

 

The Pastoral drive would be mapped for users that belonged to any of the first two groups based on item-level targeting.

 

Full Access was reserved only for those in IT, with access from servers only. If you weren't in this group, then you had no permission of deleting the root folder except anything inside of it.

[msi_school]

I try to keep my daily driver account the same as a normal staff account so I experience the same environment as my users, if I need more privilege's I can then log into a higher privileged account or onto a server.

 

This has the added advantage of fitting the lowest privilege security paradigm.

[robjduk]

I like the idea of having the same level as my users however still a little hazy on how best to manage it if we do need to delete or move anything. There doesn't seem to be an easy way to elevate your account for file shares and don't really want to make signing into a server the norm.

 

I shall continue to ponder.

[msi_school]

I like the idea of having the same level as my users however still a little hazy on how best to manage it if we do need to delete or move anything. There doesn't seem to be an easy way to elevate your account for file shares and don't really want to make signing into a server the norm.

 

I shall continue to ponder.

 

I have a daily driver account which is a normal staff account and an elevated account which has higher levels of access that I can use on client machine. I don't do any sort of fancy elevation of privilege's if I want to use the higher level of access I log on as this user, it does lack some elegance but it is simple and its much harder to leave my self elevated.

[psydii]

Very siilar to Chuckster we have a collection of groups per resource.

 

Say we have a share, there are (theoretically) three groups:

share_sharename_readonly

share_sharename_fullcontrol

share_sharename_chage (to be fair, usually we don't bother with this one)

 

These groups are the only groups that have access to the share (and the Local Administrator group of the server).

 

Into these group we nest groups of *ROLES* that need that level of access. So role_fileserver_Administrators is in the _fullcontrol group. And role_FileServer_Adminsitrators contains a set of accounts that are to be administrators of the serer. These are never our daily driver accounts, and more recently they are not our DA accountes either.

 

Other roles might include role_Teachers role_SupportStaff role_Students.

 

We get more granular too.

 

Each Deperartment has a set of role groups

 

role_english_teachers

role_english_admin

role_english_HeadofDepartment

role_english_HeadofKS3

role_english_HeadofKS4

role_english_HeadofKS5

role_english_LitteracyLead.

 

All these group are members of the role_English_members group.

 

Then on file server there is a folder for the English Department. This has three groups built for it:

folder_EnglishDepartment_ReadOnly

folder_EngishDepartment_FullControl

folder_EnglishDepartment_Change

 

For departmental folders we have role_staff as member of these _readonly groups

the group role_english_members is a member of _Change

the server administrator group is a member of _fullcontrol

 

And we iterate through all folders/departments/teams/functions like that.

 

We have a dirty set of scripts that sync the _members groups to their equivalent 365 Groups/Teams.

 

There are other groups like role_headsofdepartment_members that contain all the _headofdepartment groups and the each of the _headofdepartment groups are used to provide additional access into 3rd party services that read from AD such as papercut. Other role and capability groups are used to filter access to 365 authenticated apps. etc.

 

 

For each server there is an group called serveradmin_servername and we use gpp to add this to the local administrators group.

 

When we need admin on a server we add our serveradmin_ittechsname account to the appropriate serveradmin_servername group, and then hop on via a fresh remote session. It needs to be fresh so it picks up the appropriate tickets/tokens. One can fudge it with klist, but it is more reliable/faster just to start a new session.

the serveradmin_servername groups are purged regularly to prevent any account building too much authority over the infrastructure. These accounts are in the Protected Users group so authentication details are not cached.

Edited October 11, 2023 by psydii

[jthompson]

Yep, similar here.

 

Each file share will have a corresponding pair of "fs_sharename_r" and "fs_sharename_rw" security groups. The only things that get added to those groups will be "role_" security groups (e.g. role_staff, role_student, role_teacher, role_finance_officer, etc). Users are then members of role_ security groups as required.

 

For admin tasks needing higher privileges, signing in to something (either a server or workstation) with a different account is probably going to be needed. The "Run as" mechanism in Windows is designed to behave a bit differently where Explorer is concerned, so you can't really 'elevate' from your regular day-to-day account to do fileshare admin tasks.