There are different methods of creating and managing an Isilon SMB share and permissions.

We need to first understand the basics of how an SMB user or group access works in a Windows environment.
There are 2 types of permissions when dealing with an SMB share - 

• Share level permission.
• NTFS or folder level permission.

The below conditions should be satisfied for the user to access the share -

• The user trying to access the share should be a part of the ACLs on the NTFS level and also should be a member of the share permissions list.
• The user can either be a direct entry in the ACLs and the share or can be a member of a group which is in the ACLs and the share.
• The access to the user is decided by combining the NTFS and share permissions. It is always the most restrictive permission that is applied to the user.

Let us consider an example where an user John who is also a member of the domain group app_team is trying to access an SMB share.
The below table lists some of the common scenarios on deciding the share access - 

NTFS	Share	Final
Full Control - John	Read - Everyone	Read - John
Full Control - John	Full Control - John	Full Control - John
Full Control - John	Read - app_team	Read - John
John or app_team not present in the ACLs	Full Control - John	Access denied
Full Control - John	Full Control - John, Read - app_team	Read - John

The above examples show that in every case the most restrictive access is applied by combining the share and NTFS level permissions.
However there is one exception, that is when we apply the "Run as Root" permission on the share level to any user or group. This setting basically translates the user or group to Isilon's root user hence giving that user or group root privileges.

We will now look at different ways of managing the SMB shares on Isilon.

Using the Windows File Explorer for user defined access zones -
This section talks about managing the SMB shares and permissions through Windows File Explorer.
The first step in managing SMB shares is to create an admin share at the zone base directory of the access zone.
             We can create the zone base directory in any one of the following ways -  

1. Map the default /ifs share with the admin credentials and create the zone base directory required for the access zone.
   • For Ex -
   • If abc-ex.com\\john is the domain admin and we need to create an access zone HR with the zone base directory /ifs/isi_prod/HR then 
   • Map the default /ifs share through an IP in the system access zone using abc-ex.com\\john 's credentials.
   • Create the /ifs/isi_prod/HR directory.
   • The domain admin will now be the owner of the /ifs/isi_prod/HR directory tree and will have full control to modify or assign new permissions to other users or groups.
2.  If we are creating the zone base directory using the OneFS WebUI or CLI then the login user gets the permissions on the directory structure. Usually admins use the root user to login and hence root will get the NTFS permissions.
   • But if we have RBAC configured with the admins being part of the SecurityAdmin and SystemAdmin roles then the admin user can login to the WebUI with his domain credentials and either use the default option of "Create zone base directory if it does not exist" in the access zone creation window or create the directory structure from File System -> File System Explorer.
   • If using the CLI then run the mkdir command to create the directory structure or use --create-path when running the access zone creation command.
   • NOTE - If we are using this method to create the directory, it will get the POSIX permissions. We will need to inherit the admin user or group to the sub-directories by running the command - chmod +a user/group domain\\user/group allow object_inherit,conatiner_inherit

 

•  Once the zone base directory is created, create a hidden admin share for the same through the OneFS WebUI or through the CLI

 

• Admin share - app$
• Share to be provisioned - app-p1 (/ifs/isi-prod/apps/app-p1)
• Group Access - xyz-ex\fe-apps
• Access zone - Apps 
• Base directory - /ifs/isi-prod/apps
• Admin - xyz-ex.com\adm_john91
  • Map the app$ share through the adm_john91 admin account and an IP or SC zone name in the Apps access zone.
  • Create the share folder /ifs/isi-prod/apps/app-p1. 
  • Right click on the folder app-p1: Properties --> Security --> Edit --> Add fe-apps with the required access to the list.
• We can now create the share app-p1 with xyz-ex.com\fe-apps in the permissions list and on the folder /ifs/isi-prod/apps/app-p1 through the Isilon WebUI or CLI.

Using the Windows File Explorer for System zone -
 

• The zone base directory /ifs for the System access zone already exists.
• The NTFS permission on the /ifs directory by default has everyone read, write and execute.
• This can be deleted and only the admins can be assigned permissions by running the below commands - 
  • chmod -a Everyone allow  dir_gen_read,dir_gen_write,dir_gen_execute,delete_child /ifs
  • chmod +a user/group domain\\user/group allow dir_gen_all,object_inherit,container_inherit /ifs

• We can hide the default ifs share and assign only the required domain admins to the share permissions list.

Using the "Run as Root" SMB share permission

The above sections works well if we are configuring a new Isilon cluster, but if we already have an existing Isilon where the admins do not have control on the directory tree then the only way left to modify the permissions would be through CLI by logging in as root or by assigning the Run-as-Root share permission.

There is an option within Isilon SMB shares to assign a "run-as-root" permission, when this permission is assigned to an user or group that entity will be mapped with Isilon's root user giving that user root privileges.

We will consider the same example to create a data share with the below requirements - 

• Share to be provisioned - app-p1 (/ifs/isi-prod/apps/app-p1)
• Group Access - xyz-ex\fe-apps 
• Admin - xyz-ex.com\adm_john91
  • Create the share through Isilon WebUI and assign the admin xyz-ex\adm_john91 the run-as-root permission and select the "Create SMB share directory if it does not exist".
  • The share created will now have root privileges for the admin account.
  • The admin can now map the share through Windows File Explorer and assign the domain group xyz-ex.com the required permissions.
  • We can also assign the group xyz-ex.com\fe-apps the run-as-root permission but it is not recommended as the group will have root privileges for the shared directory and all its sub-directories as well.

Using the Windows Computer Management 

A share can be created and managed through the Computer Management MMC.

If an admin needs to manage SMB shares through the Computer Management MMC, then that user should be a member of the access zone's local Administrator group.
We need to follow the below steps to add the domain admin user or group to the local Administrators group.

• Open the Isilon WebUI click Access -> Membership & Roles.
• Select the access zone from the Current access Zone list.
• Click on the Groups and select the LOCAL:System for the providers. 
• Click on View/Edit for the Administrators group, Edit group -> Add Members.

We can now connect with the admin user credentials through the Computer Management MMC console.

• Login to a system through an account which was added to the local Administrators group in the previous step.
• Search and open Computer Management from the Windows search bar.
• Click on Action -> Connect to another computer
• Expand the shared folders.
• Right Click on shared folders and click on New Share.
• Go through the share creation wizard to create a new share.

We can also manage the share and NTFS permissions of already existing shares through the same console.

General Considerations for assigning share permissions 

• It is usually a good practice to assign group permissions on the share and NTFS level, and control the access of users by modifying the group memberships.
• For Ex - 
• Let us consider we have 2 application workflows on the cluster which are in their own access zones App1 and App2.
• Zone Base directory of App1 : /ifs/isi-prod/app1
• Zone Base directory of  App2 : /ifs/isi-prod/app2
• Admin share for App1 : app1$
• Admin share for App2 : app2$
• We can create domain groups like app1-rw, app1-ro, app2-rw, app2-ro representing read-write and read-only groups.
• The admin can map the shares app1$, app2$ and add the above groups to the NTFS permissions such that the app1-rw/app2-rw groups has full control or read-write permissions and app1-ro/app2-ro has read-only permissions. 
• Also add these groups to the share permissions such that app1-rw/app2-rw has full control or change permissions and app1-ro/app2-ro has read-only permissions.
• The admin can now add the required users to these domain groups depending on the access levels required.
• NOTE: This method is effective if we have shares being accessed by a set of users or teams. It will not be helpful for individual share management.The share level permissions 

• We have seen in the previous section that it is always the most restrictive access given to the user by combining the share and NTFS level permissions.
• Considering this we can set the share permissions to Everyone -Full Control and manage the permissions only on the NTFS level, although this is a easier method to manage permissions it is not recommended for sensitive data as it skips the second factor of authentication on the share level.