samba - Jan 2022 - Remove LanMan auth from the AD DC and possibly file server?

On 1/25/22 21:50, Andrew Bartlett via samba wrote:
> I'm looking to add a mode to Samba without the NT Hash (for normal
> users, NETLOGON is stuck using it for the secure channel).
> 
> In doing that I have to change the codepaths around password hash
> storage, and it would be simpler if I could first remove lanman auth
> (set and check) from the AD DC first.
> 
> It just makes no sense in 2022.
> 
> As a stretch goal, if I or someone else got bored/stuck-in-lockdown or
> such, it might be great to be consistent to remove it from the whole
> server codebase.
> 
> The parameter 'lanman auth' has been deprecated for some time now.
> 
> My feeling is that for the Win9X and OS/2 irrilplacable industrial
> equipment case, that guest authentication would suffice, combined with
> 'force user' and 'hosts allow' for 'security'.
> 
There are 2 competing issues:

  - Instrumentation equipment running old versions of Windows which 
can't be upgraded

  - Maintaining endless backwards compatibility results in unsustainable 
technical debt and terrible, hard to maintain software.

My solution to dealing with old software that must continue to run is to 
containerize it or run it in a VM, but that doesn't generally work for 
instrumentation equipment, a lot of which still uses things like USB 
hardware dongles.  However it should be possible to run older versions 
of Samba in a container?

In any case, however inappropriate it is for me to offer an opinion, 
maybe it's time to branch?  Create a samba4-legacy branch which only 
gets security patches and otherwise never changes, and a samba4 main 
branch from which old junk is ruthlessly stripped without mercy and 
which is updated to work with the endless Windows updates that break 
things in Samba

In this scenario samba4 main would only work with version of Windows >= 
8.1.  If you have an environment with new and old Windows systems you 
would need to run 2 Samba servers, samba4-legacy and samba4.

BTW, I think (based on hearsay) that the way Microsoft maintains 
backwards compatibility with older Office formats is that MS Word, for 
example, contains big blocks of "black box" code that no one
understands
any more, but which are included to allow users to open old .doc 
documents. Never minding the engineering nightmare this is, from 
experience, this doesn't work very well, and more than once I've had to 
harvest text out of a .doc file which was unreadable by the version of 
MS Word installed on the user's machine.

> What do folks think?
> 
> This would be for Samba 4.17.
> 
> Andrew Bartlett
>

Am Wed, 26 Jan 2022 07:55:22 -0600
schrieb Patrick Goetz via samba <samba at lists.samba.org>: 
>   - Instrumentation equipment running old versions of Windows which 
> can't be upgraded
>  However it should be possible to run older versions 
> of Samba in a container?
I think for old appliances without software maintenance, it is
appropriate to segregate them in the network and have an equally
segregated instance of an old version of samba serving them. I'd build
some kind of bridge pulling the data from things like scanners into the
new storage environment automatically, but not having the old devices
dictate how the public service is run.

Heck, you could encapsulate things even by (literally) duct-taping a
single-board computer to the old expensive hardware that presents as
the old-style SMB server to it (using container, VM, or just a custom
build of samba for this) and talk to the newer servers on the outside
in whatever fashion.

But of course, if this is in a customer's network who doesn't even
want to consider changing the config of scanners to use SMTP instead ?
it might not be viable to convince them of such a solution;-)

Not speaking current SMB might be one of the lesser reasons not to have
these things on the network along with other gear ?


Alrighty then,

Thoams

-- 
Dr. Thomas Orgis
HPC @ Universit?t Hamburg

On 1/26/22 6:55 AM, Patrick Goetz via samba wrote:
> 
> In any case, however inappropriate it is for me to offer an opinion, 
> maybe it's time to branch?? Create a samba4-legacy branch which only 
> gets security patches and otherwise never changes, and a samba4 main 
> branch from which old junk is ruthlessly stripped without mercy and 
> which is updated to work with the endless Windows updates that break 
> things in Samba
> 
IMHO, I'd rather move forward with the stripping without mercy, and let 
someone else do the forking if they really need legacy cruft.

-- 
*David Mulder*
Labs Software Engineer, Samba
SUSE
1221 Valley Grove Way
Pleasant Grove, UT 84062
(P)+1 385.666.5660
dmulder at suse.com
  <http://www.suse.com/>