- AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023
- Read NTFS permissions: View read, write, and deny access information with AccessEnum - Wed, Mar 29 2023
- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
Effective NTFS permissions refer to the actual permissions that a user or group has to a specific object, taking into account all of the explicit and inherited permissions that apply to that user or group. It is a combination of permissions granted through group memberships, individual assignments, and denials. For example, the folder C:\Users\Default User is a junction (link) that exists for compatibility purposes. Its permissions grant Full control to the Administrators group and deny List folder permissions to the Everyone group.
My user on the server is a member of the Administrators group as well as a member of the Everyone group. The effective permissions are a combination of the permissions configured for these two groups. Because a denial takes precedence over the allow privilege, the effective permissions for my user deny access to list the folder contents, even though the user is a member of the Administrators group. That's why the user receives an Access is denied error when trying to view the folder contents.
Note that, when talking about the file system, the effective NTFS permissions shown in Windows (both File Explorer and AccessChk) might not always be the actual permissions on the object, as these depend on how the object is accessed. This is especially the case for shares, where the actual permissions are a combination of NTFS and share permissions. For example, a user might have Write access to the folder when accessing it via a local path (e.g., C:\myfolder), but only Read permissions when accessing it via a share name (e.g., \\myserver\myfolder). Share permissions can also be checked by AccessChk, as described later in the post.
AccessChk is a command-line utility that reports effective permissions. It can run without administrative permissions in most cases, assuming that the account running AccessChk can read the security descriptors of the objects. AccessChk uses the same APIs as Windows in the Advanced Security Settings dialog box (shown in the screenshot above). You can use AccessChk to view permissions on files, folders, registry keys, processes, services, shares, semaphores, and other objects defined in the Windows Object Manager. To get a list of all options, type accesschk.exe at the command line.
This is the basic syntax of AccessChk:
accesschk.exe [options] [user-or-group] objectname
The objectname parameter stands for the object (for example, a file) to be analyzed. If the object is a folder or registry key, AccessChk will show permissions for each object in this folder or key instead of the object itself. For example, accesschk.exe d:\temp\myfolder will show permissions for the two files located in myfolder. To show the permissions on the folder itself, use the -d option. Add the -s option to perform a recursive search through all subdirectories. You can also use ? and * as character substitutes and wildcards when querying a filesystem.
AccessChk uses R for Read permissions and RW for Read-Write permissions. If the user has no access to the object, nothing is shown.
Query different object types
As already mentioned, AccessChk can query different object types, such as shares and services. If no options are added to the command, AccessChk will consider the input a filesystem object (file or folder). To view permissions on a registry key, use the -k option. The root key can be specified by a short or full name, as shown in the screenshot. The same applies to folder objects. AccessChk shows permissions for all subkeys present in the key rather than for the key itself. Add the -d option to view the permissions for the key itself.
Share permissions can be queried by adding the -h option. For the purposes of this post, I created a shared folder named myfolder$ and set Read permissions for the Everyone group. As you can see in the output below, AccessChk also shows RW permissions for the BUILTIN\Administrators group, even though the group does not actually have the Write privilege. If I try to write to the share from the network, I will get an access denied error message. I'm not sure if this is a bug or shown on purpose, as the BUILTIN\Administrators group is an owner of the share object. This can be seen in the object's security descriptor using the -l option.
Process permissions can be queried by adding the -p option. Add the -t option to view permissions for all the process's threads. When querying process information without administrative permissions, you will receive access denied for all processes running in a higher security context than your account. Run AccessChk with elevated permissions to get more details.
Another interesting feature of AccessChk is its ability to search security privileges. For example, SeBackupPrivilege grants the user system-wide privilege to backup files and folders. This requires administrative privileges. Use the -a option to search security privileges. In the screenshot below, you can see a list of privileges held by the Administrators group.
Searching for effective permissions
The most powerful feature of AccessChk is its ability to discover whether a particular user or group has access to an object. Use the -s option to search recursively through the directory, registry keys, and so on. With no additional options, AccessChk will display all permissions on such an object. Add the -r option to list only Read permissions, or the -w option to list only Write permissions. Finally, the -n option lists objects that grant no access to the specified account.
In my case, I want to view permissions for the user LAB\leos on the C:\Apps folder. The first example shows all the permissions the user has, while the second command shows only items with Read-Write permissions.
You can also search for permissions on objects such as the registry, services, and global objects. Here are a few examples:
- Search the Program Files folder for objects on which users have Write permissions:
accesschk.exe -s -w Users "C:\Program Files"
- Search the HKLM registry key for objects on which LAB\leos has Write permissions:
accesschk.exe -s -k -w LAB\leos HKLM
- Search all services on which the Server Operators group has Write permissions (Write permissions for services means permission to control the service; that is, to start or stop the service):
accesschk.exe -c -w "Server Operators" *
To search for permissions, the user running AccessChk must have Read permissions on the object. Therefore, some searches require AccessChk to run with elevated privileges. The search for service permissions is a good example of such a case.
AccessChk allows several different output types. Add -v for verbose output, which shows specific permissions under each account, as they are named in Windows SDK. To view the security descriptor rather than the effective permissions, use the -l (lowercase L) option. To display the security descriptor in SDDL format, use the -L option. See the screenshot below for examples of these options.
To filter specific users or groups from the output, use the -f option. The command below removes the Administrators group from the output.
Subscribe to 4sysops newsletter!
.\accesschk.exe -v -d -f Administrators D:\temp\myfolder\
In this post, you have learned how to use AccessChk, a tool in the Sysinternals suite, to search for permissions on different object types, such as files or folders, registry keys, and services. Using AccessChk together with AccessEnum can give you a good overview of the permission configuration of your systems.
Want to write for 4sysops? We are looking for new authors.