This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(22.400000000000002, 43%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EC%3C/text%3E%3C/svg%3E)
Hi,
We already install the certificate, enable LDAP signing and channel bind in AD. How to configure client’s directory service settings point to the LDAPS port (usually 636)?
Thanks
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(28.799999999999997, 57.99999999999999%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBW%3C/text%3E%3C/svg%3E)
The RFC 4511 (the LDAP Standards definition) does not include "LDAPS" on TCP636. The standard defines a process mirroring SMTP in that the STARTTLS command verb is required to secure LDAP traffic via TLS. "LDAPS" over TCP636 is a common usage thing and is not supported in the standard. Thus, Active Directory uses TCP389 and the STARTTLS command verb to sign and secure LDAP traffic. Blocking TCP389 will cause innumerable problems with Active Directoy in both Nortth-South (Client-Server) communications and East-West (server-Server) communications and is not supported in any way, shape or form.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 80%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETB%3C/text%3E%3C/svg%3E)
Hi @Chong •
You can use group policy or registry key:
Fore more information please refer to the following link:
How to set the client LDAP signing requirement by using a domain Group Policy Object
Please don't forget to accept helpful answer
We configured the "Domain controller: LDAP server signing requirements" and "Network security: LDAP client signing requirements" "Require signing" in both Default Domain Controller Policy and Default Domain Policy already, But the client still using 389 port. Any idea?
It's normale behavior, the port 389 will continue used tby client to send a ping LDAP during the Dclocator process in order to identify the closest domain controller and domain join.
Please don't forget to accept helpful answer
@Chong •
So the 389 port cannot block in the network?You should avoid blocking this port 389 because there are certain services which cannot communicate through port 636 and you will have problems such as joining a machine in the domain and dclocator process
Please don't forget to accept helpful asnwer
If the port 389 cannot blocked, that means the LDAP cannot migrate to use LDAPS in AD, and the transmission still running on port 389 which is unencrypted?
@Chong •
At the active directory level, it is not a question of LDAP migration to LDAPs, it is a question of forcing the applications to use only the secure LDAPS protocol except for certain functionalities necessary for Windows such as dclocator and the join in the AD. So Active directory should accept the both awaiting a update from microsoft to these windows functionalities to use LDAPS instead of LDAP
LDAP to LDAP migration is at the LDAP application and client level.
Please don't forget to accept helpful answer