Understanding the Security Tab in Process Explorer
Learn how to inspect Process Explorer security tokens, group and privilege states, UAC virtualization, SIDs, and process-object permissions.
The Security tab in Process Explorer exposes security-token information for the currently selected process. It helps explain why a process can or cannot access a protected file, registry key, service, device, or another process.
A Windows access token is the security context attached to a process. It contains the account identity, group memberships, privileges, and related attributes that Windows uses during authorization checks. The token belongs to the process, so its contents may differ from the groups and capabilities you expect from the interactive user account.
For background on the surrounding properties dialog, see Process Properties. This lesson focuses specifically on the Security tab.
Opening the Security Details
- Select a process in Process Explorer.
- Open the process properties dialog, such as by double-clicking the process.
- Choose the Security tab.
The displayed information applies to the selected process. It does not necessarily describe every process started by the same user, nor does it simply reproduce the interactive account's complete membership. For example, UAC can give a non-elevated application a filtered token even when the account belongs to the Administrators group.
Security Tab Fields at a Glance
| Field or area | Information shown | Why it matters during troubleshooting |
|---|---|---|
| Token groups | Users and groups represented in the process token | Shows which identities can participate in access checks |
| Group attributes | State and flags associated with each token group | Helps distinguish ordinary membership from Deny-Only membership |
| Privileges | Special operating-system capabilities assigned to the token | Shows whether a required privilege exists |
| Privilege state | Whether a listed privilege is enabled or disabled | Separates an available-but-inactive capability from an absent one |
| User SID | The security identifier for the account associated with the process | Confirms the token's account identity without relying on a display name |
| Selected group SID | The SID for the group selected in the groups list | Allows exact identity comparison and troubleshooting |
| File virtualization status | Whether file-system UAC virtualization applies to the process | Can explain why legacy application writes appear in a per-user location |
| Registry virtualization status | Whether registry UAC virtualization applies to the process | Can explain unexpected per-user registry data |
| Permissions button | The security permissions on the process object | Shows which users and groups may perform operations against that process |
Token Groups and Group Attributes
The groups list represents security groups included in the process token. During an access check, Windows compares the token's user SID and group SIDs with allow and deny entries in the target object's access control list (ACL). An individual rule in an ACL is an access control entry (ACE).
Group attributes and flags describe how a group participates in authorization. The exact presentation can vary with the Process Explorer version and Windows configuration, but the important distinction is whether a group is an ordinary usable member or is marked Deny-Only.
Normal Membership and Deny-Only Membership
| Group state | Can satisfy an allow ACE? | Can be considered by a deny ACE? | Typical UAC-related example |
|---|---|---|---|
| Normal or enabled membership | Yes, potentially, when the token and ACL conditions otherwise permit access | Yes | An ordinary group included in an elevated or standard-user token |
| Deny-Only membership | No; it is generally not usable to grant access through a matching allow rule | Yes; a matching deny rule can still refuse access | The Administrators group in a filtered, non-elevated administrator token |
A Deny-Only group remains relevant to deny decisions, but it is prevented from satisfying an allow ACE. Therefore, a resource that grants access only to Administrators may deny a non-elevated administrator process when the Administrators group is Deny-Only.
This is different from ordinary group membership. A normal group can potentially match both allow and deny entries. Deny-Only status changes how the group contributes to the access decision; it does not mean that the group has disappeared from the token.
UAC and Filtered Administrator Tokens
User Account Control (UAC) is the Windows elevation model. When an administrator account starts a program normally, Windows can create a filtered, non-elevated token for that program. The token behaves like a standard-user token for many authorization purposes even though the account is a member of Administrators.
In such a process, administrative groups may appear in the Security tab as Deny-Only. This prevents those groups from satisfying ordinary allow entries. A protected resource with an allow ACE for Administrators can therefore return access denied to the non-elevated process.
An elevated process is started with an elevated token containing administrative capabilities permitted by Windows and the account's policy. Compare the same application in its normal and elevated forms:
- In the normal instance, Administrators may be present as Deny-Only.
- In the elevated instance, the Administrators group can be usable for matching allow entries.
- The two processes can therefore receive different access results even though they were started by the same account.
Use Run as Administrator when an authorized test requires an elevated launch. Elevation is not a universal solution: the target ACL, account policy, integrity level, and required privileges still matter.
Privileges in the Token
A privilege is a special system capability carried by a token. Privileges are separate from ordinary group-based ACL permissions. Examples include capabilities used for debugging certain processes, backing up data, restoring data, or managing security-sensitive resources.
The privileges section lists capabilities assigned to the token and shows their states. The most important diagnostic distinction is between a privilege that is disabled and one that is absent.
| Privilege condition | Present in token? | Potentially usable by the process? | Troubleshooting interpretation |
|---|---|---|---|
| Enabled | Yes | Yes, subject to the operation and Windows policy | The token currently has the privilege active |
| Disabled | Yes | Potentially; suitable software may enable it if Windows permits | The capability was assigned but is not currently active |
| Not present | No | No | The process cannot obtain it merely by changing an enabled/disabled state |
Software can sometimes enable a privilege that is already present but disabled. That requires appropriate program logic and permission from Windows. Software cannot simply activate or obtain a privilege that is not included in its token. If an operation requires a particular privilege, first locate it in the Security tab, then determine whether it is enabled, disabled, or absent.
UAC File and Registry Virtualization
The Security tab reports file and registry virtualization status for the process. UAC virtualization is a compatibility feature for certain eligible legacy desktop applications that were written to expect write access to protected locations.
When virtualization applies, a write that would otherwise target a protected file-system or registry location may be redirected to a per-user virtualized location. The application can appear to succeed while the data is stored somewhere other than the protected path the developer or administrator inspected.
Virtualization does not apply to every process or every operation. It does not replace normal ACL permissions, and it should not be treated as a general permission-elevation mechanism. Check the virtualization indicators when an older application appears unable to save to a protected folder or when its registry changes cannot be found where expected.
Security Identifiers
A SID, or Security Identifier, is the stable identifier Windows uses for users, groups, and other security principals. Names are convenient for people, but authorization uses SIDs.
User SID
The user SID identifies the account associated with the process token. It represents the account under which the process was started, subject to the token and logon context shown by the process.
Selected Group SID
When you select a group in the token groups list, the selected group SID display identifies that exact group. Use it to verify that similarly named groups are actually the same security principal.
SIDs are useful when an account has been renamed, a name cannot be resolved, multiple domains contain similar names, or you are comparing security information from different systems. A name change does not turn a different SID into the original security principal.
Viewing Process Permissions
The Permissions button opens a permissions view for the selected process object. A process object is the Windows kernel object representing the running process. Its ACL controls which users and groups may request particular process access rights.
Process-object rights can include querying information, terminating the process, reading or modifying process memory, creating threads, opening handles, and other process operations. The exact right required depends on the operation and Windows version.
Do not confuse this ACL with:
- The filesystem permissions on the executable file.
- The token groups and privileges displayed elsewhere on the Security tab.
- The permissions on a file, registry key, service, or other resource used by the process.
The process ACL describes who may interact with the running process object. Compare its entries with the user SID and effective group states in the requesting process token when diagnosing an inability to inspect, terminate, debug, or otherwise open a target process.
How Windows Combines These Concepts
| Concept | Controlled by | Example question answered |
|---|---|---|
| Group membership | User and group SIDs plus token group attributes | Can this token match an allow or deny ACE for a group? |
| Privilege | Special rights assigned to and enabled in the token | Does the process have a system capability required for this operation? |
| Process-object ACL permission | ACE entries on the target process object | May this caller request termination, memory access, or process information? |
| UAC elevation state | Whether the process has a filtered or elevated token | Are administrative groups usable for allow checks in this process? |
| Virtualization status | Windows compatibility rules and application eligibility | Could a legacy write have been redirected to a per-user location? |
Broadly, Windows evaluates the caller's token against the target object's security descriptor. Token SIDs, group states, ACEs, and required privileges all contribute, but they solve different authorization problems.
- An enabled or ordinary group can potentially satisfy a matching allow ACE.
- A Deny-Only group does not satisfy a matching allow ACE, although a matching deny ACE can still matter.
- A deny ACE can override an otherwise applicable allow result according to Windows access-check rules.
- A privilege is not interchangeable with an ACL permission. Having a group allow entry does not automatically supply a required privilege, and having a privilege does not automatically grant every object access right.
Security Investigation Workflow
- Inspect the application while it is running normally.
- Record the user SID, relevant groups, group attributes, privilege states, and virtualization indicators.
- Run an authorized comparison with the application elevated, then inspect the second process.
- Check whether expected administrative groups are Deny-Only in the non-elevated process.
- For a required privilege, distinguish enabled, disabled, and absent states.
- Review file and registry virtualization when a legacy application's writes do not appear in the expected protected paths.
- Use the Permissions button when the problem involves opening, inspecting, terminating, debugging, or modifying another process.
- Compare the target process ACL with the requesting process's effective token and determine whether a privilege is also required.
Practical Troubleshooting Examples
Administrator Account Receives Access Denied
Inspect the application's Security tab while it is launched normally. If the Administrators group is marked Deny-Only and the target resource grants access through an Administrators allow ACE, the filtered token explains why the application is denied. Test an appropriately elevated launch when authorized, then compare the group state in the elevated process.
Required Privilege Does Not Work
Locate the privilege in the list. If it is disabled, the capability is present and suitable software may be able to enable it. If it is absent, changing the state is not enough; the process token was not assigned that privilege. Investigate the account, launch context, and local or domain policy.
Legacy Application Writes to an Unexpected Location
Check file and registry virtualization status. If virtualization is active, investigate per-user redirected locations rather than looking only at the protected system path. Also check whether the application is elevated and whether it follows current Windows permission practices.
Diagnostic Tool Cannot Access Another Process
Open the target process properties and select Permissions. Identify whether the requesting user or group has the required process-object right. Compare that result with the caller's token groups, Deny-Only states, elevation state, and privileges. The failure may come from the target ACL, a filtered token, or a missing required privilege.
Key Takeaways
- The Security tab describes the selected process's token, not merely the interactive user's account.
- Token groups and their attributes affect whether group ACEs can grant or deny access.
- Deny-Only groups cannot normally satisfy allow ACEs but can remain relevant to deny ACEs.
- UAC explains why a non-elevated administrator process can behave differently from an elevated one.
- A disabled privilege is present but inactive; an absent privilege is not available to the process.
- Virtualization can redirect eligible legacy writes, but it does not replace normal permissions.
- SIDs provide stable identities when names are ambiguous or unavailable.
- The Permissions button examines the process object's ACL, which is distinct from executable-file permissions and token contents.
For related Process Explorer navigation, see Process Actions, View Integrity Levels, and the Process Explorer Course.