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. For
further resources, see the Learning
Path on page 36.
End of Article
Prev. page
1
[2]
next page -->
