Windows Sysinternals Administrator's Reference: Security Utilities
- 6/15/2011
AccessChk
AccessChk is a console utility that reports effective permissions on securable objects, account rights for a user or group, or token details for a process. It can search folder or registry hierarchies for objects with read or write permissions granted (or not granted) to a user or group, or it can display the raw access control list for securable objects.
What Are “Effective Permissions”?
Effective permissions are permissions that a user or group has on an object, taking into account group memberships, as well as permissions that might be specifically denied. For example, consider the C:\Documents and Settings folder on a Windows 7 computer, which is actually a junction that exists for application compatibility purposes. It grants full control to Administrators and to System, and Read permissions to Everyone. However, it also specifically denies List Folder permissions to Everyone. If MYDOMAIN\Abby is a member of Administrators, Abby’s effective permissions include all permissions except for List Folder; if MYDOMAIN\Abby is a regular user, and thus an implicit member of Everyone, Abby’s permissions include just the Read permissions except List Folder.
Windows includes the Effective Permissions Tool in the Advanced Security Settings dialog box that is displayed by clicking the Advanced button in the permissions editor for some object types. The Effective Permissions Tool calculates and displays the effective permissions for a specified user or group on the selected object. AccessChk uses the same APIs as Windows and can perform the same calculations, but for many more object types and in a scriptable utility. AccessChk can report permissions for files, folders, registry keys, processes, and any object type defined in the Windows object manager namespace, such as directories, sections and semaphores.
Note that the “effective permissions” determination in Windows is only an approximation of the actual permissions that a logged-on user would have. Actual permissions might be different because permissions can be granted or denied based on how a user logs on (for example, interactively or as a service); logon types are not included in the effective permissions calculation. Share permissions, and local group memberships and privileges are not taken into account when calculating permissions on remote objects. In addition, there can be anomalies with the inclusion or exclusion of built-in local groups (See Knowledge Base article 323309 at http://support.microsoft.com/kb/323309.) In particular, I recently came across an undocumented bug involving calculation of permissions for the Administrators group. And finally, effective permissions can depend on the ability of the user performing the calculations to read information about the target user from Active Directory. (See Knowledge Base article 331951 at http://support.microsoft.com/kb/331951.)
Using AccessChk
The basic syntax of AccessChk is
accesschk [options] [user-or-group] objectname
The objectname parameter is the securable object to analyze. If the object is a container, such as a file system folder or a registry key, AccessChk will report on each object in that container instead of on the object itself. If you specify the optional user-or-group parameter, AccessChk will report the effective permissions for that user or group; otherwise it will show the effective access for all accounts referenced in the object’s access control list (ACL).
By default, the objectname parameter is interpreted as a file system object, and can include ? and * wildcards. If the object is a folder, AccessChk reports the effective permission for all files and subfolders within that folder. If the object is a file, AccessChk reports its effective permissions. For example, here are the effective permissions for c:\windows\explorer.exe on a Windows 7 computer:
c:\windows\explorer.exe RW NT SERVICE\TrustedInstaller R BUILTIN\Administrators R NT AUTHORITY\SYSTEM R BUILTIN\Users
For each object reported, AccessChk summarizes permissions for each user and group referenced in the ACL, displaying R if the account has any Read permissions, W if the account has any Write permissions, and nothing if it has neither.
Named pipes are considered file system objects; use the “\pipe\” prefix to specify a named pipe path, or just “\pipe\” to specify the container in which all named pipes are defined: accesschk \pipe\ reports effective permissions for all named pipes on the computer; accesschk \pipe\srvsvc reports effective permissions for the srvsvc pipe, if it exists. Note that wildcard searches such as \pipe\s* are not supported because of limitations in Windows’ support for named-pipe directory listings.
Volumes are also considered file system objects. Use the syntax \\.\X: to specify a local volume, replacing X with the drive letter. For example, accesschk \\.\C: reports the permissions on the C volume. Note that permissions on a volume are not the same as permissions on its root directory. Volume permissions determine who can perform volume maintenance tasks using the disk utilities described in Chapter 12, for example.
The options let you specify different object types, which permission types are of interest, whether to recurse container hierarchies, how much detail to report, and whether to report effective permissions or the object’s ACL. Options are summarized in Table 8-2, and then described in greater detail.
Table 8-2 AccessChk Command-Line Options
Parameter |
Description |
Object Type |
|
–d |
Object name represents a container; reports permissions on that object rather than on its contents |
–k |
Object name represents a registry key |
–c |
Object name represents a Windows service |
–p |
Object name is the PID or (partial) name of a process |
–f |
Used with –p, shows full process token information for the specified process |
–o |
Object name represents an object in the Windows object manager namespace |
–t |
Used with –o, –t type specifies the object type Used with –p, reports permissions for the process’ threads |
–a |
Object name represents an account right |
Searching for Access Rights |
|
–s |
Recurses container hierarchy |
–n |
Shows only objects that grant no access (usually used with user-or-group) |
–w |
Shows only objects that grant Write access |
–r |
Shows only objects that grant Read access |
–e |
Shows only objects that have explicitly set integrity levels (Windows Vista and newer) |
Output |
|
–l |
Shows ACL rather than effective permissions |
–u |
Suppresses errors |
–v |
Verbose |
–q |
Quiet (suppresses the banner) |
Object Type
As mentioned, if the named object is a container—such as a file system folder, a registry key, or an object manager directory—AccessChk reports on the objects within that container rather than on the container itself. To have AccessChk report on the container object, add the –d option to the command line. For example, accesschk c:\windows reports effective permissions for every file and subfolder in the Windows folder; accesschk -d c:\windows reports the permissions on the Windows folder. Similarly, accesschk . reports permissions on everything in the current folder, while accesschk -d . reports permissions on the current folder only. As a final example, accesschk * reports permissions on all objects in the current folder, while accesschk -d * reports permissions only on subfolder objects in the current folder.
To inspect permissions on a registry key, add –k to the command line. You can specify the root key with short or full names (for example, HKLM or HKEY_LOCAL_MACHINE), and you can follow the root key with a colon (:), as Windows PowerShell does. (Wildcard characters are not supported.) All of the following equivalent commands report the permissions for the subkeys of HKLM\Software\Microsoft:
accesschk -k hklm\software\microsoft accesschk -k hklm:\software\microsoft accesschk -k hkey_local_machine\software\microsoft
Add –d to report permissions just for HKLM\Software\Microsoft but not for its subkeys.
To report the permissions for a Windows service, add –c to the command line. Specify * as the object name to show all services, or scmanager to check the permissions of the Service Control Manager. (Partial name or wildcard matches are not supported.) For example, accesschk –c lanmanserver reports permissions for the Server service on a Windows 7 computer, and this is its output:
lanmanserver RW NT AUTHORITY\SYSTEM RW BUILTIN\Administrators R NT AUTHORITY\INTERACTIVE R NT AUTHORITY\SERVICE
This command reports the permissions specifically granted by each service to the “Authenticated Users” group:
accesschk -c "authenticated users" *
In the context of services, W can refer to permissions such as Start, Stop, Pause/Continue, and Change Configuration, while R includes permissions such as Query Configuration and Query Status.
To view permissions on processes, add –p to the command line. The object name can be either a process ID (PID) or a process name, such as “explorer.” AccessChk will match partial names: accesschk –p exp will report permissions for processes with names beginning with “exp”, including all instances of Explorer. Specify * as the object name to show permissions for all processes. Note that administrative rights are required to view the permissions of processes running as another user or with elevated rights. The following output is what you can expect to see for an elevated instance of Cmd.exe on a Windows 7 computer, using accesschk –p 3048:
[3048] cmd.exe RW BUILTIN\Administrators RW NT AUTHORITY\SYSTEM
Combine –p with –t to view permissions for all the threads of the specified process. (Note that the t option must come after p in the command line.) Looking at the same elevated instance of Cmd.exe, accesschk –pt 3048 reports:
[3048] cmd.exe RW BUILTIN\Administrators RW NT AUTHORITY\SYSTEM [3048:7148] Thread RW BUILTIN\Administrators RW NT AUTHORITY\SYSTEM R Win7-x86-VM\S-1-5-5-0-248063-Abby
The process has a single thread with ID 7148, with permissions similar to that of the containing process.
Combine –p with –f to view full details of the process token. For each process listed, AccessChk will show the permissions on the process token, and then show the token user, groups, group flags, and privileges.
You can view permissions on objects in the object manager namespace—such as events, semaphores, sections and directories—with the –o command line switch. To limit output to a specific object type, add –t and the object type. For example, the following command reports effective permissions for all objects in the \BaseNamedObjects directory:
accesschk -o \BaseNamedObjects
The following command reports effective permissions only for Section objects in the \BaseNamedObjects directory:
accesschk -o -t section \BaseNamedObjects
If no object name is provided, the root of the namespace directory is assumed. WinObj, described in Chapter 14, “System Information Utilities,” provides a graphical view of the object manager namespace.
Although they aren’t securable objects per se, privileges and account rights can be reported by AccessChk with the –a option. Privileges grant an account a systemwide capability not associated with a specific object, such as SeBackupPrivilege, which allows the account to bypass access control to read an object. Account rights determine who can or cannot log on to a system and how. For example, SeRemoteInteractiveLogonRight must be granted to an account in order to log on via Remote Desktop. Privileges are listed in access tokens, while account rights are not.
I’ll demonstrate usage of the –a option with examples. Note that AccessChk requires administrative rights to use the option. Use * as the object name to list all privileges and account rights and the accounts to which they are assigned:
accesschk -a *
An account name followed by * lists all the privileges and account rights assigned to that account. For example, the following command displays those assigned to the Power Users group (it is interesting to compare the results of this from a Windows XP system and a Windows 7 system):
accesschk -a "power users" *
Finally, specify the name of a privilege or account right to list all the accounts that have it. (Again, you can use accesschk –a * to list all privileges and account rights.) The following command lists all the accounts that are granted SeDebugPrivilege:
accesschk -a sedebugprivilege
Searching for Access Rights
One of AccessChk’s most powerful features is its ability to search for objects that grant access to particular users or groups. For example, you can use AccessChk to verify whether anything in the Program Files folder hierarchy can be modified by Users, or whether any services grant Everyone any Write permissions.
The –s option instructs AccessChk to search recursively through container hierarchies, such as folders, registry keys, or object namespace directories. The –n option lists objects that grant no access to the specified account. The –r option lists objects that grant Read permissions, and –w lists objects that grant Write permissions. Finally, on Windows Vista and newer, –e shows objects that have an explicitly set integrity label, rather than the implicit default of Medium integrity and No-Write-Up.
Let’s consider some examples:
Search the Windows folder hierarchy for objects that can be modified by Users:
accesschk -ws Users %windir%
Search for global objects that can be modified by Everyone:
accesschk -wo everyone \basenamedobjects
Search for registry keys under HKEY_CURRENT_USER that have an explicit integrity label:
accesschk -kse hkcu
Search for services that grant Authenticated Users any Write permissions:
accesschk -cw "Authenticated Users" *
List all named pipes that grant anyone Write permissions:
accesschk -w \pipe\*
List all object manager objects under the \sessions directory that do not grant any access to Administrators:
accesschk -nos Administrators \sessions
This last example points out another powerful feature of AccessChk. Clearly, to view the permissions of an object, you must be granted the Read Permissions permission for that object. And just as clearly, there are many objects throughout the system that do not grant any access to regular users; for example, each user’s profile contents are hidden from other nonadministrative users. To report on these objects, AccessChk must be running with elevated/administrative rights. Yet there are some objects that do not grant any access to Administrators but only to System. So that it can report on these objects when an administrative token is insufficient, AccessChk duplicates a System token from the Smss.exe process and impersonates it to retry the access attempt. Without that feature, the previous example would not work.
Output Options
Instead of reporting just R or W to indicate permissions, you can view verbose permissions by adding –v to the AccessChk command line. Beneath each account name, AccessChk lists the specific permissions using the symbolic names from the Windows SDK. These are the effective permissions reported with the –v option for %SystemDrive%\ on a Windows 7 system:
C: Medium Mandatory Level (Default) [No-Write-Up]
RW BUILTIN\Administrators
FILE_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
FILE_ALL_ACCESS
R BUILTIN\Users
FILE_LIST_DIRECTORY
FILE_READ_ATTRIBUTES
FILE_READ_EA
FILE_TRAVERSE
SYNCHRONIZE
READ_CONTROL
W NT AUTHORITY\Authenticated Users
FILE_ADD_SUBDIRECTORY
The verbose output shows that Administrators and System have full control, Users have Read access, and Authenticated Users additionally have the ability to create subfolders within that folder.
Instead of showing effective permissions, you can display the object’s actual access control list (ACL) with the –l (lower case L) option. Here is the ACL for the “C:\Documents and Settings” junction on Windows 7 that was described at the beginning of the AccessChk section. Each access control entry (ACE) is listed in order, identifying a user or group, whether access is allowed or denied, and which permissions are allowed or denied. If present, ACE flags are shown in square brackets, indicating inheritance settings. If [INHERITED_ACE] is not present, the ACE is an explicit ACE.
C:\Documents and Settings
Medium Mandatory Level (Default) [No-Write-Up]
[0] Everyone
ACCESS_DENIED_ACE_TYPE
FILE_LIST_DIRECTORY
[1] Everyone
ACCESS_ALLOWED_ACE_TYPE
FILE_LIST_DIRECTORY
FILE_READ_ATTRIBUTES
FILE_READ_EA
FILE_TRAVERSE
SYNCHRONIZE
READ_CONTROL
[2] NT AUTHORITY\SYSTEM
ACCESS_ALLOWED_ACE_TYPE
FILE_ALL_ACCESS
[3] BUILTIN\Administrators
ACCESS_ALLOWED_ACE_TYPE
FILE_ALL_ACCESS
AccessChk reports any errors that occur when enumerating objects or retrieving security information. Add –u to the command line to suppress these error messages. Objects that trigger errors will then go unreported. Finally, to omit the AccessChk banner text, add –q to the command line.