Just-in-time (JIT) privileges
JIT privileges is the only realistic way to go to keep flexibility for your users and at the same time lock down admin rights.
This Microsoft blog
explains what Microsoft does internally, which talks about this best practice:
Non-persistent access — Provide zero rights by default to administration accounts. Require that they request just-in-time (JIT) privileges that gives them access for a finite amount of time and logs it in a system.
This - in a nutshell - is what Admin By Request does. Without setting up any infrastructure. Without blocking your users.
Lean Privileged Access Management
Admin By Request only consists of a portal account and a small client program for Windows or Mac.
All you need to do is deploy the client program and you're set. It's that simple. There is no initial work
for endless whitelists or on-premise installs. Nothing needs to be installed or modified on-premise
and you can therefore literally set this up for proof of concept in minutes.
Try for free
You can get a free fully functional trial login right away by using the "Download" top menu.
With your portal login, you download your Windows or Mac client program and
configure settings and you're set. You can now see activity and approve requests.
It is highly recommended to also install the free mobile app
on your phone as
a supplement to the portal for easier access to data and approving requests.
If you prefer a personal one-on-one demo first, please contact us and we will set this up right away.
Sandboxed software installation
In most cases, users need admin rights to install or update software, such as WebEx, Adobe Reader or TeamViewer.
With Admin By Request active, user's admin rights are revoked, but the user can still install software.
When the user starts an installation, the process is intercepted and the user has to enter a reason, email and phone number
to continue (if configured). The email and phone number are pre-populated from Active Directory or Azure AD. The fact that the user
is confronted with this reason screen (see next section for screenshot) and has to validate contact details in itself has a huge preemptive effect. This in itself takes
away a lot of the most obvious abuse, as the user is forced to give thought to the fact that "someone will know what I am doing now".
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.
This solves the local admin security problem.
But the true value of this is not a technical one. Users do the same as they have always done, but they don't have admin
rights to change anything on the machine. And because the user does the same as they have always done - no users are unhappy
and no re-education of users is needed. Think about the value of not have to re-educate all your users for a second.
The video below will give you a quick overview of this feature called "Run As Admin".
If you click the button below, it will take you to a page that talks about "Run As Admin" in greater detail.
Run As Admin in detail
Requesting a session
Some expert users, such as a developer, may have a need to do more than installing software or running applications as administrator.
You can allow some of your users to request a protected administrator session that grants the user temporary administrator rights under full audit.
If this feature is enabled, users will see a checkmark icon in the system tray (Windows) or icon bar (Mac). You can additionally choose
to have Admin By Request place a shortcut on the user's desktop (Windows) or in the dock (Mac).
When the user needs to do something advanced that requires administrator rights, the user just has to click the icon
to request a time-limited on-the-fly administrator session under full audit.
When the user makes the request for administrator rights, two things can happen.
When you are signed in to the portal, you configure your settings, including whether you allow administrator access without
approval or not. If you allow access without approval, the user becomes time-limited administrator right away. If you do not,
someone must approve the request in the portal or in the app first. In either case, the user will see the screen below
before starting and must enter a reason for this need. You can disable this screen for some or all users.
If the user is allowed to start without approval or the request has been accepted by you, the session can start.
This happens on-the-fly without having to log off and on and you can configure the maximum time the user is allowed
to be administrator. You can also configure whether applications that run after the timer runs out are killed or not.
Once the user either stops the timer or the time runs out, data about the session will be uploaded to the portal.
You can then see who had the session when and which software was installed or uninstalled and on Windows,
which applications were run UAC elevated during the session. Admin By Request protects the computer during the session
from tampering, such as users trying to add new local users or remove Admin By Request.
When you log into the portal and select the "Settings" top-menu, you define authorization settings. You can differentiate
these settings for users or computers based on their Active Directory groups or Organizational Unit through the
"sub settings" menu. If you are using Azure AD only, you can filter by Azure groups.
If you click the button below, it will take you to go a page that talks about the approval flow in greater detail. It explains how you use sub settings to
differentiate authorization for different users in your organization and it also talks about how you can pre-approve applications, network
shares or vendors to avoid trivial approvals or logging of applications known to be good.
You can also find a video that goes through the 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 ever having admin rights.
Approval flow in detail
Approving access from the app
If the user requests Run As Admin or an Admin Session and approval is required, a portal user with approval rights has to approve the request.
The easiest way to do that is to use the mobile app or an Apple Watch to get a real-time push notification. Because this is a real-time push,
someone will often react right away and the user experience is that there is no delay. When you press the Approve or Deny button, the user will
receive an email with instructions. These emails can be customized with company specific information, such as a Help Desk phone number.
The app also provides a great insight to what's going on a daily basis.
Click the download icon under the screenshots on your iPhone, iPad or Android device to download the free app.
Learn more about the app
Approving access in the portal
You can also approve requests in the portal, instead of using the app. Typically, you would set up an email notification to all users that can approve requests,
so the user doesn't have to wait longer than necessary. When you click the email link, it simply takes you to the "Requests" page in the portal.
Here you will see a list of pending requests, as shown below,
including contact information and computer data. You then simply click Approve or Deny for each request, as you would in the app.
The entire approval flow is described in greater detail on this page
So what prevents the user from abusing an Admin Session?
The fact that the user has to request IT for access will in itself prevent the most obvious abuse.
But as part of your settings, you can also configure a Codes of Conduct page. Here you customize
wording that suits your company policy. For example, what is the penalty for using the administrator session
for personal objectives. You can also choose to explain, what you can monitor from the portal.
When you enable the Codes of Conduct ("instructions") screen in the settings, this screen will appear right before the administrative
session starts, as shown further up. You can also customize company name and logo for all screens, so there is no doubt
this message is authentic and indeed from the user's own company. This is the configuration part of the portal,
where you set authorization, company logo, policies, email communications, etc:
Admin By Request works the same whether the computer is online or offline.
Portal settings, domain groups and OU are cached on the client and all data going the other way are queued,
so the user experience is exactly the same, when a computer is away from your LAN or even when it has no internet connection.
Computers work the same online or offline - except of course, if you require approval and the computer is offline.
Then no one will know the user has a pending request until the computer has an internet connection,
at which time it will flush its upload queue. This would rarely be a real-world problem, but there are examples,
where a computer is offline for a long period of time with no option to get online. A good example is our customer
Red Cross, which has workers going offline for weeks to a village in Africa. This is not a problem in itself,
because the computer will just collect data and flush the queue later - but if approval is required, the user is stuck.
If the user makes a request and approval is required, the user is informed that either the user has to wait, seek internet
(for example by connection sharing on the phone) or queue the request until there is internet. Or request a PIN code in
case of urgency and internet connectivity is impossible. If the user requests a PIN code, the user will see a 6 digit "PIN 1"
code and must call, say, your Help Desk over the phone and get the matching 6 digit "PIN 2". PIN 2 is a one-time
PIN code that is hashed from PIN 1, customer id and computer name. Therefore, in the odd chance the same PIN 1 appears on a
different computer, the PIN 2 is different.
Our reporting tools put you in the front seat of the whole operation. When logged on to the portal, select the "Reports" top-menu and
you have a whole data mining universe available. You can extract anything real-time, such as seeing a graphical representation of how many
request and elevations are going on right now, what's the approver activity this week per approver, backlogs, new computers being deployed
on a daily chart, a real-time map of where your computers are right now and so much more. Below is a snippet of some of the reporting tools.
For technical details of the client software, please refer to the Windows client page
or the Mac client page
You can also find answers to frequently asked questions here
If you have further questions, feel free to contact us using the chat or the "Contact" top-menu.