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
    Use Cases and Industries
    See All Products
  • 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

RunOnce to the hills

October 20, 2017

  • Blog
  • Archive

Here in the Avecto Support Team we come across various issues with customers that wish to allow their users to perform elevated tasks in Windows once their Administrator rights have been removed; this can vary from changing Windows settings or allowing a legacy app to run with admin rights for compatibility reasons, to installing complex application suites.

There are however a few areas in the OS that simply do not work unless you log in as an Administrator, and one of these mechanisms is the RunOnce key in the Windows Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
The offending key

For those of you that haven’t come across this before, the RunOnce key in the registry is used to run an application once when users log in – no surprises there – and is then removed from the key so that it is not executed again. This is similar to the Run key, which instructs Windows to run the applications specified every time a user logs in.

Crucially, the difference between the Run key and the RunOnce key is that applications listed under RunOnce are only executed if the user logging in has Administrator rights; the applications in the Run key will run when any user logs in.

The issue here is that some applications, when installed, make use of RunOnce in order to allow an application to continue installing after a reboot; how many times have you had to restart a machine in the middle of a software install in order to complete the installation successfully? When your users no longer have Administrator rights, the applications listed under RunOnce do not execute, and therefore any install making use of this key no longer works.

So, how do we fix this? At first glance, it seems like there is nothing that can be done, especially as the applications listed under RunOnce don’t even execute when logging in as a Standard user; if they did, perhaps we could have targeted them for elevation and the installs would have been able to complete. This is not the case – what we need to do is ensure that the entire RunOnce mechanism is actually executed when a Standard user logs in.

Fortunately there is a command that we can execute which triggers the RunOnce mechanism to run:

c:\windows\system32\runonce.exe /explorer
Salvation!

This command needs to be executed on every user login. The easiest way to make this happen is to add it to the Run key on each machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
The Run key

The final hurdle is that the RunOnce mechanism requires elevation – so use your chosen Privilege Management software to add a rule to elevate the command. You can then either allow the RunOnce mechanism to elevate all child processes, or if you wish to be more secure, target individual applications listed under RunOnce.

The net result is that whenever any user logs in to a machine, the presence of the new command in the Run key triggers the execution of the RunOnce mechanism, which is then elevated by your chosen Privilege Management software. If there are applications listed under RunOnce, they are then executed; if there are none present, the RunOnce mechanism simply stops without running any further processes.

For those of you that are Avecto customers, please log in to Avecto Connect and see Knowledge Base article #1231 for full instructions on how to implement this fix specifically using Defendpoint.

So there you have it; the list of excuses reasons that users have for not having their Administrator rights taken away is getting shorter and shorter.

Gareth Remblance,

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:

Whitepapers

Mapping BeyondTrust Solutions to the Identity, Credential, and Access Management (ICAM) Architecture

Whitepapers

Four Key Ways Governments Can Prepare for the Growing Ransomware Threat

Whitepapers

The Operational Technology (OT) Remote Access Challenge

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.