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.