Just-In-Time (JIT) Privilege Elevation Task
The Just-In-Time (JIT) Privilege Elevation Task is driven by PAM and may require additional licensing. Contact your Imprivata Customer Support for more information.
The Just-In-Time (JIT) Privilege Elevation Task enables administrators to temporary elevate the privileges of the account behind an eligible secret only when an internal user needs them. The feature limits how long privileged access exists by requiring approval before elevation and by removing the elevation when one of the following happens:
-
The secret is checked in
-
The session using the secret ends
-
The time approved finishes
The JIT Privilege Elevation Task does not run as a scheduled task. Instead, it marks selected secrets as eligible for privilege elevation. Users request approval from the connection workflow, launch a service with elevated privileges after approval, and the system removes the elevated privilege when the checked-out secret is checked in.
This document contains the requirements and process to configure, approve, launch, and remove Just-In-Time privilege elevation.
Requirements
To use the JIT Privilege Elevation Task, ensure that your environment meets the following requirements:
-
Feature Availability: The JIT Privilege Elevation feature must be enabled in your server.
-
Secret Checkout: Secret Checkout must be configured and enabled on each target secret you want to configure.
-
Supported Platform: Only Windows targets are currently supported. The account behind a target secret can be a local Windows account or an Active Directory account. Elevation and de-elevation always run on the host associated with the connection request.
-
To properly configure a JIT task, the application associated to the secret must have a WinRM service configured; otherwise, the task fails.
-
-
Internal Users: Only internal users can request privilege elevation. Vendor Reps do not see the privilege elevation option.
-
Eligible Secrets: A secret must be assigned to a JIT Privilege Elevation Task before users can request elevated privileges for it.
Any given secret can belong to only one JIT Privilege Elevation Task. -
Credential Provider and Application Configuration:
-
The credential provider configured in the target secret must be an admin user or have necessary permissions to modify groups of other users.
-
The application associated to the target secret must have a host with the WinRM Secure service configured.
-
-
Permissions: Depending on the role, Internal users must have the following minimum permissions:
-
Administrator: Creates and manages a JIT Task
-
LOGIN_TO_WEB_UI -
VIEW_APPLICATION -
VIEW_TASK -
CREATE_TASK -
EDIT_TASK -
VIEW_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS -
CREATE_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS -
EDIT_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS
-
-
Approver: Approves or denies a JIT request (elevation request)
-
LOGIN_TO_WEB_UI -
APPROVE_PRIVILEGE_ELEVATION_REQUEST -
APPROVE_SECRET_ACCESS_REQUEST -
VIEW_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS -
UNLOCK_SECRET
-
-
Requester: Internal User that requests elevation
-
LOGIN_TO_WEB_UI -
VIEW_APPLICATION -
CONNECT -
VIEW_SECRETS_AND_CREDENTIAL_PROVIDER_CONFIGS
-
-
For the current implementation, the JIT Privilege Elevation Task uses the On Secret Check-In privilege removal policy. Alternate privilege removal policies are not available in the task creation flow.
How To Use the Feature as a System Admin
The JIT Privilege Elevation feature functions in three areas of the User Interface:
-
The Vault tab, where administrators create and manage the target secrets and the task execution credential.
-
The Tasks tab, where administrators create the JIT Privilege Elevation Task and assign eligible secrets.
-
The Requests tab, where administrators approve or deny privileged elevation requests.
Internal Users only interact with the feature during a Connection where they can raise a request and launch elevated access.
Before you create a JIT Privilege Elevation Task, create the credentials that the task uses.
The task requires a task execution credential with admin privileges, an application with a WinRM Secure host, and one or more target secrets.
-
Open the Vault tab.
-
Create or verify the credential provider that the task uses to elevate and remove privileges.
-
Create or verify the target secrets that users launch with elevated privileges.
-
Ensure that the target secrets are not part of a credential pool.
-
Ensure that Secret Checkout is enabled for the target secrets.
For Active Directory configurations, the task execution credential must be able to authenticate to the LDAP or LDAPS host service and apply the privilege change to the selected target secrets.
To create a new JIT Privilege Elevation Task, navigate to the Tasks menu. Use the following steps to create the task:
-
Open the Tasks sub-menu.
-
Select Add New Task.
-
Select Just-In-Time Privilege Elevation.
-
Select the target system type.
-
Click Next.
-
Complete the form considering the details in the following table:
| Field in Form | Description | Required |
|---|---|---|
| Task Name | Unique name for the task. | Yes |
| System Type | Windows (only system supported currently.) | Yes |
| Credential Provider | Password-based credential provider that authenticates to the target host and applies the privilege change. | Yes |
| Target Secrets | Secrets that users can request to launch with elevated privileges. Each secret must use a single credential provider (not a pool). | Yes |
| Privilege Removal | Removes elevation when the secret is checked in. | System-defined |
When the target account is a domain (Active Directory) account, the task execution credential must be able to authenticate to the domain and apply the privilege change on the host associated with the connection request. For local Windows accounts, the task execution credential must have administrative rights on that host.
System Administrators and users with the APPROVE_PRIVILEGE_ELEVATION_REQUEST permission can approve or deny privilege elevation requests. To approve or deny a request:
-
Open the Requests tab.
-
Locate the privilege elevation request.
-
Review the requester, target secret, request message, and requested access window.
-
Approve or deny the request.
-
Optionally, add a message for the requester.
-
Save.
Once approved, the requester can launch the service with elevated privileges until whichever comes first: the approval window expires, the checkout window expires, or the secret is checked in.
If the approver denies the request, the pending request is removed and the requester must submit a new request to continue.
How To Use the Feature as an Internal User
The JIT Privilege Elevation lets Internal Users to request privilege for a secret before connecting to a service that requires elevated secret privileges. The following sections contain the process to request Privilege Elevation as an Internal User.
When Internal Users initiate a Connection, they can request privilege elevation when they select a credential for the service they run.
Internal Users request Privilege Elevation when they try to connect to a service that requires a privileged secret. Usually, the request for Privilege Elevation is as follows:
-
An Internal User opens the application or host service that contains the eligible credential.
-
They select the credential.
-
They review the available privilege elevation action:
-
Request Privilege Elevation: The secret requires approval and no request exists.
-
Pending Approval: The request has been submitted and is awaiting approval.
-
Launch with Elevated Privileges: The request is approved, or privilege elevation is not required for the credential.
-
When an Internal User selects Request Privilege Elevation, the system sends the request to approvers according to the internal-user privilege elevation workflow.
After the privilege elevation request is approved, Internal Users can launch the service with elevated privileges:
-
Return to the application page and initiate a connection.
-
Select the approved credential.
-
Click Launch with Elevated Privileges.
-
Confirm the checkout and launch.
- The checkout duration cannot exceed the approved access window. During checkout, other users cannot use the same secret with elevated privileges.
- A secret cannot be checked out by another user while it has elevated privileges. The secret list and secret view pages show the secret as unavailable while privileges are elevated.
Remove Elevated Privileges
The system removes elevated privileges when the checked-out secret is checked in. Check-in can occur when one of the following events occurs:
-
The user closes the service.
-
The session times out.
-
The user manually checks in the secret.
-
The checkout window expires.
-
The approval window expires.
If de-elevation fails, the system retries the removal task to prevent a credential from remaining elevated.
Privilege Elevation Request Status
The connection workflow displays the privilege elevation action based on the credential status.
| Status | Displayed Action |
|---|---|
NOT_REQUIRED
|
Launch with Elevated Privileges |
NOT_REQUESTED
|
Request Privilege Elevation |
PENDING
|
Pending Approval |
APPROVED
|
Launch with Elevated Privileges |