When a user has a need to install software or run an application with administrative privileges, the user invokes the Admin By Request "Run As Admin" feature.
The user will experience that one of these four things happens:
- It works just as if Admin By Request was not installed (audit only)
- The user has to enter a reason and then it works
- The user has to enter a reason and wait for an approval
- The user gets a message that this is not allowed (PIN option still possible)
Which of these scenarios the user will experience is decided by the rules you set up in your portal account settings.
You can configure different rules for different users based on Active Directory groups or OU. This is called subsettings and is explained further down.
The chart below shows the flow of approval. Advanced users may have the option to start an Admin Session, which has the same flow.
Run As Admin with approval
The video below walks through the set up steps and the user experience. A typical set up is allowing "Run As Admin" without approval, but with the reason screen enabled.
The video below goes through a scenario, where both are turned on, to show the full approval flow.
Naturally in any organization, you would not want the same rules for all employees. You may have anything from expert IT users
to external personnel that would have no reason to do anything on a computer. The way you solve this is
by having default settings, which are called Global Settings. These would typically be the most restrictive to handle
a case, where a user or computer by mistake is not in any groups or OUs of any subsetting. This is the Authorization
page of Global settings from the portal "Settings" menu:
In the portal, you have a submenu called "Subsettings". Subsettings is for defining other rules than the Global/default for some users or computers.
When you create a new subsetting, you must enter the scope of the subsettings. The scope is based on the user or computer and can be
one or more groups and/or one or more OUs.
When creating subsettings, it is typcally to have different authorization rules, but you can overrule all settings in subsettings.
You may wonder, if this works off the LAN, as it is based on Active Directory. It does - because computers cache this information encrypted for
usage off your LAN. This means that all your portal changes are real-time no matter where you endpoints are in the world. Endpoints are not dependant
on having to visit your LAN from time to time.
If you do not use "Required approval" for Run As Admin, pre-approval is not relevant. But if you do
require approval for Run As Admin, one problem often arisis.
While the intention with IT approving all administrator activity is to keep the environment
tight, some users have a legitimate need to run the same applications over and over with administrator privileges. An example is a developer having
an occational need to run Visual Studio with administrator privileges. Using approval for these bread-and-butter operations is not really a viable solution.
One way to solve the developer example would be to create a subsetting for developers and not have approval on for these users. This would however of course
disable approval for all applications. One other way is to pinpoint the applications that they use often and pre-approve them if they are deemed safe.
Let's say 10 applications are pre-approved, then everyone can run these 10 applications without approval from you. All other applications go through the approval flow above.
The way you pre-approve is to either go to Settings -> Applications and add an entry. You can also locate the application if it appears in your Auditlog and click the link
to take you to the same page. This would pre-populate all the information.
This will open a page, where you define properties for the pre-approved application. This only thing you have to take into account is that you have to be sure
that users cannot rename a file and thereby get an unintended pre-approval. Therefore you should add what is called a "Protection". Protection can be:
- No protection (not safe, as a user can rename a different file).
- File must be located in a specific read-only location.
- File must match a checksum (specific binary version of a file).
- File must have a specific code certificate (the "Digital Signatures" tab on a file).
In the case of visual studio, devenv.exe is located under Program Files, where users cannot put a different file with same name. Adding the protection that
it must be located anywhere in Program Files makes sure that someone cannot rename a different file to devenv.exe and get it pre-approved. Note that we did
not put in the full path, but just selected anywhere in the read-only Program Files tree. This makes sure that this rule applies to any version of Visual Studio, not
just the 2019 version.
An application file and an install file are both just a file. The main difference is that an install file would typically be considered more dangerous
than an installed application file. But also, an install file would typically be downloaded from the internet, so we have to apply a different protection
than the file location. One way is to look at the digital signature of the file. This means we pre-approve, say, acmesetup.msi - but because a user can just
rename any other file to be called acmesetup.msi, it must also match a digital signature (specific vendor). You can also use a checksum. Checksum is bulletproof,
because only one file in the world can match the checksum. The drawback is that a checksum would be version dependant. Let's say your company uses TeamViewer and
you pre-approve the TeamViewer setup file, then you have to add another checksum every time there is an update. In this case, it would make more sense to generally
pre-approve any files from the vendor (digital certificate of file) "TeamViewer Gmbh". The video below goes through the process of preapproving everything from a
Network share pre-approval
Some companies practice that the IT department approves software and put install files on a read-only network share, where users can install from.
You can make a general pre-approval on a network location, so any file located here is pre-approved. You can also point to a vendor (digital certificate)
and say that any file from this vendor, say "Microsoft Corporation" or "Adobe Inc.", is good and is pre-approved. The video below goes through a scenario
where both Run As Admin and Admin Sessions are disabled - but users are allowed to self-install files from a network share of install files sanctioned by IT,
without users having admin rights.
Voiding Auditlog logging
If you look at the screenshot for adding a new entry above, there is an on/off toggle "Log to Auditlog". Since you know these applications or installers are good,
it would typically not make sense to fill your auditlog with these trivial entries. You can decide per pre-approved application, if you want the application or install
file to log to the auditlog. Note that even if you do not use approval at all, you can still add entries for the sole purpose of getting them excluded in the Auditlog.
If Run As Admin or Admin Session is not allowed and user is shown an access denied message, it is possible to use a PIN code. The PIN code option is
also shown, when a computer is totally offline (no internet connection) and approval is required. The PIN code can be found in the inventory for the
given computer and can overrule the settings. A scenario could be when a Help Desk employee is doing a remote control of a user's computer and needs
to perform the operation without logging off and on. This is explained in greater detail on this page
Approving a request
When approval is required, the request is pushed to the mobile app in real-time. An administrator can then press either Approve or Deny without
unlocking the phone or click the notification message for more information. The mobile app is explained in greater detail here
The same requests will appear in the portal under "Requests". If you are not using the app, you can set up an email notification
to administrators in the Authorization section of your portal settings to be notified of new entries in the requests list.
If you have questions not answered on this page, please contact us using the chat or the contact menu at the top.
LATEST CYBERSECURITY BLOGS