Tài liệu Sharing and Securing Files and Folders pptx

Sharing and
Securing Files
and Folders
T
his chapter provides an understanding of access control
to network file and folder resources. Chapter 21 provided
an in-depth review of the Windows 2000 file systems, especially
NTFS. Now, let’s look at the file systems from other viewpoints:
users and applications and, of course, administrators.
Most data is generated and stored on computer systems,
using the file and folder metaphors inherited from our three-
dimensional world. However, since the advent of local and
wide area networks, particularly the Internet, your files and
folders (directories) are accessible to anyone with a computer
and a network connection unless you secure them. You need
to secure the data within their files, and the folders that contain
those files, while at the same time providing controlled access
to authorized users. The NT File System (NTFS) lets you do that
on three security access levels:
✦ Shares
✦ Folder permissions and file permissions
(called NTFS permissions)
✦ Encryption
NTFS creates a hierarchy of folders in a volume, all starting
from a root folder (see also Dfs and mounted volumes in
Chapter 21). The earlier versions of NTFS could only store a
single folder hierarchy on a single hard drive or volume,
maintained on a single computer. As we stated in Chapter
21, the folder hierarchy (or folder namespace) can traverse
or span hard disk volumes on any computer on the net-
work. To keep things simple in this chapter, we’ll discuss

folder and files independently of where they may be
located on the network.
Note
22
22
CHAPTER
✦✦✦✦
In This Chapter
The Concept of
Shares, Permissions,
and Ownership
Strategies for Effective
Folder, File, and Data
Security
✦✦✦✦
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 789
790
Part VI ✦ File, Print, and Web Services
Sharing and Securing Your Data
Windows 2000, like all modern graphically managed operating systems, allows you
to manage your files and folders in the same way as your hardcopy filing systems:
in folders and filing cabinets. Think about the file room in a law firm or a newspaper
morgue. It is unlikely you would be allowed to just walk into this room: It is usually
locked or guarded, and you would need authority to enter, but you know it’s there.
The company does not hide it away from you, because it is a shared resource, and
they usually want you to know about it because you might need data in it to do
your work.
Shares are the clubhouses of the network. A share is where users and groups of
users go to share resources. You enable folder-sharing for your users and applica-
tions by creating a share, or in the lingo of mainframes, midrange, and legacy sys-

tems, a share-point. By owning the files and folders on your own machine (and
we discuss ownership next), you automatically have full access and control over
your folders and their contents. Administrators own all the folders they create
anywhere on the network, and can thus share them.
Over the years, we have found that most calls to the support desk originate
because a user or a group cannot connect to shared resources, such as folders,
files, and printers. When users cannot connect, and get the “access denied” mes-
sage, they assume the world has ended, such is the extent of their panic. Usually,
it is a simple case of an incorrect permission. However, we have seen how per-
mission misadventure causes much consternation and is a waste of time, so we
stress that every administrator should become an expert in this subject.
Getting back to our brick and mahogany file room: By having access to the file room,
you do not necessarily have access to every file or folder it contains. Depending on
your rank in the company, the department you work for, and the work you do, you
may or may not be allowed to open a file cabinet, read a file, check it out, change its
contents, or add data to it. Likewise, by being a member of a group of users or by
having individual authority, you may gain access to the NTFS share, but some files
will not be for your eyes. Others will be accessible for reading only—you might not
be allowed to change, delete, copy, or move them. The levels of access you have to
the folders and files are called permissions. Administrators, members of Admin-
istrator groups, and the owners of objects can assign permissions and control
access to these objects, and they can also encrypt the files.
Folder and file encryption is the third mechanism you can now use for protecting
your files and folders. It has been added to the Windows 2000 file system and is only
supported under NTFS. When you add Windows 2000’s support for cryptography
and distributed security services, such as Kerberos and digital certificates, to the
file system, you have what is known as the encrypting file system or EFS. The EFS
is fully discussed later in this chapter.
Note
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 790

791
Chapter 22 ✦ Sharing and Securing Files and Folders
Ownership
Another means of understanding shares or share-points is by understanding
ownership. Ownership is not a configuration setting, or a mere value in the registry
or Active Directory; it derives from the security services of the NTFS and the Win32
security system (this is discussed in more detail in Chapters 3 and 10).
It helps to understand ownership if you’ve done some Windows programming. The
Win32 API has a
Create or CreateFile function that creates objects such as folders
and files. If the
Create function you are calling can take a security parameter, you can
lock the object (pass a security descriptor) and keep other processes from accessing
it. The lock is like a key that you, the owner, get to keep when you create the object.
That is the essence of ownership. Of course, the whole process is managed by the OS
and requires no user actions.
When a process creates a file or a folder—objects—the file system assigns that
process the rights of ownership, and passes it a key. The process created it, so
that process owns it . . . and it can do whatever it likes with that object. If you cre-
ate a folder on the computer you are logged onto, or within a folder namespace to
which you have access, you own the folder. Only you and the processes that oper-
ate within your security context (activated by the validation of your password)
can access that folder.
Now, when other users or processes need access to the folder you just created, do
you allow them to take ownership, hand them the key? No, not normally, because if
you did, you would be losing your right to the object. By creating a share, you are
essentially inviting others to access the folder (with restrictions, of course), but you
don’t give them the key. If someone else with bad intentions got hold of your keys,
they might come back after dark and destroy your network. Remember the old adage:
Possession is nine-tenths of the law. And remember what we said about safeguarding

the Administrator account back in Chapter 10. You can do tremendous damage with
50 lines of code and access to the Administrator account.
The owner of an object can actually allow a specified user or a group to take over
the ownership of the object (we’ll get to that shortly). Taking ownership is a one-way
action. You can take ownership, but you cannot bestow it or return it. You can allow
someone else to take ownership; you assign them this permission. Ownership can
only be transferred if the would-be benefactor is willing to take it. By not being able
to transfer ownership unilaterally, NTFS prevents users from hiding dirty work. In
other words, you cannot go and lock up a folder and throw away the key, and then
make it look like someone else did the damage.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 791
792
Part VI ✦ File, Print, and Web Services
Publishing Shares in Active Directory
The idea of published shares is new to the Windows networking environment, and it
begins with Active Directory, as discussed in the previous chapter. Windows 2000
users connect to shared resources on a Windows 2000 domain by looking them up
in the Active Directory. You can still connect to shares on the browse list and from
the command line, as described later in this chapter.
Creating shares on Windows 2000 is really easy, and if you have Windows experience,
you will only need to read the next section as a refresher and to pick up subtle yet
important differences. Establishing shares on remote computers is another story,
however, and the process is handled in the new Computer Management snap-in
described later in this chapter.
Creating a Share
When you first create a share, the file system automatically gives access to the
Everyone group, unless you have taken steps to prevent that, discussed later. If
the contents of the files are sensitive, you need to remove the Everyone group
and assign access only to authorized users or groups.
Back in Chapter 10, we encouraged you to use common sense management prac-

tices and avoid assigning rights to individual users. The same advice applies to
shares. Share folders with groups, not individuals. One of the only times you should
circumvent this advice is when you need to audit individuals.
Sharing a Local Folder
If you are the owner of the folder or the folders within the local folder namespace,
then sharing a folder involves little more than right-clicking the new or existing
folder and selecting Sharing from the Context menu. Select the option Share this
folder in the dialog box. The share name field is enabled. This is demonstrated in
Figure 22-1.
As soon as the dialog box is enabled, you can enter the following share data:
✦ Share name: The actual folder name is used as the default share name, but
you can change this to reflect any name that better suits the application for
the share. It is a good idea to use the best share name for the share, possibly
one that better informs the user of the purpose of the share or that provides
a hint of the share’s contents. For example, a folder might be named Y2K, and
rather than changing that name (it’s been done before), which would impact
other applications, it would be better to make the share name “Y2K data files
and documents.” Share names can be up to 80 characters in length, and they
can contain spaces. However, if your users are attaching from the command
line or you have applications that might send share attach commands to
Note
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 792
793
Chapter 22 ✦ Sharing and Securing Files and Folders
the system console, you should stick to single names of between 8 and 12
characters (and even 8.3 names for those still using Windows 3.1). The best
command-line-compliant substitute for the aforementioned share name is the
simple Y2KDATA.
Figure 22-1: The Sharing tab on
the folder’s Properties dialog box

✦ Comment: The comment field will take 100 characters, so you can be creative
here. It is a good idea to include the comment field wherever possible because
it shows up in Explorer when users browse for a share. Although we said you
can be creative, be conservative. A hundred-character comment field forces
most users to waste time scrolling to the right.
✦ User limit: You will ignore this most of the time, allowing the client access
licensing to monitor the number of connections. On server shares there is
no maximum limit, but you can restrict connections for application-specific
purposes or licensing. Windows 2000 Professional prohibits more than ten
concurrent connections and several other exclusions you will discover . . .
so forget about using it as a substitute for a server.
✦ Caching: The cache settings allow you to configure offline access to the
shared folder. Offline folder and file access is touched upon later in this
chapter, and explained in the context of Group Policy and change control
in Chapter 11.
As soon as you enter the share name and comment, you can click the Permissions
button to admit users to the share and set the desired access types.
Once you have created a share, you will notice, as shown in Figure 22-1, that you
now have the option of creating another share. The New Share button does not
replace the old share; you can share a folder as many times as you like, each time
with different access clients and permissions. At any time you need to end a share,
just select the share name from the drop-down list and click Remove Share.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 793
794
Part VI ✦ File, Print, and Web Services
Establishing Shares on Remote Computers
There are two ways to connect to a remote computer and create a share-point on
it. The first and hardest way is by using the NET SHARE command at the command
prompt. This is explained in Appendix A. The second, and by far the easiest way, is
by opening the Computer Management snap-in (

compmgmt.msc).
Once you are in Computer Management, select the first option, Computer Manage-
ment (Local). Right-click it and select Connect to another computer from the Con-
text menu. This is illustrated in Figure 22-2. You can connect to a computer listed
in the Active Directory (the best way), or you can connect to a computer listed in
the domain. Once you have opened the remote computer into the snap-in, you will
be able to expand the System Tools tree and select the remote computer Shared
Folders option. From here on, the process of creating the share-point is no different
from creating shares on the local machine.
Figure 22-2: The Shared Folders option in the Computer Management
snap-in
Share Attributes
Share access can be given directly to users or processes, or implicitly through
group membership. Shared folders possess the following attributes:
✦ Shares only work on folder objects, and not on files that folders contain. You
cannot select a file, x-file, and share it as x-file on the network. But you can
share a folder called thexfiles and allow users to access the files in that folder.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 794
795
Chapter 22 ✦ Sharing and Securing Files and Folders
✦ The default access permission on a share is Full Control. This permission is
assigned to the Everyone group. So, if you create such a share, and have your
Guest account enabled and not governed by any domain policy, every com-
puter user has access to it. But you are a common-sense administrator, and
you will follow our advice and make sure that your network is locked down.
✦ Shares can be established on most file systems, including FAT. But NTFS
permissions, discussed later in this chapter, are peculiar to the Windows NT
and Windows 2000 operating systems.
✦ Shares are visible to you (if they are not hidden) when you are trying to
connect over the network. Share access also applies to the local user logged

onto the computer that is hosting the shared folder. This feature is extremely
important because it means you can prevent users who log on locally from
accessing folders. And it’s a surefire way of protecting your data on a note-
book computer.
✦ A shared folder on your machine is represented as an icon with a hand holding
the folder. But across the network, the icon does not include the hand.
✦ Shares can be hidden, a very valuable security and administration tool that
we will discuss later in this chapter.
Table 22-1 lists the folder permissions that apply to Windows 2000 shares. Remember
that the access level is at the share only; NTFS permissions provide the “second line
of defense” to locked-down resources. You set these permissions through the Share
Permissions properties, which you can access by clicking Permissions on the Sharing
page of the shared folder’s property sheet, as shown in Figure 22-3.
Table 22-1
Shared Folder Permission Types
Permission Privilege
Read The user can see the entire shared folder tree (root shared folder and
subfolders). The user can also see all the files in the folder tree (traversing)
and open them for reading. The user can execute applications in the
shared folder hierarchy.
Change This privilege inherits the Read privileges and also allows the user to
change the folders and the data in the files within the shared folder’s
namespace. The user can also change file attributes, and can copy, move,
and delete files and folders. The user cannot change the actual share.
Full Control This privilege allows the user to take ownership of the files and folders,
within the shared folder’s namespace. It inherits the privileges of the Read
and Change permissions. Under NTFS, only Full Control allows a user to
change permissions and take ownership of a file or folder.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 795
796

Part VI ✦ File, Print, and Web Services
Figure 22-3: The Share Permissions
dialog box
Deny
You can deny access to any of the above permissions. For example: If you deny Full
Control, you drop the privilege level down to Change. Deny is useful if you wish to
single out a user and deny him or her access (the same applies to groups). Deny
is the strongest of permission attributes; in other words, it takes precedence over
every permission. For example, if a user in a primary group has full access to a
share, but you deny access directly or via a secondary group, the user is denied
despite the access given in the primary group. However, it is better to take the
user out of a group rather than keep him or her in the share and specifically
deny him or her the access.
Accumulation of Share Permissions
Share permissions accumulate. If a user is a member of one group that is
given Read access, but he or she is also a member of another group that
is given Change access (to the same share), then the user’s cumulative
permissions in the share are Read and Change. The user’s effective
permission is Change, because it includes Read permission.
Moving or Copying Folders
When you move a folder, the shares assigned to it are deleted. The folder is not
shared at the new location. If you copy a folder, the new copy is not shared, but
the source folder remains shared.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 796
797
Chapter 22 ✦ Sharing and Securing Files and Folders
Intra-Domain Shares
Shares are not restricted to the users and groups of the domain in which they were
created. If a trust relationship exists between two domains, then a user or group in
one domain can be given access to the share in another domain (see Chapters 3, 7,

and 10). The administrator of Domain A can provide access to a user or to a global
or universal group from Domain B.
Who Can Share Folders
Members of the predefined Administrators, Server Operators, and Power Users
groups can share folders. On a member server, in a Windows 2000 domain, the mem-
bers of the Administrators or Server Operators groups can share folders that exist on
any computer on the network. On a standalone computer, only the Administrator and
members of the Power Users and local Administrators groups can share a folder.
Workgroups do not make for such flexible sharing. Only members of the local
Administrators group and the Power Users group can share folders. Remember
that if you own the folder, you can share it. But an administrator can take owner-
ship at any time.
Hidden Shares
The ability to hide shares is a useful feature of the Windows OS. It makes up for the
problem of shares being visible to everyone on the network, even to users who do not
have access to the shares. Relative hiding of shares is probably a very difficult and
cumbersome technology to introduce into the OS, but it makes sense to only expose
shares to users who have access to them. To the other users, the shares should just
not be visible . . . only available on a need-to-know basis. Active Directory goes a long
way to make that possible by locating published shares in organizational units.
It is, however, possible to hide shares by simply ending the share name with the
dollar sign ($). You can still connect to the share if you have access to it, but it
does not show up on the browse list (as nothing ending with the dollar sign shows
in the browse list). You connect to the share using Run, as explained next, or at the
command line using
NET SHARE (see Appendix A).
Here is a good example of a hidden share in action: A certain company in Florida
transmits millions of dollars of direct deposit information to the bank every after-
noon. The application resides at the data center in Miami, but it logs into a hidden
share on the wide area network, after an application in Los Angeles writes the

direct deposit information to a file in the same hidden share. Both applications or
processes are members of the Banking group, and they have Read and Write access
to the file in the share. No one else can see the share on the network, and the cloak-
ing affords the share a measure of concealment. Of course, it is possible to dig
around on computers and look for hidden shares. But did you know that you can
hide computers as well? See Chapter 3.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 797
798
Part VI ✦ File, Print, and Web Services
Connecting to Shares
There are several ways to connect to shares. You can connect using interactive
tools or at the command line. You can also connect to published shares in Active
Directory, which is the preferred way. DNS directs you to the domain controller
hosting the Active Directory, so connecting to a share is as simple as browsing
for a Web page:
To connect to a share using the Map Network Drive Wizard (this option assigns
a drive letter):
1. Right-click the My Network Places on the desktop and select Map
Network Drive.
2. Type in the UNC path to the folder if you know it, or click Browse to drill
down to the exact folder.
3. Enter a drive letter of your choice or use the default.
4. Check the Reconnect at Logon checkbox if you wish the connection to
remain persistent.
5. You can also connect to the share under another user name. All you need
is the logon name and password. This is useful if you need to connect to a
resource on a domain for which you have not been fully authenticated.
To connect to a share using Run:
1. Select Start➪ Run.
2. Type in the UNC path to the folder if you know it, or click Browse to drill down

to the exact folder.
To connect to a share from My Network Places:
1. Open My Network Places.
2. Find the computer that contains the share and drill down until you locate
the folder in the browse list.
3. When you find the share, double-click it to establish the connection.
To connect to a share in the Active Directory:
1. Open My Network Places.
2. Expand Active Directory until you locate the domain in which you wish to
locate a published share.
3. When you find the share, double-click it to establish the connection.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 798
799
Chapter 22 ✦ Sharing and Securing Files and Folders
Administrative Shares
When you install Windows 2000, NTFS automatically creates administrative shares
on your local volume. These shares are placed in strategic administrative folders,
the most important being where you installed the Windows 2000 system files. The
administrative shares are listed in Table 22-2.
Table 22-2
Administrative Shares
Share Purpose
Roots (C$, D$, E$ and so on) The root of every volume on a Windows 2000 server (and
even on NT 4.0 and earlier servers) is shared. This means
that if you can map to the share, you have access to the
entire volume.
ADMIN$ This share is the system root, the Windows 2000 system
folder hierarchy. To map to this share simply use
\\SERVERNAME\ADMIN$.
PRINT$ This share is created when you install the first shared

printer on the server. This share is established at
\\SERVERNAME\SPOOL\DRIVERS, and its purpose is to
allow clients to remotely pull printer drivers for installation
on their machines. The Everyone group has Read access
to this share, and administrators are able to install new
drivers to the share as needed, using Full Control.
NETLOGON This share is used for the net logon service, which is the
mechanism to service logon requests to the server. It is
also used for locating logon scripts.
IPC$ This is the share for Named Pipes, intra- and inter-process
communications between applications.
It is possible to shut off these shares, and doing so might result in unpredictable
results. You can, for example, shut down the NETLOGON share to prevent anyone
from trying to obtain authentication at your machine—and you may have legitimate
reasons for doing so—but the correct way is to stop the NETLOGON service.
We have found that you can delete the share, if you are an administrator or have
ownership of the share. However, if you try to change permissions on the share,
Windows 2000 denies access with a nasty message saying that built-in shares can-
not be modified—absurd in light of the fact that you can delete the administrative
shares at any time after you unseat the ownership.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 799
800
Part VI ✦ File, Print, and Web Services
Incidentally, if you delete an administrative share, it will return when you reboot the
computer. The administrative shares are controlled by the server service. Anytime
that you restart this service, such as reboot time, the shares are reestablished and
reset to the factory default.
You might be concerned that the administrative shares pose a potential danger, and
they do. In fact, all shares are dangerous if not managed with common sense. It is
feasible, if you know Windows NT or Windows 2000, to map to the shared roots on

each drive. If you are able to connect, you get total access to the drive and the
entire folder hierarchy within.
You would be right to say that these shares are the equivalent of leaving the
hen-house door open for the fox to walk right in. However, only administrators
have access to these shares. That, however, is still not comforting, and the whole
administrative share quirk is another reason why we lock up the Administrator
account. As long as the Administrator account’s identity and password are locked
away, and security policy is in force, you will not experience hacking of these shares.
Common-Sense Strategies for Sharing Folders
The following sections include strategies for closing holes in your network with
respect to shares.
Restricting Shares
Many administrators prefer to keep shares wide open by leaving the Everyone
group in the share with full access. Instead, they control access to subfolders via
folder and file permissions. We understand this policy, and the reason is the effort
to relieve the administrative burden (one less thing to worry about). But is this
common-sense management? Not if it means you are leaving doors unlocked on
your network.
The problem is that the subfolders below the share become accessible to the users
given access at the share-point. And if the Everyone group has access to the root,
then it has access to all the subfolders. So by not restricting the share, you are in
effect giving yourself more work to do because you have to go to every subfolder
and apply NTFS permissions. On a complex folder hierarchy, the task of locking up
all the subfolders could be next to impossible. If you want to keep shares (and your
network) secure, it is best to remove the Everyone group from the share and admit
only the groups that require the access to the folder namespace. Further security
can be applied with the file and folder permissions.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 800
801
Chapter 22 ✦ Sharing and Securing Files and Folders

Limiting use of the Everyone group makes it easier to troubleshoot user- related
problems. The Everyone group forces you to be cognizant of every user account in
your domain and every domain with which you share trusts.
Setting Up Application Share-points
When users need to access a remote application, shortcuts are created on their
systems (manually or via profiles, logon scripts, and Group Policy). The users run
the applications from the network shares, and the applications run in the local
memory space on the client computer. Most well-designed Win32 applications can
be executed multiple times in this fashion. And you will often be asked to install an
application on the applications server and then share that folder. The following
strategies are suggested for creating application shares:
✦ Create a root “application share-point.” On our servers, we call these shares
the “Apps” share-points.
✦ Under the Apps share-point, you can create a share for each application you
are installing, and then share each respective install folder. It might not be nec-
essary, however, because the subfolders are accessible to those given access
to the share-point. If you need to restrict access to a subfolder, simply ensure
only that the authorized group has access, through folder permissions, which
are discussed in the latter part of this chapter.
✦ Provide access to an administrators group (or whatever suits your purpose)
for the root (Apps) share and make sure the group has the Full Control privilege
assigned. This allows application administrators only to manage the applica-
tions, such as patches and upgrades. You might also add a special “applications
admins” group with Change control enabled to allow technicians or consultants
to troubleshoot the applications.
✦ Remove the Everyone group from the share and provide access to either the
Users group or a specific group that requires the access. Make sure these
groups have only the Read privilege assigned.
Setting Up Data Share-points
Data shares contain files that users or applications need to share. Users mostly

share spreadsheet and document files, while applications (clients) need access to
databases. It is common-sense practice to keep the data share-points separate from
application share-points because data shares require more that just Read access.
Data backup is another good reason for separate data share-points. Your backups
should not be repetitively backing up application files (see Chapter 17), and the
share is easy to identify and backup.
Tip
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 801
802
Part VI ✦ File, Print, and Web Services
✦ Create a root “data” share-point for applications. Name the shares after the
groups or projects that require them. For example: Y2K compliance docs
or materials management. Naming the shares after the application name is
confusing, and you may have many shares that contain data generated by
the same application. A share named Microsoft Access Files would be a bad
idea. For example, we manage several hundred servers, and they all contain
Microsoft Access files.
✦ Give your users Change access so that their applications can update files and
save the data. Administrative groups should be given Change or Full Control
as needed.
Offline Access
It is possible on Windows 2000 to configure shared folders and their contents for
offline access. This means that the contents of these shares can be “seconded”
to the target computer. The remote or standalone computer disconnects from the
network and maintains a mirror or shadow copy of the folder and files. You con-
tinue to work with the offline resource as if you are connected to it on the server.
To mark a file or folder for offline access, do the following: Right-click the shared
folder and select the Caching option. The Caching Settings dialog box appears.
All shares are cached for offline use by default, so you can clear the “Allow caching
of files in this shared folder” checkbox if you do not need to cache the contents of

the folder.
If you do want to keep caching for offline access, you can choose one of the options
illustrated in Figure 22-4 and outlined in Table 22-3.
Figure 22-4: The Caching Settings
dialog box
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 802
803
Chapter 22 ✦ Sharing and Securing Files and Folders
Table 22-3
Caching Settings
Caching Option Purpose
Manual caching for documents This option lets users select the files to be cached.
This is the default setting for all shares, but only
files marked for offline use will be cached. Every
file marked for caching is cached, regardless of
whether the file was opened or not.
Automatic caching for documents This option allows every file in the folder that is
opened to be automatically cached. This option
saves on bandwidth because only files actually
used are cached.
Automatic caching for programs This option provides for unilateral caching of
program files and applications. The file is cached
for offline use, but when the user reconnects to
the network, no synchronization is required.
Caching Attributes
The following are attributes of the offline access features of Windows 2000:
✦ When a computer connects to the share on the network, any files marked
for caching on the server are copied to the client computer’s hard disk.
✦ When a computer connects back to the share on the network, any files that
have been updated on the client computer are copied to the server.

✦ When the user logs off the network, the server and the client synchronize
the files automatically.
Synchronizing Cached Resources
To manage the synchronization between offline files and folders and their sources
on the server clients, you need to open Windows Explorer and select Tools➪
Synchronize from the menus. In the Items to Synchronize dialog box, first select
the items in the list to synchronize, and then click the Synchronize button.
The synchronization management options, as shown in Figure 22-5, can be used to
determine when offline files are synchronized with the versions on the servers. You
can do either a quick or full synchronization. The latter takes longer but ensures
that the current versions are saved to the network and copied to the client.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 803
804
Part VI ✦ File, Print, and Web Services
Figure 22-5: The Synchronization Settings
dialog box
Securing Files and Folders with Permissions
As you learned in Chapter 3, permissions are the means by which you control
access to network objects. After shares, they are the second and third lines of
defense in protecting data and network resources. File and folder permissions
are controlled by NTFS. This section deals specifically with the permissions
that control access to volumes, folders, and files, as opposed to permissions
that control access to share-points.
Permissions kick in as soon as you format a volume to NTFS. Volumes are protected
with NTFS permissions, just as are folders and files. As soon as you have formatted
a volume to NTFS 5.0, right-click the volume in Windows Explorer and select the
Properties option on the ensuing Context menu. Click the Security tab. You will now
notice that the Everyone group has default access to the drive, and thus any new
folder or file you create will allow Everyone access. We advise that you change that
as follows (please proceed with caution; this can be done on a drive in service but

is safest and most easily done on a new volume):
1. Click Advanced.
2. Make sure the Reset permissions checkbox is unchecked (this avoids
resetting permissions on all child objects, and we’ll explain why later).
3. Click Add, and add the Administrators group or any special administration
group or account you have created. We always create a root admin group
and often use this group instead of the built-in one for tighter security.
4. Assign Full Control to the Administrators group.
5. Remove the Everyone group. Click Apply.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 804
805
Chapter 22 ✦ Sharing and Securing Files and Folders
Now, only your select administrators can create and manage new folders on the vol-
ume. The default allows anyone to create a folder on the volume. Also, each time that
you create a folder, you automatically assign your administrators group to the folder
and nothing else. This makes for good security practice and keeps the doors locked
until the folder is ready for group access. Remember that the Everyone group is auto-
matically given carte blanche access to any share you create, and there is currently
no way to override that because the volume’s administrative share is inaccessible at
the user level.
We strongly recommend that you remove the Everyone group’s Full Control
permissions. If you don’t, you’re creating a security risk.
The Permission Types
Table 22-3 lists the folder permissions you can apply. Folder and file permissions
are accessible from the Security tab of the Folder Properties dialog box. To access
properties, right-click the folder and select the Properties option. Then select the
Security tab, as shown in Figure 22-6.
Table 22-3
Folder Permissions
Permission Purpose

Read This permission is the first that provides access to the folder’s
contents. Without this permission, the user would get the dreaded
“Access Denied” message. This permission allows the user to see
ownership, permissions, and file attributes. All Write permissions are
grayed out.
Write This permission allows you to authorize the user to create files and
folders with the folder under management. You can also permit the
ability to change file attributes and view ownership and permissions.
List Folder Contents This permission allows you to let the users see files and subfolders in
the folder under management.
Read & Execute This permission allows you to authorize the user to traverse the
folders from the root folder down. It also lets the user read the files
and execute applications in the folder under management and all
subfolders.
Modify This permission lets you authorize users to delete the folder under
management and all earlier permissions.
Full Control This permission allows the user to take ownership and perform all
the actions of the previous permissions.
Deny You can deny the user the permissions at any time. If you deny Full
Control, you effectively deny all sub-permissions as well.
Caution
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 805
806
Part VI ✦ File, Print, and Web Services
Figure 22-6: The Security tab on the
Properties dialog box
Table 22-4 lists the permissions possible on files.
Table 22-4
File Permissions
Permission Purpose

Read This permission permits the user to read the files and view their
attributes, ownership, and permissions.
Write This permission permits the user to change the files’ contents and
attributes, and to view ownership and permissions.
Read & Execute This permission permits the user to run applications and also applies
the Read permissions to the file.
Modify This permission permits the user to delete and perform all the actions
permitted by the previous permissions.
Full Control This permission allows the user to take ownership and perform all the
actions of the previous permissions.
Deny You can deny the user the permissions at any time. If you deny
Full Control, you effectively deny all sub-permissions as well.
NTFS 5.0 also lets you assign advanced versions of the permissions we just described.
These permissions, shown in Figure 22-7, are more specific versions of the general
permissions. In other words, they allow you to pinpoint the level of access you wish
to provide to the user, such as only read a file or only execute an application . . . as
opposed to the Read and Execute options in the basic permissions.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 806
807
Chapter 22 ✦ Sharing and Securing Files and Folders
To assign Advanced permissions, click the Advanced button on the Security page
of the Properties dialog box. Then click the View/Edit button on the dialog box
that appears.
Figure 22-7: The Permission Entry dialog box
Permissions Attributes
You can assign multiple permission types to users, groups, and computer accounts,
for tighter control of access to folders and files. As with shares, you need to under-
stand the attributes of permissions to more effectively achieve your objectives.
Permissions possess the following attributes:
✦ Permissions are cumulative. A user’s total authority is the sum of all permis-

sions granted to him or her over the use or access of an object. For example:
If a user is granted Read permission by virtue of his or her membership in the
Readers Group, and is a member of an Application Access Group that bestows
the Execute permission, then the user’s total access is Read and Execute.
✦ The Deny permission option overrides any and all permissions granted to a
user over the specific object. If a user has Full Control of an object by virtue
of membership in several groups, it only takes the Deny option in one group
to lock the user out of the file or folder completely.
✦ File permissions are not stronger than folder permissions. This means that any
file permission bestowed to a user does not override or supercede any permis-
sion granted at the folder level. In other words, if you give a user access to a file
(even Full Control), but deny the user access at the folder level, the user cannot
access the file. This mechanism prevents the user from connecting to the file
from the command line by specifying a UNC path to the file.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 807
808
Part VI ✦ File, Print, and Web Services
Inheritance
The permissions that you assign to a given folder or file can, by default, propagate
down to the child folders and files. In other words, if the Everyone group is given
access to a folder and inheritance is turned on for all the subfolders in the hierar-
chy, they will also allow the Everyone group to have access, as will the files. We
recommend you keep inheritance turned off by default or via domain policy so
that you do not leave doors open by acts of omission or by failure to keep an eye
on the propagation chain reaction.
Of course, the inheritance option is useful when you have to build a huge folder
hierarchy and automatically provide one group with specific permission access
to the entire folder and file namespace.
To prevent or allow permission inheritance, simply uncheck or check the Allow
inheritable permissions option on the Security tab. You will be prompted to Copy

or Remove the inherited permissions every time you elect to uncheck the check-
box. By turning inheritance off for a folder, you make the folder the new parent,
and if subfolders have inheritance turned on, they become children.
Earlier, when we advised you to knock out the Everyone group from the volume
access control list, we made special note to ensure you kept the “Reset permissions
on all child objects and enable propagation of inheritable permissions” checkbox
unchecked. The option can be selected from any level in the folder hierarchy.
The option brings back not-too-fond memories of the “Replace permissions on
subfolders and files. . .” option on NT 4.0 and earlier versions of NTFS.
By running this option, you are replacing, not merging, the permissions on all child
folders and files on the volume. This means that any permissions applied to sub-
folders and files will be lost. If that is not your desired end, you could end up losing
weeks of work restoring permissions so that users and applications can operate.
And it gets worse: The action cannot be undone. You will only be able to rebuild
what you had from backups and documentation. Proceed with care here, as it could
cost you dearly.
Taking Ownership
Administrators, owners, or users with Full Control of an object can set up a user
or a group to take ownership of the object. This is done by first admitting the user
or group to the access control list (ACL), and checking the Take Ownership option
on the Permission Entry list as described previously, or by giving the potential
owner Full Control (which is a security risk). See Figure 22-8.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 808
809
Chapter 22 ✦ Sharing and Securing Files and Folders
Figure 22-8: The Ownership
tab on the Permissions Entry
dialog box
Administrators, as long as they inherit their power from an administrator’s group,
can take ownership of objects regardless of the permissions in the object’s ACL.

To take ownership of the object, you do the following:
1. Open the Access Control Settings dialog box for the object in question
(see Navigating the Security Tab discussed earlier). Select the Owner tab.
2. In the Change owner to list box, select the user or group account name that
will be taking ownership. Highlight the account and click Apply.
3. Check the Replace owner on subcontainers and objects to take ownership
of all child subfolders and files contained by the parent folder.
Copying and Moving
Often, you may need to move or copy folders and their contents to other volumes
or containers on the network. You cannot do this, even as an administrator, if you
do not have ownership or the permission to do so. But you can take ownership and
then assign yourself the necessary permissions.
Before you move a folder or a file, you should check and document the ownership
and rights before the actual copy or move. Once you have successfully completed
the process, you can reapply any permissions along the way.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 809
810
Part VI ✦ File, Print, and Web Services
The following security behavior applies to copying, moving, and ownership of files
and folders:
✦ When you copy a file or a folder to a container within the same volume,
the permissions assigned to the object are dropped, and the object and its
contents and children inherit the permissions assigned to the destination
container.
✦ When you move a file or a folder to a container within the same volume, the
permissions assigned to the object are kept, and the object’s permissions
remain independent of the destination container.
✦ When you copy a file or a folder to a container on another volume, the permis-
sions assigned to the object are dropped, and the object and its contents and
children inherit the permissions assigned to the destination container.

✦ When you move a file or a folder to a container on another volume, the per-
missions assigned to the object are dropped, and the object and its contents
and children inherit the permissions assigned to the destination container.
✦ You cannot copy or move a folder or a file to the destination container if the
destination container has not given you Write access, regardless of which
volume you are moving or copying to.
✦ The user account that performs the actual copy or move becomes the owner
of the objects when they reach their destination, usually the administrator.
✦ Permissions and ownership do not change at the source objects.
Strategies for Managing Permissions
Assigning permissions is not a complex art, but you need to be orderly and consistent
about the process. It looks easy, but on a big network with a lot of resources, thou-
sands of users, and mission critical applications, you cannot afford to drop the ball.
Here’s a good example: Every night at a certain company, a process on an AS/400
connects to a share on a Windows network, opens a file, and writes a million dollars
worth of business to the file. As soon as the file is closed and saved, another process
connects to the same file and performs special functions on the data. What would
happen if by some mistake on the part of the administrator, the permission on that
file was changed, by some oversight, and the file could not be opened? It’s possible
that a million dollars worth of business could be lost. In our case, we had alerts on
the AS400 that raised an alarm when the process failed. And the only damage done
was the administrator was beeped at three in the morning to fix the problem.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 810
811
Chapter 22 ✦ Sharing and Securing Files and Folders
Consider the following guidelines when working permissions:
✦ Create groups for access to folders and files, and assign them only the neces-
sary permissions required to work on the files. If the group only needs the
Read permission on the file, then only assign Read permission.
✦ Have team leaders or department heads formally request all permission levels.

And have them put the requests in writing. Then, only assign the rights accord-
ing to the written request. In the event that a user accidentally deletes a file, the
damage will not be on your head. All requests for permissions should be chan-
neled through the help or support desk, where a case can be opened specifi-
cally for the purpose.
✦ Document everything you do on a permissions case. You will always have some-
thing to refer back to if there are problems later. Often, you will get a request to
restore a folder and permissions back to the way they were because of some
problem. Folders and files get deleted, and the backups do not always contain
the latest permissions work performed on the object. Make sure your documen-
tation is clear and concise so that other administrators or support desk staff
can handle the case.
✦ Use the Deny option only when it is essential or urgent to implicitly deny
access to a user or group. Opt rather to remove a user from a group or
remove the group from access control.
✦ Work permissions on a folder-by-folder or file-by-file basis. Make sure the
permission requestor opens a separate support case for each permission
required on a folder or a file.
✦ Avoid propagation where at all possible. In other words, don’t simply set
permissions for a root or parent folder and then leave all subfolders exposed
to the inherited permissions. By the same token, don’t just add a group to
the parent folder when they only and specifically need access to a single
subfolder or file. (Prevention is better than cure when dealing with deleted
or damaged files.)
✦ In today’s world of virus and denial of service attacks, it makes sense to
assign Read and Execute permissions to application folders or files (see
Chapter 3). This prevents any hostile attempt to delete or infect files in a
folder, or to replace the file with a Trojan horse.
✦ When working with public data folders, assign the Read and Execute permis-
sion and the Write permission to the group requiring access to existing files.

This allows the group to read or execute a file, and to save changes when nec-
essary. Consider it good and safe practice to add the built-in Creator Owner
entity to the folder and assign it Full Control. This means that users who cre-
ate their own files can safely perform all necessary functions on the file, and
delete it if need be.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 811
812
Part VI ✦ File, Print, and Web Services
✦ Assigning permissions to files at every corner can be tedious. It makes sense
to classify files according to their level of importance and application, and
then to group them in folders. This would allow you to assign permissions
to the folders, and not each file.
For most enterprise work environments, share and folder and file permissions are
sufficient security. However, if someone steals a server or a hard disk, and attempts
to access its files from another operating system, it is possible to gain unfettered
access to the data. If the data needs to be protected from such an attack, no NTFS
permissions will keep the data safe. You need to encrypt your data, and that can
now be done with Windows 2000 and the Encrypting File System.
Securing Files with the Encrypting File System
Windows 2000 provides a new feature called the Encrypting File System (EFS)
that enables users and administrators to encrypt and protect the file system
in situations where the file system is subject to unauthorized physical access.
This would also include a server in a small office that typically does not lock the
server in a secure computer room, or a public place that would use a server to
support a transient work force, such as a circuit court or polling station. EFS is
invaluable on workstations where hard disks are accessible or on notebooks that
are easy pickings for the criminally motivated. A storage area network (SAN) is
also an ideal candidate for EFS, as is an intranet that allows many people to access
secure corporate data, such as 401K or similar employee-related information that
should not fall into unauthorized hands. EFS provides on-the-fly encryption and

decryption, working transparently to the user just as NTFS compression works
behind the scenes without any interaction with the user.
NTFS provides a means of protecting data while it is safely tucked in a user’s com-
puter or a server, and that computer is not subject to a direct hacker attack. But
there is little to prevent someone from stealing a computer or removable storage
device and gaining access to the device by cracking the password or using one
of the tools floating around the Internet or available commercially that enables
access to NTFS volumes while bypassing NTFS security. The only viable solution,
other than using only internal devices and wrapping hefty chains around your
computers, is to use encryption.
Encryption on individual files is not always an answer, either. Many applications
create temporary files when you work with a document, and these temporary files
are not encrypted unless you use an encryption system that automatically encrypts
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 812
813
Chapter 22 ✦ Sharing and Securing Files and Folders
everything in the folder where the temporary files are created. EFS addresses this
potential problem, as well as other disadvantages of some other file encryption
mechanisms.
EFS supports encryption of folders and files on NTFS volumes but does not support
encryption on FAT volumes (because encryption is integrated with the NTFS file
system, it relies on NTFS reparse points and an installable NTFS file system filter).
You can use encryption on folders and files stored locally as well as on remote
servers. However, encryption doesn’t protect file data as it moves from the remote
server to your workstation across the network (or vice-versa) because the network
traffic is unencrypted. If you need to ensure security throughout the entire process,
use IPSec to encrypt network traffic.
How EFS Works
EFS employs public key encryption and the Windows 2000 CryptoAPI architecture
to encrypt and protect files. Windows 2000 encrypts each file with a unique, ran-

domly generated file encryption key. These keys are independent of the user’s pub-
lic/private key pair. By using a different key for each file, Windows 2000 provides a
very secure encryption method that is difficult to compromise at all, much less on
a widespread basis (decrypting an entire volume of encrypted files, for example).
The current implementation of EFS uses the Data Encryption Standard X (DESX),
which provides 128-bit encryption, which was until recently only available in North
America (see Chapter 3).
As an administrator, there is very little, if anything, you need to do to enable users
to encrypt and decrypt files. EFS automatically creates a public key pair and a file
encryption certificate for a user the first time he or she attempts to encrypt a file.
This eliminates the need for you to create a certificate or key pair for each user
who needs or wants to use EFS. The users’ encryption certificates and keys are
stored in their profiles, so they are available each time a user logs on.
When a user encrypts a file, EFS automatically generates a bulk symmetric encryp-
tion key and then encrypts the file using the bulk encryption key. EFS then uses the
user’s public key to encrypt the bulk encryption key (called a File Encryption Key, or
FEK). EFS stores the FEK for an encrypted file within an attribute called the Data
Decryption Field (DDF) within the file itself. In addition, EFS also encrypts the bulk
encryption key using the recovery agent’s public key. This FEK is stored in the Data
Recovery Field (DRF) of the file. The DRF can contain data for multiple recovery
agents. Each time EFS saves the file, it generates a new DRF using the current
recovery agent list, which is based on the recovery policy (explained later).
Figure 22-9 illustrates the encryption process.
4667-8 ch22.f.qc 5/15/00 2:18 PM Page 813