For remote employees, nothing is more frustrating than being unable to access an application they need to do their job. It’s an issue every employee will experience at some point. But while many applications appear to run locally on an employee’s computer, they’re really running on a server. So, if your employees need to access one of these applications and its data, they either must either have a license to install it locally or be working from inside the office perimeter. This is where RemoteApp comes in. Below, we’ll see why it’s so important to secure access to these applications with MFA for RemoteApp.

RemoteApp and Desktop Connections (RADC) (“RemoteApp”) is a feature of Microsoft’s Remote Desktop Services (RDS) suite that allows users to connect to any application if it is installed on the desktop, although the applications are run from a remote server using Remote Desktop Protocol (RDP).

While SaaS services solve remote access problems for common office applications, specialized applications run from on-premise servers. This makes them unavailable to remote users.

Bring Your Own Device (BYOD) security is another problem. Applications aren't pre-installed on employee-owned devices, which means access becomes impossible.

In short, RemoteApp solves the problem of remote application access for on-premise applications. Here’s how it works.

Once configured using a settings file, applications hosted via RemoteApp launch from the startup menu like any other application, including via a simple URL in the case of RD Web Access:

 https://<servername>/rdweb/feed/webfeed.aspx

Users can also open and save files from a work drive and even remotely access Windows applications when using an Apple Mac, Chromebook, or Android device, as well as from a web page.

RemoteApp makes life easy for users because they can access any application from anywhere on almost any computer.

Admins win too because they can give employees access to an application and any partner applications connected to it through a simple process.

It’s often said that organizations are moving applications to the cloud, an approach Microsoft supports for remote applications through Azure Virtual Desktop (AVD) and bring your own license (BYOL). But many organizations continue to use on-premise applications for a variety of important business reasons.

One is the need to run older, legacy, or specialized applications that require a specific Windows environment to work correctly.

Another reason is to retain control over the data (data sovereignty) inside these applications to meet strict security or regulatory demands.

Smaller organizations may also value on-premise applications because this approach allows them to continue using the Active Directory (AD) infrastructure they’ve invested in over many years.

However, RemoteApp is not binary and also works well in hybrid environments. For example, by allowing users to open an application hosted on-premise while saving files to a cloud service such as Microsoft 365.

As we already know, RemoteApp gives remote employees easier access to on-premise applications.

For admins, RemoteApp brings other advantages, such as:

• Removing the overhead of installing and maintaining software on individual computers.

• Giving users access to only the application being used and not the whole server, improving security.

• Facilitating access to older or legacy applications that might not be compatible with a newer version of Windows.

• Deploying a more secure virtual desktop infrastructure (VDI) experience serving individual apps rather than a full desktop.

As with all remote access security, it’s important to properly secure RemoteApp connections. Windows remote access can be configured in different ways, which leads to confusion about the security offered by each approach. The oldest and simplest is to set up a direct RDP connection, which allows users to access their entire desktop environment remotely.

However, this is not only bandwidth-intensive but poses a big security risk. By default, RDP is not encrypted while anyone able to steal or brute force a user’s RDP credentials will be able to access the entire remote desktop environment and the possibly remote server from which it is running.

Criminals are all too aware of this and aggressively target direct RDP connections to spread things like ransomware. Using RemoteApp reduces this attack surface in several ways. First, when set up for remote access, it usually connects through RD Gateway, a Remote Desktop Services (RDS) proxy server that secures the connection using HTTPS while allowing admins to centralize management.

Most important of all, where RDP exposes the whole desktop environment running on a server, RemoteApp ensures that users can only access a single application for each connection.

Today, default security is usually weak security. RemoteApp is no different in this respect. In the case of an application served via RemoteApp, default security means Windows credentials (a username and password). This, at a time when it's clear that passwords have become easy to bypass for several reasons:

• Credentials such as passwords are easy to phish or steal, and weaker ones are easy to brute force.

• Users have a habit of re-using even strong passwords, something admins won’t know about. If this credential gets compromised somewhere along the line, the organization will be exposed without realizing it.

These issues are no secret among admins. This is why the security best practice is to apply multi-factor authentication (MFA) to all RDP connections, including RemoteApp.

While MFA for RemoteApp is essential, it is still important to achieve this extra layer of security without adding new layers of complexity elsewhere. UserLock offers a way out of the impasse. It’s specifically designed for organizations that want to continue using their on-premise applications and infrastructure.

Installed on a dedicated server, UserLock integrates with an organization’s existing AD. So there's no need to connect to an external identity provider (IdP). You can use your on-premise Active Directory as the identity provider for secure RemoteApp access with MFA.

The benefits are many. For one, you can keep sensitive infrastructure on-premise, serving RemoteApp from servers under IT control and oversight. This is simpler and more cost-efficient. There are also scenarios where it is more secure. Relying on a third party for applications and data security is always a risk. UserLock removes this uncertainty.

UserLock allows you to implement MFA granularly, so you customize the policies that best fit your team.

You can choose to deploy MFA across AD users, groups, or organizational units (OUs).

Then, you can define policies based on session types including VPN, SSO, and IIS, as well as RDS session types such as RD Gateway and RD Web, and RemoteApp.

You can even differentiate policies for connections coming from inside or outside the network.

In the case of RemoteApp sessions, admins create a protected account for the AD user, group, or OU, setting MFA prompt frequency for this remote connection.

Admins can offer up to two of the following MFA methods: push notifications, authenticator apps, or hardware authentication devices like USB tokens or keys. The only prerequisite is that the MFA desktop agent is installed on an RD Web host server through which the application connection is made.

Once set, each time a user clicks on a RemoteApp application link on their desktop, UserLock prompts them to authenticate using one of these methods.

Since admins can fine-tune when and how MFA prompts appear, UserLock helps avoid MFA fatigue.

With UserLock, admins can also define role-based access control (RBAC) and contextual access management policies to limit access to RemoteApp, before and after authentication. By layering these customized login restrictions with MFA, admins can further ease the burden of security on their end users, while ensuring comprehensive access security.