Creating and Managing

Shared Folders
Microsoft threw all sorts
of new services, features, and functions into Windows 2000 Server,
but at the heart of it all was still the requirement to be a good file server. Windows 2000 took
the solid file sharing capabilities of Windows NT, extended them with the Distributed File
System (Dfs), and made permissions and shares easier to manage—not to mention that this
was all on top of a more stable and powerful operating system. The release of Server 2003
brought a few enhancements, the most important being that the new default permission sets
are far more secure than they were in Windows 2000. In this chapter, I will talk about what
file sharing really is, how those permissions work, and how to set it all up. Next, we’ll dig
into the Dfs. You’ll find out what it is, how it works, and how to make it work for you.
Finally, you’ll take the basic file sharing capabilities and push them right out to your users’
Web browsers. I’ll also show you how to make your users files available for offline use.

Basics of File Sharing

The core component of any server is its ability to share files. In fact, the Server service in all
of the Windows NT family, including Server 2003, handles the server’s ability to share file
and print resources. But what exactly does that mean, and why is it so important? By default,
just because you have a server running doesn’t mean it has anything available for your users.
Before they can actually get to resources on the server, you must share out your resources.
Let’s say you have a folder on your local I: drive named APPS with three applications in
subfolders, as shown in Figure 11.1. When you share this folder out to the network under the
name of APPS, you allow your clients to map a new drive letter on their machines to your
I:\APPS folder. By mapping a drive, you are placing a virtual pointer directly to where you
connected. If you map your client’s M: drive to the APPS share of the server, their M: drive
will look identical to the server’s I:\APPS, as shown in Figure below

Subfolders in I:\APPS
M:\ mapped to I:\APPS

That’s really all there is to it. Sharing resources means that you allow your users to access
those resources from the network. No real processing goes into it as far as the server is
concerned; it just hands out files and folders as they are.

Creating Shared Folders

Before you can create a shared folder, you must have appropriate rights to do so. This
requires that you are either an Administrator or a Power User. You can create shares in a few
ways: You can use the Explorer interface when sitting at the server or use the Computer
Management Console to create shares either at the server or remotely.

Creating Shares from Explorer

If you’re sitting at the server, the Explorer interface provides a simple and direct means for
creating and managing all properties of a share. In windows explorer or my computer, go to
the C: drive and create a new folder called APPS.

In Explorer, right-click the APPS folder and select the Sharing and Security menu option. This
will bring up the properties page for the folder APPS, already set to the Sharing tab. To share
the folder, click the Share This Folder radio button, as shown in Figure below.
Properties for the APPS share

Note
If you want to stop sharing this folder later through the Explorer interface, go back into the
properties as you just did and select the Do Not Share This Folder button.

The Share Name option on this page is the most critical entry. This is how your users will
reference this share. For our purposes, share this folder as APPS. The Description field is used
to provide more descriptive information about this share. Technically, the description has no
real bearing on the server or client; it just makes browsing a little less cryptic.
Click OK, and your share is enabled and ready for immediate use by your users.
To check it go to start run and type \\servername and you should see your new share name
APPS. Or use windows explorer as shown below and in the address field type \\servername
Setting User Limits

You can also configure how many users can connect to a share simultaneously in the User Limit area of
the Sharing properties page. If the applications under your share are each licensed for 100 concurrent
users you can configure your server share to maintain a that limit, even though you may have 200 users
on your network. Just check the Allow This Number of Users radio button and fill in the appropriate
number (it defaults to 10). As users connect to the share, they build up to the user limit. As users log off,
or disconnect from the share, the number drops. This type of licensing enforcement can be handy in
reducing your licensing costs.

Managing Permissions
Now that you’ve shared out your resources to the world, it’s time to protect them
From the world. Of course, there are numerous ways to secure your server and its resources
from the outside—using routers and firewalls, for instance—but by setting permissions on
your files and shares, you are more likely to stop an intruder who
Does manage to make it all the way past your other barriers. And, of course, this also ensures
that even the folks on the inside are only allowed access to what they need. The two kinds of
permissions that I’ll talk about here are share permissions and file and directory (NTFS)
permissions. These permissions let you control who accesses your data and what they can do
with it.
Note
NTFS (NT File System) is the most common and the most secure file system used for Windows
Server.

Share permissions are applied any time a user accesses a file or folder across the network, but
they are not taken into consideration when a user accesses those resources locally, as they
would by sitting directly at the computer or by using resources on a terminal server. NTFS
permissions, in contrast, are applied no matter how a user accesses those same resources,
whether they are connecting remotely or logging in at the console. So, when accessing files
locally, only NTFS permissions are applied. When accessing those same files remotely, the
sum of both share and NTFS permissions are applied by calculating the most restrictive
permissions of the two types.

Share Permissions
Share permissions are possibly the easiest forms of access control you will deal with in
Windows Server. Remember that share permissions only take effect whenever you try to
access a computer over the network. Consider share permissions to be a kind of access pass to
a secure building. When you walk up to the front door and show your identification, the guard
looks up your name and gives you a pass that shows your access level for everything else on
the inside. If your pass says “Level One access,” then your pass will get you into every door
on Level One—and nowhere else. Once inside, try to get into a room with Level Two access
requirements, and it won’t work. By defining share permissions, you can safely control the
access level for each person at the front door.
Keep in mind, though, that this front door—or share-level permission—isn’t the entire
picture. The share-level permission only represents the maximum level of access you will get
on the inside. If you get read permissions at the share, the best you can do once you’ve
connected remotely to the share is read. Likewise, change permissions will grant change at
best. If you want full control to anything inside the share, you need full control at the share.
But understand that when I say the share permission is the maximum level of access you will
get inside the share, it is entirely possible to restrict access more once you’re inside, using
file-level (or NTFS) permissions. You can have full control at the share, but an object inside
can still have NTFS permissions that say you can only read it.

Note
There are cases every once in a while where you will choose one of the FAT file systems for
your logical drives. FAT has no file and directory permission capabilities, which leaves your
data very insecure. However, you can alleviate some of these pains through share
permissions. Even on FAT partitions, you can share out folders and assign whatever
level of share permissions you like. In this scenario, the share permissions are it—they won’t
be overridden by file or directory permissions because there aren’t any. If you get to change
the share, you get to change everything within the share. Unfortunately, this still doesn’t
prevent an intruder from accessing data directly at the console. Physical security of the
server is your only surefire protection.

Defining Share Permissions

To define share permissions, we will work through the Computer Management Console.
Select the share you want to secure by right-clicking the share name and selecting Properties,
then selecting the Share Permissions tab. You can get to the same place from Explorer by
right-clicking the locally shared folder, selecting Sharing and Security, and then clicking the
Permissions button; both methods will bring you to essentially the same dialog box which is
shown in Figure below.
Note
Note that the Everyone group, by default, has Read access permissions, which is a great step
forward in the Windows world in terms of security. Until, Server 2003, the Everyone group
was given Full Control access by default. Another new feature in Server 2003 is that the
Everyone group no longer contains the Anonymous User account, which will help keep your
resources more secure.

In this dialog, you are shown a Group or User Names box that lists users and groups assigned
to the share; when a user or group is selected, the permissions for that user or group to access
the share are revealed. You can assign different levels of permission for different users and
groups. At the share level, you have the following types of permission:

Permission Level of Access

Full Control
The assigned group can perform any and all functions on all files and folders through the
share.

Change
The assigned group can read and execute, as well as change and delete, files and folders
through the share.

Read
The assigned group can read and execute files and folders, but has no ability to modify or
delete anything through the share.

The example in Figure above shows read access for Everyone. Although you won’t see the
administrator’s account listed with any specific rights, note that local administrators always
have full control of the shares on the computer. If you want to change share permissions to
give all your network administrators full control, you will need to add the group and assign
them rights. Select the Add button to see the dialog box shown in Figure below.

You can either type in the name of the account or group that you want to add, or click the
Advanced button, which will bring you to the second Select Users, Computers, or Groups
dialog box, shown in Figure 11.14. This dialog box enables you to search the directory.
You can either use the Active Directory search functions on the Common Queries tab to
narrow down your choices or select the Find Now button, which will enumerate all of the
users in the directory. From here you locate the group that you want to add—the Domain
Administrators group in the example—and click OK and then OK again. This brings you back
to the Share Permissions tab with the Domain Administrators group added to the display and
highlighted. Select the Full Control check box, and as you can see in Figure 11.15, everything
else is checked automatically.
Figure 11-14
Figure 11-15

Again, keep in mind that share-level permissions are just your first filter for users accessing
files over the network. Whatever level of permissions you get at the share level will be the
highest level of permissions you can get for files and directories (the most restrictive apply,
remember?). If you get read-only rights to the share, but full-control rights to the file, the
share will not let you do anything other than read.

File and Directory Permissions

The old days of Microsoft networking (before the arrival of the NTFS file system) utilized
sharelevel permissions only. Once connected to a share with a given set of permissions, you
had those permissions for everything under the share. If you had 1000 users who all wanted
private access to their data, you would have to create 1000 shares with specific permissions
on each share. Then, with the introduction of Windows NT to the Microsoft networking
platform, you could create one share for all users, and customize access via file and directory
permissions—permissions that could be assigned directly to the files and folders. With this
new feature came an unending ability to customize the security of your data.
You may hear a lot about how NTFS, in conjunction with file and directory permissions, can
help you protect the server itself from an intruder. Theoretically, this is true. Assuming that
you do not know an administrator username and password, if you sit down at the server, you
cannot gain access to the server’s data. The idea is that NTFS will not let you boot to anything
less than the NT operating system and view files. This feature lets you relax a bit about the
physical security of the server. You know that no one can log in to the server, and that your
partitions are using the NTFS file system. Pop a DOS boot disk in, reboot the server, and you
can’t see a thing on the hard drive.
Well, it was only a matter of time. Someone did come up with a utility that allows you to gain
access to NTFS partitions via a simple boot disk. Microsoft’s Recovery Console, released
with Windows 2000, lets you boot from the Windows 2000 Server or Professional CD. But
actually, there was a similar package that existed long before Microsoft gave it to us. Mark
Russinovich and Bryce Cogswell wrote a utility called NTFSDOS way back in 1996 that let
you mount an NTFS volume from a boot disk. Mark is the same smart guy who discovered
that the only difference between NT Workstation and NT Server code was just one Registry
entry. You can still find this tool—and many others—through Mark and Bryce’s freeware
company, Sysinternals, or its sister company Winternals. (You can find out more at
www.sysinternals.com.) What all this means is that, to be secure, go back to square one: Lock
your server up so no one can sit at its keyboard.

Permission Types
Before you assign permissions to your files and folders, you need to have a good
understanding of what those permissions mean and how they work. There are two different
levels of permissions. To see the higher level, go to any NTFS folder, right-click it and
choose Properties, and then the Security tab. You’ll see a permissions dialog box like the one
in Figure 11.16.

Figure 11-16

Compare Figure 11.16 to Figure 11.15, a standard share-level permissions dialog box. Notice
that share-level permissions only offered three permission types—Full Control, Change, and
Read. Very simple, and note that there was no Advanced button in the dialog box, unlike
Figure 11.16.
Permissions Explained

Read
Read permissions are your most basic rights. They allow you to view the contents,
permissions, and attributes associated with an object. If that object is a file, you can view the
file, which happens to include the ability to launch the file, should it be an executable
program file. If the object in question is a folder, Read permissions let you view the contents
of the folder.
Now, here is a tricky part of folder read. Let’s say that you have a folder to which you have
been assigned Read permissions. That folder contains a subfolder, to which you have been
denied all access, including read access. Logic would say that you could not even see that
subfolder at all. Well, the subfolder, before you even get into its own attributes, is part of the
original folder. Because you can read the contents of the first folder, you can see that the
subfolder exists. If you try to change to that subfolder, then—and only then—will you get an
Access Denied.

Write
Write permissions, as simple as they sound, have a catch. For starters, Write permissions on
a folder let you create a new file or subfolder within that folder. What about Write
permissions on a file? Does this mean you can change a file? Think about what happens when
you change a file. To change a file, you must usually be able to open the file, or read the file.
To change a file, Read permissions must accompany your Write permissions. There is a
loophole though: If you can simply append data to a file, without needing to open the file,
Write permissions will work.

Read and Execute

Read and Execute permissions are identical to Read, but give you the added
atomic privilege of traversing a folder.

Modify
Simply put, Modify permissions are the combination of Read and Execute and
Write, but give you the added luxury of Delete. Even when you could change a file, you never
really could delete the file. You’ll notice that, when you select permissions for files and
folders, if you select Modify only, then Read, Read and Execute, and Write are automatically
checked for you.

Full Control
Full Control is a combination of all previously mentioned permissions, with
the abilities to change permissions and take ownership of objects thrown in. Full Control also
allows you to delete subfolders and files, even when the subfolders and files don’t specifically
allow you to delete them.

List Folder Contents

List Folder Contents permissions apply similar permissions as Read
and Execute, but they only apply to folders. List Folder Contents allows you to view the
contents of folders. More important, List Folder Contents is only inherited by folders, and is
only shown when looking into the security properties of a folder. The permission allows you
to see that files exist in a folder—similar to Read—but will not apply Read permissions to
those files. In comparison, if you applied Read and Execute permissions to a folder, you
would be given the same capabilities to view folders and their contents, but would also
propagate Read and Execute rights to files within those folders.

Special Permissions
Special Permissions is simply a customized grouping of atomic rights you
can create when one of the standard molecular permissions just covered isn’t suited to your
specific situation. Although it might appear that the Special Permissions feature is new to
Server 2003, it did, in fact, exist in Windows 2000. It just wasn’t visible as a molecular
permission. In fact, in Win2K, there wasn’t any way to tell whether or not a folder had
customized atomic permissions unless you looked in the Advanced tab of the Securities
properties sheet. In Server 2003, you can tell just by looking at the Allow/Deny check boxes
used for Special Permissions whether the ACEs have been modified. If the check boxes
appear shaded, then, by clicking the Advanced tab, you can view and edit those
modifications.

Inherited Permissions
A tool that was released with Windows 2000 is the inherited permissions feature. It basically
allows permissions to be passed to subfolders and files, see fig below.

Quota Management

On the Quota Management node of the File Server Resource Manager Microsoft
Management Console (MMC) snap-in, you can perform the following tasks:
• Create quotas to limit the space allowed for a volume or folder and generate
notifications when the quota limits are approached or exceeded.
 • Generate auto quotas that apply to all existing folders in a volume or folder, as
well as to any new subfolders created in the future.
• Define quota templates that can be easily applied to new volumes or folders
and that can be used across an organization.

For Example:
• You can place a 200 megabytes (MB) limit on the personal folder of each user
on a server, with a notification to you and the user when 180 MB of storage
has been exceeded.
• A flexible 500 MB quota on a group's shared folder can be set. When this
storage limit is reached, all users in the group are notified by e-mail that the
storage quota has been temporarily extended to 520 MB, so that they can
delete unnecessary files and comply with the preset 500 MB quota policy.
• You can receive a notification when a temporary folder reaches 2 gigabytes
(GB) of usage yet not limit that folder's quota because it is necessary for a
service running on your server.
PATH’s

Both Windows and Unix/Linux systems use PATH’s. The use of a PATH allows files
to be executed that do not reside in the current directory. For example we are in
directory C:\tmp\jbloggs and we type the command cmd the cmd window will open
even though it is not in the directory C;\tmp\jbolggs. The reason this happens is
C:\windows\system32 where the cmd application is stored is in our PATH. Use the set
command to view the full details of your path.

Adding or Editing PATH

You should be able to

1 set up a shared folder

2 give users the correct rights on share
3 give users correct security on folders and files within the share
4 create a hidden share
5 set a quota on a drive
6 view and edit your path settings.