|
|
|
|
|
NTFS SECURITY In order to alter any permissions on a file or directory, you must either have
The following table summarizes each of the rights associated with the file permissions defined above.
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.
New files or subdirectories inherit the parent directories permission settings. The following table defines the permissions associated with directories.
R Display the directory’s data, attributes, owner and 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
 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.
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.
The following criteria are applied to permissions
Consider what happens now, when the permissions assigned to the group Web Admins is altered.
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.
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.
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).
Salam Saif Said AL-Riyami Sultanate
of Oman
|
|
|
NTFS File Permissions
