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 needs 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 interecepted and the user has to optionally
enter a reason to continue to the actual installation.
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.
Click the button below for more information on App Elevation.
App Elevation in detail
Requesting a session
Some expert users might have a need to do more than running applications as administrator. You can allow all or some of your
users to request a protected administrator session that grants the user temporary administrator rights under full audit.
If this 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 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 (hence the name Admin By Request), 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 users that do not require approval.
If the user is auto-approved 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 for.
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.
In the "Settings" menu in this portal, you can define authorization settings. You can different these settings for users or computers based on their
groups or Organizational Unit through the "Sub settings" menu. If you are using Azure AD only, you can filter by Azure groups.
You can choose to completely overrule all cloud settings on client computers by registry policy keys on Windows (see here
and a policy file on Mac (see here
Approving access from the app
If the user is not auto-approved, a portal user with approval rights has to approve the request.
The easiest way to do that is to use the Admin By Request mobile app, which pushes an approval
request to all approvers in real-time. When you press the Approve or Deny button, the user will receive an email with instructions.
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.
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
verbage 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 will be no different, whether the computer has internet or not.
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.
Techinical details of the client software
For technical details of the client software, please refer to the Windows client page
or Mac client page
Please review the sections below for Windows or Mac, depending on which platform you are interested in.
If you have questions, please contact us using the chat or the contact menu at the top.
You can find answers to frequently asked questions here