In addition to shares created by a user or administrator, the
system creates a number of special shares that shouldn’t be modified or deleted.
These include the administrative shares: the ADMIN$ share and the hidden shares for each hard drive volume
(C$, D$, E$, and so on). These shares allow administrators to connect
to drives that are otherwise not shared. These shares are not visible
by default and can be connected to only by administrators.
Special shares exist as part of the operating system’s
installation. Depending on the computer’s configuration, some or all
of the following special shares might be present (and none should be
modified or deleted):
ADMIN$ Used during the remote
administration of a computer. The path is always the location of
the folder in which Windows was installed (that is, the system
root). Only Administrators can connect to this share.
driveletter$ The root folder
of the named drive. Only Administrators can connect to these
shares on Windows SBS servers or clients.
IPC$ Used during remote administration and when viewing
shared resources. This share is essential to communication and
can’t be deleted.
NETLOGON Used while processing domain logon requests. Do not
remove.
SYSVOL Required on domain controllers. Do not
remove.
PRINT$ A resource that supports shared printers.
To connect to an unshared drive on another computer, you need to
be logged on using an account with the necessary rights. Use the
address bar in any window, and type the address using the following
syntax:
\\computer_name\[driveletter]$
To connect to the system root folder (the folder in which
Windows SBS is installed) on another computer, use the following
syntax:
\\computer_name\admin$
1. Ownership and How It Works
Every object on an NTFS volume has an owner. By default, the
owner is the person who created the file or folder. The owner
controls how permissions are set on the object and to whom
permissions are granted. Even if the owner is denied access, the
owner can always change permissions on an object. The only way to
prevent this is for the ownership to change.
Ownership of an object can change in any of the
following ways:
An administrator can take ownership.
Any user or group with administrative rights on the computer where the
object resides can take ownership.
The owner can transfer ownership to another user if the
owner has administrative rights or User
Account Control is turned off.
1.1. Taking Ownership of an Object
To take ownership of an object, you must be logged on as an
Administrator or as a remote user with administrative rights, and
then follow these steps:
Right-click the object and select Properties. Click the
Security tab.
Click Advanced and then click the Owner tab. Click
Edit.
To change the owner to a user or group that is not
listed, click Other Users And Groups. In the Select User,
Computer, Or Group dialog box, type the name of the user or
group, click Check Names, and then click OK.
To change the owner to a user or group that is listed,
in the Change Owner To box, click the new owner.
To change the owner of all subcontainers, select the
Replace Owner On Subcontainers And Objects check box.
1.2. Transferring Ownership
Users with administrative credentials can transfer
ownership of an object by following these
steps:
Right-click the object and select Properties. Click the
Security tab.
Click Advanced and then click the Owner tab. Click
Edit.
If the proposed new owner is in the Change Owner To
list, select the name as shown in Figure 1 and click OK.
If the proposed new owner isn’t listed, click Other
Users Or Groups to open the Select User, Computer Or Group
dialog box.
Locate the new owner and click OK.
Select the new owner in the Change Owner To list and
click OK.
It’s generally best to
use NTFS file permissions instead
of share-level permissions to control access to shared resources
over the network. Using share-level permissions alone gives you
significantly less control over the specific permissions being
granted, and they’re less secure than file system permissions
because they apply only to users connecting over the
network.
However, there are some exceptions to this rule. For
example, you might want to permit all authenticated users to
access a volume in a certain subfolder but allow only a certain
group to access the root directory. In this instance, you can
create two file shares: one at the subfolder level with no
share-level security (Full Control For Everyone), and one at the
root folder level with share-level security to allow only the
specified group access.
Somewhat more useful is the ability to hide file shares by
adding the dollar sign character ($) to the end of the
share name. This notation allows any user to
connect to the share—provided that she knows the share name.
After users connect, they’re still bound by NTFS security
permissions, but this approach can be handy for storing advanced
tools so that an administrator can access them from a user’s
system or user account. File security isn’t really an issue—you
just don’t want users messing around with the files.
