This page goes into technical details of the Windows endpoint software. Please refer to the Product Overview page for an overall understanding of the functioning of the software.
The local administrator’s group
If the computer is in a domain, the Domain Users group will be removed from the local administrator’s group right away. That is all that happens initially. When a user logs on, the user will be removed from the local administrator’s group, unless:
- You have unchecked the “Revoke admins rights” in the portal settings (see screenshot below)
- The user is in the list of excluded accounts in the portal settings
- The user is member of a group that is the local administrator’s group (such as domain admins)
The reason all users are not removed right away is to only remove accounts that are interactive user accounts and not accidentally remove service accounts used to deploy software or similar.
Domain groups (except Domain Users) are not removed from the local administrator’s group. This means that if a domain user logs on and is member of a domain group that is in the local administrator’s group (for example a Help Desk domain group), the user is always local administrator. In this case the tray icon is red and hovering it, you can see the tool tip saying “You are logged on as administrator”.
Azure AD and computers outside domains
The software works exactly the same without a domain or for computers joint to Azure AD. For Azure AD, you can set up a connector in the portal settings. You do not need to do this for Azure AD, unless you need to use subsettings, in which case you can set up the connector to create subsettings based on Azure AD groups.
Admin By Request SSO (Single Sign On)
This section covers how to set up Enterprise applications for Admin By Request SSO.
There are two methods that can be used to setup Admin By Request SSO in Azure AD, depending on whether or not users are allowed to grant consent to applications that might request access to data:
- Users are permitted to grant consent.
- Users are not permitted to grant consent.
A) Users are permitted to grant consent
The first method requires that a user be allowed to grant consent to apps in Azure AD, as indicated in the screenshot below:
The first time Admin By Request requires SSO from an endpoint, a Microsoft Permissions requested dialog appears:
When the first user accepts, an Azure AD application is created for Admin By Request SSO. This application is now ready for any other user in the enterprise:
B) Users are not permitted to grant consent
The second method is more complex and is needed when users are not permitted to grant consent to apps in Azure AD, as indicated in the screenshot below:
In this case, the following tasks must be completed:
- Modify Admin consent settings.
- Elevate a program as a normal user.
- Approve the request as an authorized approver.
1. Modify Admin consent settings
Admin consent settings must be modified so that users can request admin consent to apps they are normally unable to consent to:
Determine which Users, Groups and/or Roles will be permitted to approve consent requests. To ensure approval requests are handled efficiently, those able to review requests for approval for a given application should be specified at this point.
2. Elevate a program as a normal user
The first user to initiate SSO validation from an endpoint is presented with an Approval required dialog:
To ensure first use is controlled, login as an ordinary user and create a consent request for the application by elevating a program. Enter the reason why you want this and click Request approval.
3. Approve the request as an authorized approver
Once the first approval request is made, go to your AAD tenant > Enterprise Applications | Admin consent requests > All (Preview) as one of the Users/Groups/Roles specified earlier. The following shows one request in the list:
For the request shown, click Admin By Request SSO to open it.
Finally, click Accept to approve it:
Once accepted, all users can run the application.
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 Code 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 Code 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.
The software has built-in measures to avoid tampering with the software to become permanent administrator. The users and groups administration will be removed entirely from Computer Management during an administrator session. Even if the user still manages to tamper the local administrator’s group, the administrator’s group is snapshotted before the session starts and restored after the session ends. If the user tries to add other users or groups to the administrator’s group, these will simply be removed at the end of the session. If the user tries to uninstall Admin By Request during a session, Windows Installer will show an error message saying that Admin By Request cannot be uninstalled during an active session. If the user tries to tamper policy keys, these are also snapshotted and restored after sessions.
User Account Control
User Account Control (UAC) is still enforced (if enabled) to maintain the extra layer of security. If the user needs to run an application during an Admin Session, the user still has to envoke “Run as administrator” directly or indirectly and enter own credentials. This is intentional to avoid reducing the security level. Admin By Request does not replace or tap into UAC for the reasons stated in the previous section.
Admin By Request does not replace User Account Control, like some other solutions do. This is a design choice. Replacing Windows system files or components is dangerous and can lead to future problems because of Windows Updates, which could ultimately break your OS installs to the extent that computers can no longer boot. This is especially true with Windows 10 feature updates that often change basic functioning of the operating system. A significant advantage to the Admin By Request endpoint software is that it does not change or replace any system files or components and only uses what is already built into Windows. Because of this, it also does not consume any resources at all, unless the user invokes the software.
You can generally block applications you don’t want users to run, such as Spotify or certains browsers. You can also block users from elevating any Windows system file, which prevents users from running cmd.exe, regedit.exe, mmc.exe, etc as administrator.
In the portal, you have settings for Workstations and Servers. These are the default settings. You can then define overruling setting based on computer or user groups and/or Organizational Unit(s). A common scenario would be to require approval for all users – except users in the IT department, who are allowed to elevate without permission.
Proxy servers work transparently with Admin By Request. The application that runs in the user space (AdminByRequest.exe) that you see in the system tray will detect if the current user has a proxy server enabled or not for the IP addresses that are used for the cloud service (see here for IP addresses). If the user does have a proxy server enabled, this is passed to the underlying service that will in turn use this proxy for cloud service communications. This traffic uses NO-AUTH (no credentials) and will be seen as the computer account making the traffic. You can check if a proxy is being used or not by opening the connectivity screen at System Tray -> Admin By Request Tray Icon -> About -> Connectivity.
If you have questions not answered on this page, please contact us using the chat or the contact menu at the top.