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

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

On Mon, 2022-01-10 at 09:58 +0000, Rowland Penny via samba
wrote:
> 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.
Samba has been actively removing code to connect over LDAP+SSL (636) as
absent channel binding it is a security problem.  We never got TLS
channel binding working to our satisfaction and TLS certificate
validation is poor within internal networks (often not done at all).

Andrew Bartlett

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions