File sharing is one of the most important uses of a network. Any directory on any workstation or server in the network can be set up as a shared directory.
Although shares don’t have the same level of security as NTFS directories on a dedicated server, Windows does provide a simple set of security features for shared directories.
Creating a Share
You can create a share with any volume or any directory within a volume. You can create shares in either NTFS or FAT partitions, although shares in NTFS par-titions can be made more secure. To create a share, right-click a drive or a direc-tory in an Explorer window and select the Sharing option. The Sharing Properties dialog box is displayed.
From this dialog box you can specify these options:
Not Shared/Shared As Specify whether the volume or directory should be shared.
Share Name Choose a name for the share. This name will appear as a directory name when users view a directory listing for the server. If the share will be accessed by users running Windows 3.x or if your users use DOS applications, be sure to use a DOS-compatible name for the share (eight or fewer characters).
Comment Enter a description of the share’s purpose, or other information.
(This is optional.) The contents of this field are displayed in the Explorer window to the right of the share name if the user selects the Details view.
User Limit If Maximum Allowed is selected, the number of users access-ing the share is limited only by the Windows NT license. If a number is specified, only that many concurrent users can access the share.
4374Book.fm Page 166 Tuesday, August 10, 2004 10:46 AM
Windows Security 167
Permissions Clicking this button displays a dialog box that allows you to change permissions for the share, as described later in this chapter.
Caching Click this button to configure caching options for this share.
Offline caching allows users to store the file locally on their hard disk so it’s available even if they’re not online or if the server is unavailable.
When a directory or drive is shared, it is listed in Explorer with a special icon that shows a hand underneath the drive or folder icon.
Accessing Shares
Although a server might have several shares configured—some entire volumes, some directories several levels deep—they all appear to users as a single listing under the server’s name. Users can navigate to the server name using the My Net-work Places icon and then open it to display a list of shares. Unfortunately, share names are not shown automatically in the Active Directory when you double-click on a computer—they must be manually added in the Active Directory hierarchy.
As an example, suppose we created several shares, including VOL_F for an entire NTFS volume and IE4 for the \Program Files\Plus!\Microsoft Internet directory. A user who navigated to the server through My Network Places or Network Neighborhood would see a flat list of shares.
To make access to shares more convenient for users in the workgroup, you can create Desktop shortcuts to particular directories. You can also map a drive letter on the workstation to the share. This method has the benefit of not only fooling users into thinking it’s a local drive, but also fooling DOS and Windows applications that otherwise might not support network access. To map a drive to a share, right-click the My Network Places icon and then select Map Network Drive. Mapping drives is not normally necessary to access files from the Desktop Explorer or from Win32 applications.
To use this dialog box, choose a local drive letter and then choose a server name and path to map the drive to. In Windows NT, the window at the bottom of the dialog box displays a list of servers and shares. In Windows 2000 and XP, you click the Browse button to search for a server and share. Select the Reconnect at Logon option to have the drive mapped each time the user logs on.
4374Book.fm Page 167 Tuesday, August 10, 2004 10:46 AM
168 Chapter 10
As an administrator, you have another option for displaying a list of shares on a server. The Computer Management snap-in’s Shared Folders extension allows you to list shares on the local machine, add or remove shares, and monitor users who are currently accessing shares. The tool is available in the Administrative Tools folder and works just like every other MMC snap-in.
Default Shares
Windows automatically creates some shares, called administrative shares, which are accessible only to administrators and the operating system itself.
These shares are used for remote administration and communication between systems.
Each drive is automatically given an administrative share, with the share name being the drive letter followed by a dollar sign. The ADMIN$ share is con-nected to the \WINNT directory on each server. There is also an IPC$ share, used for inter-process communication between Windows NT servers, and a PRINT$
share, which shares printer information between servers. Domain controllers have a SYSVOL$ share used to distribute group policies, scripts, and installa-tion packages.
As you’ve probably noticed, these shares don’t appear in the browse lists that you can view from the Explorer. The only way to list them is with the Computer Management snap-in, which was described in the previous section.
You can create your own “administrative” shares. Any share name ending with a dollar sign ($) will be hidden from browse lists. Users (administrators or not) can access the share if they know its exact name.
Administrative shares present a potential security risk. A hacker who has gained access to the Administrator account on a single workstation in the work-group can access the system drives of other workstations, effectively allowing administrator-level access to the entire workgroup.
You can improve security by disabling the administrative shares. You can remove the shares from each drive’s Properties window or use the Shared Folder extension’s Stop Sharing option. It’s best to disable all of these and then add a share for any specific drives or directories that need to be available across the network.
Share versus File Security
Share-level security is similar to file system security, but not nearly as sophisti-cated (or as secure) because share access control entries can be applied only to the share as a whole. Security cannot be customized within a share.
There is one significant advantage of share-level security: It works with any shared directory, whether it’s on an NTFS or FAT volume. Share-level security is the only way to secure FAT directories. However, the share permissions you set affect only remote users. Users logged on to the machine locally can access
4374Book.fm Page 168 Tuesday, August 10, 2004 10:46 AM
Windows Security 169
anything on a FAT volume, shared or not. Share-level security also does not apply to users logged on locally or to Terminal Services clients.
Share Permissions
To set permissions for a share, click the Permissions button from the Sharing Properties dialog box. By default, the Everyone built-in group is given Full Con-trol access to the share—in other words, share security is not implemented by default. The first thing you should do to secure a share is remove the Everyone group from the list. You can then add any number of users or groups and give them specific permissions. The following are the permissions available for shares, and each can be allowed or denied:
Read Allows users to list contents of the directory, open and read files, and execute programs.
Change Allows users to create, delete, or modify files, as well as do every-thing the Read permissions allow.
Full Control Allows all Read and Change permissions. In addition, users can change permissions and change file ownerships.
IPSec
Windows can be configured to use IPSec to secure communications between computers. Using default IPSec policy rules, you can configure clients to allow encryption and configure servers to request encryption or require encryption. A server that requires encryption will only communicate with hosts that have a valid Security Association (SA) that can be negotiated using Internet Key Exchange (IKE).
Windows 2000 supports both Authenticated Headers (AH) and Encapsulat-ing Security Payload (ESP) in transport mode. Windows 2000 does not support ESP tunnel mode (IP encapsulation). This means that a Windows host cannot act as a bastion host and encrypt the communication stream between two private networks; it can only encrypt communications between itself and other hosts.
Windows 2000 uses IKE to negotiate encryption protocols and keys among hosts. As with any implementation of IKE, a private key is used for IKE authen-tication. In the case of Windows 2000, the private key can be a valid Kerberos ticket, a certificate, or a manually configured secret key.
Kerberos tickets Make IPSec authentication seamless among hosts in the same domain, but they only work when all the participants are running Windows 2000 or higher.
Certificates Are appropriate for use in extranets, in situations in which trust does not transit between domains, in communication with non-Windows
4374Book.fm Page 169 Tuesday, August 10, 2004 10:46 AM
170 Chapter 10
hosts that can utilize certificates, or in environments where a Public Key Infrastructure (PKI) is in place.
Manual secret keys Are useful for encrypting communications between hosts that are not in domains and not in PKI environments where commu-nications with non-Windows hosts are required; they are also useful when compatibility problems prevent the use of Kerberos or certificates.
Windows 2000 creates filters to determine which SA a particular host belongs to in order to encrypt the communications with that host. These filters can be edited by the administrator to fix problems and for further customization or refine-ment. Automatically created filters tend to have problems if the host has more than one network adapter (as all remote access servers do) and in other situations.