samba - Jan 2022 - Forcibly disabling connection attempts to port 389?

We recently discovered an annoying problem where it seems that Samba often first
attempts to connect to LDAP port 389 before switching to port 636 (SSL-LDAP)
when talking to AD servers. This is normally not a big issue since the AD server
has the port blocked/disabled. However we currently have an issue with a
FortiGate firewall that for some unknown reason decided to start running a
?SYN-proxy? on that port for one of the AD servers?

This has the effect of causing clients that try to connect to port 389/tcp on
that AD server to ?see? an accepted TCP session until it times out a number of
seconds/minutes later instead of a quick reject. This causes Samba to regularly
take a long time to accept user authentications if it happens to choose to bind
to that server.

For the moment I've ?fixed? that by adding machine-local firewall rules that
block outgoing TCP connection attempts to that specific AD server, but I was
wondering if there perhaps could be some better way to solve this - like having
some option in Samba to forcibly stop attempting to connect to port 389 and just
use 636 (ssl-ldap)? Or switch it so it first attempts 636 and then if that fails
falls back to 636?

- Peter

On Mon, 2022-01-10 at 10:24 +0100, Peter Eriksson via samba
wrote:
> We recently discovered an annoying problem where it seems that Samba
> often first attempts to connect to LDAP port 389 before switching to
> port 636 (SSL-LDAP) when talking to AD servers.
1) that is the way AD works
2) do not use ldaps, use kerberos instead, it is a lot more secure.
>  This is normally not a big issue since the AD server has the port
> blocked/disabled.
I suggest you unblock it, you need it.
>  However we currently have an issue with a FortiGate firewall that
> for some unknown reason decided to start running a ?SYN-proxy? on
> that port for one of the AD servers?
> 
> This has the effect of causing clients that try to connect to port
> 389/tcp on that AD server to ?see? an accepted TCP session until it
> times out a number of seconds/minutes later instead of a quick
> reject. This causes Samba to regularly take a long time to accept
> user authentications if it happens to choose to bind to that server.
See, I said you need it.
> 
> For the moment I've ?fixed? that by adding machine-local firewall
> rules that block outgoing TCP connection attempts to that specific AD
> server, but I was wondering if there perhaps could be some better way
> to solve this - like having some option in Samba to forcibly stop
> attempting to connect to port 389 and just use 636 (ssl-ldap)? Or
> switch it so it first attempts 636 and then if that fails falls back
> to 636?
That isn't how AD works, it starts with '389' and escalates from
there.

Rowland