How To Use The LDAP Over SSL In Active Directory
In addition to the option of working with signatures for access in Active Directory to achieve a higher level of security, data traffic in the network can also be secured via SSL. This prevents attackers from gaining administrator privileges in Active Directory.
There are various ways to secure the data traffic in Active Directory. By default, network traffic between clients and domain controllers is hardly protected by LDAP and is also not encrypted. This is because conventional LDAP connections to port 389 are not encrypted. This can result in attackers using man-in-the-middle attacks being able to eavesdrop on the data traffic and thereby hijack permissions in Active Directory.
This can initially be prevented by activating the LDAP signature and LDAP channel binding. If you want to ensure even more security reliably, you also activate LDAP over SSL (LDAPS) for domain controllers to encrypt the data traffic between clients and domain controllers. This protects data traffic in Active Directory in a similar way to HTTPS on websites. By default, LDAP uses port 389 for communication. After switching to data traffic over SSL, port 636 is used.
Table of Contents
Test LDAPS Connections
Before installing and setting up LDAPS, the “ldp.exe” tool can be used on domain controllers to check which type of LDAP connections are activated. In “Connection\Connect”, first enter the name of the domain controller, select port 389, and then click on Connection. This shows whether the domain controller also accepts unsecured connections.
To test SSL connections, port 636 is used and the “SSL” option is activated. Here you can see whether SSL connections are allowed. These should be used actively for the connection in the future. When activating LDAPS, i.e. LDAP over SSL, the port for the global catalog in Active Directory is also activated on 3269. Without SSL, port 3268 is used.
Use Certificates In Active Directory
To secure Active Directory with LDAPS, certificates are first required for the domain controllers and computers in the network. Access to Active Directory is then secured using SSL certificates. The configuration of SSL for LDAP takes place on the command line and the PowerShell. There is no graphical user interface available.
The certificates can come from a certification authority that is installed in Active Directory, or a SSL Certificate from outside is used. Self-signed certificates, without a certification authority, should not be used in productive networks, since the data traffic does not always work stably here, because the authentication of the certificates can cause problems. Active Directory Certificate Services are certainly the most suitable, but if possible they should not be installed directly on a domain controller, but on a member server.
By installing the Active directory certificate services, all computers in the Active Directory automatically receive a certificate via group policy. This may take several minutes. With the command “gpupdate/force” on the domain controller or a restart, the process can be accelerated. You can check whether the server has received a certificate in the administration of the certificates. The quickest way to do this is with the “certlm.msc” tool. The issued certificates can be seen under “Own certificates\Certificates”.
As soon as the domain controller has received its certificate, access via SSL should already work as described above. If the connection is not yet working, the server must be restarted. After that, the connection with SSL should work. For such a connection, each domain controller needs its certificate, which it automatically receives when using the Active directory certificate services. If another certificate provider is used, the certificate must be suitable for LDAPS.
Use LDAPS Together With LDAP Signature And LDAP Channel
Ideally, LDAPS should be used together with the LDAP signature and the LDAP channel binding. We describe this configuration in separate posts (see links at the end of this post). By activating the LDAP signature, requests to the domain controllers can no longer be falsified. This prevents man-in-the-middle attacks. If SSL is set for access in parallel, the data can no longer be read by unauthorized persons.
If connections are signed consistently and encrypted at the same time, you can achieve maximum security. Activating the signature is an important basis for preventing man-in-the-middle attacks. Devices that establish an LDAP connection to domain controllers should at least use this function, it is better to use LDAPS in parallel.
LDAPS With Windows And Linux
If devices use LDAP, the connection to LDAPS should be activated on them. Most Linux distributions that connect to a domain controller using LDAP also support LDAPS. In this case, the certification authority must be configured as trustworthy in Linux. On Windows computers that are members of the same Active Directory forest, the certificate of the certification authority from the Active Directory certificate services is automatically integrated with group policies.
Also Read: DevOps Should Focus More On Security
- Mastering Algorithmic Trading Without Coding Skills - November 10, 2023
- 8 Tips for Procuring Technology for Your Business - August 15, 2023
- 5 Financial Best Practices To Follow When Starting A Business - July 6, 2023
