Practical example - WebEx Desktop
Let's take a practical example. An employee needs to invite other people to a WebEx meeting and therefore needs to install the WebEx desktop app.
But here is the problem - the desktop app requires admin rights to install. Let's assume the user has no special Windows skills,
so the user will simply Google and download the install file and eventually get stuck in the browser without admin rights:
But with Admin By Request installed, exactly the same happens - except the result is different. The user enters unprivileged credentials
and the installation runs without the user actually being administrator. And you will know, because the installation is logged to the
Auditlog menu here in the portal.
So what happened? Admin By Request intercepted the browsers' request to elevate with admin rights to install the software and
then executed the installation sandboxed with admin privileges, but without the user having admin rights. Nothing in the process
was different to the user than when the user had admin rights. This video below shows a quick overview of how it works.
When the elevation attempt is intercepted, you can enable a recommended reason screen and a Code of Conduct screen. When you enable
the reason screen, a form is shown before the user enters credentials to start the installation. The user must enter a reason why
the user needs to install this software. And if a Code of Conduct message is set up, this will also be displayed before the installation
starts. A Code of Conduct screen would typically mention that the process is audited, give general guidelines for which software
in allowed in the company and a Help Desk phone number in case of questions. In our case with the reason screen enabled, the user has to enter
a reason for installing WebEx before starting:
When the user starts an installation, you will see a new entry in the AuditLog in the portal and in the app
with status "Running". Once the elevated program is finished, the status changes to "Finished" and you can see a list of installed or uninstall software
and a list of processes that were started during the elevation. If multiple processes appear, it is because the process that started spawned other processes.
This is perfectly normal for software installers.
Asking for admin execution
If the user tries to run a software installation, the interception automatically happens.
Users can also ask the Windows Explorer to execute a file with admin privileges using the built-in "Run As Administrator" feature.
An example could be a developer that needs to run Visual Studio to develop a driver or SQL Server Management Studio to create a database.
The process of automatic interception or manually request for admin execution is called App Elevation.
To indicate that App Elevation is active, you can see the "Run As Administrator" icon change from a Windows one to an Admin By Request one:
The same rules applies, if the reason screen and Code of Conduct message are enabled. Then the user has to supply a reason
and will have to accept the Code of Conduct to continue and the elevation is fully auditted.
Once the user enters their own unprivileged credentials, the application runs. The application is run with administrator rights
and UAC elevation, but the user does not have administrator rights at any point.
The configuration is done by using the "Settings" menu at the top after logging in.
Some expert users may be authorized to perform modifications to the machine, such as IT staff or developers. Such users can be granted a protected time-limited,
real-time administrator access under the same full audit as App Elevations. Therefore, there are two levels of configuration in the portal:
- App Elevation is when Admin By Request intercepts a software installation or the user invokes the Windows Explorer "Run As Administrator" feature
and Admin By Request sandboxes the execution of this application.
- Admin Session is a protected administrator session, where the user has admin rights for a limited
period of time under full audit, which is started by clicking the tray icon or using a desktop shortcut that Admin By Request places there.
In the portal "Settings" menu, you configure whether these two features are enabled or not. You can differentiate all settings based on user or
computer groups or organizational unit.
There might be programs you would not want users to run as administrator generally. In the portal settings,
you can block files that you don't want users to run as administrator. You can also block programs that you don't want the
users to run generally, such as Dropbox or Spotify.
To prevent users from running system files, such as cmd, regedit and powershell, you can block these from running elevated in the list above.
There is however a global switch you can turn on to simply disallow running any system files elevated. If the user needs to install software, the
user would have no legitimate need to run a system file elevated.
If you look at the settings at the top again, you can see that there are two options "Require Approval" and "Require Reason".
If "Require Approval" (approval mode) is on, it means that users are not automatically approved to run a program as administrator.
If you have approval mode on, a request will appear under the "Requests" menu, where you can approve or deny the request to run the application:
If you installed the app in your phone, you will also receive a real-time push notification of the request and it will appear in your list of
pending approvals. The entire approval flow is explained in greater detail here
Run As Administrator with administrator credentials
Sometimes it is a useful to run a program as administrator, while a normal user is logged on.
If administrator credentials are supplied instead of the user's credentials, the execution is excluded
from logging and the optional reason information is not used. This allows an administrator to use
"Run As Administrator" the same way as it is built into windows.
Choosing the right settings
Choosing which settings are best for your company depends on your company policy, the amount of time you want to invest
in approving requests and the size of your organization. Often customers start by having approval mode on with the intention
of approving all requests. But almost all customers end up disabling approval mode, learning that because users have to document
the reason and are aware that activity is audited, abuse simply stops and there is no need to spent time approving requests.
Most companies learn that they are satified with having a full audit log. Remember that with approval mode off, no IT resources
have to be spent at all to solve the local admin problem.
If you do wish to have approval mode on, you can differentiate between Admin Sessions and App Elevations. You could allow
running an application, but not allowing a full session without approval. There is also the option to use Sub Settings. Sub Settings
are settings that overrule the global settings for some users or computers based on groups or OU. This allows you to disable approval
mode and/or the reason screen for some users and not for others. If you are uncertain about settings or have questions about App Elevations,
please feel free to contact us using the chat or the contact menu.