Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Improve Security with Challenge Response Authorization in Privilege Guard 3.6

October 20, 2017

  • Blog
  • Archive

Removing administrative privileges from users is always a challenge, but especially in the case of notebook users, who can find themselves on the road with no internet access and requiring support or needing to make a system-wide changes, such as installing a driver or application. As a result, notebook users either get to keep their administrative rights or Privilege Guard (Edit: now Defendpoint) is deployed to track when and why users are elevating privileges.

Prior to Privilege Guard 3.6, there were three options for IT when users elevated privilege or ran untrusted applications, i.e. those not included in a allow list policy:

  1. Block applications or privilege elevation requests.
  2. Allow users to run or elevate applications on demand and log the activity for later inspection.
  3. Create exception rules on demand so users can run blocked programs or elevate privileges as necessary.

Typically, allowing notebook users to run or elevate applications on demand is the most practical option, providing a means for users to do their jobs and track when applications have been run or elevated. But unless we regularly inspect event logs, it may be that users are elevating or running untrusted applications far more than we would like, putting devices and the organization’s data at risk. On demand exception rules require notebooks to have connectivity to the corporate network and some administrative effort from the IT department, which is not optimal from both users’ and IT’s perspective.

Where on demand elevation operations in Privilege Guard require only user confirmation (Figure 1), challenge response authorization necessitates that users enter an authorization code. When elevating an application, users must dictate a code displayed on screen to the helpdesk (Figure 3), and the helpdesk responds with a corresponding authorization code that confirms the required operation (Figure 4).

Setting up challenge response authorization

When creating a challenge response policy in Privilege Guard for the first time, you’ll be asked to enter an authorization key. This key is used as the basis for generating challenge response codes and is required by the helpdesk to create authorization codes. It is best practice that the authorization key should be changed on a regular basis. The challenge response system is integrated into Privilege Guard messaging, so it can be used for both privilege elevation requests and for unblocking applications not included on a allow list.

In this example, I’ve changed an existing elevation message in a Privilege Guard GPO, which is applied to notebooks and previously only required users to confirm elevation requests, so that challenge response authorization is enabled with a maximum of three attempts. As you can see in Figure 2, all I needed to do was enable challenge response authorization and change the Maximum Attempts parameter from Unlimited to Three attempts.

Once my updated policy has been applied, when a user tries to run blocked applications or elevate privilege, instead of a simple confirmation message (Figure 1), they’re required to enter an authorization code given to them by the helpdesk (Figure 3).

The authorization code is generated by a support technician using a small program (PGChallengeResponseUI) supplied as part of the Privilege Guard management console. To generate an authorization code, the authorization key and the code generated on the user’s desktop are required. In Figure 4 you can see that the authorization key is hidden, the challenge code provided by the user is in blue and the authorization code is shown in green.

Once the user has entered the authorization code received from the helpdesk into the elevation dialog on their screen, all they have to do is click Yes to run the blocked program (Figure 3).

Confidence with challenge response authorization

While challenge response authorization doesn’t completely remove the need to trust users, it is likely employees will think twice before calling the helpdesk to receive an authorization code for something they know shouldn’t be run or elevated, not least due to the effort required. Challenge response authorization allows organizations to block untrusted applications and privilege elevation requests in all but the circumstances where genuinely required, while retaining confidence that support can be provided or changes made when users are working remotely without Internet connectivity.

Defendpoint

Edit: Privilege Guard has now evolved into the brand new security suite, Defendpoint, which encompasses Privilege Management, Application Control and Sandboxing. For more information, please visit www.avecto.com/defendpoint.

Russell Smith

IT Consultant & Security MVP

Russell Smith specializes in the management and security of Microsoft-based IT systems. In addition to blogging about Windows and Active Directory for the Petri IT Knowledgebase, Russell is a Contributing Editor at CDW’s Biztech Magazine.

Russell has more than 15 years of experience in IT, has written a book on Windows security, co-authored one for Microsoft’s Official Academic Course (MOAC) series and has delivered several courses for Pluralsight.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Webcasts | February 09, 2021

Customer Webinar: Remote Support 21.1 Released!

Webcasts | February 24, 2021

Your PAM 2021 Blueprint: Securing Privileged Accounts for On-Premises and Cloud Assets

Whitepapers

Evolving Privileged Identity Management (PIM) In The 'Next Normal'

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.