Assigning permissions to a volume through the NetApp PowerShell Toolkit

As part of my work to automate as much as I can, both to reduce time and increase consistency, I was looking for a way to assign permissions to a newly created volume which was providing a CIFS share through our NetApp FAS unit.

Normally I would use the Get/Set-Acl cmdlets that are provided through Windows, however this was not an option as the machine that is running the script to create the volume does not have access to the network on which the volume was going to be accessed. The script only has access to the management lif on the NetApp.

The DataOnTap PowerShell toolkit has a series of commands which can set file and directory permissions, however, the documentation isn’t the most clear, and working out the correct order and requirements is a little challenging. To view a list of all the commands related to setting file and directory security, enter the following into your PS session:

Get-Command *NcFileDirectorySecurity*

There is no equivalent commands (that I could quickly find) built in DataOnTap for 7-mode – and as they don’t exist now, I don’t imagine they will be added.

The Script

This is the excerpt of script that I am running. I have broken down the script and explained each part below – however for those wishing to dive right in, here you go:

$VolName = “MyVolName”
$Vserver = “vs1”

# Create the ACL to apply. 
# ACL has some ACEs created by default, so after creation clear everything.
New-NcFileDirectorySecurityNtfs -SecurityDescriptor $VolName -VserverContext $Vserver
Get-NcFileDirectorySecurityNtfsDacl -SecurityDescriptor $VolName | Remove-NcFileDirectorySecurityNtfsDacl

# Add in the permissions that we want (can be DACL or SACL)
Add-NcFileDirectorySecurityNtfsDacl -Account "DOMAIN\Domain Admins" -AccessType allow -Rights full_control -NtfsSd $VolName -VserverContext $Vserver
Add-NcFileDirectorySecurityNtfsDacl -Account "DOMAIN\MyVolNameUsers" -AccessType allow -Rights modify -NtfsSd $VolName -VserverContext $Vserver

# Create a Policy Task to apply the permissions, and then apply them
Add-NcFileDirectorySecurityPolicyTask -Name $VolName -SecurityType ntfs -VserverContext $Vserver -Path "/$VolName" –NtfsSecurityDescriptor $VolName
Set-NcFileDirectorySecurity -Name $VolName -VserverContext $Vserver

# Sleep required else the policy tries to be removed when it is still in use
Start-Sleep -Seconds 5

# Cleanup the created objects. This does not remove the applied permissions
Remove-NcFileDirectorySecurityPolicy -Name $VolName -VserverContext $Vserver
Remove-NcFileDirectorySecurityNtfs -SecurityDescriptor $VolName -VserverContext $Vserver

Getting Information about Current Permissions

It is important to know what is already applied before making changes. The Get-NcFileDirectorySecurity cmdlet can be used to interrogate the permissions assigned to any object that the NetApp can see. Permissions can be looked at for any object in a NAS volume.

To show the permissions on $VolName that we are working with in this example run this command:

Get-NcFileDirectorySecurity –Path “/$VolName

In this example it assumes that the volume is mounted to a junction path with the same name as the volume itself.

Steps

The most important part of this process is knowing the correct order to apply the settings with. Once you know the order, it becomes quite easy.

In the example here, I have already created a new volume, and the name of the volume is stored in the $VolName variable. The SVM/vServer that I am using is stored in $Vserver

Like most of the CDot management, permissions are based on policies that are then applied to objects.

Step 1 – Create a Policy

New-NcFileDirectorySecurityNtfs -SecurityDescriptor $VolName -VserverContext $Vserver

In this, a new policy is created. The SecurityDescripter is actually a name – it does not have to be the volume name. I find that it is easier to call the policy something meaningful in case the script fails and requires cleanup.

To verify that your new policy is created run:

Get-NcFileDirectorySecurityNtfs –SecurityDescriptor $VolName

The SecurityDescriptor parameter can be omitted to get all the policies on the cluster.

Step 2 – Remove the default permissions assigned (optional)

When you look at the new policy that has been created, you should see that a default set of permissions has been created and assigned to the policy. This is a bit like Windows, and you get SYSTEM, CREATOR OWNER, etc. In my case, I was going to be stripping these out, so wanted to remove them. The simple way to do this:

Get-NcFileDirectorySecurityNtfsDacl -SecurityDescriptor $VolName | Remove-NcFileDirectorySecurityNtfsDacl

What this is doing, is pulling all of the Discretionary ACLs from the policy and then removing them.

There is no need to do this for the System ACLs (for auditing) as no SACLs are created by default

Step 3 – Add in your new DACLs and SACLs

This is like adding in permissions to your Windows ACL list. This can be repeated as many times as you want to create the permissions that you want to apply to the object.

Add-NcFileDirectorySecurityNtfsDacl -Account "MINTS\Domain Admins" -AccessType allow -Rights full_control -NtfsSd $VolName -VserverContext $Vserver

Confusingly, they change terminology in this cmdlet. The NtfsSd parameter is the same as SecurityDescriptor in the previous examples.

You can keep using the Get-NcFileDirectorySecurityNtfsDacl cmdlet from step 2 to check your work. The Add/Set/Remove commands all use the same syntax format, so you can modify the rules until you get them as you want.

Note: The Netapp Modify rights is subtly different to Windows. Netapp Modify includes the Delete Subfolders and Files rights, which Windows Modify does not. This shows as the user having a special permission when looking through Windows.

Step 4 – Add a Policy Task

This step links the policy that you have now created to an object. Once again I have used the volume name that I am applying to as the Name of the policy, so it is clear what it applies to. You can choose whatever name you want though.

Add-NcFileDirectorySecurityPolicyTask -Name $VolName -SecurityType ntfs -VserverContext $Vserver -Path "/$VolName" –NtfsSecurityDescriptor $VolName

It is worth adding here that until this point the policy you have created can be applied to any number of objects, and can even be used as a template for future use. In my case it is a one off application. You could also schedule a job to reapply this policy at a given time if that is what your business requirements dictate.

Step 5 – Apply the Policy

Despite having linked the policy to an object, the permissions that you have defined have not yet been applied to your object. This last step is required to actually set the permission.

Set-NcFileDirectorySecurity -Name $VolName -VserverContext $Vserver

Step 6 – Cleanup

Once the policy and task have been used, unless you want to keep them for re-use on other objects or to reapply the permissions on a schedule, you can remove them. Now that the permissions have been applied to the object they no longer require the task or policy to remain.

These lines remove the Task and the Policy.

Remove-NcFileDirectorySecurityPolicy -Name $VolName -VserverContext $Vserver
Remove-NcFileDirectorySecurityNtfs -SecurityDescriptor $VolName -VserverContext $Vserver

If you are scripting this, then you may need to put a pause in here between steps 5 and 6. I found in testing that the removal attempted to happen before the Set above had actually completed properly, causing the Remove job to fail as the object it was removing was still in use by an active task. Unfortunately the Set task did not return a Job Id that could be used to track the status. There is probably a way of finding this, but I did not look into it.