With your file server service set up, the next step in deploying a file server is to create SMB shares and secure them. For decades, administrators have used the net.exe command to set up shared folders and to do a lot more. These continue to work, but you may find the new cmdlets easier to use, particularly if you're automating large-scale SMB server deployments.
This recipe looks at creating and securing shares on a Server 2019 platform using the PowerShell SMBServer module. You also use cmdlets from the NTFSSecurity module (a third-party module you download from the PS Gallery).
You run this recipe on the file server (FS1) that you set up and hardened in the Setting up and securing your SMB server recipe. In this recipe, you share a folder (C:Foo) on the file server. You created this folder previously. Then, you create a file in the C:Foo folder you just shared and set the ACL for the files to be the same as for the share. You use the Set-SMBPathAcl cmdlet to do this. You then review the ACL for both the folder and the file.
This recipe uses a global security group, Sales, which you create in the Reskit.Org domain. See the introduction section in Chapter 7, Managing Printers, for the script snippet you can use to create the groups, users, and group memberships used by this recipe.
In this recipe, you use the Get-NTFSAccess cmdlet from NTFSSecurity, a third-party module that you downloaded from the PowerShell Gallery. See the Managing NTFS permissions recipe for more details about this module and for instructions on how to download it.
- Discover existing shares and access rights:
Get-SmbShare -Name * | Get-SmbShareAccess | Format-Table -GroupBy Name - Share a folder:
New-SmbShare -Name Foo -Path C:Foo
- Update the share to have a description:
$CHT = @{Confirm=$False} Set-SmbShare -Name Foo -Description 'Foo share for IT' @CHT - Set folder enumeration mode:
$CHT = @{Confirm = $false} Set-SMBShare -Name Foo -FolderEnumerationMode AccessBased @CHT - Set encryption on the
Fooshare:Set-SmbShare –Name Foo -EncryptData $True @CHT
- Remove all access to the
Fooshare:$AHT1 = @{ Name = 'Foo' AccountName = 'Everyone' Confirm = $false } Revoke-SmbShareAccess @AHT1 | Out-Null - Add
ReskitAdministratorto have Read access to the share:$AHT2 = @{ Name = 'foo' AccessRight = 'Read' AccountName = 'ReskitADMINISTRATOR' ConFirm = $false } Grant-SmbShareAccess @AHT2 | Out-Null - Add Full access for the OS:
$AHT3 = @{ Name = 'foo' AccessRight = 'Full' AccountName = 'NT AuthoritySYSTEM' Confirm = $False } Grant-SmbShareAccess @AHT3 | Out-Null - Set Creator/Owner to have Full access:
$AHT4 = @{ Name = 'foo' AccessRight = 'Full' AccountName = 'CREATOR OWNER' Confirm = $False } Grant-SmbShareAccess @AHT4 | Out-Null - Grant
Salesadministrators Read access, and grantSalesAdminsFull access:$AHT5 = @{ Name = 'Foo' AccessRight = 'Read' AccountName = 'Sales' Confirm = $false } Grant-SmbShareAccess @AHT5 | Out-Null $AHT6 = @{ Name = 'Foo' AccessRight = 'Full' AccountName = 'SalesAdmins' Confirm = $false } Grant-SmbShareAccess @AHT6 | Out-Null - Review the ACL on the
Fooshare:Get-SmbShareAccess -Name Foo | Sort-Object AccessRight
- Set the ACL file to be same as the shared ACL:
Set-SmbPathAcl -ShareName 'Foo'
- Create a file in
CFoo:'foo' | Out-File -FilePath C:FooFoo.Txt
- Set the ACL file to be same as the shared ACL:
Set-SmbPathAcl -ShareName 'Foo'
- View the ACL folder using
Get-NTFSAccess:Get-NTFSAccess -Path C:Foo | Format-Table -AutoSize
- View the ACL file:
Get-NTFSAccess -Path C:FooFoo.Txt | Format-Table -AutoSize
In step 1, you look at the existing shares and access rights, which looks like this:
In step 2, you create a new SMB share (Foo) on the C:Foo folder, which looks like this:
With step 3, you add a description to the share. In step 4, you set the share enumeration mode to AccessBased. In step 5, you set encryption for data sent to/from the Foo share. With step 6, you explicitly remove all access to the Foo share. In step 7, you enable ReskitAdministrator to have read-only access to the share. In step 8, you enable the OS to have full access to the share, while in step 9, you allow the creator or owner full access to files or folders in the share. In step 10, you grant all members of the Sales group read access to data on the share, and you grant members of the SalesAdmins group full access to the share. Step 3 through step 10 produce no output.
After configuring access to the share, in step 11, you use the Get-SMBShareAccess cmdlet to view the Foo share's ACL, which looks like this:
In step 12, you set the NTFS ACL file/folder to be same as the ACL for the share, which produces no output. With step 13, you create a new file in the C:Foo folder. These two steps produce no output.
In step 14, you view the updated ACL on the C:Foo folder itself, which looks like this:
Finally, in step 15, you view the ACL for the file you created in step 13, which looks like this:
In step 1, you examined the existing SMB shares. This step is run on the FS1 file server after you've hardened it (see the Creating and securing an SMB file server recipe). Thus, all the default shares (except the IPC$ share) aren't present on FS1.
The IPC$ share is also known as the null session connection. This session connection enables anonymous users to enumerate the names of domain accounts and network shares. The lanmanserver service creates this share by default, although you can turn it off. The IPC$ share is also used to support named pipe connections to your server.
In step 4, you set the enumeration mode on the Foo share to AccessBased. This means that when you're browsing folders and files within this share, you only see the objects you have access to. There is an improvement in security (as people can't see files they have no access to), but this does introduce a small performance penalty.
In step 5, you set up this share to encrypt data sent to/from the share. This overrides the overall server configuration you set in the Setting up and securing an SMB file server recipe.
In step 14 and step 15, you examined the ACLs on the underlying folder and file after setting NTFS permissions on C:Foo to be the same as for the Foo share. Since you didn't remove inheritance from the C:Foo folder in this recipe, you can see that some users still have access (due to inheritance) to the files and files in the folder. To further secure this folder, you should remove NTFS inheritance from the C:Foo folder.
For details about IPC$ share, see https://support.microsoft.com/en-in/help/3034016/ipc-share-and-null-session-behavior-in-windows. Be careful if you chose to turn off the IPC$ share—test the resulting configuration very carefully.