Run as an Administrator

This topic describes the Privilege Manager Right-Click Run As Thycotic Administrator, or Request Run As Administrator (RRAA), functionality and cover use cases.

Due to a Microsoft limitation on Windows 11, you need to select Show more options from the initial right click menu menu access the Request to Run as Administrator right-click option.

Also refer to the Adjust Process Rights Action topic for further details and best practices.

RRAA Use Cases

Removing all accounts from the local Administrator group creates several “Gotcha” situations:

• The UAC prompt to Elevate becomes an un-answerable request when there are no account credentials to satisfy UAC with
• Trying to use the built-in right-click Run as administrator we also have no credentials that can be entered.

RRAA becomes a very useful support tool and can provide those “special” users unfettered access to administrator functionality they demand.

RRAA is a tool that satisfies administrator removal issues when: you are under the gun of a deadline to remove an administrator, in a very fast paced environment and understaffed to keep up with policy creation, it can also provide the support staff with the super powers they need.

Background of RRAA

This function is built into the Privilege Manager agent. There are different versions of the agent and new versions sometimes have additional RRAA functionality, like the recent addition of .MSI file types to the right-click option. This feature is for Windows Operating Systems only. It is toggled on or off via any of your Windows Computer Groups | Agent Configuration and under Self-Elevation set the switch to on.

Testing RRAA Policies

This section explains how to create a RRAA Elevation policy for developers. As described here, this feature will be added to all endpoints with the Application Control agent. It will require authentication from a developer to proceed, so other users won't be able to use the feature, but it will be present.

There are two steps to configuring the Right-Click Run As Thycotic Administrator feature.

One is the global configuration setting to enable the feature. Enabling this adds the Request Run as Thycotic Administrator option to all endpoints with the Application Control agent installed.

After enabling the global feature, policies are created that assign actions to this feature, typically based on specific use cases (such as the developer use case detailed below).

If testing this feature in an environment with agents deployed to production machines, consider first creating a policy that targets all endpoints and all users that includes a custom Application Denied Message action or Application Warning Message action explaining that this feature isn't currently enabled, but may be used in the future by help desk or other users. Then, create a separate policy that has Resource Targets only for your test machines and a Policy Priority to occur earlier in processing. That way, your tests will be separate from the global actions of this feature.

Create a RRAA Elevation Policy for Developers

After the Right-Click Run As Thycotic Administrator feature is enabled, an Elevation policy that handles the Elevation workflow will need to be created. The policy in this topic uses the default Resource Targets for all Windows computers with the Privilege Manager agent installed. Using computer groups, smaller Resource Targets can be used and many custom options can be created to address many use cases in the environment, each having a customized menu mext and resource specific targeting.

In the following example, a RRAA Elevation policy will be created for the Developers group. First, a custom Message action will be created to use on the policy.

Advanced Message Actions

There are several Advanced Message Actions that can be displayed to end users. Advanced Message Actions can either require feedback in a justification and/or group member authentication, require approval from within Privilege Manager when the process runs, or require no input.

The most common Message actions used with RRAA Policies are the Advanced Feedback Message actions, including:

• Group Member Authenticated Message Action: This action will display a customized message to the user and requires authentication by a member of the specified group if the end user is not a member.

• Authenticated Justification Message Action: This action will display an authentication prompt to the user before continuing to the process controlled by a policy.

• Justify Application Elevation Action: This action will display a justification prompt to the user before continuing to the process controlled by a policy.

Each of these actions provide fields that can adjust the communication presented to the user.

As the following steps demonstrate, the Message actions have several radio buttons in the Settings area to shape what they do and how they interact with the user.

These actions are really just different radio button selections of two basic actions. One action with a justification and the other action without justification.

Custom Group Member Authentication Action for Developers

For this example, we will be using the Group Member Authenticated Message action with the default radio button configuration. The action will require credentials from a user who is a member of a specific AD group. This action will not require justification.

To begin, find an existing Message action to duplicate.

1. Navigate to Admin | Actions.

2. Search for Group Member Authenticated Message Action.

3. Click Duplicate.

4. In the Duplicate modal, enter the name LAB Developer Group Member Authentication Action.

5. Click Create.

   

6. Under Settings and By a member of group, click Administrators. As a resource select the AD group for your developers, in this example Developers. (Use Search to search and identify a resource.) Click Save Changes.

   

Custom RRAA Elevation Policy for Developers

To build the custom RRAA Elevation policy for developers, copy an existing RRAA Elevation policy. A default policy is included with Privilege Manager.

1. Navigate to your Windows computer group.

2. Search for User Requested Elevation Justification Policy (Sample), to locate the default policy.

   

3. Click Duplicate. In the Duplicate modal, enter the name LAB RRAA Policy for Developers. Click Create.

   

   Under Conditions the policy includes the Application Target of User Requested Run As Administrator. This corresponds to the Right-Click Run As Thycotic Administrator option on the endpoint.

   Under Actions the policy includes by default:

   • Add Administrative Rights
   • Justify Application Elevation Action
   • Restrict File Dialogs

4. Next to these actions, click Edit.

   • Remove the Justify Application Elevation Action and Restrict File Dialogs default actions.
   • Search for and add the LAB Developer Group Member Authentication Action.
   • Click Update.

   

5. Click Save Changes.

With the LAB RRAA Policy for Developers, logged-on members of the Developers group can seamlessly get administrators rights when using the Right-Click Request Run As Thycotic Administrator.

Activate this policy, when you are ready to begin using it on endpoints.

Multiple RRAA Policies in the Same Policy Stack

Another common use case for the Right-Click Run As Thycotic Administrator feature is a RRAA Elevation Policy for Helpdesk. To do this, follow the same steps for the RRAA Elevation policy for Developers, outlined above, using Helpdesk AD groups and naming conventions for the action and policy during creation.

It's possible to have multiple RRAA policies that work for different groups in the same policy stack. To get this working, User Context Filters will be built in Privilege Manager that match the targeted AD groups.

Once the basic policies needed are made, and the User Context filters are created, use the Add Inclusion Filter and Add Exclusion Filter sections under the policy's Conditions to logically get all policies working in your policy stack.

In the Developers & Helpdesk example:

• If the current user on an endpoint is in the Developers AD group and initiates the Right-Click Run As Thycotic Administrator feature, the LAB Developer Group Member Authentication action will execute, requiring the credentials of a member of the Developer AD group.

• A separate policy is created that excludes the Developers User Context filter (therefore, applies to all other users) and includes a custom Helpdesk action that requires credentials from a member of a Helpdesk AD group and a justification/reason.

• If the current user on an endpoint is not a member of the Developers AD group and initiates the Right-Click Run As Thycotic Administrator feature, the custom Helpdesk action executes.

• The Helpdesk's RRAA policy would not work when the computer user is in the Developers group, but the Helpdesk policy would work on all other computers regardless of who the user is.

This example gives Helpdesk users a workflow to enter their credentials on any computer to request elevation for supporting all computers not having a separate RRAA Policy of their own (in the above example, only the Developers have a separate RRAA Policy).

Other examples can be added for other use cases. By utilizing user AD groups, this can be managed in AD with corresponding User Context filters created in Privilege Manager and assigned to policies.

If more than two RRAA policies are required like adding with and without Justifications, sorting the Inclusion/Exclusion logic would be required. The Global RRAA has all other RRAA group filters in the Exclusions, the user specific RRAA get only their Group filter put in the Inclusions.

If the Inclusion/Exclusion logic is managed correctly, the RRAA policies could use the same policy Priority, but policy priorities can also help with the logic. Assume the RRAA Elevation Policy for Developers has a policy Priority of 14, and the RRAA Elevation Policy for Helpdesk has a policy Priority of 15. In this example, the RRAA Elevation Policy for Developers has priority over the RRAA Elevation policy for Helpdesk.

Also, the policy priority of the RRAA Elevation policies matters in relation to the other policies in the policy stack. Other policies with policy priorities to occur before the RRAA Elevation policies (such as Deny policies) would happen before the RRAA Elevation. This is why the single, default User Requested Elevation Justification policy has a policy Priority of 15, to occur early in the policy stack.

Enabling the right-rlick Run As Thycotic Administrator feature via Computer Groups | Agent Configuration will add the right-click Run As Thycotic Administrator feature to all machines with the Application Control agent installed.

If not using the RRAA Elevation policy for Helpdesk example for all other RRAA use cases not defined, consider a Global RRAA policy that adds a Notification Message action to inform these users that they do not have permissions to run the right-click Run As Thycotic Administrator feature.

User Context Filter for Developers

A User Context filter can be created for the Developers AD group. That filter can then be used as an Inclusion filter on the RRAA Elevation Policy for Developers.

In the use case of a separate RRAA Elevation Policy for Helpdesk, the User Context filter for the Developers AD group will also be used as an Exclusion filter on the RRAA Elevation Policy for Helpdesk.

Create a Custom User Context Filter for Developers

1. Navigate to Admin | Filters and click Create Filter.

2. From the Platform drop-down, select Windows Computers Filters.

3. From the Type drop-down, select User Context Filter and enter the name LAB Developers Group Member Filter. Click Create.

   

4. Under Settings next to Domain User Groups, click Add. In the Select Resources modal, click Search and add the Developers AD group. Click Select.

   

5. Set the Require accounts to be enabled switch to Yes.

6. Click Save Changes.

   

Include User Context Filter for Developers to RRAA Elevation Policies for Developers

Adding LAB Developers Group Member Filter to the RRAA Elevation Policy for Developers will result in the Actions on this policy only executing if a member of the Developers AD group initiates the right-click Run As Thycotic Administrator.

1. Navigate to your LAB RRAA Policy for Developers policy.

2. Under Conditions next to Inclusions, click Edit.

3. Search for and add the LAB Developers Group Member Filter, you might have to refresh the available filter list.

4. Click Update.

5. Click Save Changes.

   

Exclude User Context Filter for Developers to RRAA Elevation Policies for Helpdesk

If an RRAA Elevation Policy for Helpdesk was created, as described in Multiple RRAA Policies in the Same Policy Stack, the LAB Developers Group Member filter can be added to the RRAA Elevation Policy for Helpdesk as an Exclusion filter to ensure that there is not a conflict between which action to run when Developers initiate the right-click Run As Thycotic Administrator feature.

To create an RRAA Elevation Policy for Helpdesk, follow the same steps for the RRAA Elevation Policy for Developers, as described in this document, but use the Helpdesk AD group(s) and naming conventions for the action and policy.

A RRAA Elevation policy for Helpdesk may require or desire different types of Message actions than used on the RRAA Elevation Policy for Developers. Consider using the Authenticated Justification Message action for the RRAA Elevation Policy for Helpdesk.

To add the LAB Developers Group Member filter as an Exclusion filter:

1. Navigate to your LAB RRAA Policy for Helpdesk policy.
2. Under Conditions next to Exclusions, click Edit.
3. Search for and add the LAB Developers Group Member Filter, you might have to refresh the available filter list. Click Update.
4. Click Save Changes.

The Helpdesk policy is now finished. When ready to use, click Enable on the General tab and click Save.