Access Requests

Granting access to the resources via the request is a basis of the Just in Time feature. A user requests for access via the User Access Gateway, and authorized administrators vote for the request’s approval or rejection on Admin Panel.

In order to set the voting process for access to your resources, follow the procedure:

1. Select Management > Safes.

2. Select the safe from the list, or create a new one.

3. Check the Just in Time option. Provide a number of the voters that will be deciding about each request to the Safe resources.

To require approval only outside the user’s daily access policy hours, also check the Skip approval during Daily Access Policy hours sub-option - see Time-Based Access Requests.

Note

• Users with Admin role and users added as the Granted Users to the Safe are allowed to be the voters.

• A user, who sent an access request isn’t allowed to vote for access on their own request. Therefore, their own requests aren’t visible for them.

• Having more than one voter sets a request to be accepted by more than 1 authorized person. If one of the voters votes for rejection, the system automatically rejects the request.

4. Go to the Permissions and Notifications tab, select the particular user and click the Manage notifications button.

5. Select the Access request sent type of notification and click Add notification to close the window.

Note

Notifications are set per node, according to the settings in the Notifications tab. In case of the Access request sent type, notifications are sent from the node, on which the request was created. More on this subject is at the Notifications page.

6. Click Save.

All the requests are available in the Requests tab.

Note

The reason a user gives when sending a request can be constrained to a defined set of fields instead of free-form text, so that it is easier to process automatically. Refer to JiT Reason Formats.

Time-Based Access Requests

By default, a safe with the Just in Time option enabled requires an approved access request for every connection, and the daily access policy of the user’s assignment to the safe is enforced on top of that requirement: outside the policy hours the connection is denied, even when an access request has been approved. Selecting the Skip approval during Daily Access Policy hours sub-option makes the approval requirement time-based instead: inside the configured time windows the user connects directly, and outside them an approved access request is required.

Safe configuration	Inside daily access policy hours	Outside daily access policy hours
Just in Time off	Direct connection	Access denied by the time policy
Just in Time on, sub-option off	Access request required	Access denied by the time policy, even when a request is approved
Just in Time on, sub-option on	Direct connection	Access request required

In order to configure time-based access requests, follow the procedure:

1. Select Management > Safes.

2. Select the safe from the list, or create a new one.

3. Check the Just in Time option and provide a number of the voters (at least 1).

4. Check the Skip approval during Daily Access Policy hours sub-option.

5. Go to the USERS tab, select the users and click Manage Options.

6. In the DAILY ACCESS POLICY tab, enable the time policy and define the access windows.

7. Click Save.

Note

• The sub-option is available only while the Just in Time option is enabled. Disabling Just in Time resets it.

• The daily access policy is taken from the user-safe assignment, or from the group-safe assignment when the user gets access through a group. A direct user-safe assignment overrides group-based rules, as described in the Access Resolution and Prioritization section.

Caution

• A session started inside a time window is terminated when that window closes, unless an approved access request covers the remaining time.

• In the User Access Gateway, an account on such a safe is not shown as Blocked outside the time windows. Instead, the user can send an access request for it. Requests and their history stay available inside the time windows too, even though no approval is required there.

Awaiting Requests

The Awaiting tab shows a detailed list of the requests that are waiting for a decision of the currently logged in user. Two types of requests are available for the user who sends an access request: immediate and scheduled.

Immediate requests can be set from now up to the next 24 hours.

When a user sends an immediate request, its access time starts when the request is accepted. Then, the user has 24 hours to start their session. When the user starts the session, the system counts the session time, which the user had requested, and terminates connection when the requested session time is over. If the user does not use the access and does not connect for 24 hours after access is granted, the access becomes expired.

For the scheduled type of requests, the user chooses a time period in the future, including exact time and date.

Sending response to the request

In order to vote for approval or rejection of the request, follow the steps:

1. Select Requests tab.

2. In the Awaiting tab select the request to be processed and click the Response button .

3. In the modal click the Accept or the Reject button.

Note

The Response reason field is required to activate the rejecting option.

Note

• Users who sent the request via the User Access Gateway and have their e-mail address configured on the Admin Panel, receive notifications when their request was accepted or rejected.

• If a user is trying to connect to a server (for example, based on the SSH protocol) via the native client option, but hasn’t sent an access request, a respective message about authentication error is recorded into the Event logs: Unable to authenticate user: safe requires acceptance.

Active Requests

The Active tab shows a list of two types of the requests: 1) requests that were accepted, and their sessions are currently ongoing, and 2) requests that are waiting for the part of the voters. The Votes column of the requests list shows a number of voters that the particular request needs to be processed. Hover on its value to see the details of who had voted.

Given vote for accepted and active requests can be revoked, for example, for preventing a possible misuse. This option is useful when the user finished their work earlier than expected, but their request is still valid.

Archived Requests

History of the processed requests is available under the Archive tab.

The Votes column of the requests list shows a number of voters that the particular request needed to be processed. Hover on its value to see the details of who voted.

The Just in Time feature also works when there are Fudo instances connected in the cluster. Votes and requests are replicated on nodes in the cluster.

Note

If the admin voted on more than one machine in the cluster and his decisions were contradictory, it will be treated as a single rejecting vote and the accepting vote will be revoked.

Related topics:

• Creating a new safe