VMware ESXi and vSphere Cluster Management
Understanding the Security Tab in Process Explorer
Learn how to inspect Windows process tokens, SIDs, groups, Deny-Only status, privileges, UAC virtualization, and process-object permissions in Process Explorer.
Process Explorer's Security tab helps explain why a process can or cannot perform an operation. It shows the security context associated primarily with the process's Windows access token, along with a way to inspect permissions on the process object itself.
This is not merely a list of permissions on the executable file. A process can have different authorization behavior from another process started by the same user because the two processes may have different tokens, elevation states, privileges, or object permissions.
Opening the Security tab
- Select a process in Process Explorer.
- Open the process's Properties dialog.
- Choose the Security tab.
- Select a group or privilege entry to inspect its details.
- Choose Permissions when you need to inspect permissions on the selected process object.
The Security tab is useful during permission troubleshooting because it brings together identity, group membership, privileges, UAC-related state, virtualization indicators, and process-object security information.
Windows access tokens
An access token is the Windows authorization context associated with a process or thread. It carries identity and authorization data used during access checks. The information relevant to the Security tab commonly includes:
- The user SID identifying the account associated with the process.
- Group SIDs representing memberships carried by the token.
- Attributes on groups, such as enabled or Deny-Only status.
- Privileges assigned to the token and their current states.
- Integrity and UAC-related information that helps describe the process's elevation context.
- File and registry virtualization status where applicable.
Windows uses this token when evaluating whether the process may access a securable object or perform a privileged operation. Two processes launched by the same account can behave differently if one uses a filtered, non-elevated token and the other uses an elevated token.
Security Tab Fields and What They Represent
| Field or section | Information displayed | Why it matters during analysis |
|---|---|---|
| Process user and user SID | The account name and durable Security Identifier associated with the process. | Identifies whose token is being examined. |
| Token group list | Group memberships carried by the token. | Shows which group identities may participate in access checks. |
| Selected group SID | The SID for the currently selected group entry. | Allows exact comparison with security descriptors and access-control entries. |
| Group attributes including Deny-Only | Flags that affect how a group participates in authorization. | Reveals whether a visible membership can grant access or only contribute to a denial. |
| Privilege list and privilege state | Token privileges marked enabled or disabled. | Distinguishes an assigned privilege that may be activated from one that is absent. |
| File virtualization status | Whether qualifying legacy file writes may be redirected. | Helps explain why a program appears to write successfully without changing the protected system location. |
| Registry virtualization status | Whether qualifying legacy registry writes may be redirected. | Helps locate settings that were written to a per-user virtualized location. |
| Permissions button/process ACL view | The security descriptor and ACL applied to the process object. | Shows which principals may request particular process access rights. |
User identity and SIDs
The process user identifies the account under which the process started. A Security Identifier (SID) is the durable Windows identifier for a security principal such as a user, group, computer, or special identity. An account name is a human-readable label; a SID is the identifier used by authorization mechanisms.
SIDs appear in access-control entries and in token membership because Windows evaluates identities using these identifiers. Names can be changed or can be ambiguous across domains, while a SID is intended to remain the stable identity reference for that security principal.
When a group is selected, the selected group SID field describes that particular group entry. It is not a second user identity and does not represent all groups at once. Use it to match the selected token group with an SID shown in an object's ACL or security descriptor.
Token groups and group attributes
The groups list contains group membership entries included in the process token. These can include local groups, domain groups, built-in groups, logon-related groups, and special identity groups. The exact entries depend on the account, computer, domain context, logon method, and UAC token filtering.
An Access Control List (ACL) is a collection of Access Control Entries (ACEs) attached to a securable object. An ACE can allow or deny rights to a user or group. During an access check, Windows compares the caller's token with the object's security descriptor and the requested rights. Group membership can therefore help satisfy an allow ACE or match a deny ACE.
Group entries have attributes or flags that change how they participate in this evaluation. A group name by itself is not enough to determine effective access.
Deny-Only groups
A Deny-Only group remains in the token for deny checks but cannot be used to satisfy an allow permission. For example, if an object's ACL contains an allow ACE for the Administrators group, a token in which Administrators is Deny-Only does not receive that allow through the group.
If an applicable deny ACE names that Deny-Only group, however, the group can still contribute to the denial. Explicit deny entries are comparatively uncommon, but they are significant when present. In ordinary allow-access terms, a Deny-Only group is similar to a group that cannot be used for granting access.
UAC and administrator group filtering
User Account Control (UAC) is Windows' elevation model. For an administrator account, UAC commonly provides a split token: a filtered token for ordinary, non-elevated applications and a full administrative token for elevated applications.
A standard, non-elevated process started by an administrator may show Administrators as Deny-Only. The account is still associated with that administrative group, but the filtered token cannot use the membership to obtain ordinary allow access. An elevated copy of the application can instead have a token in which the administrative membership is usable.
This explains why simply launching an application from an administrator account does not necessarily give it administrator access. When diagnosing access denied, compare the failing non-elevated process with the same application launched elevated. Inspect whether Administrators or another relevant group is Deny-Only, and then check the target object's ACL and any required privileges.
Token privileges
A privilege is a token-based system right that authorizes certain sensitive operations. Privileges are separate from group membership and separate from permissions granted by an object's ACL. The Security tab lists privileges assigned to the process token and shows their current state.
Representative privileges include:
- SeDebugPrivilege, associated with certain forms of access to other processes.
- SeBackupPrivilege, associated with bypass-style backup operations when used according to Windows rules.
- SeRestorePrivilege, associated with certain restore operations.
- SeShutdownPrivilege, associated with system shutdown or restart operations.
- SeTakeOwnershipPrivilege, associated with taking ownership of selected objects.
These examples are not universally assigned or enabled. A privilege is not the same as an administrator group membership, and possessing it does not mean every operation will succeed. The target object, requested operation, Windows protections, and the way the application uses the privilege still matter.
Disabled, enabled, and absent privileges
An enabled privilege is currently active for relevant operations. A disabled privilege is assigned to the token but is not currently active. Software can request activation of an assigned disabled privilege through the appropriate Windows token APIs when Windows permits it and the application is written to do so.
A privilege that is absent from the token cannot be enabled by the process. Therefore, seeing a privilege listed as disabled is not evidence that it is unavailable. During troubleshooting, distinguish these cases:
| Token item state | Present in token | Can grant ordinary allow access immediately | Can contribute to denial | Can potentially be activated by the process |
|---|---|---|---|---|
| Normal enabled group | Yes | Yes, when an applicable allow ACE grants access | Yes, if a matching deny ACE applies | Not applicable as a privilege |
| Deny-Only group | Yes | No | Yes, if a matching deny ACE applies | Not applicable as a privilege |
| Privilege enabled | Yes | Not through an ordinary group allow ACE | Not as a group membership | Already active |
| Privilege disabled | Yes | Not through an ordinary group allow ACE | Not as a group membership | Potentially, through application code and token APIs |
| Privilege absent | No | Not applicable | Not applicable as an assigned privilege | No |
UAC file and registry virtualization
UAC virtualization is a compatibility feature for certain legacy, non-elevated desktop applications. When such an application tries to write to a protected file or registry location, Windows may redirect a qualifying write to a per-user location instead of allowing the application to modify the machine-wide target.
This can make a legacy program appear to save settings successfully even though another user or an elevated tool does not see those settings in the expected protected location. The Security tab's file and registry virtualization indicators help identify this possibility.
Virtualization is not a general permission bypass. It does not apply to every process, path, application, or access type. Elevated processes and modern applications commonly do not rely on it; modern software should use an appropriate user-writable application-data location or request elevation when it genuinely needs to change a protected system-wide location.
Permissions and the process object
The Permissions control opens an ACL and security-descriptor inspection view for the selected process object. A process object is the Windows kernel object representing a running process. It has its own security rules, separate from the permissions on the executable file that started the process.
Process-object permissions control whether a caller may request rights such as querying process information, terminating the process, reading memory, writing memory, or changing the process security. The exact result depends on several factors:
- The caller's access token, including user and usable group identities.
- The process object's security descriptor and ACL.
- The specific process access rights requested.
- Relevant privileges, if the operation supports or requires them.
- Protected-process or other Windows process-protection restrictions.
Being able to see a process in Process Explorer does not imply that the caller can terminate it or inspect its memory. Visibility and control are different permissions.
Authorization concepts that are commonly confused
| Concept | Controls | Typical source | Example question answered |
|---|---|---|---|
| Group membership | Identity memberships carried by a token. | Token group entries and their attributes. | Which group identities can participate in this access check? |
| Object ACL/ACE | Allow and deny rules for a particular object. | Object security descriptor. | Does this object grant the requested right to this principal? |
| Token privilege | Specific sensitive system operations. | Privilege assignments in the token. | Does this token have the relevant system right, and is it active? |
| UAC elevation state | Whether the process uses a filtered or full administrative context. | UAC token construction and process launch. | Is administrative membership usable by this process? |
| UAC virtualization | Compatibility redirection for qualifying legacy writes. | Windows compatibility behavior. | Was the apparent write redirected to a per-user location? |
| Process object permissions | Rights to operate on a running process. | Process object's security descriptor and access check. | Can this caller query, terminate, or read this process? |
A structured troubleshooting method
- Identify the process user. Confirm the account name and user SID shown for the process.
- Inspect relevant groups. Look for the group that should provide access and check its attributes, especially Deny-Only status.
- Compare UAC states. Compare the failing process with a working elevated process when appropriate.
- Review privileges. Determine whether the relevant privilege is enabled, assigned but disabled, or absent. Do not treat a disabled privilege as absent.
- Review virtualization. For legacy file or registry behavior, determine whether writes may be redirected to a per-user location.
- Inspect process-object permissions. Use Permissions to compare the requested process right with the ACL and applicable principals.
- Consider additional protections. Check whether the requested operation, target type, privilege requirements, or protected-process restrictions change the result.
Do not draw a conclusion from a single group name or privilege. Windows authorization combines the caller's token, group attributes, ACL evaluation, requested access, privilege state, and object-specific protections.
Practical diagnostic examples
An administrator account receives access denied
Confirm whether the process is elevated. If Administrators is marked Deny-Only, the process is likely using a UAC-filtered token. An allow ACE for Administrators will not grant ordinary access through that membership. Review the target ACL and determine whether elevation or a specific privilege is required.
A listed privilege does not make an operation succeed
Check whether the privilege is disabled. The application may need to enable an assigned privilege through Windows token APIs before performing the operation. If the privilege is absent, the application cannot activate it merely because the account is expected to have that right.
A legacy program saves settings in the wrong place
Check the file and registry virtualization indicators. A qualifying non-elevated application may have written to a per-user virtualized location instead of the protected machine-wide path. Compare behavior when elevated and inspect the intended application-data design.
A technician can see a process but cannot terminate it or read memory
Inspect the process-object ACL and compare it with the requested right. The caller may lack the required process access, elevation, or privilege. Some targets remain restricted even for administrators because of additional process-protection rules.
Exam-relevant points
- The Security tab primarily exposes information from the process access token, not just executable-file permissions.
- A SID is the Windows authorization identifier; an account name is only its readable label.
- A Deny-Only group can match deny ACEs but cannot satisfy allow ACEs.
- UAC can place Administrators in Deny-Only status in a non-elevated administrator process.
- A disabled privilege is assigned but inactive; an absent privilege cannot be enabled.
- Privileges and ACL permissions are different authorization mechanisms.
- UAC virtualization redirects some legacy writes; it is not a universal way to bypass permissions.
- Permissions on a process object are different from permissions on its executable file.
- Process visibility does not imply the right to terminate, read, or write that process.
For related process inspection material, see Process Explorer security inspection.