LAD over SSL

Question

Hi,

I have installed and configured LDAP over SSL in my AD Server and successfully able to connect using port 636

Shall I need to configure in GPO for Client Computers to access LDAP which is configured over SSL or will connect to that server without any configuration

Kindly advise

Answer 1

Hello @Manish Chawda

Yes, you need to deploy the setting to computers and users through the domain, as both will need to use LDAP signing, you can see all the settings here:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-signing-in-windows-server

Hope this resolves your query,
Best regards,

Answer 2

Hi Manish,

LDAPS is primarily intended to support simple bind requests, so plain text passwords are encrypted when transmitted over the network. To use this functionality the application or service must be specifically written to support LDAPS, as it needs to request a SSL based connection.

LDAP on the cients and servers already supports encryption over port 389 and can be enabled via policy settings. If you are looking to increase the security or encryption of the LDAP traffic, there are a few options available that don't rely on LDAPS.

Check out the following post that talks about how to configure signing and encryption - https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always

Answer 3

Hi @Manish Chawda

Perhaps I can provide some background information which might help.

Windows client that are joined the AD domain, use a combination of LDAP and RPC to communicate with the domain controllers. When Windows clients use LDAP on port 389, they use SASL authentication to authenticate to the domain controller, this covers a number of possible authentication methods, but by default Kerberos is used. When Kerberos is used the user credentials are protected and protected, the access token is transferred. This is used to authenticate the user and confirm their rights. So by default the credentials are protected. However, some of details that are passed backwards and forwards by the LDAP protocol are in clear text, this is typically the LDAP query string and the attributes that are returned. By enabling signing and encryption the connection between the domain controller and the client is encrypted, and the LDAP traffic is transmitted in this tunnel, so the all traffic is encrypted.

Third party devices such as router, firewalls, and other devices, use LDAP on port 389 to authenticate a user against AD to confirm that the user exists and is allow to access a service. Typically these devices don't support the SASL authentication methods and use simple binds, as this is common authentication method supported by all LDAP directories. The simple bind authentication method sends the user name and password in clear text across the network, obviously this a significant security risk. To over come this risk it's common to use SSL to encrypt the traffic to the user's credentials can't be captured. When you install the correct certificate on the certificate on the domain controller, you enable LDAP over SSL (LDAPS). You will need to reconfigure your devices to now use the LDAPS connection on port 636.

By installing the certificate and enabling LDAPS, this doesn't change the existing protection that are already in place for Windows clients as they are using SASL (Kerberos), you can enable additional encryption on the link to hide all traffic (I think is now the default with 2019).

To answer your original question,

I'm not aware of a policy which will force Windows client to change their connection port from 389 to 636 and client will not automatically change to use the 636 and LDAPS. This communication doesn't need to use LDAPS, you can enable additional encryption on the connection to ensure that all the traffic is encrypted.

If you have 3rd party devices or applications that are use LDAP and simple binds to authenticate and authorise user's access to services, then you should change these services to use LDAPS to ensure that the user credentials are not sent in clear text.

I hope that helps, if not, ask away.

Gary.

If this was helpful, please consider accepting this answer.