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 (a unique value) that identifies whether the entry is a User or Group.
• Discretionary Access Control List (DACL) – contains the Users and Groups and 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 various electronic lock codes for accessing the file cabinet are Permissions, which control who gains access to the file cabinet and 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.
Whenever a user logs into the system, the system creates a unique Access Token for the user. The Access token contains the information about the 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 items, applicable permissions are given 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 “Shared Folders” across File Servers.
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 permissions. 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 while accessing the object, the resultant permissions that are applicable are:
Effective permissions are the resultant permissions a User or a Group has towards an object. Effective permissions are the combination of Explicit and Inherited Permission entries and the restrictive permissions apply while accessing object. The following shows the essential factors that need to be addressed while considering effective permissions:
• Well known SID
• Local group membership
• Global group membership
Effective permission calculation involves both direct and indirect group membership. The user may be direct member of the group or may become an indirect member of the group by-means of nested groups. For example consider the following scenario
Even though User Gary is not a direct member of the Team Leaders group, by means of nested group Team Leader -> Team Auditing, Gary is somewhat of an “indirect” member of Team Leaders. That is, the permissions of Team Leaders are also applicable for user Gary along with the other permissions.
If the user is a member of more than one group, effective permissions are calculated by taking all the groups’ membership into account and the approximating them.
Effective permissions for groups do not involve group membership. It shows only the explicitly assigned permissions in the ACL.
How Admin Report Kit For Windows Enterprise (ARKWE) address effective permissions reporting?
ARKWE has the provision to report about Share folders and Files NTFS permissions in all dimensions.
It has the ability to report the permissions information about the Users and groups that may or may not present in the Share Folders across File servers and domains.
It has provision to Export/Print reports in various formats (HTML/CSV/MDB/PDF/TIFF/XLS) and also to schedule reports at required Time intervals without any user interaction.
ARKWE addresses the effective permissions reporting pain, by taking all the necessary factors such as Group membership, Well Known Sid etc into account. The following summarizes the advantages of ARKWE over the Windows Effective Permissions Tool.