Short summary
I set up a lab environment with an active directory based on domain functional level 2016 and windows server 2022. I also configured the domain controller (just a single dc) do use LDAPS and reject inbound unsecure LDAP connections. Nevertheless ldap over port 389 still communicates.
More detailed overview
On the domain controller i activated (in the Default Domain Controllers Policy) the following policies
- Domain controller: LDAP server signing requirements to Require signing
- Domain controller: LDAP server channel binding token requirements to Always
On the client side (lets call it server X) (in this case windows server 2022) i configured the following settings in a gpo
- Network security: LDAP client signing requirements to Require signing
CA is installed on another server. The certificate chain is fine and the FQDN of the dc is also configured as SAN. Long story short the root CA is known to the dc and to server X. To sum up, everything should be fine.
That's the output from a ldap test script from server X regarding the available ports on the dc.

I also installed the AD DS tools on server x to validate ldap and ldaps communication to the dc. I performed the following tests in ldp.exe tool from server x
- If i connect to the dc over port 389 (SSL and Connectionless is not checked) and perform a simple bind afterwards i get (as expected) the following error
Server error: 00002028: LdapErr: DSID-0C090254, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4f7c
Error 0x2028 A more secure authentication method is required for this server.
- If i connect to the dc over port 636 (SSL is checked) and perform a bind with credentials afterwards i am authenticated successfully.
Long story short - i configured LDAPS correctly in active directory, but for whatever reason, following szenarios appear, i do not understand.
Problems
- If the MMC (for example Active Directory Users and Computers) is used, the connection is still made via port 389.
- From a third-party application which uses the PowerShell commandlet Get-GPOReport (more details here) the active directory port is configured with 636 but in wireshark you only see connections over port 389. The commandlet Get-GPOReport seems not to have the possibility to specify a parameter using only port ldaps.
Questions
- Did i forget something important to validate concerning the use of LDAPs?
- From my point of view, the usage of ldap or ldaps does not rely on a native configuration in the operating system itself. The application layer is the only layer where you can specify if ldap or ldaps should be used. Is this correct?
- But if the dc is configured to require signing, the connection setup should not behave in such a way that ldaps over port 636 is tried first? And if that fails, ldap will be used?
- Independent from the fact that port 389 is still shown in wireshark, why does it even work? DC was configured to require signing.
- Does each MMC uses port 389?
- Does the Get-GPOReport commandlet only use port 389? I need to push that communication over port 636.
- How does the prioritization even work if ldap or ldaps is used?