Remote learning and remote teaching are indispensable concepts in higher education around the world. Since the shift to remote working and online learning, the sector is facing more and more cybersecurity challenges. Where before the biggest part of school operations stayed in the school’s environment, there is now an increased use of technology in a remote environment. That means that there are also more potentially vulnerable access points for attackers. But how can you let staff and students securely access a desktop or application without putting the school network at risk?

IT admins of universities and colleges are thus looking for secure remote access solutions in education, as security is one of the primary worries in an increasingly digital world. We’re talking about enormous user groups (dozens of teachers and often thousands of students) that use many different devices to access applications and files with a lot of personal and sensitive data.

In this blog, we will be looking at  the top 4 remote access solutions used in education. Those are Teamviewer, VPN, RDP and secure unified workspaces. Needless to say, all these solutions are valid options to enable remote access in education – but they’re not always equally secure. Nevertheless, it’s important to keep the specific problems you want to solve in mind. Define how you want to enable remote access, and what remote access solution fits your query. That way, it will be clear that some solutions offer more advantages, often in terms of security, than others.

Why have remote access for staff and students?

In their courses, students often have to use very class-specific applications and software, which are installed on computers in university PC rooms. In times where (partially) remote learning is the norm rather than the exception, it is usually not possible to offer this software personally to students, as it is very expensive for the university and/or cannot be installed on any hardware. A way to solve this, could then be to give students remote access to the school computers via their own device (Chromebook, tablet, …) . Depending on what type of access your provide for these forms or remote learning, they can easily access the software – even if it’s legacy software (that needs to be installed on the device) from outside the university or college.

Another often-heard use-case is that of network-restricted third-party services. Educational institutions often have memberships for services like JSTOR that they offer to their students and academic personnel. Often, access to those services is limited to the network of the university or college. If a researcher or student can get access to these services from anywhere, this would greatly benefit the institution’s (and their personal) academic prowess.

However, enabling remote access is not only a necessity for the students. There are also many administrative staff members working in universities and colleges who would like the option of working remotely. For example, they may need access to personnel files or work with accounting applications from home. For those people, universities and colleges should be looking for a secure and simple solution, because this administrative staff often works with personal data of staff and students. There must be absolutely no risk of data loss, so security is very important. Furthermore, the IT team should not be burdened with the fact that these employees want to work at home, so a school should look for a simple solution that requires few support (tickets). Of course, this is also the case for teachers who want to be able to access files and applications they need for lessons remotely.

Remote access solutions in education in 2022

There are many remote access solutions for education on the market. However, some of them are complex to use or to manage, and others pose a risk to the educational organization’s critical cybersecurity. Let’s take a look at the top 4 remote access solutions in education in 2022:

TeamViewer

TeamViewer is a remote control computer software, that allows you to maintain computers and other devices. In an educational context it is sometimes used by IT teams to give remote support to students or teachers when one of those parties is not present at school. With the software, users can share their screens, application window and even an entire remote desktop.

This solution is especially useful to share a remote desktop view between users to collaborate or support. However, it is a less ideal software for teachers and students to connect with lab computers in the school.

Disadvantages of TeamViewer

• It is free for home/personal use, but it cannot be used for free in the commercial settings. Prices are steep: $130/mo for 3 concurrent sessions – at that rate, giving entire classes remote access quickly becomes a costly affair.
• TeamViewer offers built-in MFA, but there is as of yet no way to enforce its use. This is a long outstanding request by the TeamViewer community
• Because integration of AD and MFA are not mandatory, you risk leaked credentials. Students will log in with a username and password, and they’re in. It is unwise to have thousands of credentials shared with users that can access your network, and that don’t necessarily adhere to the privacy protocols you have put up
• In the past years, researchers (and hackers) have discovered multiple 0day exploits in the TeamViewer software, such as CVE-2018-16550 (brute-force vulnerability) and CVE-2020-13699 (allowing malicious websites to launch the host device’s TeamViewer application)
• Depending on your license, you can miss out on mass deployment. If you’re configuring (and maintaining) accounts for the entire school, this can become a very time-consuming effort. Furthermore, users report that its AD integration is cumbersome and requires many steps (it requires an additional software download (the TeamViewer AD connector), API key generation, etc.)
• TeamViewer doesn’t have the ability to use full screen with high-resolution screens
• A student or teacher needs a fast and continuous internet connection if they want to use TeamViewer
• Students and staff are not able to share large files in an easy way
• Every system needs to have a TeamViewer and the same version installed on it to work which is not efficient when students work remotely on an unmanaged device

RDP (Remote Desktop Protocol) is one of the most used technologies for access to server based applications or desktops and to enable remote user access. Unfortunately, using RDP in its simplest forms is a huge security risk. The UK NCSC (National Cyber Security Centre) has identified unprotected RDP to be the #1 reason for ransomware attacks (more on this topic). And these antics take can take place really, really fast…

A “honeypot” experiment from Unit 42 in the summer of 2021 found that 80% (!) of its unprotected RDP setups was hacked within 24 hours. Ouch. And these attacks are not isolated: on average, the honeypot RDP environments are attacked every 11 hours.

Multi-factor authentication

One of the recommendations to protect RDP environment from getting hacked is to add MFA (Multi-Factor Authentication). Note that this is one of but far from the only recommendation.

You‘d think the fact that many businesses are not using MFA on top of the RDP today is because there is a lack of solutions. However, the opposite is true: the number of options in the MFA space are as plenty as there are fish in the ocean. At Awingu, we also provided built-in MFA capabilities as part of the product since day 1.

The purpose of this post is to bring some structure into your options. We’ll add some specific vendor solutions, but keep in mind that there are many players in this domain. Rather than comparing vendors, let’s look into the architecture, the complexity of setup and the cost elements in play. We’re not making any analysis (or judgement) on which MFA token generation is better than other in this blog: e.g. is SMS as a token as secure as a time-based token generated on a phone?, etc.

The high-level options of MFA

On the highest level, MFA can be added on top of RDP by using:

• An MFA vendor/product such as Duo Security, OKTA MFA, … and many more;
• Using an external Identity Provider (IdP) and the MFA services linked to this IdP. Specifically we look at Microsofts Azure AD and the linked Azure MFA service. (more on the setup and requirements);
• Using a VPN (let’s assume with an MFA-based authentication) before enabling access to the RDP service. It would still be best practice to add MFA on top of the RDP service additionally;
• Certificate-based authentication where the certificate sort-of takes the role of the second factor;
• Awingu, a browser based remote access solution that makes RDP-based apps/desktops available in HTML5 (on any browser). Awingu comes built-in with MFA options and enables combinations with (1) third-party MFA products and (2) Identity Providers (IdP).

MFA solutions comparison chart

In this comparison, we have made a distinction between (a) Remote desktop deployments that leverage the RDP client to launch RDP services and (b) deployments with Remote Desktop Gateway. The latter is a web application that enables launching RDP services from the browser and from there opening a config file that will push the locally installed RDP client on the device to open. The benefit of using a Remote Desktop Gateway is that only port 443 (https) is open. Option (a) requires opening port 3389 for external use, which is a no-go from a security point-of-view.

For completeness sake: Awingu does not require the use of RD Gateway. It connects over RDP to RD Session hosts (server of desktop) and then acts as an HTML5 Gateway, making all sessions available in https in the browser (using just port 443). RDP as such is not made available externally. While Awingu replaces the need for RD Gateway, it actually offers tons more.

Comparing the MFA options

Dare to compare… even if it feels a bit like comparing apples with oranges. We’ve tried to come with a perspective on:

• Complexity: the more complex, the more room for failure and the more time-consuming;
• Cost: what are the different elements that need to be purchased or installed (e.g. consuming infrastructure)?;
• Any device access: this could be relevant when you, for example, allow BYOD for your employees, or when you have external users (such as contractors) that access your RDP services;
• Relative Risk Assessment: the most tricky of them all. For one, because the (correctness of the) deployment itself plays a big role. And for two, because there are differences within each category (for which we’re making full abstraction).

MFA solutions comparison chart

How does Awingu fit the MFA list?

Awingu is not an MFA product. If you ask Gartner, Awingu is a Unified Workspace. It aggregates different applications (and desktops and file servers) and makes them available in the browser via its ‘RDP-to-HTML5’ gateway. These can be RDP-based services, but could also be web applications (that leverage the Awingu Reverse Proxy). Having all applications available in a browser is really convenient: there is no local data on the device, and I can work from any device (whatever the formfactor).

Awingu workspace

Next to offering a ‘workspace’, Awingu really adds a lot of ‘Zero Trust‘ security capabilities. Especially on top of typically vulnerable RDP environments, these are very interesting because all security features are part of the same product and they can be activated and managed from the same Awingu management console (via the Awingu System Settings).

Zero Trust features of Awingu

ne of the built-in features is… MFA. Awingu will enable Time-based (TOTP) as well as Counter-Based (HOTP) token generation. And end-users can just install an authenticator App on their phones such as Microsoft Authenticator or Google Authenticator. It is all part of the package. (How to install MFA in Awingu? Easy, take a look at our MFA technical session video.)

If you desire more token options, then Awingu can enable using other systems as well (such as RADIUS based services, or DUO security, or IdP based services such as Azure MFA or IdenProtect.)

Curious to know what the one thing is that all Awingu customers and partners like? Well, it’s the fact that Awingu is so simple to set up and manage. This simplicity is driven by the architecture: a simple virtual appliance that can be installed in your cloud (infrastructure) of choice. The Awingu Virtual Appliance will then act as a gateway and connect using standard protocols to your back-end: RDP, WebDAV, CiFS, …

Architecture of Awingu

This means you don’t need to install (or manage) anything extra in the back-end. And also towards the end-user device there is nothing to install. The only thing they need is a browser (be it on a Chromebook, iPad or Windows device…).

What is the cost of Awingu?

Our recommended end-user pricing is publicly available. The smallest deployment has 20 concurrent users. Other than the user-based Awingu licensing, the only extra cost that applies is one (or more) virtual machines (and RDS CALs, but for the sake of this blog post: all solutions will require RDS CALs).

In this blog post, we are going to focus on RD Gateway (Remote Desktop Gateway). We’ll explain what it is, and how it‘s different from Awingu.”>

What is Remote Desktop Gateway?

Remote Desktop Gateway (RD Gateway in short) is a component of Windows Server and RDS. It is a role that can be activated, in the same way as an RD Session Host or RD license manager. The RD Gateway enables end-users to launch the RDP client from a browser. End-users can browse a launcher webpage (not calling it a “workspace” via their browser; from there, a .rdp file is downloaded to the device where the RDP client will be launched.

RD Gateway is typically set up over port 443 (with SSL) and transports the RDP protocol in HTTPS (opposite to a simple deployment without RD Gateway, where there is no https encapsulation.

The following high-level picture illustrates the principles of the setup:

The biggest benefits of RD Gateway are that port 3389 does not need to be used for external access and that the user is provided a list of applications/desktops he can access. Using the default RDP 3389 port for external access is a magnet for hackers and really easy to breach (password injection, brute force, …). With the use of RD Gateway, a web application is put in front of the vulnerable RDSHs. Port 443 is used and the RDP stream from the RDSH is encapsulated in HTTPS. Web applications are more difficult to breach than old-school 3389 deployments; more difficult, but obviously far from impossible.

Even if users launch their apps/desktops via the browser, running the sessions themselves still requires usage of the RDP client on the device. One of the main downsides is that there is still an end-to-end RDP connection from the endpoint to the RDSH (even if the first leg is encapsulated in https). It means that if the endpoint is compromised, the risk to get the exposure on the backend is very real.

Awingu vs. RD Gateway

Awingu really is a different product than RD Gateway. Our unified workspace offers secure remote access to RDP-based applications or desktops, to file servers, and to web applications. That remote access is offered in the form of a browser-based workspace, where all services are available (translated to HTML5) from within the browser. From there, Awingu offers a rich turnkey solution with a focus on UX and security.

Let’s start with the similarities:

• Awingu has a browser based workspace (so does RD Gateway with its web launcher);
• Awingu is available over port 443 (so does RD Gateway);
• Awingu is installed on a Virtual Machine, typically in the same datacenter as the RDSH back-end (however, Awingu is delivered as a virtual appliance, not a Windows Server role like RD Gateway)

That’s it … so let’s have a look at some of ways how Awingu is different.

• Awingu does not use the RDP protocol as such towards the client. A 100% HTML5 experience is given where RemoteApps (or desktops) are made available fully in the browser. There is no dependence on the RDP client (or other clients for that matter). For avoidance of doubt: Awingu does not use the RD Gateway. It connects directly with the RDSH (using RDP as the a protocol);
• As a workspace aggregator, Awingu can also provide access to file servers (WebDAV or CIFS) and to web applications (via the built-in Awingu Reverse Proxy);
• The Awingu workspace is built with ease-of-use in mind, for the admin, and for the user. It’s supported by capabilities such, as for example:
  • Rich multi-monitor working
  • Session sharing
  • File sharing (similar-ish to wetransfer
  • Virtual printing (a PDF printer engine)
  • …

• As a turnkey security solution, Awingu is built on Zero Trust principles with lots of built-in capabilities:
  • MFA (Multi-Factor Authentication)
  • SSL encryption
  • Granular usage controls
  • Context awareness
  • Usage auditing and anomaly detection
  • Session Recording
  • …
• Rich SSO (Single Sign-On) capabilities – that do not rely on password vaulting – with external Identity providers such as Azure AD, Okta and ForgeRock;

Comparing Apache Guacamole & Awingu

Awingu has a built-in RDP to HTML5 gateway. No wonder that we get compared to Apache Guacamole from time to time. In this blog we’ll have a look at what Guacamole is and how it compares to Awingu.

Apache Guacamole is a client-less remote desktop gateway. It supports standard protocols like VNC, RDP, and SSH. It is client-less in the sense that it delivers apps (or desktops) in HTML5 when Guacamole is installed on the back-end. Apache Guacamole is a free and open-source platform that is maintained by the Apache community.

As a free open-source tool, it got a nice basis of fans; from home-users to businesses to software companies. The latter embed Guacamole in their products (VPN and firewall vendors for example; even if most of them will be secretive about it).

How can they be compared exactly?

Awingu does not rely on Apache Guacamole

For starters, lets be clear about this: Awingu does not use (build on, rely on, …) Apache Guacamole. Awingu uses its own proprietary HTML5 gateway. I frequently hear the false claim that Awingu used Guacamole… and while this is true for a number of competitors in our space, it is certainly not for Awingu.

Awingu is a commercial product

Secondly, Awingu is a commercial product with a commercial organization around it. So this means we have extensive product documentation, technical support, technical trainings, commercial models for channel partners, contractual obligations, etc. That obviously means we sell our product and don’t offer it for free. I guess that’s the first big difference. Who will you call when you have a problem? What happens when there are security vulnerabilities identified? And so on.

This also extends into the organization behind Awingu. We are a very security and compliance focused organization, e.g. we are ISO27001 certified. I need of course to be very cautious as there is no such thing as absolute security: we continuously get pen-tested (by customers, internally and by neutral third parties) and always pass the bar, moreover our roadmap is very security / Zero Trust focused (with capabilities such as MFA, SSL, context awareness, usage audit, …). Apache Guacamole has been hit by a pretty severe vulnerability in July 2020. Since then, 5 other CVEs (Common Vulnerabilities and exposures) have been identified (and fixed!)

Furthermore, it means that we not only have a wide channel ecosystem with trained and certified engineers that covers big parts of the globe; but also that we have a set of tested technology partnerships (e.g. BlackBerry, OpsWat, IdenProtect, …) that extend and  complement the Awingu perimeter.

Differences on technology level

Thirdly, if we take a look at the technology perspective there are also some obvious (and less obvious) differences. Awingu was built with the idea that it should be simple to deploy and work with, for Windows or Linux admins. I think its not a false statement to claim Guacamole has most fans in the Linux and open-source communities.

Now, let’s take a deeper look in the architecture and features (this will not be an exhaustive list, but I try to list the main differences):

Some similarities:

• HTML5 gateway & Protocols supported: Guacamole supports SSH, VNC and RDP. From that list, Awingu supports RDP. However, Awingu also supports WebDAV as well as CiFS and further Awingu’s built-in reverse proxy supports web applications.
• Similar(ish) features for published applications:
  • HMTL5 access (browser-based access)
  • Virtual keyboard
  • Virtual (pdf) printer
  • Session sharing and session recording
  • MFA TOTP built-in, incl. support for RADIUS
• Also similar to Awingu, Guacamole is not built to render highly graphical applications (e.g. 3D rendering), video or run video/voice calls

•  

… and some differences:

• File server access:
  • Awingu includes access to file servers via WebDAV or CIFS via the Awingu ‘files’ section. Files can be opened from Awingu ‘files’ with associated published applications
  • Via Awingu files, one can also ‘share’ files (large or small) similar to the functioning of WeTransfer (with the exception that you don’t need to upload your file(s) into a 3rd party cloud)
• Awingu comes with a built-in Reverse proxy to enable access to (internal) web applications without the need for RDP (nor RDS CALs)
• UX:
  • I’m too biased to judge on the intuitiveness and look and feel of the workspace front-end. I’m not going to comment on it 

 

 

• • Multi-monitor capabilities in Awingu are better developed with multiple options (more on this feature)
• Smartcard support (in-app usage): Awingu can support the use of smartcard (e.g. eID card) within applications (e.g. reading an eID card info) with the support of its RAH (Remote Application Helper). The RAH is the only exception in Awingu’s HTML5 centric story. The RAH is an agent that needs to be installed on the local computer (Windows, MacOS or Linux). Guacamole does not support in-app usage.
• Security & compliance: Awingu also comes with…
  • built-in Context Awareness capabilities (e.g. based on location or IP address as context)
  • built-in usage audit and anomaly detection (which can be hooked-up into a SIEM)
  • Single Sign-On (SSO) capabilities over SAML or OpenID Connect without vaulting passwords in the Awingu appliance. Guacamole does support SSO, but leverages password caching. We believe the Awingu setup is more secure.
  • SSL encryption built-in
• Also, from an architecture perspective there are differences:
  • Awingu is delivered as a virtual appliance, while Guacamole requires installing multiple services (or multiple docker containers which require to be linked). We believe the virtual appliance does not only offer significant benefits in speed of deployment but especially stands out in simplicity.
  • Inside the Guacamole Server, Guacamole will behave different than Awingu as it leverages in an internal translation protocol (RDP Guacamole protocol HTML5) while Awingu does not. This makes Awingu a more resource optimized HTML5 gateway (but obviously, Awingu runs a lot of other services on the same virtual appliance).
  • Awingu can enable HA (High Availability). In a multi-node deployment, Awingu can fail-over between nodes when issues arise.
  • Awingu comes with out-of-the-box multi-tenancy.

Conclusion

So, Guacamole vs. Awingu? A lot of similarities, but even more differences. This blog post is based on our knowledge of Guacamole – which might not be complete, we don’t pretend to be Guacamole experts – and takes a deeper look into those elements that we hear our customers mostly talk about.

Speaking of those Awingu customers, could be interesting to know that they are typically part of these following groups:

• Organizations (public or private) that enable:
  • Work from Home
  • Contractor Access
  • Secure intra-network access
• Cloud/managed service providers that offer their customers a digital workspace
• ISVs (making legacy applications available in the browser, just like SaaS)