The Mac Client User Interface

Introduction

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

The color of the icon depends on the currently logged-in user: if the user is an administrator, the icon is red, whereas if the user is a standard user, the icon is black:

Click the icon to display the menu and select About Admin By Request for further information (Administrator and Standard User) or Request Administrator Access to carry out an admin task (Standard User only):

In this topic

About Admin By Request

Submitting Diagnostics

Requesting Assistance (Support Assist)

Uninstalling via PIN Code

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 or the dock launches the user interface, which comprises a simple window with four buttons down the left-hand side:

The default panel is About Admin By Request, which is accessed via the top button. It shows the following information:

  • Current workstation edition

  • License details - this information matches the organization details in the portal

  • Website link

  • Copyright information

Other panels presented in the user interface are accessed via buttons at the left. Clicking a button opens its corresponding panel and clicking the About button gets back to the default panel if viewing one of the others.

  • 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:

  • Diagnostics – provides a way to send useful diagnostic data on this workstation to the ABR support team (see Submitting Diagnostics for more information):

  • Assistance - (Standard User only) allows users to ask a knowledgeable support person  to access the endpoint remotely and carry out tasks on the user's behalf (see Requesting Assistance (Support Assist) for more information):

  • Uninstall – enables administrators to uninstall Admin By Request from this workstation. See Uninstalling via PIN Code for more information:

Submitting Diagnostics

Diagnostic information is available on each endpoint that has Admin By Request installed. The details recorded help IT administrators and the Admin By Request support team to troubleshoot issues that might be occurring.

The following data is recorded and submitted:

  • Current system configuration

  • Errors from the system log

  • Admin By Request-related crash logs

  • Admin By Request service log

To send diagnostic information about how Admin By Request is running on this workstation, select the Diagnostics button on the About Admin By Request panel and click Submit Diagnostics Data.

The button changes to text Diagnostics submitted, indicating that diagnostics have been sent for analysis:

NOTE:

It's a good idea to submit diagnostics when raising a support ticket for a new issue. The Admin By Request support team will frequently ask for diagnostics when responding to tickets if the information is not already available.

Requesting Assistance (Support Assist)

Assistance  (also known as Support Assist or Remote Assist) is a feature that allows users to ask for help from someone who can use a third-party tool to connect remotely to the user's computer and provide technical assistance with tasks that the logged-on user would not normally be able to complete.

Support Assist  has been designed to be used with a non-admin user, so that customers can apply the best practice "principle of least privilege" to help desk staff as well as end users. The non-admin user helps the logged-on user (also non-admin) to carry out a task with less restrictive settings than the logged-on user during a remote control session.

IMPORTANT:

At the time of writing, Support Assist  is available only to users logged-in under Azure SSO.
Support Assist  does not establish a remote control session - a third-party tool must be used for that.

The following scenarios are examples of when this might be useful:

  • End users who are not allowed to install software at all (i.e. neither Run As Admin  nor Admin Sessions  are enabled).

  • End users who don’t know where to get the software they need to use.

  • End users who are not IT savvy enough to self-service.

  • End users who refuse to take on the responsibility of installing software on their work computers, knowing they will be audited.

An example of the first scenario could be in Customer Relations, where users do not need to install software by default. When the time inevitably arrives that new or upgraded software is required, they have to call your help desk. If the request is accepted, a help desk staff member can assist by connecting remotely and using screen sharing with the end user.

Let’s take this scenario and say Customer Relations employee, Olivia, calls Steve at the help desk to assist with a task for which Olivia does not have privileges, but Steve does.

There are several (problematic) ways this could be solved without the Support Assist feature, with or without Admin By Request:

  1. Steve could have a local administrator account to all computers. However, this is an absolute security no-no and there is no auditing.

  2. You could have Microsoft’s Local Administrator Password System (LAPS) in place, but this also lacks proper auditing and doesn’t work without a LAN or VPN connection.

  3. Olivia and Steve could agree to use the Admin By Request feature Run As Admin and use Olivia’s credentials, but then Olivia gets audited for Steve’s changes.

  4. Steve could log on and use Run As Admin, but then Steve gets audited for Olivia’s request and furthermore, Olivia cannot see Steve executing the request.

Ideally, Steve should execute the request with Olivia watching and auditing should clearly show that Olivia requested the change and Steve executed it.

If you have a change management or ticketing system, you would also want a reference to document this change. This is exactly what the Support Assist feature does.

Multi-Factor Authentication (MFA)

If MFA is enabled (EPM > Settings > Mac Settings > Endpoint > AUTHENTICATION), the support person (i.e. Steve) must authenticate using MFA.

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

  1. Olivia submits a request for help to the Help Desk.

  2. Steve is assigned the task and connects remotely to Olivia's computer using a third-party application.

  3. Steve starts Admin By Request, selects Assistance from the About panel and clicks Start:

  4. At the UAC Support Assist window, Steve enters his own User account and Password credentials.

  5. The session starts, indicated by a progress timer, which displays for the duration of the session.

  6. When the assist task is complete, Steve clicks Done. If he forgets, Olivia can click done before the timer counts down, or it will simply expire. Note that Olivia cannot use her credentials while Steve is signed-in to Admin By Request.

Is it risky if a user finds and clicks the Start button from the Assistance panel? No - the UAC window at step 4 checks the credentials supplied to see if the person logging-on has the necessary privileges to carry out the task. If they don't, the task is denied and this is logged.

For Help Desk employee Steve, it is essentially the same as logging in to Windows: whatever Admin By Request settings are in effect for Steve are also in effect when he uses Support Assist. For example, if Steve is not allowed to start an Admin Session, he is also not allowed to while using Support Assist.

Think of Support Assist as a shortcut to logging in to Windows and starting Admin By Request. If someone who is not from the Help Desk uses this feature, nothing is achieved as this would be the same as if this user was simply logging in to Windows.

Uninstalling via PIN Code

Offline users can obtain a challenge/response PIN, which allows the user to perform tasks requiring elevated privileges. A PIN Code can also be used to uninstall Admin By Request when online and this is the purpose of the Uninstall panel in the About Admin By Request window.

The first few steps in this procedure require access to the portal.

  1. In the Admin By Request portal, navigate to the Inventory  page and identify the device on which to perform the uninstall.

  2. Locate the device in the inventory list - in the PIN column, click PIN for that device (columns can be switched around - the PIN column in your portal might not be the right-most column):

  3. Click tab UNINSTALL PIN and then click button Generate PIN:

    Note that clicking UNINSTALL PIN also displays a list of previous uninstall events on this computer (below the Uninstall Pin Code  window):

  4. Copy the PIN.

  5. Back on the device on which you want to uninstall Admin By Request, go to the About  panel (i.e. select the Admin By Request icon from the top menu bar and click About Admin By Request).

  6. In the Uninstall  window, select Uninstall from the left button group, enter the PIN copied from the Portal, and click Uninstall:

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.

Example 1 - Install app VLC

A standard user, requiring elevated privileges to execute the VLC installation program, initiates the following sequence of events:

  1. Download the package or application file for installation.

  2. Start the installation by opening the Downloads folder and dragging the VLC icon to the Applications folder. If the download is a .dmg file, double-click it first to mount it:

    If a warning about VLC being downloaded from the Internet pops-up, click Open to continue.

  3. Admin By Request suspends installation and checks the organization's portal settings.

    1. EPM > Settings > Mac Settings > Authorization > AUTHORIZATION:

      Authorization (i.e. approval) is not required, so installation can proceed. This is also the case when approval is  required, but the app is pre-approved.

    2. EPM > Settings > Mac Settings > Endpoint > AUTHENTICATION:

      Authentication is always required and the mode in this case is Confirm. so the following prompt is displayed and the user simply has to click OK to continue:

  4. Once authenticated, installation proceeds to completion and Admin By Request displays a note from the application installer saying that installation has completed successfully.

After installation, portal administrators can check the audit log in the portal for details on the user, the endpoint, the application and execution history:

Example 2 - Install app Foxit PDF Reader

A standard user, requiring elevated privileges to execute the Foxit PDF Reader installation program, initiates the following sequence of events:

  1. Download the package or application file for installation.

  2. Start the installation by opening the Downloads folder and double-clicking the .pkg file:

    If a warning about the file being downloaded from the Internet pops-up, click Open to continue.

  3. Admin By Request suspends installation and checks the organization's portal settings.

    1. EPM > Settings > Mac Settings > Authorization > AUTHORIZATION:

      Authorization (i.e. approval) is required, so Admin By Request prompts for phone, email address and reason. This information is submitted for approval and the user is advised they will be notified via email when approved:

      A portal administrator receives the request and approves it:

      When approval arrives via email, the user can continue the installation with authentication (step 3.b below).

    2. EPM > Settings > Mac Settings > Endpoint > AUTHENTICATION:

      Authentication is always required and the mode in this case is Authenticate. so the following prompt is displayed and the user must supply credentials to continue:

  4. Once authentication is provided, installation proceeds to completion and Admin By Request displays a note from the application installer saying that installation has completed successfully.

After installation, portal administrators can check the audit log in the portal for details on the user, the endpoint, the application and execution history:

IMPORTANT:

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

Multi-Factor Authentication (MFA)

MFA is available as an option for authenticating users prior to granting Run As Admin  privileges. The three 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.

  3. Authenticate - User must validate with credentials, face recognition, fingerprint, smartcard or similar.

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

Intuitive app updates

Prior to Mac 5.0, updating already-installed applications required an Admin Session. Now, pre-approved apps can be updated when the apps themselves prompt for it on manufacturer release. Alternatively, IT departments can control app updating by withholding pre-approval for the next release of an app until full testing has been completed.

As with the initial installation, portal settings determine if users must request approval to update (authorization) and, once approved, they are asked to confirm an update via Confirm, MFA or Authenticate with credentials (authentication).

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.

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

  1. A prompt asks “Do you want to start an administrator session?”. The user clicks Yes to continue:

  2. An empty Request Administrator Access form appears:

  3. 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 > macOS Settings > Endpoint > INSTRUCTIONS).

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

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

  5. 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:

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

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

  8. 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.

Multi-Factor Authentication (MFA)

MFA is available as an option for authenticating users prior to allowing an Admin Session. The three 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.

  3. Authenticate - User must validate with credentials, face recognition, fingerprint, smartcard or similar.

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

Setting-up a Break Glass Account

The Break Glass feature extends the functionality of MS LAPS. It creates a new, temporary, one-time-use Administrator account on an endpoint, that works on domains, Azure AD, and stand-alone, which audits all elevated activity, and terminates within a pre-defined amount of time or on log out.

The Break Glass feature includes the following security benefits:

  • Break Glass circumvents the need to use the built-in local Administrator account – you can disable it completely to add an extra later of security to your endpoints.

  • The account must be used within an hour of being generated, minimizing the potential attack window and risk of account compromise.

  • Risk is further minimized by a one-time-only log in functionality: the user can log in once, and after log out, the account is terminated.

  • The user has only the time specified under Expiry when the Break Glass account was generated to use the administrator account; this duration is indicated on the built-in desktop background of each account. When the time-period is up, the session is terminated.

  • Measures are in place to ensure the Expiry time cannot be tampered with: if the Account user attempts to extend their time limit by adjusting the clock, the Account automatically logs out / terminates.

  • All Usernames and Passwords are automatically generated, random, and complex, minimizing the possibility for a successful brute force attack.

  • Passwords are stored within the web application, only accessible by Portal users / IT Admins via credentials – a safer option compared to MS LAPS' storage of admin account passwords in plain text along with the AD computer record.

A Break Glass account is useful in the following scenarios:

  1. Regaining Domain-Trust Relationship
    As the name suggests, the Break Glass feature is ideal for "last resort" situations, such as when the domain-trust relationship is broken and needs to be reconnected using an Administrator account.

  2. Provisioning a Just-In-Time Administrator Account
    The Break Glass Account doubles up as a Just-In-Time account that can be used for specific purposes / situations when necessary; e.g., provisioning an account for someone who doesn’t have credentials, but requires access to service an endpoint.

  3. Extra Possibilities with Server Edition
    Further to point 2, with Admin By Request Windows Server Edition you can provision an admin account to a consultant without giving them domain-wide permissions at any point in time.

Using the Break Glass feature

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

  1.

    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 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.

    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.

Refer to Features > Break Glass / LAPS for more information on the feature.