NTFS SECURITY

This section discusses Windows NT NTFS file and directory security. Windows NT explorer can be
used to set and modify permissions on shares, files and directories.

In order to alter any permissions on a file or directory, you must either have

• full control access to the resource

• change permission rights
• ownership of the resource

NTFS File Permissions

These permissions define how a file can be used and accessed. The FIVE predefined file access
permissions are:

• No Access
• Read
• Change
• Full Control
• Special Access

The following table summarizes each of the rights associated with the file permissions defined above.

Permission R X W D P O
No Access
Read Yes Yes
Change Yes Yes Yes
Full Control Yes Yes Yes Yes Yes Yes
Special Access (any combination) Yes Yes Yes Yes Yes Yes
R Display the file’s data, attributes, owner and permissions
X Execute the file
W Write to the file or change it's attributes
D Delete the file
P Change the file’s permissions
O Take ownership of the file

When an NTFS partition is created, Windows NT Server assigns Full Control rights to the group
Everyone. This means all users (including network users) have unrestricted access to any data stored
on that partition. Network Administrators might alter these settings to provide additional security.
Please note that users would be required to either have access to the local computer (and if it's a
domain controller, they do not have logon rights by default), or a share has been created which gives
the users access permissions.

NTFS Directory Permissions

Directories have essentially the same permissions as files. Setting permissions on a directory alters the
existing permissions on that directory, and all the files in that directory. Subdirectories are not affected
(this is a selectable option).
New files or subdirectories inherit the parent directories permission settings. The following table
defines the permissions associated with directories.

Permission R X W D P O
No Access
List Yes Yes
Read Yes Yes
Add Yes Yes
Add and Read Yes Yes Yes
Change Yes Yes Yes Yes
Full Control Yes Yes Yes Yes Yes Yes
Special Access (any combination) Yes Yes Yes Yes Yes Yes
R Display the directory’s data,attributes,owner,& permissions
X Execute files in the directory
W Create new files in the directory, change it's attributes
D Delete files in the directory
P Change the directory’s permissions
O Take ownership of the directory

Directory and File Auditing

Windows NT provides auditing of file and directory access on NTFS partitions. When auditing is
enabled, an event detailing the type of access is written to the Security log, which can be viewed using
event viewer. Both successful and unsuccessful attempts can be audited.

It should be noted that the event logs can fill up quickly, and performance of the server can be affected
if excessive auditing is done.
User Manager for Domains is used to enable auditing. The following dialog box of User Manager
shows the Directory Auditing options that are available.

The following table shows which actions can be audited for Directories.

Change
Audit Type Read Write Execute Delete Take Ownership
Permissions
Display Filenames Yes
Display Attributes Yes Yes
Change Attributes Yes
Create Subdirectories and Files Yes
Change to the Directory’s
Yes
subdirectories
Display owner and permissions Yes Yes Yes
Delete Directory Yes
Change Directory permissions Yes
Change Directory Ownership Yes

If auditing is already enabled on a directory, any new files or subdirectories created in that directory
are also subject to auditing.

The following table shows which actions can be audited for Files.

Audit Type Read Write Execute Delete Change Permissions Take Ownership
Display Filename Data Yes
Display Attributes Yes Yes
Display File Owner and
Yes Yes Yes
attributes
Change File Data Yes
Change Attributes Yes
Run the file Yes
Delete the file Yes
Change File permissions Yes
Change File Ownership Yes

File Copying and File Moving

When a file is copied, it inherit's the file permissions of the receiving directory’s file permissions.
When a file is moved, it keeps the existing permissions and owner settings.

NTFS User And Group Permissions for Directories and Files

Permissions under Windows NT can be assigned to individual users and groups. It then becomes
important to understand how conflicting sets of permissions interact in providing an overall set of
permission rights.

The following criteria are applied to permissions

• user and group permissions are cumulative
• any permission specifying No Access results in a cumulative permission of No Access
• if the permissions are not explicitly specified, the result is denial of access

Consider the following table, where the user Jon [who belongs to the group Web Admins] has rights to
a resource that the group has also.
Jon Web Admins Effective Rights
Change No Access No Access

Consider what happens now, when the permissions assigned to the group Web Admins is altered.

Jon Web Admins Effective Rights

 Read Write Read and Write

Local Permissions And Shared Permissions

Where permissions are assigned at the NTFS file or directory level, and that directory is shared across
the network as a share point, then remote access to the resource is a generated by the permissions on
the share level, and the NTFS permissions.

The permissions are based on the least permission. They are not cumulative, as in the previous
example. Remember that when an NTFS partition is created, the group EVERYONE has full control
rights. Any files or directories then created inherit these permissions unless explicitly changed.

When assigning a new share, the default setting in Windows NT server is to allocate Full Control
rights to the group Everyone. This would match those default rights which exist on the NTFS file
system.

The administrator can remove the permissions on the share, and restrict the permissions through the
share level, without having to worry about changing those on the NTFS file system. As long as the
users do not have logon rights to the computer where the resource is located [access is only across the
network], the resource is secured.

Consider the following table, where the user Jon has the following rights.

NTFS Level Share Level Effective Rights

Read Write Read

Taking Ownership of Files

Under Windows NT, the person who creates the directory of file becomes the owner of that file or
directory. The owner can grant others [but directly assign ownership rights] the right to take ownership
of the files or directories that they created and own.

An administrator can take ownership of a resource at any time, and if they do so, they become the new
owner. The owner of the resource has permission rights to change the permissions on that resource.

When an administrator takes ownership of a resource like a file or directory, all the existing
permissions for that resource are reset.

Windows NT Resource Security Model

Examples of resources in Windows NT include a file, printer or directory. Each resource is protected
by the use of permissions rights. A resource, together with the actions which can be performed on that
resource (like read, write) is called an object.

Examples of Windows NT objects are directories, printers, processes, threads, ports, network shares
and files. Access control lists (ACL) are associated with each Windows NT object, as well as the list
of users and groups permitted to use that object. When a user is granted access to an object, an Access
Control Entry is created and added to the ACL for that object. In the ACL, entries that deny access are
always listed first, followed by those ACE’s which permit access.
When a user performs a logon to Windows NT, they are assigned an access token, which includes
information such as a user ID (Security Identifier SID), the user’s name and their group membership’s.
Whilst the user is logged on, this access token is used to identify the user. Whenever a user accesses an
object, the access token is used to authenticate the request. The SID is unique for each user.

If you assign permissions to a specific user, the SID of that user is assigned into the ACL for the
object. If the user is then deleted, and created using the same name as previously used, the new user
does not have permissions to the object, because the SID will not be the same. The administrator will
have to reassign all the group memberships and resource access rights as those assigned to the
previous user, even though the usernames are the same.

When an object is first accessed by a user, they receive a handle to the object, and builds a list of
granted access rights. Each subsequent access to that object is verified through the local handle, rather
than to the object itself. This speeds up access. The handle is destroyed when the user logs off the
system or disconnects from the object.

If the administrator changes the permission rights on an object that a user is currently accessing,
those rights do not take immediate effect because of the local handle being used by the user. The new
rights will only take effect when the user releases the object, then tries to reuse it [in the case of a file,
closing the file would release it).