Windows Server 2019 – Prt.4 Installing and Configuring File Server Roles

Windows Server 2019 – Prt.4 Installing and Configuring File Server Roles

Introduction

In part four of this series, we will be installing and configuring the File and Storage Services role onto our Windows Server 2019 server. In windows server 2019 they have a bunch of new features for us to play around with. But for this first part of the File Server guide, we will be touching base on the basics and one of the most common practices for File Server setups. If you want to read up on what’s new on Windows Server 2019 Storage, check out the Microsoft Docs which are continuously updated as new features are released.

CHANGE NOTE

Before we begin with the file server setup and configuration, a few changes have been made to the environment since Part 1 and Part 3. Note that these changes are not required on your side, these are due to LAB environment migration off my home network.

  • Environment moved from 10.0.1.x subnet to 10.0.2.x subnet.
  • DHCP & DNS re-configured to reflect 10.0.2.x subnet
  • Implementation of PFSense for Virtual Routing: Note that Hyper-V doesn’t have native vRouting, I will make a guide on Hyper-V virtual networking in a later guide.


Prerequisites

  • New server/virtual machine provisioned with Windows Server 2019
  • Server re-named
  • Server domain joined
  • Server has a static IP
  • Physical storage setup and configured, whether that be a NAS with RAID setup, single SSD/HDD for lab environment, etc.
    Physical storage Infrastructure/management is an entirely different topic that I might cover in a later post.
  • Naked provisioned drive with nothing in it (Storage size as required)

In my environment I will have the following prepared:

Server Name Server IP Roles & Products
ITSTG-NSW-DC01
(Domain Controller)
10.0.2.40 Active Directory Domain Controller, DNS, DHCP
ITSTG-NSW-FP01
(File Server)
10.0.2.44 File and Storage Services (not added yet)
ITSTG-NSW-PFSENSE
(Virtual Router)
10.0.2.1 DHCP Relay, WAN Access

Let’s not waste anymore time and cut to it! Throughout the setup I’ll touch on different things and dive a little deeper into each topic.

Installing File and Storage Services Role

  • Open Server Manager > Manage > Add Roles and Features
  • Click Next on the Before you begin wizard
  • Select Role-based or feature-based installation and Next
  • Select the file server you wish to install the role onto and click Next
    File Server Config Server
  • Select File and iSCSI Services, and File server, click Next.
    By default you should already have File and Storage Services, and Storage Services installed. (we will cover data replication methods in a later guide).
    File Server Roles
  • No features are required, click Next
  • Review your configurations and click Install
  • Click close once completed
    File Server Complete Wizard

As you can see, the installation of the File Server role is pretty simple. A lot of the power behind this, is when we start to dive into other roles such as DFS-N, DFS-R, Duplication and shadow copy.

When building a file server, its more a case by case scenario depending on the clients requirements. What we have here would suffice for a small business that have 100 users or less, the load on the disk is low, and they have a good backup solution in place for disaster recovery. 

In later guides, we will build another file server for load balancing across multiple sites. Looking into DFS-R and DFS-N.

Configuring File Share

During this phase, I will assume you have provisioned your NTFS or REFS volume. I will be creating a blog on which is better to use and when to use NTFS or REFS. In this case, I will be using 100GB NTFS volume.

  • Open Server Manager, on the left you should see File and Storage Services
  • Navigate to Shares and click To create a file share, start the New Share Wizard
    File Server Share
  • Select the File share profile that suites your needs. In my case, I will be using SMB Share – Quick for general windows environment file sharing (in most cases this will suffice unless your requirements meet one of the profiles needs). I will also be showing how to upgrade your SMB Share – Quick to an Advanced Share, because you will come across cases where the SMB Share Quick has been setup and have a requirement to use Advanced with the File Server Resource Manager role installed. click Next
    Profile Description
    SMB Share – Quick This basic profile represents the fastest way to create an SMB file share, typically used to share files with Windows-based computers.

     

    • Suitable for general file sharing
    • Advanced options can be configured later by using the Properties dialog
    SMB Share – Advanced This advanced profile offers additional options to configure a SMB file share.

     

    • Set the folder owners for access-denied assistance
    • Configure default classification of data in the folder for management and access policies
    • Enable quotas
    SMB Share – Applications This profile creates an SMB file share with settings appropriate for Hyper-V, certain databases, and other server applications.
    NFS Share – Quick This basic profile represents the fastest way to create a NFS file share, typically used to share files with UNIX-based computers.

     

    • Suitable for general file sharing
    • Advanced options can be configured later by using the Properties dialog
    NFS Share – Advanced This advanced profile offers additional options to configure a NFS file share.

     

    • Set the folder owners for access-denied assistance
    • Configure default classification of data in the folder for management and access policies
    • Enable quotas

    NOTE: in order to use the Advanced and Applications profile, you need to install and configure the File Server Resource Manager first.
    File Server SMB Wizard

  • Select the volume for your data share. Best practice is to place the data share on a separate volume and create a share folder on the root drive. By default it will call the folder “share”. Click Next.
    File Server Volume Drive
  • Create your share name, notice that the remote path to share will update the UNC to reflect your share name. Click Next.
    NOTE: If the folder does not exist, you will be prompted if you would like it created for you.
    File Server Share Name
  • Select the required options that suites your business needs. In my case, I will be enabling Enable access-based enumeration and Allow caching of share.
    These three options are security features that need to be discussed as a business and align with the business security best practices.
    In this case I don’t wish for general staff to see that the HR data folder is in the same location as the Sales and generals folder. To best address this issue, enabling Enable access-based enumeration will solve this.
    I would also like users to be able to read contents offline, in case they wish to work on the files at home and sync back to the file server when they come online. Enabling allow caching of shares will also address this issue.
    To read more about Share Folders, please read the Microsoft Docs.
    File Server Share Configurations
  • For demonstration purposes, I’ll be leaving the root permissions to the native inherited permissions and show you how to modify these permissions another way. 
    Best Practice is to customise permissions, disable inherited permissions, then remove all BUILTIN\ principals, add domain\admins and then create delegated privileges group to your root folder and sub-folders.  Click Next.
    File Server Specific Permissions
  • Confirm all your configurations are correct and meet your requirements, then click Create.
  • Once created and successful, close the wizard.
    FS SMB Completed

You should now see the share under your server manager shares list, and if you check the properties of your share folder, you should see the UNC path added to the folder.
FS Share Test 01

Testing Share and Permissions

Now that we have our share setup, it’s time to test it out and confirm we have it all working. For this, inside the share folder I have created the following folders with Active Directory Security Groups:

Folder Name AD Security Group Allocated Users
Data Root SG-DATA Adding root folder security for administrators
HR SG-DATA-HR None: Testing for Enabled access enumeration
Sales SG-DATA-SALES None: Testing for Enabled access enumeration
Engineers SG-DATA-ENG Bill Shorton

Share folder security group naming convention best practices, is to make them clear and direct. When you look at the policy, it should reflect a folder path tree that allows you to navigate to where that file or folder is located.
For example:
DATA-HR > Located in the DATA folder of the file server and it will either be an HR file or folder.
You can break this down to even the type of access privileges they have, since this is a root folder of that particular department, for example:
DATA-HR-RW > Located in the DATA folder of the file server and it will either be an HR file or folder, with Read and Write privileges.
DATA-HR-RO > Located in the DATA folder of the file server and it will either be an HR file or folder, with Read Only privileges.
Going off this table, when I login to the Windows 10 machine, I should only be able to see the Engineers folder in the share.

Root Folder NTFS Permissions

On the root folder, I will be tightening up the security and making it(security) more controlled. The first thing I will do is disable inherited permissions on the root share, this so we can remove all the default system permissions. Ideally, we want to tighten the access of these files, only to domain users. This mitigates access from external local users, if for whatever reason those credentials were breached.

NOTE: It’s always Best Practice to NEVER add users directly to a share permissions. It’s always Best Practice to create Root Permission Group and Sub-Folder Permissions Groups, then add and remove users from the groups.

A common scenario you will see, are permission tress breaking due to this exact reason. When you have a small share, it can be easy to recover, but when you deal with massive shares with lots of departments and users coming and going, accessing and modifying files and folders, this can become a massive issue and hard to recover from. In most cases you need to recover from backup, or export a backups permission tree and re-write the permission tree to production, which can take hours.

  • Server Manager > File and Storage Services > Shares
  • Right click the share you just created and select properties
  • In the properties of the share, select permissions and Customise permissions
    File Server CORPDATA Permissions
  • First thing, click Disable inheritance and accept the pop-up
  • Next, remove all the users from the list
  • Next, add your SYSTEMS with Read & Write, Domain Admins with the default permissions plus modify permissions, add your root security group (in my case its SG-DATA) with default permissions BUT set the applies to “This folder only”.
    It should look something similar to this:
    File Server Advanced Permissions
  • Click Apply on both the advanced security settings and the share configurations.

Once you have added the user to the security group, you should be able to UNC to the data share and see the sub-folders we created.
FS Folders

Sub-folder NTFS Permissions

That’s great we can share a folder with root permissions, but what happens when we want to restrict the access of our sub-folders? We might have some sensitive data in our HR and Sales folder that we don’t want our Engineers to see. 

First thing, create a the AD security groups for each of your sub-folders you want protect. In the above table you can see the security groups I created, and I added each one to the respective sub-folders. I only added bill to the engineers security group, so lets see what happens once we UNC to the ITSTG-NSW-FP01\CorpData share:
FS Completed

You will notice that the only folder I can see is the Engineers folder on the share. This is wonderful! That means our “Access-Based Enumeration” is working!

If we try and UNC to the HR folder, you can see we get an error stating windows connot access the HR folder/share, which demonstrates our permissions are working as expected.
FS UNC Test 02

As you dive deeper into the rabbit hole of sub-folders, you continue to follow this process of quality controlled permissions for restricted access. Just remember, at times it’s best to cut the rabbit hole short and create a new share for restricted access for a particular group, department or project, than to have a sub-folder tree of twenty folders deep and twenty permission groups big. Always plan out your file and folder structure before implementation, that way creating security groups will be a much cleaner and controlled process.

This post was a little longer than expected, but I figured I’d dive a little deeper into NTFS permissions. I see the common issue of poor permission control, broken permission trees, etc. It’s something if you do right from the start, you won’t have issues down the track.

Pt.5: YET TO COME!

Leave a Reply

Close Menu