Adjust Process Rights Action

This topic explains the Adjust Process Rights Action and Unrestricted Tokens in Privilege Manager.

When elevating process rights with Application Control Solution (ACS) on Windows, there are times when the rights given by ACS appear to be insufficient. The process still doesn't work as it does when the user is logged in as Administrator, accepts the UAC box, or the process is run with the right-click Run As Administrator option. Sometimes an error is returned stating insufficient rights to access.

Microsoft with the release of Windows Vista introduced changes to security which included creating two tokens for users when they log in. For more information refer to the Microsoft Documentation on Restricted Tokens.

The following are the Privilege Manager default Adjust Process Rights actions. As with all actions delivered with Privilege Manager, these actions cannot be modified. They can be copied and then customized and as many actions as necessary can be created for a custom implementation:

  • Add Administrative Rights
  • Adjust Process Rights for Resource Monitor
  • Remove Administrative Rights
  • Remove Advanced Privileges Action

Each of those actions has by default related items associated, which need to be considered when customizing an action.

The Suppress UAC Consent Dialog (Legacy) action should only be used with Agent versions 10.4 and older.

Add Administrative Rights

The Add Administrative Rights (Modern) action provides LSA privileges that exactly match what an administrative user should have as of Windows Vista and newer. This new action directly replaces the former Add Administrative Rights action and will be used automatically by existing policies, as it has the same ItemId value.

Delinea recommends using the Add Administrative Rights (Modern) action when creating new elevation policies. The Modern version will reduce program compatibility issues and tighten security by removing some unnecessary privileges that are granted by the legacy version.

The former Add Administrative Rights action has been renamed as Add Administrative Rights (Legacy) in the event that an existing policy needs to use the older Admin elevation methodology. If any existing elevation policy results in a program failing to run properly with the new Add Administrative Rights (Modern) action, the policy can be modified to use Add Administrative Rights (Legacy) while the issue is being reassessed.

Elevated Token

Add Administrative Rights (Modern) addresses token elevation as follows:

  • The unrestricted token is now always used, if it exists, as the source token when creating an elevated token.

  • The following complete set of LSA privileges are included in the elevated token.

    • SeBackupPrivilege (Back up files and directories)

    • SeChangeNotifyPrivilege (Bypass traverse checking)

    • SeCreateGlobalPrivilege (Create global objects)

    • SeCreatePagefilePrivilege (Create a pagefile)

    • SeCreateSymbolicLinkPrivilege (Create symbolic links)

    • SeDebugPrivilege (Debug programs)

    • SeDelegateSessionUserImpersonatePrivilege (Obtain an impersonation token for another user in the same session)

    • SeImpersonatePrivilege (Impersonate a client after authentication)

    • SeIncreaseBasePriorityPrivilege (Increase scheduling priority)

    • SeIncreaseQuotaPrivilege (Adjust memory quotas for a process)

    • SeIncreaseWorkingSetPrivilege (Increase a process working set)

    • SeLoadDriverPrivilege (Load and unload device drivers)

    • SeLockMemoryPrivilege (Lock pages in memory)

    • SeManageVolumePrivilege (Perform volume maintenance tasks)

    • SeProfileSingleProcessPrivilege (Profile single process)

    • SeRemoteShutdownPrivilege (Force shutdown from a remote system)

    • SeRestorePrivilege (Restore files and directories)

    • SeSecurityPrivilege (Manage auditing and security log)

    • SeShutdownPrivilege (Shut down the system)

    • SeSystemEnvironmentPrivilege (Modify firmware environment values)

    • SeSystemProfilePrivilege (Profile system performance)

    • SeSystemtimePrivilege (Change the system time)

    • SeTakeOwnershipPrivilege (Take ownership of files or other objects)

    • SeTimeZonePrivilege (Change the time zone)

    • SeUndockPrivilege (Remove computer from docking station)

Adjust Process Rights Action Settings Explained

The application action elevates or restricts the group SIDs and/or LSA privileges present in a process access token. By default, each process inherits the process access token of its parent.

The four main areas to customize are:

  • Selecting an Action Type, which can either Elevate Rights or Restrict Rights. When the adjustment is a rights restriction, there is an advanced feature that allows you to apply restricted Security Identifiers (SIDs), which further restricts access to securable objects. More about this under the What is a Restricted SID topic.
  • Adding or Removing Windows Privileges, these come pre-populated with a set of default recommendations for each out of the box Action. To learn more about these Windows Privileges visit Microsoft's Documentation about User Rights Assignment.
  • Adding or Removing Build-in Roles, these are built-in local groups that are present on every Windows system, and their SID values can be added to an access token or removed from it.
  • Adding or Removing Well-known Accounts, these are other SID values that exist, but that do not necessarily have a user or group account associated with them. Adding these SID values to an access token or removing them from one may result in the alteration of the process's effective access to resources.
    For example, one single SID is always present, specifying the Mandatory Integrity Level of the process, where non-admin users run at the medium integrity level, while a process running elevated with administrative rights runs at a high integrity level. Refer to Microsoft's Documentation about Mandatory Integrity Control. Other well known group SID values may be added to or removed from the access token via this configuration option.

What is a Restricted SID?

A restricted ID, when present in an access token, may result n more restrictive access checks being performed when accessing directories, files, registry keys, etc., on the local computer.

Permissions on HKey

When a restricted process or thread tries to access a securable object, the system performs two access checks, using the

  • token's enabled SIDs, and
  • the list of restricted SIDs.

Access is granted only if both access checks allow the requested access rights.

When to use Restricted SID

Use a restricted SID to further restrict the applications in the sandbox, which you can use as another method of monitoring. In other words, this is a way to protect yourself against unknown applications if you don't want to implement a blocking policy.

The restricted SID will allow only Read access to the user registry but not to the local machine registry. Also, restricted processes do not have rights to open any network-based resource, such as file servers. As a result, the restricted SID will be able to do very little and apps may not work correctly under this model. Ultimately, apps in the sandbox that have restricted SID applied to them will be severely locked down.

Using Apply Restricted SID

When you select Restrict Rights and then Apply Restricted SID, you add the Restricted SID to the process. When evaluating security for any operation, when there is any Restricted SID specified then not only does the Security Descriptor need to allow access to the user, but explicitly to the Restricted SID.

How to Add Windows (LSA) Privileges

Windows (LSA) privileges are used to allow certain actions to be performed that are not otherwise controlled by the persistently assigned permission on a securable object, such as changing system time, creating a symbolic link on disk, or bypassing the assigned permissions when accessing a securable object. To learn more about these Windows (LSA) privileges, refer to Microsoft's Documentation about User Rights Assignment.

How to Use Well-known Accounts

In this area you will most likely specify either of the following:

  • High Mandatory Level
  • Low Integrity Level
  • Medium Integrity Level
  • Medium Plus Integrity Level
  • Restricted Code Well Known Group
  • System Integrity Level
  • Untrusted Mandatory Level

These integrity levels determine who else can use a specific process. Processes launched by a standard user are by default medium integrity. Any process that gets launched via an elevated policy has a high integrity level assigned by default.

Processes need to have level parity to be able to utilize each other. This means, if a process is running at a high integrity level and wants to inject code into another process, it can do so if that other process is running at high, medium, or low integrity levels, but it cannot inject code into system level processes. Processes that run at low integrity levels can be utilized by pretty much any other process, but they cannot reach out to other processes.

New processes are always created with the minimum of the user integrity and file integrity levels. This guarantees that a new process never executes with higher integrity than the executable file.

Example Scenario

In Privilege Manager we can use these Well-known Accounts to set or remove level integrity independent of or in combination with any assigned elevation or blocking policies.

For example, Adobe applications are generally part of elevation policies in an organization. As mentioned before an elevation policy defaults to a high integrity level. Due to Adobe interoperability requirements within their product suites and with processes launched by standard users, it requires medium integrity levels for all Adobe products.

Any elevation policy pertaining to Adobe products, needs an Adjust Process Rights Action that sets the Well-known Accounts setting to Medium Integrity Level.

Additional Options Explained

Starting with agent version 12.0.1, the Use User's Unrestricted Token is ignored and no longer has any meaning or effect on elevation actions.

Enabling Unrestricted Token Use

Starting with agent version 12.0.1, the Use User's Unrestricted Token is ignored and no longer has any meaning or effect on elevation actions.

Adjust Process Right for Resource Monitor

The following image shows the default action. To customize make a copy to change any of the default items.

Adjust Process Right for Resource Monitor

Related Item - Policy

The following image shows the default related item policy for the above action. To customize make a copy to change any of the default items.

Related Item - Policy