parallels-awingu

Corel Acquires Awingu to Accelerate Its Secure Remote Workspace Offering. Read more

Microsoft security update disables unsecure LDP logins – how to fix, and why

As announced by Microsoft in a recent Security Guidance advice (ADV190023), two security updates will be released that will enable LDAP (lightweight directory access protocol) channel binding and LDAP signing hardening changes. The first patch (March 2020) adds new audit events and remap GPV that enables this hardening.

More importantly, however is the second patch (H2 2020): when that update is applied, Microsoft Active Directory will reject LDAP simple binds – which will unable you to log in to any service that uses unencrypted LDAP traffic. If you didn’t enable LDAP over SSL in Awingu, you might also face this issue.

Although the patch is still a few months away, it’s already a good idea to enable LDAP over SSL today for numerous reasons, as explained in this blog post – here’s how you can do that, or how you can fix any issues you may have with this patch in just a few clicks.

LDAP vs. LDAPS

What is LDAP?

LDAP (Lightweight Directory Access Protocol) is a protocol via which directory services communicate with each other to send, amongst other things, usernames and passwords, e-mail address, login attempts, etc. So this means that LDAP stores usernames and passwords, and this way applications and services can validate users with that data to give them access.

LDAP and active directory: What is the difference?

It is not to be confused with Active Directory, which is that directory service available on Windows server that support LDAP protocol. To function it requires a Microsoft Domain Controller and it is included in various Windows Operating Systems.

Although Microsoft Active Directory is the industry standard directory service, you may hear people say that they ‘use LDAP’ instead – what they’re actually saying is that they use a different directory that is also using the LDAP protocol.

Unsecure LDAP traffic

LDAP in itself sends its data to the directory service ‘in plain text’. Therefore, it’s safe to say that Microsoft’s reasoning behind introducing these changes is solid: unsecure LDAP traffic contains highly sensitive data that is unencrypted, and thus a sitting duck for attackers and hackers. Or, as Extrahop puts it, “LDAP authentication is not secure on its own. A passive eavesdropper could learn your LDAP password by listening in on traffic in flight.”

What is LDAPs?

There is a version of Lightweight directory access protocol called Secure LDAP, which encrypts the data transfer. It is more often known as ‘LDAPS’ or ‘LDAP over SSL’, just like HTTP over SSL is also called HTTPS. “LDAPS uses its own distinct network port to connect clients and servers,” says ExtraHop, and “the default port for LDAP is port 389, but LDAPS uses port 636 and establishes TLS/SSL upon connecting with a client.” So this way the connection is more secure and protected against data theft.

Microsoft guidance and changes

In ADV190023, “Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing”, Microsoft recently announced the changes will run in 2 steps:

  1. Windows Updates in March 2020 add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers.

  2. A further future monthly update, anticipated for release the second half of calendar year 2020, will enable LDAP signing and channel binding on domain controllers configured with default values for those settings.

Microsoft is moving its deadlines. Nevertheless, it is worth taking this action as soon as possible.

What is the impact of the LDAP change on Awingu?

What is Awingu?

Awingu is a unified workspace that provides users highly secure, controlled and audited access to all your company files and legacy, web and SaaS applications in a browser-based workspace, accessible from any device. System administrators don’t need to install anything on the end-user device, as Awingu runs completely in the browser.

Architecture of Awingu

Awingu leverages on your company’s current architecture and is deployed as a virtual appliance on most hypervisors. This can be a private or public cloud. From there, Awingu will connect into a classic back-end environment. It will link with a directory service (Active Directory), LDAP or an external IdP for user management.

It will connect to application servers running Microsoft RDP for legacy applications or desktops. Web applications (e.g. intranet) can be connected via the “Awingu Reverse Proxy”. Finally, it will connect to classic file systems via WebDAV and CIFS and with cloud storage environments such as Microsoft’s OneDrive.

Built-in capabilities of Awingu

Awingu comes with interesting built-in (security) capabilities. Let’s take a look at some of them

  • MFA included: Enables simple authentication and security when users want to access.

  • Granular usage control: Extra security layer as system administrators can control the rights of users or user groups in a very granular way.

  • Context-awareness: Define geo locations and/or IP addresses as safe zones per user account or user group. Within those safety zones, users can access all applications and file shares.

  • Leverage (external) identity providers (IdP): Already using an external Identity Provider (e.g. Azure AD, Okta, Google Identity)? You can set up a SAML or OpenID Connect connect to this service (full SSO or pre-authentication models are both supported) to leverage all security services offered by the external service.

Awingu & LDAP

If your Awingu domain is configured to go over LDAP, your users will no longer be able to access Awingu directly after the March 2020 patch hits ground. The following error will be shown when users try to log in to their workspace:

It is highly recommended that you prepare your Active Directory to allow LDAPS connection from Awingu, not only to ensure the login possibility for your users but also to add a (low-effort, highly rewarded) security layer on top of your environment. Luckily, fixing this in your Active Directory takes only a few clicks:

  • Make sure that port 636 is open between Awingu and the Active Directory.

  • Install the following role on you Active Directory: Server Manager -> Manage -> Add roles and features -> role-based or feature based installation -> Active Directory Certificate Services. Only the Certification Authority needs to be installed (no reboot required).

  • After installation, You will receive a popup to configure the Certificate services:

  • Select the Certificate Authority role:
  • Select Enterprise CA

  • Select Root CA

  • Select “Create new private key” and leave everything default

  • Finally, click on “configure”

  • Reboot the Active Directory server

After rebooting your Active Directory server, you’ll be happy to find out that enabling LDAP over SSL is an out-of-the-box option in Awingu that has a straightforward ‘on/off switch’:

Enabling SSL over HTTP in Awingu

The above method is used to enable LDAP over SSL with Awingu. However, our Unified Workspace also provides the possibility to enable HTTP over SSL, to encrypt all data transfers from the device to your Awingu appliance and app/file servers. It’s best illustrated with the diagram below:

To make sure the traffic between the user and Awingu is encrypted, you can enable HTTPS following these steps, as outlined by our COO Steven Dewinter in the video below:

About the author
karel
Karel Van Ooteghem

Marketing Manager

  • https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
  •  
Table of contents
Want to learn more about Awingu?
This website uses cookies. Read our transparent cookie policy!