In-the-Lab: Default Rights on CIFS Shares

Following-up on the last installment of managing CIFS shares, there has been a considerable number of questions as to how to establish domain user rights on the share. From these questions it is apparent that the my explanation about root-level share permissions could have been more clear. To that end, I want to look at default shares from a Windows SBS Server 2008 R2 environment and translate those settings to a working NexentaStor CIFS share deployment.

Evaluating Default Shares

In SBS Server 2008, a number of default shares are promulgated from the SBS Server. Excluding the "hidden" shares, these include:

• Address
• ExchangeOAB
• NETLOGON
• Public
• RedirectedFolders
• SYSVOL
• UserShares
• Printers

Therefore, it follows that a useful exercise in rights deployment might be to recreate a couple of these shares on a NexentaStor system and detail the methodology. I have chosen the NETLOGON and SYSVOL shares as these two represent default shares common in all Windows server environments. Here are their relative permissions:

NETLOGON

From the Windows file browser, the NETLOGON share has default permissions that look like this:



Looking at this same permission set from the command line (ICALCS.EXE), the permission look like this:


The key to observe here is the use of Windows built-in users and NT Authority accounts. Also, it is noteworthy that some administrative privileges are different depending on inheritance. For instance, the Administrator's rights are less than "Full" permissions on the share, however they are "Full" when inherited to sub-dirs and files, whereas SYSTEM's permissions are "Full" in both contexts.

SYSVOL

From the Windows file browser, the NETLOGON share has default permissions that look like this:



Looking at this same permission set from the command line (ICALCS.EXE), the permission look like this:


Note that Administrators privileges are truncated (not "Full") with respect to the inherited rights on sub-dirs and files when compared to the NETLOGON share ACL.

Create CIFS Shares in NexentaStor

On a ZFS pool, create a new folder using the Web GUI (NMV) that will represent the SYSVOL share. This will look something like the following:

From the NMV (Data Management/Shares), select the CIFS checkbox to share with defaults (including anonymous read/write). Edit the share and rename it SYSVOL - uncheck "Anonymouns Read-Write" before saving.

Login to the NexentaStor appliance and enable a root shell. From this shell, determine the GID of your Domain Admins (or equivalent) super group:

root@san01:/export/home/admin# idmap dump -n | grep Domain
wingroup:Domain Users@solori.local == gid:2147483653
wingroup:Domain Users@san01 == gid:2147483651
wingroup:Domain Admins@solori.local == gid:2147483650

From this output, it is clear that the GID for the Windows "Domain Admins" group is 2147483650. [NOTE: Your UID/GID will be different, this is an example only.] We'll use this information to enable our administrator user to modify the share permissions, but first the GID must be applied to the root share from NexentaStor. To do so, we select the share folder (opens-up the share parameters) and select "Add Permissions for Group."



Within the "Create New ACL Entity" control box, we insert the GID of our "Domain Admins" group, and check all of the extended "read" permissions. Additionally, we check the "delete" permission, and intentionally leave the "inherit" permission disabled.



With these permissions applied, we can begin adding additional permissions from the Windows browser. Why is this an important shift of administrative control? Not all permutations of ACL options are available from the NMV. For instance, it would be impossible to set the complex permissions for Administrator on NETLOGON from the NMV since there are actually two sets of permissions for the same user at that level.

As a Windows domain administrator (group), use a file browser to find the share (i.e. \\NAS_NAME) and right click on the "sysvol" share and select the security tab. You may note that there are three unexpected group permissions already enabled on the share: Everyone, Current Owner and Current Group. Do not delete these NAS permissions until later.



We can start with deleting the extra SAN-based permissions - Everyone, Current Owner and Current Group. Next, we'll add permissions for Authenticated Users, SYSTEM and CREATOR OWNER. Do so by clicking the "Advanced" button, then the "Edit" button on the Advanced Security Settings window, and finally "Add..." on the resulting pop-up requester.

Type in "Authenticated Users" and click the "Check Names" button to confirm the spelling, then click "OK." Make sure the "Apply to" section lists "This folder, subfolders and files" and check the following: Traverse folder, List folder, Read attributes, Read extended attributes, Read permissions - then click OK. The "Authenticated Users" group should now show "Read & execute" permissions for this share.

Next, click "Add..." again and enter SYSTEM as the selected object. Check the "Full control" box and all other boxes should auto-fill, make sure the "Apply to" selector shows "This folder, subfolders and files" before clicking "OK."

Finally we'll add the "CREATOR OWNER" user and apply permissions to "Subfolders and files only" using all permissions except: Full control, Delete subfolders and files, Delete. Once applied, the permissions box should look like this:



The NexentaStor appliance will not have an analog to "Server Operators" from the Windows Server built-ins. To see the NexentaStor built-ins, click the "Locations..." button and select the NAS at the top of the tree, then, select the "Advanced..." button and click "Find Now..." on the subsequent pop-up.  It does have an Administrators group and a Backup Operators group - we'll use these to stand-in for our remaining groups.

Next page, Comparing and Overriding Permissions...First, we apply the built-in Administrators group to have the same permissions as CREATOR OWNER but applied to "This folder, subfolders and files." Our Backup Operators group will have the same permissions as the Authenticated Users group. Once applied, the new user permissions should look like this:



Back at the NexentaStor/NAS level, these permissions will show-up as a set of new UID/GID ACLs.

These ACLs are now part of the filesystem and will remain attached to the filesystem even after a ZFS send/receive operation (i.e. block-level backup with metadata). Similarly, if you wanted to create a set of "share templates" you could use ZFS send/recieve to clone the template for rapid provisioning/duplication.

That said, you could apply the same permission set using ICACLS.EXE from the command line (where NAS01 is the doman NAS name):

icacls \\NAS01\SYSVOL "NT AUTHORITY\Authenticated Users":(RX)
                   "NT AUTHORITY\Authenticated Users":(OI)(CI)(IO)(GR,GE)
                   "BUILTIN\Backup Operators":(RX)
                   "BUILTIN\Backup Operators":(OI)(CI)(IO)(GR,GE)
                   BUILTIN\Administrators:(RX,W,WDAC,WO)
                   BUILTIN\Administrators:(OI)(CI)(IO)(WDAC,WO,GR,GW,GE)
                   "NT AUTHORITY\SYSTEM":(F)
                   "NT AUTHORITY\SYSTEM":(OI)(CI)(IO)(F)
                   BUILTIN\Administrators:(RX,W,WDAC,WO)
                   "CREATOR OWNER":(OI)(CI)(IO)(WDAC,WO,GR,GW,GE)

(Line spacing has been added to enhance readability: the above mentioned command is entered on one complete line.) We'll use this method to rapidly provision the NETLOGON share. After creating and enabling the share (as above), we'll add only the "Domain Admins" group (as above) and issue the following command (as a domain admin) from Windows command shell:

icacls \\NAS01\NETLOGON /grant "NT AUTHORITY\Authenticated Users":(RX)
                 "NT AUTHORITY\Authenticated Users":(OI)(CI)(IO)(GR,GE)
      "BUILTIN\Backup Operators":(RX)
     "BUILTIN\Backup Operators":(OI)(CI)(IO)(GR,GE)
                 BUILTIN\Administrators:(RX,W,WDAC,WO)
   BUILTIN\Administrators:(OI)(CI)(IO)(F)
   "NT AUTHORITY\SYSTEM":(F)
   "NT AUTHORITY\SYSTEM":(OI)(CI)(IO)(F)
   BUILTIN\Administrators:(RX,W,WDAC,WO)
   "CREATOR OWNER":(OI)(CI)(IO)(F)

Now, we can compare the results:



Looking at the NexentaStor view of the permission set for NETLOGON:



Note the ACL warning that some permissions are duplicate for NETLOGON. This fact can be readily seen from the "Advanced Security Settings" view of NETLOGON's permissions:



As you can see, the Administrators group has two entries (as expected from the introduction section) and this creates a challenge for the NMV to visualize. Even so, these permissions persist within the filesystem correctly but this warning should provide ample caution to anyone considering tinkering with AD permissions from the NMV. Now we can remove "Domain Admins" from the shares to complete the configuration.

If you perform some file and folder creation within these two shares, something should jump out right away: file/folder creation is possible for Administrator users in both shares but file deletion/rename is not possible in SYSVOL. Notably, when a folder or file is created using the browser, it cannot be renamed. This is due to the inheritance of the "imperfect" CREATOR OWNER permissions which do not carry the modify/delete permissions on SYSVOL. [Note: without CREATOR OWNER, the surviving default group permissions would prevail. The creating user would match the actual file creator, however that user would have no named permissions (only implied) but could alter the file permissions (including the addition of explicit permissions) which would allow delete/rename.

Overriding the Default ACLs

We can superimpose Domain Admins rights from within NexentaStor and do so all the way through the filesystem (if necessary). This facilitates file access recovery in cases where a ACL lock-out has taken place and ownership does not grant the privileges needed. To do so from NMV, we simply add the group permission as before, but this time, add directory and file inheritance:



This approach propagates "Domain Admins" access rights all the way down the filesystem tree regardless of the inheritance flag set on file systems within the directory. By overriding explicit and implicit rights to regain control of the filesystem, other rights can be modified and the override removed without significant overhead (ever try to apply new rule set to 50K files?)