Changing CIFS/SMB permissions from the NetApp CLI for an entire volume

I recently came across a scenario a couple weeks ago where my customer had a ONTAP 8.3 CIFS server joined to DomainOLD, they needed to join to DomainNEW. Also, due to recent security changes in the environment, this customer (like many others) had do disable SMBv1 on their Domain Controllers(DCs). This has the side effect of preventing older ONTAP versions from communicating with the DCs. NetApp has a reported BUG (598688) and Knowledge Base (KB) article about this (1000201) In order for this customer to have a proper working environment, ONTAP must be upgraded to a minimum of 9.1P8.

Using guidance from the noted KB article, first we shut down the CIFS vserver:

vserver cifs modify -vserver svm1 -status-admin down

From there, appropriate procedures were followed to updated from ONTAP 8.3.1 to ONTAP 9.1P15. After the nodes stabilized, we finished the rest of the procedure which included disabling SMBv1 DC connections, enabling SMBv2 DC connections and disabling SMBv1 access and then actually changing the domain:

set advanced
vserver cifs security modify -vserver svm1 -smb1-enabled-for-dc-connections false -smb2-enabled-for-dc-connections true
vserver cifs options modify -vserver svm1 -smb1-enabled false
vserver cifs modify -vserver svm1 -domain DomainNEW -status-admin up

This took us through the CIFS setup asking us to supply a username and password with an account capable of adding a machine account to the domain. Success!

The CIFS Shares remained in place. There is no trust between the old and new domains. Therefore, we had to slightly modify the access-lists for the CIFS shares. The usernames are the same in the two domains so it was as simple as removing an share-level access control entry and recreating.

After performing those tasks, we were finally able to see the shares using the new domain. Using File Explorer, we went to \\svm1 and we could see all the shares.

BUT….we were not able to access some of the shares!

It turns out that the accessible shares were UNIX-based security and the non-accessible shares were NTFS-based security. Using the FPolicy ONTAP commands which are available in advanced mode, I was able to see that the OWNER and the discretionary access control list (DACL) both contained entries from the OLD domain. Since there is no trust, how does one fix this?

FILE-DIRECTORY to the rescue!

I found another NetApp KB article (1029805) that was very close to what we needed to do. The title of that article is “Cluster Data ONTAP: How to remove ‘Everyone’ from the file level permissions at the top level of a volume

We wanted to do something similar. Since the customer was OK with reapplying any access-control lists all through the volume, we just used the Brute-Force method and set the same security on the top level directory and all files and folders all the way down. Doing this required a number of commands. Here we go:

First, we start by verifying the security on the top level:

file-directory show -vserver svm1 -path /eng
  (vserver security file-directory show)

                Vserver: svm1
              File Path: /eng
      File Inode Number: 64
         Security Style: ntfs
        Effective Style: ntfs
         DOS Attributes: 10
 DOS Attributes in Text: ---D----
Expanded Dos Attributes: -
           UNIX User Id: 0
          UNIX Group Id: 0
         UNIX Mode Bits: 777
 UNIX Mode Bits in Text: rwxrwxrwx
                   ACLs: NTFS Security Descriptor
                         Control:0x8014
                         Owner:BUILTIN\Administrators
                         Group:BUILTIN\Administrators
                         DACL - ACEs
                           ALLOW-S-1-5-21-296924722-389102597-4211195190-1163-0x1200a9
                           ALLOW-S-1-5-21-296924722-389102597-4211195190-513-0x1f01ff-(Inherited)

Notice the DACLs refer to SIDs. A proper output would have converted the SID to a name that is easily recognized. Additionally, at my customer, the Owner/Group were also SIDs and not nice usernames. Someone had taken ownership.

Here is how we fixed this:

  1. Create a security file-directory policy, associated with your SVM:
file-directory policy create -policy-name MyPolicy -vserver svm1

file-directory policy show
  (vserver security file-directory policy show)
   Vserver          Policy Name
   ------------     --------------
   svm1             MyPolicy
  1. Create a security descriptor that will be used in a security file-directory policy:
file-directory ntfs create -ntfs-sd SD -vserver svm1 -owner juser -group "domain admins"
  (vserver security file-directory ntfs create)

file-directory ntfs show
  (vserver security file-directory ntfs show)

Vserver: svm1

   NTFS Security    Owner Name     Primary            Raw Control
   Descriptor Name                 Group Name         Flags
   ------------     -------------- --------------     --------------
   SD               DEMO\juser     DEMO\Domain Admins -

Note: If you want to change the SD Owner and Group you can use the flags -owner and -group. In my example we will be denying one group (BadGroup), allowing one group (GoodGroup) and allowing one user (MyUser) and setting the top level user to “juser” and the top level group to “Domain Admins.” This only appears to modify the top-most item and does not propagate the owner/group down.

  1. Create a DACL with the users and permissions that will be applied. You might need to run the command multiple times to design a policy that can be used to apply various access control entries (ACEs) to the DACL. 

To view the current ACEs set on the DACL:

file-directory ntfs dacl show
   (vserver security file-directory ntfs dacl show)

Vserver: svm1
   NTFS Security Descriptor Name: SD

    Account Name           Access  Access       Apply To
                           Type    Rights
    --------------         ------- -------      -----------
    BUILTIN\Administrators allow   full-control this-folder, sub-folders, files
    BUILTIN\Users          allow   full-control this-folder, sub-folders, files
    CREATOR OWNER          allow   full-control this-folder, sub-folders, files
    NT AUTHORITY\SYSTEM    allow   full-control this-folder, sub-folders, files
4 entries were displayed.

Note: These 4 ACEs on the DACL are automatically created by system itself when we created the ntfs-sd. Since we don’t want them, we will remove them.

To remove the ACEs from DACL:

file-directory ntfs dacl remove *
   (vserver security file-directory ntfs dacl remove)
4 entries were acted on.

To add ACEs to the DACL:

file-directory ntfs dacl add -vserver svm1 -ntfs-sd SD -access-type allow -account    MyUser -apply-to this-folder,sub-folders,files
  (vserver security file-directory ntfs dacl add)

file-directory ntfs dacl add -vserver svm1 -ntfs-sd SD -access-type allow -account GoodGroup -apply-to this-folder,sub-folders,files
  (vserver security file-directory ntfs dacl add)

file-directory ntfs dacl add -vserver svm1 -ntfs-sd SD -access-type  deny -account  BadGroup -apply-to this-folder,sub-folders,files
  (vserver security file-directory ntfs dacl add)

file-directory ntfs dacl show
  (vserver security file-directory ntfs dacl show)

Vserver: svm1
  NTFS Security Descriptor Name: SD

    Account Name     Access   Access             Apply To
                     Type     Rights
    --------------   -------  -------            -----------
    DEMO\BadGroup    deny     full-control       this-folder, sub-folders, files
    DEMO\GoodGroup   allow    full-control       this-folder, sub-folders, files
    DEMO\MyUser      allow    full-control       this-folder, sub-folders, files
3 entries were displayed.
  1. Add a task to the policy for each path you need to apply a security descriptor to:
file-directory policy task add -policy-name MyPolicy -path /eng -vserver svm1 -ntfs-sd replace -ntfs-sd SD
  (vserver security file-directory policy task add)

file-directory policy task show
  (vserver security file-directory policy task show)

Vserver: svm1
 Policy: MyPolicy

Index  File/Folder Access          Security NTFS        NTFS Security
       Path        Control         Type     Mode        Descriptor Name
----- -----------  --------------- -------- ---------- ---------------
1     /eng         file-directory  ntfs     propagate  SD

Note: By default, a task will run in ‘propagation’ mode, which will propagate inheritable permissions to all subfolders and files. If it is desired to replace the DACLs on all subfolders and files with inheritable permissions, append the flag -ntfs-sd replace which is what I did in the example.

  1. Run a job (task) to apply the policy to a set of files:    
file-directory apply -policy-name MyPolicy
  (vserver security file-directory apply)
[Job 77] Job is queued: Fsecurity Apply. Use the "job show -id 77" command to view the status of this operation.

cluster1::*> job show -id 77
Owning
Job ID Name                 Vserver    Node           State
------ -------------------- ---------- -------------- ----------
77     Fsecurity Apply      cluster1   cluster1-01    Success
       Description: File Directory Security Apply Job

Now we can verify our final result:

file-directory show -vserver svm1 -path /eng
  (vserver security file-directory show)

                Vserver: svm1
              File Path: /eng
      File Inode Number: 64
         Security Style: ntfs
        Effective Style: ntfs
         DOS Attributes: 10
 DOS Attributes in Text: ----D---
Expanded Dos Attributes: -
           UNIX User Id: 0
          UNIX Group Id: 0
         UNIX Mode Bits: 777
 UNIX Mode Bits in Text: rwxrwxrwx
                   ACLs: NTFS Security Descriptor
                         Control:0x8014
                         Owner:DEMO\juser
                         Group:DEMO\Domain Admins
                         DACL - ACEs
                           DENY-DEMO\DnsAdmins-0x1f01ff-OI|CI (Inherited)
                           ALLOW-DEMO\Domain Admins-0x1f01ff-OI|CI (Inherited)
                           ALLOW-DEMO\juser-0x1f01ff-OI|CI (Inherited)

After verifying the Share level Access Control was correct, upon accessing the shares, we had a successful result. The customer was able to go in and modify the file and directory level permissions as needed.                           

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s