Multi-Factor Authentication (MFA), once an ‘extra step’ only enforced by the most stringent companies, is quickly becoming a must-have.

As cyberthreats increase and advance, so do compliance and security requirements specified by governing bodies. Most organizations now have policies around MFA and Single Sign-On (SSO) in place, both to protect their IT environment and to ensure adherence to various compliance regulations.

Such policies or business rules can prove cumbersome for all involved: enforcing that they’re followed may present a problem for IT Admins, whereas abiding by them may seem annoying and unnecessary to the end user (who just got sent their 4th verification code of the day…)

So, we decided to build endpoint MFA and SSO capabilities into version 8.0 of our existing Privileged Access Management (PAM) solution, allowing customers to configure and enforce business rules around these two security features from within their User Portal.

A New Elevation Method

In the current feature set (i.e., prior to v8.0), you can configure either Confirm or Authenticate in your User Portal as the approval method users run through when requesting privileged elevation.

• Confirm: a pop-up appears with a simple option to Confirm that they are about to elevate an app or start an elevated session.
• Authenticate: A pop up appears which requires the user to enter their details and (if configured) a reason for the requested elevation.

Single Sign-On is now the third option available, which directs users to the configured SSO provider and requires MFA when they request elevation. Admin By Request then verifies that SSO is complete according to the company’s business rules, and the requested elevation is granted.

The Benefits

The feature is ideal for enabling organizations to enforce business rules and ensure security and compliance. It enforces MFA on the endpoint prior to elevation – a requirement for UK organizations who must adhere to the UK Cyber Essentials framework.

On the end user side, this feature vastly reduces the number of steps the user needs to take by essentially allowing them to bypass Windows Authenticate and use SSO in order to obtain elevated privileges; the same end result, with fewer clicks. Users no longer have to wait for approval (as is the case in Authenticate / Require Approval mode) – as soon as SSO is complete, approval is granted.

Configuring the Feature

1. In the User Portal, navigate to Logins > Single Sign-On Setup, and select Endpoint Single Sign-On from the drop-down menu:

2. In the User Portal, navigate to Settings > OS Settings > Endpoint > UAC, and select Single Sign-On as the UAC mode:

3. In the Single Sign-On Configuration section, select the preferred SSO provider from the drop-down menu:

Note you may want to enable Email match, which requires the person validating with SSO to be the same as the user logged in to the endpoint. This may seem like a given, but in some situations, customers have one email address in Azure, and use a different one for SSO.

5. Save your settings. Now when users request elevation, a window will appear requiring they sign in to the configured IdP provider according to your User Portal settings:

6. Entries in the Auditlog indicate which users have elevated using SSO with an orange SSO ✔️ badge:

Sub-Settings

This feature can be fully tailored to suit large enterprises who may use several different IdPs depending on region.

Global settings allow you to choose the global IdP which will be used for SSO across the board, however in Sub-Settings, you can override the global settings for different users or groups, and configure these users or groups to each use a different SSO solution for verification.

A use case for Sub-Settings is as follows:

• A global organization has one factory in Indonesia and six factories across Australia
• At all of the Australian sites, Okta is the IdP solution used
• At the Indonesian location, Office 365 is used
• The organization creates a Global Setting which configures Okta as the SSO solution, because this is the predominant IdP used at the company and therefore applies to most users
• In order to allow MFA/SSO for the Indonesian location, the organization creates a Sub-Setting for users in this scope, which overrides the Global Settings and instead configures Office 365 as the IdP for SSO.

Support Assist

SSO works in conjunction with our existing Support Assist feature: Help Desk personnel are able to provide Support Assistance via SSO without ever logging in to the endpoint.

The Support Assist feature allows SSO sign-ins that have been configured in Sub-Settings – without requiring an Active Directory/Azure Active Directory (AD/AAD) account.

For example, if you have configured an SSO Sub-Setting with Okta as the configured IdP, a Help Desk member with an Okta identity (but not an AD/AAD identity) is able to start a Support Assist session by authenticating to the Sub-Settings SSO provider (in this case, Okta). The ‘virtual’ user is monitored during the session, but never actually logs on to the machine.

This allows organizations to enforce policies (e.g., “log on locally” restricted to one user) while still utilizing the Support Assist feature.

Summary

The latest SSO/MFA feature coming with Admin By Request v8.0 is simple, but effective: it gives enterprises the power to enforce business rules and ensure full compliance and maximum security within the organization, while reducing wait times and increasing productivity for end users.

Get endpoint MFA/SSO as part of your existing Privileged Access Management solution: keep an eye out for Admin By Request version 8.0 – released Monday 12th December.