The Server service has been part of Windows NT–based OSs since day one, and the vast majority of Windows servers are file servers. You’d think that we IT professionals and Microsoft would have this file-server thing ironed out by now. Unfortunately, that’s not the case. I’ve heard from countless business clients (and these aren’t momand- pop shops) that IT still isn’t configuring file servers right. And Microsoft isn’t helping. In fact, in some cases Microsoft is adding to the problems in its newest OS versions by creating what I call “tools for dummies,” such as the new Windows Server 2008 Share command, which isn’t customizable and applies really poor default configurations. Although file servers are one of the most common causes of annoyance for IT, the situation isn’t hopeless. You can align file server technologies with business requirements, and I’ll show how you can work around the problems with permissions, such as Full Control or Modify, and some of their defaults, such as the default inheritance of the delete permission, that Microsoft wants you to use.
Full Control or Modify Most of us know the dangers of Full Control. Fewer of us have considered scenarios in which Modify is a risky permission to apply. I can write pages on the dangers of assigning Modify and Full Control permissions to groups, but I’ll narrow down my scope here to one of the most severe problems these permissions can cause: granting Delete permission.
In most collaborative file-sharing scenarios, such as sharing a team folder, a group of information workers receives Modify or Full Control permission. The danger is that Modify and Full Control permissions templates include the Delete permission, which applies by default to “this folder, subfolders, and files.” With this permission and its inheritance, a user in the group can delete any and all files and subfolders. In other words, anyone on the team can select a folder and press the Delete key. Say au revoir to your data and hello to denial of service. Such a deletion could be malicious or accidental, but it can be prevented.
Spend some time defining the requirements of your collaborative shared folders, and be aware that permissions used for good can also be used for evil. You’ll find that, depending on the requirements of the particular folder you’re granting permissions for, you can solve the Delete problem in a number of ways. First, you can give the whole group Allow::Write permission, which lets anyone in the group create and change files and folders. Then, give a more restricted group the Delete permission. Second, you can grant the group Modify permission but change the scope of the permission to apply to Files only. This still allows an accidental or intentional deletion of files within the folder, but it stops the recursive deletion of subfolders in the event of an accidental deletion.
Delete Subfolders and Files Even more perilous is the Delete Subfolders and Files permission, an access control entry (ACE) in the Full Controls permission template. A user with this permission on a folder can delete any subfolder or file within the folder, even if the user has explicit Deny:: Delete permission. So, any user who’s a member of a group with Full Control of a folder can delete all of its contents, creating a denial of service situation. This is far worse than the standard Delete permission because Delete Subfolders and Files overrides all other permissions, including explicit Deny permissions. It’s a doozy in the wrong hands.
To avoid this problem use Best Practice Number Two: Be extremely careful about granting Full Control. I recommend restricting Full Control to System. Give the Modify permissions template plus Change Permissions permission to support groups who need to change folder permissions.
By the way, Best Practice Number One is: Always assign permissions to groups, not users. This point leads me to the next annoyance.
Creator Owner ACE Most organizations have increased their focus on security policy, which makes defining rules for access essential. For shared folders, the parent folder ACL determines the access policy. A team shared folder, for example, is typically set to allow team members to read each other’s files. Often they can add files to the share, and sometimes they can even change each other’s files. The problem is that on each new folder, there’s a default ACE that gives the Allow::Full Control (Apply To Subfolders and Files) permission to the special identity Creator Owner. When a user creates a file or folder, the ACE assigned to Creator Owner is applied to that specific user.
So, for example, if Dan Holme joins the team and creates a new file in the team share, he receives Allow::Full Control permissions for that file. What if Dan leaves the team? He’s removed from the group that can read and create files in the share. But he can still access his file because he has an explicit Allow::Full Control ACE on that file. So just because Dan created the file, he’s exempt from the entire shared folder’s access policy, which specifies that only team members have access. Even if an administrator uses the Change Owner function to assign the file to another team member, Amy, Dan still has his explicit permission (and Amy does not inherit Dan’s Full Control permission) unless the administrator changes the file’s permissions.
To fix this annoyance, analyze the capabilities needed by the shared folder users. You might decide to remove the Creator Owner ACE. If you’ve assigned team members the Allow::Write permissions template so they can change each other’s files on the share, you don’t need the Creator Owner ACE. Without this ACE, when Dan joins the team and creates a file, the new file inherits the access policy of the parent folder but doesn’t add an explicit ACE for Dan. He can modify his file because he’s on the team, but when he leaves the team, his access is removed. There’s one more catch: Dan can, as owner, return to the object and give himself permissions. We’ll solve that one next.
Changing Permissions Every organization has battled problems caused by users maliciously or inadvertently changing permissions on files or folders they’ve created. Windows provides an implicit permission (WRITE_DAC) to the security identifier (SID) of the user who owns a file or folder. WRITE_DAC enables the user to change permissions on the object, even if he or she wouldn’t otherwise have Allow::Change Permissions. This ability represents a significant security problem because the owner of a file or folder can change the access policy defined by the ACL on the parent folder.
Prior to Windows Vista, the only viable solution was to change the Server Message Block (SMB) permissions (i.e., share permissions). Most administrators use Allow::Full Control as the SMB permission. But if you change it to Allow::Change, the more restrictive SMB permission will allow every action except changing permissions.
Vista and Windows Server 2008 make it even easier to solve the problem by adding a new special identity, OWNER RIGHTS, which represents the current owner of a file or folder. Permissions assigned to this identity will set the permissions for the owner, overriding the owner’s implicit rights, including the right to change permissions. So the new best practice is to assign OWNER RIGHTS::Allow::Modify. The Modify permission doesn’t include the Change Permissions, Delete Subfolders and Files, and Take Ownership permissions included in the Full Control permissions template. As soon as your file servers are running Server 2008, this annoyance will be history.
Users See but Can’t Access When users open folders, they can see all of the contents, by default, including files and folders to which they don’t have access. I don’t have a problem with such visibility: As long as the file or folder can’t be opened, visibility doesn’t really matter. However, if it matters to you, here is my guidance: Reorganize your files and folders or implement Access-Based Enumeration, which is available for Windows Server 2003 from Microsoft’s downloads site at microsoft.com/downloads/details.aspx?FamilyID=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en. (For more details, see the Windows IT Pro “File and Print Annoyances” article, February 2007, Instant- Doc ID 94675.)
Continued on Page 2
Shared Folder Delegation
There’s a Windows 2000 and Server 2003 annoyance—setting permissions for shared folders—that makes me want to read the riot act to the product team at Microsoft. This annoyance is so big and multifaceted that I can’t begin to do it justice here. (So if anyone at Microsoft is listening, call me!) At the core of the problem is the delegation of permissions to create shared folders.
Let’s assume you’re in an organization with more than one level of administrator. The organization has technical support people responsible for the servers. These folks work on hardware, backup, configuration, patching, and so forth—the tasks of real Administrators with a capital “A.” In Windows, a member of the Administrators group can do anything and get to anything on a server. Let’s say there’s also a support role with the task of creating a shared folder. To me and to every client I work with, this task is at a lower escalation level than the other tasks Administrators perform. Unfortunately, to Microsoft, these two types of tasks are equal. To create a share, you must be a member of a privileged group such as Administrators, Power Users, or Server Operators, and these groups have additional hard wired rights as well. Microsoft doesn’t provide a way to delegate the ability to create a shared folder to someone lower in the administrative hierarchy.
I was excited when I learned that Windows XP’s PowerToy, Tweak UI, exposed a way to delegate this ability. But, unfortunately, TweakUI isn’t an official part of Windows and Microsoft doesn’t support it. The permission to create a share is a binary registry entry, and changing it’s also not supported. So, I’m sad to say, the only way to delegate creation of shared folders is to put technical support groups into the local Server Operators or Power Users group on a member server. At least you can avoid giving them Administrators credentials.
But the fun doesn’t end there. When you create a shared folder, you want to configure its settings: permissions, caching, access-based-enumeration and perhaps its description or connection limit. The settings for the first three are the most useful and common. How do you configure them other than using the shared folder user interfaces? How can you use a command line or script? Permissions can be set from the UI or a command line (i.e., by specifying NET SHARE), but not through a VBScript. Caching settings can be set from the UI or the NET SHARE command, but not through a VBScript. Access-Based Enumeration can be enabled only in the UI. There’s no command line, and the NetShareSetInfo function isn’t something mere mortals can script. How’s that for consistency? It sure makes automating the creation of shares difficult for non-developers.
Finally, the default settings for a new shared folder are lousy for the vast majority of shared folders. Everyone::Allow::Read is the default share permission that restricts everyone, even administrators, from any higher-level access, even if NTFS permissions define more permissive access policies. Every client I’ve worked with recently has very clear policies indicating that Full Control is the correct share permission in almost every scenario and that NTFS permissions define actual access policy. This is an example of Microsoft locking down something too far and not giving customers a way to change the default to something useable.
Similarly, the default caching settings enable users to “pin” any file in the share to make it available for offline access. With any multi-user folder other than a read-only folder, this ability opens up possibilities for offline editing and conflicts on synchronization. Because of the security implications I recommend that you consider locking down the default access for offline files.
To change the default caching settings use a script or the command line to provision and automate your shares. The NET SHARE command, for example, provides an easy way to create a shared folder, including switches for configuring the Full Control share permission and for disabling offline files for the share:
/GRANT:Everyone,Full
and
/CACHING:None
File Sharing for Dummies
Everything I just discussed applies in Vista and Server 2008. Alas, Server 2008 continues down the wrong path. So consider this section a preview of Server 2008 annoyances.
My first Server 2008 annoyance is the Share command: Don’t even think of choosing the Share command on the context menu in Windows Explorer. The new Share command is reduced to “File Sharing for Dummies.” It displays the File Sharing dialog box shown in Figure 1, page 38.
In the File Sharing dialog box, you can change the Permission Level to Reader, Contributor, or Co-Owner. This dialog box sets both the share and the NTFS permissions to Read, Change/Modify, or Full Control. That implementation of permissions goes against the written policy and procedure of just about every client I’ve ever had. Typically policies require that shared folder permissions be Full Control and that NTFS permissions define access policy. And, because most of us learned to secure a folder before sharing it, we may have actually spent some time creating the perfect ACL. But this command won’t share the folder for any group that has anything other than standard Read, Modify, or Full Control NTFS permissions templates. Try securing a folder so that a team has Write permission and then try sharing it. You’ll see that the group isn’t given any share permission.
This annoyance gets worse because of the way Microsoft implements the roles in the dialog box. In most role-based security models, including Microsoft’s own SharePoint and Exchange public folder models, a Contributor doesn’t Modify, an Editor does. The difference between the Contributor and Editor roles is that a Contributor can add something and can change his or her contribution. In contrast, an Editor can change a file from any contributor. Now whether you agree with those definitions of Editor and Contributor or not, the real point is that Microsoft is making assumptions about the understanding every client has regarding roles. It doesn’t provide any options for a company to change what the dialog box does.
Finally, Microsoft rubs salt in the wound by putting this tool that I call “File Sharing for Dummies” in the same place the tried-and-true (and effective) Share interface used to be. You now have to look for the Advanced Sharing command to get to the settings you really need. And here’s my question: Because you have to be in a privileged group (such as Administrators) to share a folder and because we’re dealing with a server OS, can’t we assume that Administrators know what they’re doing? Even the very nice Provision a Shared Folder Wizard in Server Manager has crazy defaults—such as Everyone::Allow::Read and Caching=Manual—that you can’t customize for the needs of your organization.
The best solution for these Server 2008 annoyances is using the Net Share command or other scripts to provision shared folders with exactly the settings you require. Even the brilliant new PowerShell has no way to set all the Server Message Block (SMB) settings of a shared folder. Annoying.
Final Annoyance
The list of file server annoyances and solutions is far too long to detail in just one article. So watch this space for future articles.
