[Samba] Forcibly disabling connection attempts to port 389?

Peter Eriksson pen at lysator.liu.se
Tue Jan 25 10:36:52 UTC 2022


Yeah, I can see that. Btw the problem has been solved here now - it required a reboot of the firewall cluster in question since the hardware packet accelerators in one of them had suffered a condition Fortigate calls “Session Drift” (where it apparently forgets to clean up/remove running “syn-proxy” stuff, looking at the statistics on the problematic accelerator there where a million or so “drifted” sessions) - the official workaround is to reboot…

  https://docs.fortinet.com/document/fortigate/6.0.0/hardware-acceleration/184147/np6-session-drift

Anyway, I could see a use for some way to blacklist certain AD controllers if they are slow to respond. 

I “solved" it (until we could reboot the firewalls) manually by configuring the local (on the server) firewall to stop Samba from reaching the problematic AD server - which works but requires manual intervention. Which reminds me that I probably should remove that backlisting by now… :-)

- Peter

> On 25 Jan 2022, at 00:01, Andrew Bartlett via samba <samba at lists.samba.org> wrote:
> 
> 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
> 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba




More information about the samba mailing list