WINDOWS FILE SERVER - SHARES - BEST PRACTISE

[Koldov]

Another issue has meant I need to look into our file server shares and permissions and I need to do some changes, but want to do it safely and with minimum downtime.

 

It's a legacy server (in-place upgraded from 2012R2 and possibly 2008 before that), but the shares themselves have existed since the dawn of time.

 

I haven't had to make many new shares for a very long time (maybe the odd folder here and there) and for the ones I have, I've normally needed them for special purposes, so blocked inheritance and set permissions explicitly. For some parts though I have just followed the settings on all the other folders (one of those is that the users get the NTFS Security permission - FULL CONTROL).

 

Recent comments in other threads though suggest that these settings are at best, not good practise and at worst a security risk.

 

We have a main data drive where the majority of shares reside, and this has the following settings:

 

SHARING

NOT SHARED

 

SECURITY

AUTHENTICATED USERS - MODIFY

SYSTEM - FULL CONTROL

ADMINISTRATORS (SERVER\ADMINISTRATORS) - FULL CONTROL

USERS (SERVER\USERS) - READ & EXECUTE

 

Creating a new folder (as I would to create a new 'root' share) on this drive gives the same default/inherited NTFS Security permissions.

 

Sharing the folder gives the default sharing permission of:

 

EVERYONE - READ

 

So, question... When did that change? I seem to remember the default (and widely repeated best practise) being: EVERYONE - FULL CONTROL for the 'share' permission...

 

However, on the drive I have looked at most of the TOP LEVEL (root?) shares and found the following permissions on the biggest two:

 

STAFF (Inheritance Disabled)

 

SHARING

EVERYONE - FULL CONTROL

 

SECURITY

'STAFF' (SECURITY GROUP) - FULL CONTROL

DOMAIN ADMINISTRATOR - FULL CONTROL

DOMAIN ADMINS (DOMAIN\DOMAIN ADMINS) - FULL CONTROL

 

---------------------------------------------------------------------------

 

ADMIN (Inheritance Disabled)

 

SHARING

EVERYONE - FULL CONTROL

 

SECURITY

'ADMIN' (SECURITY GROUP) - FULL CONTROL

DOMAIN ADMINISTRATOR - FULL CONTROL

DOMAIN ADMINS (DOMAIN\DOMAIN ADMINS) - FULL CONTROL

 

I know this should be basic bread and butter of an IT admin and it's a pretty basic/obvious thing, but these were all created before my time and although I know I need to 'tidy them up' I'm just wary of making changes to hundreds of folders, thousands of files, with data totalling many 100s of GB.

 

Also I think part of the issue is that for the 'special' shared folders I have created, I mostly just made a folder (although inheritance is blocked for them) within one of the other 2 main shares, rather than creating a new 'root' share to save having so many 'drive' letters for all the different shared folders...

 

Anyway, in the first instance I've obviously been advised to 'nuke' the FULL CONTROL (NTFS/SECURITY) permission for any 'standard' user/group. To do this I would just untick it at the root share folder from the 'SECURITY' tab and wait for it to propagate down ignoring any errors when it hits any 'special' folder with inheritance blocked.

 

This shouldn't actually break anything, I hope?

Edited November 7, 2023 by Koldov

[Julian]

Are you running "File Server Resource Manager"?

 

Here is Microsoft desciption of the service

 

Quota management: Limit the space that is allowed for a volume or folder. These limits can be automatically applied to new folders that are created on a volume. You can also define quota templates that can

be applied to new volumes or folders.

 

File Classification Infrastructure: Gain insight into your data by automating classification processes so that you can manage your data more effectively. You can classify files and apply policies based on this classification. Example policies include dynamic access control for restricting access to files, file encryption, and file expiration. Files can be classified automatically by using file classification rules or manually by modifying the properties of a selected file or folder.

 

File Management Tasks: Gain the ability to apply a conditional policy or action to files based on their classification. The conditions of a file management task include the file location, the classification properties, the date the file was created, the last modified date of the file, or the last time the file was accessed. The actions that a file management task can take include the ability to expire files, encrypt files, or run a custom command.

 

File screening management: Control the types of files that the user can store on a file server. You can limit the extension that can be stored on your shared files. For example, you can create a file screen that doesn't allow files with an MP3 extension to be stored in personal shared folders on a file server.

 

Storage reports: Use these reports to help you identify trends in disk usage and how your data is classified. You can also monitor a selected group of users for attempts to save unauthorized files.[/i][/i][/i][/i]

 

I can recoment quotas, to stop disk space being filled.

File Sreening management (pupils are not allowed executable files).

[dmj]

So, question... When did that change? I seem to remember the default (and widely repeated best practise) being: EVERYONE - FULL CONTROL for the 'share' permission...

 

it is the filesystem that holds the ACL's and if you don't want to get in this state again, and you want authorisation and auditing controls then its about time to configure the file system permissions in code.

 

Life would be easier if you separate the concerns of the file system and the server. You should be able to have multiple servers sharing responsibility for CIFS/SMB which get their data from redundant file systems (ZFS is particularly excellent at replication here). I'd be inclined to start this from scratch, migrating the shares out to a ZFS share, setup the permissions as you need, spin up some pods to do the filesharing, test it and then nuke the original server and replicate the data back. It's probably a few days work, but its a LOT safer than hitting a button on production and hoping for the best, and you'll be in a much better place than when you started.

[jthompson]

For the 'special' folders that you've added in in recent times, you can get away with moving those out into separate, distinct shares, which you then present to users via shortcuts in a 'main' share, rather than as additional mapped drives.

 

For each of those, consider creating dedicated security groups that you'd use for providing either read or write access to them.

 

For instance, for an "SLT" folder, you can have that as its own share, with a couple of dedicated security groups (e.g. "fileshare_slt_r" and "fileshare_slt_rw") granted privileges to it in both the filesystem and share ACLs. You would then add users to the relevant security groups as required, so that you'll never have to adjust the folder's ACLs ever again. Ideally, you can add another layer of abstraction to that by instead having security groups representing roles in the organisation (e.g. "role_teacher", "role_slt") that will make managing the membership of those "filesystem_..." security groups even more hands-off.