As announced by Microsoft in a recent Security Guidance advice (ADV190023), two security updates will be released that will enable LDAP 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 AD 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 versus LDAPS
LDAP (Lightweight Directory Access Protocol) is a protocol via which directory services communicate with each other to send, amongst other things, usernames, passwords, login attempts, etc. It is not to be confused with Active Directory, which is that directory server that makes use of the LDAP protocol. 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.
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.”
There is a version of LDAP 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.”
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:
- 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.
- 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.
Impact on Awingu
If your Awingu domain is configured to go over LDAP, your users will no longer be able to log in 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 AD 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: