| Home | My Account | Directories |
Permissions
NTFS Permissions play a vital role in securing Operating system objects (Folders, Files, and Services etc). NTFS permissions works on the basis of what is called an Access Control Model. The Access control model contains of the following:
- Access token
- Security Descriptors
Access token: Contains information about the logged on user and their privileges.
Security descriptors: Every object in a system has a set of regulatory information attached to it, which controls information about gaining access to the object and its attributes. These sets of regulatory information are termed as Security Descriptors. Security descriptors are created along with creation of an object and act as the backbone of the NTFS security.
A Security descriptor consists of the following components:
Security identifier (SID) - a unique identifier that identifies whether the entry is a User or Group.
- DACL (Discretionary Access Control List) contains the Users and Groups, Permissions (Allow or Deny) on the object. Each entry in DACL is called an Access Control Entry (ACE)
- SACL (System Access Control List) contains the auditing details of attempts made to access the object.
Let us review the above concepts with a simple example. Imagine a “Folder” as a physical File folder cabinet with an electronic lock. The electronic lock codes which you put on the file cabinet are Permissions, which control who gains access to the file cabinet and it also controls what they can do inside the file cabinet. Such information is maintained in DACL as ACE entries. You can also put an additional Security near the File cabinet, to maintain an information log (audit) about who are accessing the file cabinet (SACL). SID is like an electronic key code that unlocks the file cabinet.
NTFS working
Whenever a user makes a login to the System, The System creates a unique Access Token for the user. The Access token contains the information like Security Identifier (SID) and the permissions held by the user. Whenever the user tries to access any object, a copy of the Access token is given to the thread executing the process. The object for which the user is requesting access contains the Security Descriptor. The object on receiving request compares User SID with the entries present in the Security Descriptors DACL entries. If a match is found while comparing the entries, the applicable permissions are granted to the user.
Let us review the working of NTFS permissions with a simple example.
Consider a user named "Tom" requesting Access to object as logon user.
On receiving the Access request DACL checks the ACE entry for “Tom”. In this scenario “Tom” is given the permissions to “Read, Write, Delete” on the object.
Note: This Scenario is also applicable for users accessing “Share Folders” across File Servers.
Types of Permissions
Permissions are of two types
- Explicit permissions
- Inherited permissions
Explicit permissions: Permissions that are listed in ACL directly.
Inherited Permissions - Permissions that are granted by means of group membership. The user may not be listed in the ACL directly, as we know that ACL contains permissions for users and groups, but via group membership, users may be getting some permission. For example consider an object with the following ACE entries:
Note: User "Gary" is a member of "Technical Leaders" group.
For the above Scenario, User "Gary" is getting the permission "Take Ownership" because of his membership in "Technical Leaders", in addition to his existing permissions. These extra permissions are termed as Inherited Permissions. So the object’s resultant permissions are as follows:
Effective Permissions
Effective permissions are the resultant permissions a User or a Group has towards an object (as explained above). Effective permissions are the combination of Explicit and Inherited Permission entries and in the resultant permissions set, the most restrictive permissions will apply while accessing object.