Windows client

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.

Preventing abuse

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:

Offline computers

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.

PIN code

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.

Tampering

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.

Blocking

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.

Subsettings

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

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.

Questions?

If you have questions not answered on this page, please contact us using the chat or the contact menu at the top.