SMB cmdlets come in two modules. Before you can really use these in powershell you first need to import them. These are called SmbShare and SmbWitness, so to import the modules:
Import-Module SmbShare
Import-Module SmbWitness
Or for short:
Import-Module Smb*
Once the SMB modules are imported, we’ll start by looking at what shares you’ve got on your system using Get-SmbShare:
Get-SmbShare
Next, we can create a new share with the minimum two pieces of information required and adding who get’s FullAccess, which is not required:
New-SmbShare -Name BAK -Path E:BAK -FullAccess krypted
Then we can provide a little more information if we so choose. Here, I’m going to add a description to the share I just created:
Set-SmbShare -Name BAK -Description "To be used for Windows Backup backups."
Now that we have this BAK share, we can configure who’s able to access it. To see who can access the share, use Get-SmbShareAccess along with the -Name followed by the name of each share you’re curious about:
Get-SmbShareAccess -Name BAK
Note that this -Name structure is consistent with all the smb* cmdlets.
If we want to grant another user access to our share we can go ahead and do so using the Grant-SmbShareAccess cmdlet:
Grant-SmbShareAccess -Name BAK -AccountName krypted1 -AccessRight Full
Now that I’ve given the krypted1 user access to a share, I can remove the initial user krypted since I don’t really like him any more. To do so, use the Revoke-SmbShare cmdlet, again identifying the -Name of the Share followed by the account name to remove access for:
Revoke-SmbShare -Name BAK -AccountName krypted
You can also block a user from accessing a share. If a group is granted access and the user is blocked then the user will stay blocked. To block a user, use the Block-SmbShareAccess cmdlet, identify the -Name of the share and then the users name with the -AccountName option. That krypted user is kinda’ pesky so we’ll go ahead and block him:
Block-SmbShareAccess -Name BAK -AccountName krypted
But then the krypted user ends up needing access, so we’ll unblock him using the Unblock-SmbShareAccess cmdlet with the same syntax:
Unblock-SmbShareAccess -Name -AccountName krypted
Permissions are the next most important aspect of managing access to objects. Just because a user can access a share doesn’t mean they should be able to get into that juicy morsel of a payroll directory. CACLS is the command line interface to manage permissions at the file and directory level. CACLS is not a powershell cmdlet. You can see the permissions of a file or folder using the Get-Acl cmdlet. It’s just a cmdlet that you define a location to show the permissions for. Here, we’ll check the c:SharedPayroll directory:
Get-Acl c:SharedPayroll
Then, there’s the Set-Acl command, which can alter an Acl. As you can imagine, there are a lot of different permissions that can be applied to objects, including the need for recursion and for setting the permissions for recursed objects (OK, OK – I know recursed isn’t really what you might call that, but I’ve always wanted to say it so there ya’ go!). Therefore, instead of taking you through using set-acl I’ll just say, check out the TechNet on it at http://technet.microsoft.com/en-us/library/hh849810.aspx.
Finally, many environment just want the users who can access a share to have the Acl to access the data in the shares. To aid in what should be considered a relatively simple task, you can alter an Acl by piping the output of the get-SmbShare into the Set-Acl command. This sets the Acls to be the same as the permissions set in the share itself:
(Get-SmbShare -Name Bak).PresetPathAcl | Set-Acl