The Linux GUI Client User Interface

About Admin By Request

In this topic

About Admin By Request

Connecting via a Proxy Server

Using Run As Admin

Requesting Administrator Access

Setting-up a Break Glass Account

About Admin By Request

Once installed, Admin By Request is running in the background for as long as the endpoint is powered-on. Selecting the app from the menu bar launches the user interface, which comprises a simple window with two buttons down the left-hand side:

The default panel is About Admin By Request, which is accessed via the top button. It shows the current workstation edition, license details, website link, and copyright information.

Click the About button to get back to this panel if viewing one of the other panels.

Other Panels  (accessed via their respective buttons/links).

• About – the default panel (see description above).

  Components

  Clicking link Components on the About panel displays information about the individual modules that make up Admin By Request.

  The modularized architecture means components can be updated as required via Linux distribution package management with minimal impact on other parts of the system.

  The following screens show current component versions. Refer to these should the need arise during troubleshooting.

  1. Admin By Request for Linux:

     The main module for logic and functionality carried out by the application. This module also supplies the version number of the Linux client that is installed.

     

  2. GUI:

     User interface front-end, supporting both Gnome and KDE desktop environments.

     

  3. Service:

     The local service for the Admin By Request Linux client.

     

  4. PAM plugin:

     Privileged Access Management plugin, supporting the main module.

     

  5. Polkit plugin:

     A plugin for integrating application functionality into the Polkit security subsystem.

     

  6. CLI plugin:

     The Command Line Interface plugin for enabling user input and app responses via the command line.

     

  7. Sudo plugin:

     A plugin for integrating application functionality into the sudo security subsystem.

     

• Connectivity – displays the current operational status of the Admin By Request system, including Internet and Cloud connectivity, and details about the current workstation and user (see Connecting via a Proxy Server for panel).

Connecting via a Proxy Server

Endpoints can be configured to route privilege requests through a proxy server, which works transparently with Admin By Request.

If the user does have a proxy server enabled, its configuration is passed to the underlying service that will in turn use this proxy for cloud service communications. The proxy traffic uses NO-AUTH (no credentials) and will be seen as the computer account generating the traffic.

When the endpoint starts up, Admin By Request checks to see if it can connect directly to its host cloud server. If it can, then no proxy server is required and no proxy server details are shown in the Connectivity panel.

{
    "proxy":
    [
        {
            "type": "HTTPS",
            "hostname": "my-proxy-01.anyone.com",
            "port": 8080
        },
        {
            "type": "HTTPS",
            "hostname": "my-proxy-02.anyone.com",
            "port": 8080
        }
    ],
}

Refer to How We Handle Your Data for more information.

Using Run As Admin

Run As Admin (also known as App Elevation) allows for the elevation of a single application.

This capability negates the need for users to initiate an Admin Session. Elevating privileges for execution of a single file is the much safer option compared to elevating the user’s privileges across the endpoint.

Check the audit log in the portal for details on the user, the endpoint, the application run and execution history.

MFA with Run As Admin

MFA is available as an option for authenticating users prior to granting Run As Admin  privileges. The options in the portal for authenticating users are:

1. Confirm - User must confirm with Yes or No to elevate via Run As Admin.

2. Multi-factor Authentication - User must validate identity using MFA through SSO.

Refer to Linux Settings (Authentication tab) for more information.

Requesting Administrator Access

A standard user making this selection where approval is required initiates the following sequence of events.

1. An empty Request Administrator Access form appears:

   

2. The user enters email, phone and reason information into the form and clicks OK.

   NOTE

   Settings in the portal control the full extent of what is displayed to the user:

   • If Code of Conduct is enabled, the user must acknowledge a Code of Conduct pop-up to continue (EPM > Settings > Linux Settings > Endpoint > INSTRUCTIONS).

   • If Require approval is OFF, the approval steps are skipped (EPM > Settings > Linux Settings > Authorization > AUTHORIZATION > Admin Session).

3. The request is submitted to the IT administration team and the user is advised accordingly:

   

4. The IT administration team is notified via the Admin By Request portal that a new request for administrator access has arrived.

   The following example shows how two new requests might appear in the portal:

   

5. One of the team either approves or denies the request. If approved, the user is advised accordingly:

   

6. The user clicks Yes, which starts the session and displays a countdown timer:

   

7. The duration of an admin session is set via the portal (15 minutes in this example) and the countdown timer ticks down to zero, at which time the session ends. The user can optionally end the session at any time once it has started by clicking Finish.

See Changing Admin Session Duration for more information on changing the duration of the countdown timer.

During an Admin Session, users can install programs requiring admin rights, install drivers and change system settings other than user administration. All activity during the elevated session is audited, so you can see in the audit log the reason why the person needs the elevation; anything installed, uninstalled, or executed.

MFA with Admin Sessions

MFA is available as an option for authenticating users prior to allowing an Admin Session. The options in the portal for authenticating users are:

1. Confirm - User must confirm with Yes or No to start an Admin Session.

2. Multi-factor Authentication - User must validate identity using MFA through SSO.

Refer to Linux Settings (Authentication tab) for more information.

Setting-up a Break Glass Account

Portal: Inventory > [Computer] > Break Glass

The Break Glass feature provides additional security for Linux endpoints. It creates a new, temporary, one-time-use administrator account on an endpoint that works on domains, Entra ID, and stand-alone, which audits all elevated activity, and terminates within a pre-defined amount of time or on log out.

Using the Break Glass feature

Setting-up and using a Break Glass account comprises three tasks:

1. Generate

   Create a Break Glass account:

   1. Log in to the Portal and navigate to the Inventory page. Select an endpoint on which you want to enable the Break Glass account and select Break Glass from the left-hand menu.

   2. From the Expiry drop-down menu, select an amount of time for which you want the Account to be available. The default is 2 hours, but the period can range from a minimum of 15 minutes, to an unlimited amount of time.

   3. Click the Generate Account button, which issues a Break Glass account and displays its User and Password in the read-only text boxes:

      

   4. Once generated, the status of the Break Glass account is updated in real-time in the Portal. The four possible states are:

      • Waiting for Endpoint – The account is generated in the User Portal but not yet created on the endpoint (to create the account on the endpoint, see the next section Activate).

      • Ready to Log On – The account is created but has not yet been activated / used (i.e., logged in to).

      • Session in Progress – The account is currently in use.

      • Account Removed – The account has been terminated either due to the user logging out, or the pre-defined Expiry time being reached.

   5. Optionally, you can send the new Break Glass account credentials via SMS (i.e., text message) by entering the intended recipient’s mobile number into the text box and clicking Send SMS.

2. Activate

   Activate the Break Glass account using one of the following methods:

   1. Restart the device, then wait approximately 30 seconds for the account to be created. The Portal will update the status message when the account is ready, and the account will appear in the bottom-left of the Windows log on screen along with the other accounts available on the endpoint:

      

   2. If enabled, you can select Other User in the Windows log in screen and enter the generated Break Glass account User and Password into the fields. Remember to prefix the User credential with the device name (e.g. DESKTOP-LMSEFL8\ABR524154).

      NOTE

      This may fail on the first attempt; if so, wait 10 seconds and then try again.

   3. A third method to activate the account is by logging in to another account on the endpoint, selecting the Admin By Request icon from the bottom toolbar, and clicking the About item from the menu.

3. Terminate

   Use the account and log out:

   1. Once logged in to the Break Glass account, the user has administrator privileges to do what they need to do, within the Expiry time displayed on the built-in screensaver:

      

   2. Terminate the account by either logging-out, or allowing the account to log out automatically when the Expiry time is reached – whichever comes sooner.