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.