#Can I leverage NetApp PowerShell to add NTFS Security permissions to my CIFS Shares?

1 messages · Page 1 of 1 (latest)

static mason
#

It seems like there's no way to do what I want: We have a ton of CIFS shares hosted by our NetApp. We need to add a new AD account (let's call it "BackupCIFS") to the NTFS Security permissions tab of every CIFS share hosted by this NetApp (over 400 shares)

After a bunch of research, from NetApp CLI doesn't look like it's doable. This command: vserver cifs share access-control create -vserver <vserver> -server -share <share> -user-or-group <account> -permission modify works beautifully.............to add the account to the "Network Sharing" tab of the CIFS shares (same as adding the account to the "Shares" fields in System Manager).

But I cannot find a NetApp CLI command to do the exact same to the NTFS security tab.

The closest thing I have found is: vserver security file-directory ntfs dacl add -vserver <vserver> -ntfs-sd <newSD> -access-type allow -account <account> -rights read -apply-to this-folder

But this command looks like it only create a new Security Descriptor and the correct DACLs/ACEs to it. So I end up with an unused Security Descriptor.

Ok, so then, I try to leverage the NetApp PowerShell Toolkit. Mind you my PowerShell is beginner level right now. I install the Toolkit (the latest one, 9.15.x). Then I look up some NetApp PowerShell commands, such as:

Get-NcCifsShare -Name - it works, but I don't understand the Security Descriptor output, and it only displays the BUILTIN accounts assigned to the share (I don't see the AD accounts, for example)

Get-NcNtfsEffectiveAccess
Set-NcNtfsAccess

I got these commands by asking Copilot for NetApp PowerShell commands and it gave me those, but when I look up the available cmdlets using "Get-NcCommand", I have absolutely zero cmdlets available that have anything to do with NTFS.

So either the AI hallucinated those commands into existence, or I am missing something.

Is there any way I can get my task done either from the CLI or PowerShell?

visual raft
#

it's an AI. Of course it hallucinates things

#

and you can't find commandlets for NTFS, because CIFS share permissions don't have anything to do with NTFS (in fact they were implemented for file servers with FAT partitions, that's why with NTFS you usually set them to "everyone/full control")

#

I think what you want is the add-NcCifsShareAcl commandlet (if I remember the name correctly). You can get the documentation for that by using get-help -full add-NcCifsShareAcl

static mason
static mason
#

tested the cmdlet above. It add an accound to the Network Sharing tab, but not to the NTFS Security tab. I found a kb that allow the NTFS Security to be reset from the NetApp CLI: https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/How_to_reset_NTFS_permissions_on_a_CIFS_share_created_on_the_root_of_the_Volume_or_Qtree. However, this looks like it's a brute force approach. I tested it, and it resets the entire NTFS Security, removing any accounts currently there, and adding the accounts in the created Security Descriptor (by default a bunch of BuiltIn accounts). It "works" but sadly not what I need. I'll keep on researching. If you or someone else has any ideas, I'd love to hear them.

visual raft
#

well, you said you wanted to "add permissions to your CIFS share"

#

to add NTFS security to the underlying file system, you can just mount it to any Windows client (which can be automated) and then use windows' own ACL-modifying tools (e.g. iacls.exe, cacls.exe or the set-acl commandlet). No need for any netapp-specific tools in that case

#

but if all you need is to give the "BackupCIFS" users permissions to read any files from the share, there's actually a simpler way to do that which is instantaneous and doesn't involve ACLs at all

#

I don't know if that works for you (since you specifically asked to do it via ACLs so you might have some particular use-case) but maybe look up the documentation on vserver cifs users-and-groups privilege add-privilege, and the corresponding Windows privileges SeBackupPrivilege and SeTcbPrivilege, to see if that might solve your problem

static mason
#

Hmm, ok all very good insights. I will look into these further. I have tried the Set-Acl cmdlet, but it keeps complaining, and some research suggests it's due to it relying on some Windows API (could be related to the SeBackupPrivilege you mentioned) that the NetApp CIFS server does not support. My case scenario is this: We need to backup some CIFS Shares hosted on our NetApp with Veeam Backup and Replication server. My company bought a licence for this before asking me to research it, in belief that this tool backed up at the block level (Snapmirror). It doesn't. It backs up by logging onto the Share and grabbing its content. So what that means is every single share need to have the service account we want to use, added to Network Sharing AND NTFS Security tabs with at least "read" access. So the daunting task of editing over 400 Shares.

#

I have been trying different approaches. For example, this article https://www.craig-tolley.co.uk/2016/02/09/assigning-permissions-to-a-volume-through-the-netapp-powershell-toolkit/. has a very good script to add NTFS ACLs........but it's exactly the same approach as the KB I linked to before. It will brute force replace the Security Descriptor on the Share with the one you configure. Not a big deal, except a ton of the CIFS share we have have specific accounts to the NTFS Security ACL that have been added over time, and blowing them away would be catastrophic.

Weird & Wonderful IT
Craig
Assigning permissions to a volume through the NetApp PowerShell Too...
runic berry
#

ONTAP API, via PowerShell, is not the correct implement to set file access permissions. It is effective for resetting share level permissions, or setting group memberships at the SVM level (Computer) for privilege inheritance.

I am assuming you know about file level permissions and share level permissions, and whichever is the most restrictive is used, effectively you must pass through both ACL filters to gain access at a specified level, i.e. Read or Write. There are also Privileges, such as Take Ownership, Backup or Restore, which give accounts special abilities to reset the ownership of files/folders or ignore permissions when a file is open with a backup/restore context.

#

Assuming that the account that will be running the PowerShell script is in the Administrator group of the SVM which contains the shares, you will have the necessary permissions to set share level ACL’s. From your post it looks like you have share level permissions taken care of, so I am going to ignore that part, other than to say make sure the account/group you want to add to your file level ACL’s also is allowed through at the share level. Okay, one more caveat, I promise… Since you said this account is for backing up, if it is given the Backup privilege, and opens file access using a backup context, it can ignore permissions. If it needs to restore, it will need the Restore privilege to replace files/folders regardless of permissions. Something to look in to, however I am going to proceed assuming it does not because you are rolling your own.

#

You can use PowerShell native functions to manage ACL’s fairly well, where those are limited, you can use .NET instantiation, and if those fail you can import Win32 DLL’s to access the native windows functions. Once thing to note is that PowerShell, even when launched fully elevated, strips privileges on its process, that the user token is entitled to, when UAC is enabled, so you cannot take ownership of files/folders without adding that privilege back to the PowerShell process. This is the error that you are receiving about the SeBackupPrivilege, SeRestorePrivilege, or SeTakeOwnershipPrivilege. It is not that NetApp does not support these, it is that PowerShell has striped these privileges from its process, since UAC is enabled, and you have to add them back.

#

Below is what you can add to your script to restore the privileges:

#

If you want to add the Take Ownership permission, you would call the function like this:
enable-privilege SeTakeOwnershipPrivilege | Out-Null

This must be done before any cmdlet is called in the same script, such as Set-ACL, and of course the account PowerShell is running under must be entitled to this privilege.

#

In your case, you are going to want to read the ACL's of the existing root folder, then add the account/group and its permission levels to that ACL list, then inject that modified ACL list back on to the root folder. I think what you might be having problems with is your are writing a new ACL that only contains the new account/group. It is Set-ACL, not Add-ACL.

static mason
#

"Okay, one more caveat, I promise… Since you said this account is for backing up, if it is given the Backup privilege, and opens file access using a backup context, it can ignore permissions. If it needs to restore, it will need the Restore privilege to replace files/folders regardless of permissions. " I confirmed this only works if the folders being backed up are on a Windows Server. NetApp CIFS shares apparently do not use Backup Operators or SeBackup privilege. I could be wrong. I am reading the rest of your post.....

runic berry
#

Here is a list of privileges support by NetApp:

static mason
#

ok thank you for all this information @runic berry , I will read it carefully and try to implement it tomorrow during the day

runic berry
#

So in order to use the backup or restore privilege, the account invoking that privilege must be a member of the Administrators or Backup Operators group on the SVM, by default

#

If you want to modify the defaults, here you go:

static mason
#

Ok, help me to understand some of this. On the test Share I was playing around with, I created: New NetApp Volume, then mounted it, let's call it /NetAppCIFS, then I added a share to it called "CIFSShare". If I look at it in Windows File Manager, it has "Everyone" in both Network Sharing and NTFS Security permissions tab. If I do a NetApp show command to display info about the Security Descriptor on the NetApp CLI for that volume, it doesn't have a NetApp Security Descriptor attached at all. When I add a new account at the Network Sharing tab level, it works fine, it adds the account. Sooooo let's pivot a little bit

#

If I add Backup Operators group to the AD service account I want to use, then according to that NetApp doc, the Backup Operators SeBackupPrivilege is supported, sooo......

#

where do I add this to the NetApp default Security Descriptor?

#

If I use the NetApp processes to reset the NTFS permission, it brute forces a new SD to the Share, and adds the permissions on the new SD, but wipes out any previous permissions

runic berry
#

Are you familiar with shares when they are hosted on a Windows Server?

static mason
#

to some degree. I understand the difference between Share and File level permissions. Share level is what's in Network Sharing tab

#

this is for Network authorization to the Share

#

File level is what you add to the NTFS Security tab to lock down at the file level

#

if you have everyone in Sharing, but only Read for Admin in NTFS security, it will go by NTFS security

#

the Backup Operators is supposed to be an exeption to that

runic berry
#

Yep, are familiar with managing Windows Server shares, like though Computer Management MMC?

static mason
#

yes to some degress as well. You go to the two different tabs, add accounts as required, and add permissions to the accounts also as required

runic berry
#

Okay, Backup/Restore privilege is a file system right, not a network share right. You cannot get around the network share permissions, except via the Admin$ share.

static mason
#

if you have an account that's part of the "Backup Operators" group, you should be able to add it to Network Sharing tab, and NTFS Security tab with read access, and it will read the files using SeBackupPrivilege

runic berry
#

you can get around the file system permissions with a privilege

static mason
#

ok, so does that mean if the account, let's call it "DOMAIN\BackupCIFS" is part of Backup Operators group, what do I need to do to get it to read the files on the share to back them up?

runic berry
#

correct, you will need to add the account/group to the network share and if it is entitled, and it is invoked, you can use the backup/restore privilege to ignore permissions

static mason
#

ok, I only need to add the account to the Network Sharing tab, and not the NTFS security tab?

runic berry
#

all of these statements needs to be correct for that to work:

#

you will need to add the account/group to the network share

#

it needs to be entitled with the backup/restore privilege

#

the process performing the backup/restore needs to invoke the privilege, known as using the backup or restore file context, basically it's the way it opens or saves the file/folder

#

list done

static mason
#

ok that third statement is where we got stuck

runic berry
#

let me ask this... what is going to be backing up the share?

static mason
#

it's a Veeam Backup and Restore server

#

sorry Backup and Replication

runic berry
#

Veeam supports that. Even if you use something like Robocopy, there is a flag to use these privileges.

static mason
#

We have it set up as per their instructions. Set as NAS Filer, and it attempts to connect to the share at the file level with SMB, and authenticate to the share using the service account we set up

runic berry
#

that service account should have the SeBackupPrivilege and SeRestorePrivilege on the SVM

static mason
#

The backup will work when the Share in question has the service account added to the Network Sharing tab, and the NTFS Security tab with at least "read" access

#

it will fail if the NTFS Security does not have the service account in it

runic berry
#

You have tested this?

static mason
runic berry
#

with the privilige entitled?

static mason
#

what command do I use to add the SeBackupPrivilege to the account?

#

can I do this from the NetApp CLI?

#

Do I use this command? vserver cifs share access-control create

runic berry
#

is there a reason to not add the service account to the Backup Operators group of the SVM, rather than restructure the privilege list?

static mason
#

no reason other than my lack of knowledge how to do it

#

looks like the command might be this one? vserver cifs users-and-groups privilege add-privilege -vserver vs1 -user-or-group-name CIFS_SERVER\sue -privileges SeTcbPrivilege,SeTakeOwnershipPrivilege

#

I just need to update it for my case scenario

runic berry
#

Okay, super easy. You can use the Computer Management MMC to connect to the SVM management IP like it was a windows server and then add the service account to the Backup Operators group under: Computer Management > System Tools > Local USers and Groups > Groups

static mason
#

is it that simple?

runic berry
#

as simple as it's going to get, lol

static mason
#

wow

runic berry
#

there is a ontap cli command and I'll get that for you too

static mason
#

I have spent the past couple of days researching, and I've opened a couple of NetApp AND Veeam tickets

runic berry
#

one second

static mason
#

the final verdict was NetApp CIFS did not support SePrivilege

runic berry
static mason
#

cool, appreciate the help, if it's as easy as adding the service account to the Backup Operators group on the SVM, that will basically solve all our problems in one shot

runic berry
#

so lets say the service account is YOURDOMAIN\Service_Account

static mason
#

no need to bother with PowerShell or adding accounts to the File Permissions DACL

runic berry
#

you SVM is named FILESERVER

#

vserver cifs users-and-groups local-group add-members -vserver FILESERVER -group-name 'Backup Operators' -member-names YOURDOMAIN\Service_Account

#

might have to put things in quotes if there are spaces

static mason
#

ok perfect

#

I will try this tomorrow

runic berry
#

good luck my dude

#

let me know how it goes

static mason
runic berry
#

it sure is hard to backup and restore files if the backup server doesn;t have access

static mason
#

basically the SVM has to be aware the account has SeBackupPrivilege, it's not enough to just have it at the AD level (by adding the service account to the Backup Operators group). We also need to add that service account to the BUILTIN Backup Operators group on the local SVM CIFS server, is that getting the gist of it?

runic berry
#

So you may be a little confused. Every Windows computer has default local accounts and groups. Let's focus on the Administrators group. Let's also focus on something like your workstation computer, and lets name it YOURCOMPUTER. If your computer was not joined to the domain, and you wanted to logon using the Administrator account, which by default would be a member of the Administrators local group, over the network your account would be YOURCOMPUTER\Administrator. Now if your joined YOURCOMPUTER to the domain MYDOMAIN, the Domain Administrators group existing on MYDOMAIN would get added to the YOURCOMPUTER\Administrators group. Then any account that was a member of the domain MYDOMAIN\Domain Administrators group , such as the domain Administrator account, would have administrator privileges on YOURCOMPUTER. So over the network you could logon to YOURCOMPUTER using MYDOMAIN\Administrator or MYCOMPUTER\Administrator, however they are two different accounts. The domain account is valid for all member computers, and the local account is valid for only your computer. What is important to understand is that a Domain Controller's default local groups get transformed in to domain groups and are shared across all Domain Controllers. Why I have gone in to all this mess is that when you add a user/group in to AD Backup Operators group, that is only valid for domain controllers and not all member computers.

#

Typically you would use Group Policy to modify member servers to add an account to member computers Backup Operators group. Since NetApp does not use Group Policy, you have to add it manually.

static mason
#

aha

#

ok thank you

#

I "kind" of understood those concepts, but you just explained them in a perfect way that makes 100% sense to me

runic berry
#

I hope to hear good news tomorrow and that you are up and running!

static mason
#

Will let you know for sure, friend!

visual raft
#

again, if all you want is an account to read all files regardless of ACLs, then just set the SeTcbPrivilege and SeBackupPrivilege on that account using the command I specified above. No need to mess with your ACLs at all

static mason
#

yes, @visual raft @runic berry I have tried this today (adding SeTcbPrivilege and SeBackupPrivilege with the command you both provided) and it seems to be working as intended. I am still testing it but so far it's been able to grab every share successfully