Permissions Best Practices

Overview

You use permissions to control user access to data. There are two basic considerations when using permissions to control user access to data:

• Which users have access to the data.

• What type of access the users have to the data.

With the Nasuni Edge Appliance, you apply permissions to CIFS (SMB) shares, which contain folders and files. In Windows, you apply NTFS permissions to folders and files in the shares.

Important: Windows share permissions are not Nasuni share permissions. Setting permissions using the “Share Permissions” tab in File Explorer or using the Shared Folders Microsoft Management Console (MMC) is not supported. To set share permissions, use the Authentication option for groups while creating or editing a share.

Caution: Nasuni does NOT recommend changing permissions of files protected by Global File Lock, while Global File Lock is enabled. The lock management process necessary for the changed files can cause significant delays on the appliance where the changes are made. Before changing the permissions of files protected by Global File Lock, disable Global File Lock for these files, and perform a snapshot to ensure that any changes replicate. After the permissions are changed, you can protect those files with Global File Lock again. Since disabling Global File Lock removes protection from conflicts for these files, these changes should not be made during times that these files are likely to be used.

How CIFS (SMB) share permissions and NTFS permissions interact

This example illustrates the relationship between NTFS and CIFS (SMB) share permissions. Imagine that your data is locked inside a house. If you have the correct NTFS permissions, you can open the house to get your data. However, the house also has a fence around it. To get to the house, you must first open the gate in the fence. If you have the correct CIFS share permissions, you can open the gate to get to the house.

By default, Nasuni CIFS shares authenticate all users: the gate in the fence is left open. However, by enabling any of the advanced access options, you lock the gate, which must be opened before you can open the house. Even if you leave the house door open (using NTFS permissions that have the ability to allow everyone), you must still get through the gate.

Industry standards are for the CIFS share permissions to allow everyone access. Then, use the NTFS permissions to define who has access and what access they have.

Note: CIFS (SMB) share permissions in Nasuni are the same as Share Permissions in Windows.

Windows Permissions

On a Windows system, you can set NTFS permissions for folders and files. You can assign NTFS permissions to individual users or groups of users. You can allow or deny any combination of a variety of types of access, including read, write, modify, execute, create, delete, and full control.

Tip: The "Create folders / write data" permission is necessary to create files. If you want users to be able to create files in a folder, the "Create folders / append data" permission must be allowed.

Effective Access

In Windows, it can be useful to view the Effective Access that a user or a group possesses for a file or a directory. The Effective Access is the final result of applying all the permissions for an item.

This can be useful in troubleshooting access issues. For example, suppose that a user cannot access a particular directory. By examining the user’s Effective Access, you can determine whether the user actually has permission for the item. Often, difficulty with the user’s permissions is not due to a Nasuni issue, but due to the ACLs in effect.

To view the Effective Access of a user or a group for a file or directory, follow these steps:

1. In Windows, right-click the file or directory.

2. From the drop-down list, select Properties.

3. Click the Security tab.

4. On the Security tab, click Advanced.

5. Click the Effective Access tab.

6. Click “Select a User”.

7. Enter the name, or part of a name, of the user or group to select.

8. Click “Check Names”. A list of users and groups that match the name appears.

9. Click OK.

10. Click “View effective access”. The Effective Access of the user or group for the item appears.

    

For each Permission for the item, the Effective Access is displayed. If the user or group does not have effective access to the item, an indication appears of what is limiting the access.

Nasuni Edge Appliance Permissions

The Nasuni Edge Appliance offers the ability to connect to a domain and use all the full-feature capabilities of Microsoft Active Directory or LDAP Directory Services security. To control who has permission to access shares that have Active Directory or LDAP Directory Services security, you can define users and groups of users, then assign specific permissions.

NTFS Compatible and NTFS Exclusive permissions policies

Nasuni offers two permissions policies for CIFS (SMB) volumes on Nasuni Edge Appliances joined to Active Directory:

• NTFS Exclusive Mode:

  • Default mode for CIFS (SMB) volumes on Nasuni Edge Appliances joined to Active Directory.

  • Produces full NTFS permissions support for CIFS/SMB shares. This volume permissions policy offers the greatest Windows and Mac client compatibility.

  • Recommended for CIFS volumes that do not require multiple protocols.

  • Not Supported: NFS, FTP, LDAP authentication.

Important: You cannot switch from NTFS Exclusive Mode to NTFS Compatible Mode.

Important: Volumes in NTFS Exclusive Mode do not support multiple protocols.

• NTFS Compatible Mode:

  • Optional mode for CIFS (SMB) volumes on Nasuni Edge Appliances joined to Active Directory.

  • Provides a high level of Windows and Mac compatibility through the CIFS/SMB protocol, with some limitations.

  • This mode is required for multiple protocol support that does NOT involve NFS, such as CIFS with FTP/SFTP, as well as CIFS/SMB.

  • NFS and FTP/SFTP protocols cannot see all NTFS permissions and do not obey all access rules in NTFS permissions. NFS and FTP/SFTP protocols obey only the POSIX access control list (ACL) component of inheritance rules.

  • Not supported: NFS-only volumes, LDAP authentication.

Setting permissions

Setting NTFS permissions in Windows

“Traverse folder” permission:

In Windows, Nasuni requires that users must be a member of a group that has “Traverse folder / execute file” access as well as “Read attributes”, “Read permissions”, and “Read extended attributes”.

NTFS Exclusive volumes:

• The traverse permission is NOT required from the root of the volume.

• The traverse permission IS required from the root of the share and intermediate levels for browsing.

• Directly accessing a subfolder does NOT require traverse permissions.

NTFS Compatible volumes:

• Traverse permissions ARE required at the root of the volume and intermediate levels for browsing.

• Directly accessing a subfolder DOES require traverse permissions.

To set “traverse folder” permission:

1. On the Permissions tab, click Change Permissions.

2. Select the group for the users from the list, then click Edit.

3. Click anywhere in the Permissions area, then click Clear All to clear all permissions.

4. Select the Allow check box for “Traverse folder / execute file”, “Read attributes”, “Read permissions”, and “Read extended attributes”.

5. Keep clicking OK to close all dialog boxes.

   Tip: In Windows, Nasuni recommends that users NOT have “Full control” access to the folder. On the Advanced Permissions pane, unselect the “Full control”, “Change permissions”, and “Take ownership” checkboxes.

   Tip: In Windows, Nasuni recommends that “Full control” access to the folder only be allowed for a service account specifically created for this purpose. “Full control” access to the folder should not be given to ordinary groups such as Domain Admins or IT Department.

   Tip: If you want to use the two standard Windows groups, BUILTIN\Users and BUILTIN\Administrators, see “Procedure for joining Nasuni Edge Appliance (not previously joined) to domain” in Nasuni Edge Appliance Administration Guide.

Setting share permissions with the Nasuni Edge Appliance

Join the Nasuni Edge Appliance to the Active Directory or LDAP domain before creating shares and setting share permissions.

On the Nasuni Edge Appliance, you can set share permissions only for CIFS (SMB) shares that use Active Directory or LDAP Directory Services security. These CIFS shares must be on volumes and Nasuni Edge Appliances that use Active Directory or LDAP Directory Services security.

Setting up NTFS permissions from the Nasuni Edge Appliance

You can create inheritable NTFS permissions on a file or a folder tree based on CIFS (SMB) share permissions. Follow these steps:

1. Create a CIFS share on the Nasuni Edge Appliance.

2. Apply Active Directory or LDAP Directory Services permissions to the CIFS share. The access permissions that are applied to the CIFS share on the Nasuni Edge Appliance only affect how the user connects to the CIFS share.

3. In Windows, map to the CIFS share from a host.

4. In Windows, create a new folder.

5. Apply the NTFS access permissions that are required to the new folder. Any subfolders and files created in the new folder inherit its permissions.

Permissions for Mac Clients

NTFS Permissions Best Practices for Mac Clients

There is a known NTFS permissions problem that can result from accessing SMB shares (regardless of server vendor) from a macOS client bound to Active Directory using the built-in macOS Active Directory integration functionality.

Macs with this configuration have been observed to add or remove NTFS permissions and to break inheritance during routine operations such as duplicating folders or copying files that have existing permissions from local storage or another SMB share. These changes to NTFS permissions could break access for the connected client or other clients accessing the share.

This permissions problem has not been observed with Macs that are not bound to Active Directory or when Active Directory/Kerberos integration alternatives such as Apple Enterprise Connect or JAMF Connect (formerly NoMAD) are used in lieu of Active Directory binding.

Fortunately, two settings exist to mitigate this known issue. Ideally both settings should be applied for full mitigation of the underlying issue, although setting 2 requires the Nasuni 8.5 release.

• Setting 1: Restrict NTFS Full Control Permissions (compatible with all Nasuni releases)

The NTFS Full Control permission should not be used for folders and files associated with macOS shares. The NTFS Full Control permission includes the "Change Permissions" right, and can allow for accidental permissions changes.

Instead, use the Modify permission, or select Advanced permissions and then uncheck the “Change permissions” and “Take ownership” boxes. This prevents macOS clients from inadvertently changing their permissions on save.

Nasuni also recommends restricting Full Control permissions to a specific service account that you explicitly create to manage file permissions, rather than a general-purpose group such as Domain Admins or IT Department. That helps prevent members of these groups from accidentally manipulating permissions when creating folders and files via the Finder or an application.

• Setting 2: Use the Owner Rights Windows Well-known SID to Limit Permissions for Owners (Supported in the 8.5 Nasuni Release)

Restricting NTFS Full Control Permissions to a service account, or to a select group of administrator accounts, as outlined in Setting 1, is generally effective to prevent permissions corruption, although an issue with the rights implicitly granted to owners of files or folders in NTFS can cause problems if the owner attempts an operation (such as duplicating a folder or file) that can impact permissions.

The owner of a folder or file in NTFS can always change permissions on the object, regardless of its permissions. Even if the ACL list does not contain any permissions entries, the owner is still able to change permissions. The behavior of the owner principal is implicit in NTFS and is by design.

Beginning in Nasuni version 8.5, shares with the “Enhanced Support for the Mac OS X” share setting are now compatible with the Windows "Owner Rights" well-known SID to give administrators the ability to limit the permissions that NTFS Owners are implicitly granted. The “Owner Rights” well-known SID can be used on volumes with either the “NTFS Compatible Mode” or “NTFS Exclusive Mode” Permissions Policy.

The “Owner Rights” well-known SID was first introduced by Microsoft in Windows Server 2008 to limit the default behavior of NTFS owners. When used in conjunction with Nasuni permissions best practices, adding the "Owner Rights" well-known SID to the NTFS ACLs with Modify rather than Full Control permission, owners can no longer change NTFS permissions. When the Owner Rights well-known SID is applied and set to Modify, duplicating folders and files on a Nasuni share, or copying files and folders from another server or the Mac desktop, complete without error, and permissions inheritance is not broken.

Adding the Owner Rights Well-known SID using Windows Explorer:
 

An example of NTFS Permissions with Owner Rights applied:

Note: The Owner Rights well-known SID is incompatible with the version of “Enhanced Support for Mac OS X” that was included in Nasuni versions before 8.5. Adding the Owner Rights well-known SID to the NTFS ACLs to folders and files on a pre-8.5 Nasuni Edge Appliance breaks folder creation for connected clients.

Resetting Permissions on Move

When a Mac SMB client uses the Finder to move a file or folder within a share, the permissions from the source location move with the file or folder, and are not reset to inherit permissions from the target location during the move. This is a difference between Mac and Windows clients. When a Windows client (Windows 7/Server 2008 or newer) uses Windows Explorer to move files or folders from one location to another, the permissions are reset to inherit from the target location.

However, resetting permissions on a move to inherit from the target can be helpful for environments where permissions inheritance is utilized to enforce permissions. For environments that do depend on permissions inheritance and must support move operations, it is a best practice to use one set of permissions at the top level of the share and to avoid unique permissions for subfolders and files. If unique permissions are required for folders and files, it is best to implement a new share. Then, when data is moved between shares, each with unique permissions, the permissions are reset to inherit from the target folder and are not preserved.

Note: Copy operations are distinct from move operations in this regard. Copied files always receive the inherited permissions of the target directory.

This Microsoft Blog post explains this behavior and why it varies based on the client version or OS.

Additional NTFS Permissions Best Practices

Using inherited permissions with macOS clients is recommended to avoid issues that can arise when path length exceeds the limits imposed by native Windows tools such as Windows Explorer or cacls (260 characters).

“.TemporaryItems” folder

The ".TemporaryItems" folder is a hidden folder that Mac clients create at the root of all shares. Mac users must have at least Modify permission or Full control minus “Change permissions” and “Take ownership” to this folder for certain operations to complete. Mac applications use this folder for temporary storage and not having appropriate access to this folder can break file saving or zip archive expansion. Active Directory-bound Macs create per-user folders within ".TemporaryItems" based on the Active Directory user ID. Some issues with the ".TemporaryItems" folder only occur when Mac clients are bound to Active Directory.

If explicit permissions are required for long paths, Administrators can set them using PowerShell with long path name support, included in the latest versions of Windows 10 and Server 2016. Optionally, third-party utilities, such as SetACL Studio from Helge Klein, also support setting permissions for files and folders that exceed the Windows default path limit.

Viewing and Setting NTFS Permissions

Unlike Windows clients that list the NTFS User or Group permissions of an Edge Appliance or folder through the Windows Explorer properties, the Mac Finder does not list specific User or Group permissions. Instead, the Mac Finder shows a message that "You have custom access."

The macOS Finder does not correctly display Windows Access Control Lists for mounted SMB shares. This limitation is inherent in macOS and impacts other NAS devices and Macs connected to Windows file servers.

While the permissions are not displayed properly in the Mac Finder, they are enforced properly by Nasuni. That is because, per the SMB protocol, the permissions enforcement is done by the SMB Server, in this case Nasuni, and does not depend upon the client to enforce permissions.

Note: While the macOS Finder does not show NTFS permissions, they are visible through the macOS Terminal if the Mac client is bound to Active Directory, albeit in a limited form. In order to view the information, use the following syntax with the ls command.

ls -le

Because of the lack of Full Native support for Windows ACLs in macOS, an administrator must use a Windows system to set NTFS permissions.

CIFS Protocol best practices

On the NMC, under Filers → CIFS Settings → CIFS Settings dialog box, the Protocol Level should be set to "CIFS & SMB3". This is now the default for new Nasuni Edge Appliances deployed since version 7.2. The other available Protocol Level options can cause performance and stability problems for Macs.

Native Users and Local Authentication

Using the Nasuni Edge Appliance or Nasuni Management Console (NMC), you can grant access to specific users without using Active Directory or LDAP Directory Services. This can be useful for providing secure, authenticated access for users outside your corporate network such as customers, clients, or partners. Nasuni calls such users “native users.” Native users are explicitly defined and managed using the Nasuni Edge Appliance or NMC.

Creating external user accounts that are local to a Nasuni Edge Appliance is performed through Nasuni’s role-based access control settings. You can define specific access permissions for groups and users to perform actions within the Nasuni Edge Appliance user interface.

Issues related to permissions

Permissions Compatibility Matrix  

Active Directory Security Identifiers (SIDs)

In Active Directory, a SID (Security Identifier) is a unique, immutable identifier of a user or user group. A security principal has a single SID for life (in a given domain), and all properties of the principal, including its name, are associated with the SID.

Part of the SID is unique to the domain of the SID, and the remainder of the SID is called a RID (Relative ID).

Practically, a SID consists of a string, such as: "S-1-5-21-3623811015-3361044348-30300820-1013"

where

S indicates that the string is a SID.

1 is the revision level or the version of the SID specification.

5 is the identifier authority value.

21-3623811015-3361044348-30300820 is the domain ID.

1013 is the RID or relative ID in the domain.

SID History or “Historical SIDs”

Note: Removing historical SIDs from Active Directory objects is no longer a requirement if using the NTFS Exclusive permissions policy, since the NTFS Exclusive mode was designed to minimize the impact of historical SIDs when evaluating permissions.

The SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you migrate users into the target domain, you have the option to migrate the users’ SIDs to the target domain. This becomes the sIDHistory attribute under the new user object.

Resources within the source and target domains resolve their access control lists (ACLs) to SIDs, and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL.

In practice, the use of historical SIDs can lead to confused permissions, such as users either having unexpected access to an item, or lacking expected access to an item. For example, if one company is merged with another, and the SID History is preserved when migrating a user, a user might get both a new SID and a so-called historical SID, based on their old SID. When the RID portion of the SID is used to evaluate permissions, under the assumption that the domains are the same, the permissions can become confused. Likewise, two SIDs that map to the same domain, and that have the same RID, become indeterminate.

Before adding data to a Nasuni Edge Appliance, it is a Best Practice to clean up historical SIDs from all Active Directory objects.

Unresolved and orphaned SIDs

If a user or group is deleted from Active Directory, any permissions related to that object could be described as “unresolved” or “orphaned”. When viewing these permissions in a utility such as Windows Explorer, objects with unresolved SIDs will not show the name of the associated Active Directory User or Group, since the name cannot be resolved. Instead, the SID will be displayed.

Removing orphaned SIDs is optional. Copying them across to Nasuni does not cause any difficulties with permissions, whether on NTFS Compatible or on NTFS Exclusive.

If you decide to remove orphaned SIDs from an environment, you can use a utility such as SetACL from Helge Klein.

SetACL manages permissions, auditing, and ownership information. It does everything that the tools built into Windows do and much more. It is inherently automatable and scriptable.

SetACL is available for free as a command-line utility at https://helgeklein.com/setacl/.

Just as with SubInACL, SetACL can be used to identify and remove orphaned SIDs.

To list the orphaned SIDs present in the directory structure at a given path, run a command like the following:

setacl.exe -on C:\DIRECTORYPATH\ -ot file -actn list
-lst oo:y;f:tab -rec cont

• -on: path on which to operate

• -ot: object type; setting this to “file” includes files and directories

• -actn: action; set this to “list” to view permissions

• -lst: what to list; “oo:y” means OrphanedOnly, “f:tab” means tabular format

• -rec: recursion; “cont” means directories only

To remove the orphaned SIDs from a given directory path, run a command like the following:

setacl.exe -on C:\DIRECTORYPATH\ -ot file
-actn delorphanedsids -os dacl -rec cont_obj

• -on: path on which to operate

• -ot: object type; setting this to “file” includes files and directories

• -actn: action; delete orphaned SIDs found on the path specified by -on

Additive permissions issues

Note: This is not an issue for shares on NTFS Exclusive volumes.

Windows permissions are not additive on the Nasuni Edge Appliance. For example, if a user is a member of one group that has traverse permissions and that user is also a member of another group that has permissions to create folders, that user might not be able to both traverse and create folders, unless the ACL is changed so that both rights are on the same ACL. Otherwise, the Nasuni Edge Appliance selects one of the ACLs. The Nasuni Edge Appliance does not add all of the rights of all of the ACLs.

Deny permissions issues

Note: This is not an issue for shares on NTFS Exclusive volumes.

If an object has an inherited Deny permission and a non-inherited Allow permission, then the object’s permissions cannot be guaranteed on the Nasuni Edge Appliance. For this reason, we recommend removing all Deny permissions.

Trailing spaces in filenames

In Windows, trailing spaces in filenames can break permissions. If a file is having permissions issues, check the filename for trailing spaces.

Built-In Administrators and Users Local Groups

Many local groups are created automatically when installing the Microsoft Windows operating system. These local groups are often referred to as “built-in groups”. Of these local groups, the Administrators and Users groups are granted filesystem-level permissions to the upper level of source fileserver data drives. By default, these permissions are inherited throughout directory structures. Nasuni recommends avoiding use of the local Administrator or Users groups whenever possible. Instead, on source file servers, Nasuni recommends converting permissions to domain groups.

The commands below can be used for this conversion.

To convert local Administrators (Well Known SID S-1-5-32-544) to a domain group, use a command like this:

SetACL.exe -on “<PATH>” -ot file
-actn trustee -trst "n1:S-1-5-32-544;n2:<DOMAINNAME>\<GROUPNAME>;ta:repltrst;w:d"
-actn trustee -trst "n1:S-1-5-18;ta:remtrst;w:d"
-rec cont -log "<LOGFILENAME>.log"

where:

<PATH> is the path or name of the object to process.

<LOGFILENAME> Is the name of a log file.

To convert local Users (Well Known SID S-1-5-32-545) to a domain group, use a command like this:

SetACL.exe -on “<PATH>” -ot file
-actn trustee -trst "n1:S-1-5-32-545;n2:<DOMAINNAME>\<GROUPNAME>;ta:repltrst;w:d"
-actn trustee -trst "n1:S-1-5-18;ta:remtrst;w:d"
-rec cont -log "<LOGFILENAME>.log"

where:

<PATH> is the path or name of the object to process.

<LOGFILENAME> Is the name of a log file.

When the conversion of permissions to domain groups is not possible, Nasuni provides the ability to associate the local Administrators and Users groups to domain groups. For this functionality, a single Active Directory Universal Group can be associated with each local group, and this association must be consistent across all Nasuni Edge Appliances sharing volumes.

Note: This functionality might limit future ability to connect Edge Appliances to volumes, if either group association is not consistent with other Edge Appliances already sharing the same volumes.

To enable the above functionality, see Edge Appliance Administration Guide.

Using the Windows “Owner Rights” well-known SID to limit permissions for owners

The owner of a folder or file in NTFS can always change permissions on the object, regardless of its permissions. Even if the ACL list does not contain any permissions entries, the owner is still able to change permissions. The behavior of the owner principal is implicit in NTFS and is by design.

Administrators can use the Windows "Owner Rights" well-known SID to limit the permissions that NTFS Owners are implicitly granted. The “Owner Rights” well-known SID can be used on volumes with either the “NTFS Compatible Mode” or “NTFS Exclusive Mode” Permissions Policy.

The “Owner Rights” well-known SID was first introduced by Microsoft in Windows Server 2008 to limit the default behavior of NTFS owners. When used in conjunction with Nasuni permissions best practices, adding the "Owner Rights" well-known SID to the NTFS ACLs with Modify rather than Full Control permission, owners are no longer able to change NTFS permissions. When the Owner Rights well-known SID is applied and set to Modify, users cannot change permissions any longer on folders or files that they own, and permissions inheritance is not broken.

Adding the Owner Rights Well-known SID using Windows Explorer:

An example of NTFS Permissions with Owner Rights applied:

Note: The Owner Rights well-known SID is incompatible with the version of “Enhanced Support for Mac OS X” that was included in Nasuni versions before 8.5. Adding the Owner Rights well-known SID to the NTFS ACLs to folders and files on a pre-8.5 Nasuni Edge Appliance breaks folder creation for connected macOS clients.

Security tab not accessible for a folder

Issue:

In Windows Explorer, viewing the Security tab of a Windows file or folder (right-click, select Properties → Security) on a CIFS (SMB) share on the Nasuni Edge Appliance gives a message that the user does not have permissions to see this information.

Resolution:

This is often caused by a permissions change that locked even the administrator out of the folder. The Nasuni Edge Appliance Administrative User has permissions to fix the permissions. Follow this procedure:

1. On the Nasuni Edge Appliance user interface, go to Configuration → General CIFS Settings.
    

2. Verify that there is an Administrative User set. If not, set an Administrative User (Active Directory user). This must be a user, not a group. Do not include any domain name as part of the username.
   Then click Save CIFS Settings.
   The new Administrative User must obtain a new SMB connection. This can be done by going to Status → CIFS Status and disconnecting their client.

3. Log in to the Windows server as the Nasuni Edge Appliance Administrative User. This user has the ability to view the Security tab for the problematic Nasuni Edge Appliance or folder, and to change the permissions appropriately.

Copyright © 2010-2024 Nasuni Corporation. All rights reserved.