Assigning File-Level Permissions on an NTFS Partition

Assigning File-Level Permissions on an NTFS Partition

If you are using the standard FAT file system native to DOS, Windows, and Windows 95, your Windows NT security structure will be complete after you assign share-level permissions to your files. In Exercise 8.4, however, assume that the partition on which the share is located is formatted with NTFS, Windows NT’s native file system. In this case, you can assign additional rights within the share on a per-directory and even per-file basis. The strength of NTFS security is two-fold:

NTFS security gives the administrator a wider range of flexibility in assigning rights to files and directories.
NTFS security provides security even at the local level, something that a FAT partition does not support. Interactive users are unaffected by share-level security options but still are limited by NTFS file-level security.

In the Public folder shared in Exercise 8.3, you see that two share-level permissions exist for this directory:

Everyone: Read
Administrators: Full Control

In Exercise 8.4, you assign a new permission to this directory, this time through NTFS security. The permission to be assigned will be:

Everyone: Change

As you always should before altering your permissions structure, consider how this change will affect the permissions of the Everyone and Administrators groups. Remember that Read permissions allow Read (R) and Execute (X) permissions, while Change grants these permissions plus Write (W) and Delete (D). Likewise, Full control offers these permissions plus Take Ownership (O) and Change Permissions (P). Share-level rights and file-level rights are both cumulative within themselves. For instance, an administrator on a Windows NT network will be a member of both Administrators and Everyone—and possibly a number of other groups as well.

In your Public share, the user would gain RX from the Everyone group and RXWDOP from the Administrator group. The user then would have RXWDOP over the share. On the other hand, if you include the NTFS permissions for Everyone, the user has RXWDOP over the share and only RXWD at the file level. Under NTFS only permissions granted at both the share level and the file level will be applied, and the administrative user will have only Change (RXWD) permissions over the share.

The exception to the principle of additive privilege is the No Access permission, which immediately blocks all other rights. Because of this, the No Access option should be used sparingly and very carefully. Numerous No Access permissions on the network usually point to a poorly implemented security structure. If you don’t want users to access a resource, it is sufficient simply to not give them permission—explicitly banning the users access generally is overkill. Also, never implement No Access for the Everyone group—this group includes you, as well as all other administrators and users, none of whom will be able to get to the resource until the No Access is removed, even if they belong to other groups that do have sufficient permissions.

Generally, you will try to use a dedicated server such as NT or NetWare to provide resource access on your network. In some situations, though, you may need to implement a workgroup sharing model or use a Windows 95 machine as a server.