Security considerations when implementing clustered file shares
- In all cases, Microsoft recommends you keep security simple. The standards team, or appropriate IT division should determine which type of security to use, and lock down at that level. If you mix share level and filesystem level permissions, you can create signficant administrative difficulties. In most scenarios, filesytem permissions are preferred.
- Regardless of the operating system, rights should not be granted to a local group for a directory hosted on the shared drive. Windows 2000 and Windows NT 4.0 Member Servers have their own unique user databases. Access Control Entries that reference a local SID have no meaning after the storage resource and share are failed over to another node. In theory, it is possible to duplicate local resources across the cluster nodes, however, in practice it involves entirely too much overhead, is more prone to error and is unsupported.
- The cluster service account requires at least NTFS read privileges to the directory to properly create the share.
File Shares By Type
Normal ShareNormal Shares are the most flexible and easily understood in terms of security. The only real difference is that you administer share level security using the cluster user interface instead of Windows Explorer. You administer NTFS level security using Windows Explorer.
For more information about creating cluster file shares, click the following article number to view the article in the Microsoft Knowledge Base:
Share SubdirectoriesSubdirectory shares are available in versions of Windows NT later than Windows NT 4.0 Service Pack 4. Windows NT 4.0 Service Pack 5 or later automatically creates and deletes the shares. This share allows administrators to rapidly create directories to host large numbers of shares. A root share is specified, and all subdirectories one level below the specified root are created as regular shares. These shares inherit the same share level permissions as the root share. Unless this is the desired behavior, share-level permissions should be left to Everyone, and security implemented on the file system level.
For more information about subirectory shares, click the following article numbers to view the articles in the Microsoft Knowledge Base:
DFS RootDFS root is only available in Windows 2000. You can administer stand-alone DFS roots within a cluster. You can use share level permissions for the root through the cluster administrator user interface and you can administer each link through file share permissions on the appropriate server. However, this method of controlling access can be difficult for DFS trees spanning a large number of servers and links. We recommend you administer DFS trees by leaving file share level permissions open and use NTFS filesystem permissions to restrict access. Note that filesystem security is not possible on links that point to FAT or FAT32 volumes.
For more information about DFS Roots in Cluster Server, click the following article numbers to view the articles in the Microsoft Knowledge Base:
Article ID: 254219 - Last Review: 01/11/2015 03:23:16 - Revision: 4.0
- kbnosurvey kbarchive kbclustering kbenv kbhowto kbnetwork w2000mscs KB254219