The Linux Client User Interface

About Admin By Request

The user interface is graphical and is accessed via the icon menu in the menu bar (top right) of the screen:

Click the icon to display the menu and select About Admin By Request for further information:

In this topic

About Admin By Request

Connecting via a Proxy Server

Using Run As Admin

Requesting Administrator Access

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.

 (accessed via their respective buttons).

  • About – displays the About panel, including current workstation edition, license details, website link, and copyright information.

    Clicking Components displays information about the individual modules that make up Admin By Request.

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

    The following screens show current component versions. These can be useful 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. PAM plugin:

      Privileged Access Management plugin, supporting the main module.

    3. GUI:

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

    4. Polkit plugin:

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

    5. Service:

      The local service for the Admin By Request Linux client.

    6. 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 next section for screenshot).

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.

The Connectivity panel indicates whether or not a proxy server is used for an endpoint:

Admin By Request uses port 443 and the IP addresses and URLs that need access through firewalls are as follows.

If your data is located in Europe:

  • IP: 104.45.17.196

  • DNS: linuxapi1.adminbyrequest.com

If your data is located in the USA:

  • IP: 137.117.73.20

  • DNS: linuxapi2.adminbyrequest.com

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 the value of Proxy server will be None.

If it cannot connect directly, it checks the following configuration file and works through the listed servers one by one until a connection is possible:

/etc/abr/configurations.d/proxy.conf.template

The default entries in this file are listed below. If you need to configure a proxy server, replace the information in this file with your proxy server information.

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

If the endpoint connects via a server configured in this file, None is replaced by the hostname of the proxy server and all privilege requests are routed through it.

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.

In Linux, a single line sudo command implements Run As Admin.

For example:

  1. Run a sudo command.

  2. If approval is required, a pop-up will appear asking for information, including reason. If approval is not required, a reason must still be given for logging purposes.

  3. When the sudo command is complete, check the portal under Auditlog > RUN AS ADMIN rather than Auditlog > ADMIN SESSIONS. The sudo command is logged under RUN AS ADMIN.

Pre-approved applications run without prompting for a reason and the activity is logged under RUN AS ADMIN. (e.g. the sleep command).

The elevated privileges last only for the duration of the install and apply only to the particular application or package authorized.

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

Requesting Administrator Access

Requesting administrator access is also known as requesting an Admin Session, which is a time-bound period during which a standard user has elevated privileges and can carry out administrator-level tasks..

As with About Admin By Request, click the menu bar icon to display the menu and select Request administrator access:

Submitting a request for administrator access is the primary mechanism for gaining elevated privileges.

NOTE:

Timing can be important when an admin session is started for some GUI operations:

  • If you start an admin session after you have started the GUI interface (for example, add a new user account in Settings), you will need to refresh the current GUI screen by selecting another option in Settings, then going back to User Accounts.

  • If you start the admin session before opening Settings, there is no need to refresh the user interface.

A standard user making this selection 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 (Portal > Settings > Workstation Settings > Linux Settings > Endpoint > INSTRUCTIONS).

    • If Require approval is OFF, the approval steps are skipped (Portal > Settings > Workstation 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.

IMPORTANT:

During an Admin Session, users cannot uninstall Admin By Request, or add, remove or modify user accounts.