#Global cifs share restrictions

1 messages · Page 1 of 1 (latest)

lunar belfry
#

Does netapp have a way to deny access to ALL cifs shares. I can create a share access policy but don't want to do it for 700 shares. Is there a way to set this at the vserver level? The group is an AD group.

toxic kite
#

So you want no CIFS access anymore for the vserver? I would probably do it by stopping the cifs server on that vserver.
"vserver cifs modify -vserver <Name> -status-admin down" if you want to restore access, you could switch it back to up.

signal aurora
#

I think he means denying access for a single user or group

#

I don't think this is possible other than adding a DENY ACL on every share

toxic kite
signal aurora
#

you could deactivate the account in AD I guess, that should prevent CIFS access to all shares (but also to everything else in the domain...)

#

also, with PowerShell, it is not at all difficult to do that for 700 shares at once

#

I'd be interested in the use-case though. If it's for something like preventing ransomware attacks, there are better solutions for that 🙂

toxic kite
#

or, if it is alwaays the same IP on the user client, you could go with a export policy. but you need to activate it for the vserver first. similiar to how workload security blocks the ip

lunar belfry
#

no, our use case is when certain people go on leave, they are added to a group, that group is set to no-access on the share. I don't want to manage it for every share and every new share that is created. I would like to be able deny access vserver wide the same way we do at the share level.

AD\BADUSERS / No access (but at a global level)

rustic imp
#

You can use powershell, ansible, or leverage excel. A lot of times, I leverage excel in cases like this when I don't want to spend much time scripting a rarely used procedure.

  • Get a list of your shares:
cifs share show -fiel share-n

or, to exclude the default shares...

cifs share show !c$,!admin$,!ipc$ -fiel share-n

The above will output 2 columns (vserver and share name)

  • Copy and paste all output into excel
  • In column C on the 1st row, build out your command:
="cifs access create -vserver "&$A1&" -share "&$B1&" -user-or-group AD\badusers -permission no_access"
  • Copy row C all the way down your sheet. This will produce an individual command for each row (share).
  • Test with row 1. Copy C1 from your sheet and paste in your SSH session.
  • Copy the remaining rows from column C and paste in your SSH session.
  • Verify
cifs share show -acl !*"AD\badusers"* -fiel share-n,acl
cifs share show -acl *"AD\badusers"* -fiel share-n,acl
lunar belfry
#

and when new shares are created they will not have this protection. Like I mentioned, I can do this at the share level, but I don't want to manage it. I want to protect and block at the SVM level.

And I don't think you actually need to do powershell or excel. I think -share-name * will work in this case.

signal aurora
#

I think you cannot do this SVM wide. You either have to do it at the share or NTFS level (deny ACL) or in Active Directory (disabling the user). If you do it at NTFS level and propagate it through, you only need to set it once for each volume (and not with every new share)

wispy gate
#

can always go the route of using SACL/SLAG on the netapp side

#

that can be done on the SVM level

signal aurora
#

you still have to apply SLAG to each volume/path separately (see step 8here). Although it might inherit through if you specify it for the root volume?

lunar belfry
#

NTFS perms are not an option, we are not trying to remove or restrict their access to the files. Just to the shares. These volumes are huge and setting perms would take days, and would be near impossible to restore.

The use case is: person is on leave (we block their access), person comes back (we restore their access). This is done with a group. We want that group to apply cluster wide, so we don't have to remember to add it for every share we create.

signal aurora
#

yeah, the idea was that you would do the NTFS permission thing once, i.e. add a group "on holiday" with a deny ACL, and then just move people in and out of this group. But yeah, you gotta apply this once and it will take ages

lunar belfry
#

I think the DFS team does this at their level, but home-dirs are not pushed through DFS. But doesn't solve the problem once they bypass DFS. I was hoping there was something like we have for backup users but to remove perms vs add them. If not, I think this is worthy of an RFE.

signal aurora
#

But doesn't solve the problem once they bypass DFS
What do you mean? NTFS ACLs apply no matter if you go through DFS or directly to the server

#

I'm not sure the use-case is generic enough to warrant an RFE, but yeah, it would be worth a try I guess

#

just curious, is there a way to do that on Windows Server? Because I can't think of any way other than doing it via ACLs there, too...

lunar belfry
#

no NTFS acl is off the table. There is a way in DFS to set abe where you can block perms in dfs. But if you use a non-dfs path to the netapp share it doesn't apply.