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

On Wed, 2022-01-26 at 08:26 -0600, Patrick Goetz via samba
wrote:
> 
> On 1/26/22 08:10, Dr. Thomas Orgis wrote:
> > 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.
> > 
> 
> The reality at my University is that any version of Windows which is
> out 
> of maintenance (e.g. Windows <= 7) is considered insecure and can't
> be 
> open to the public network anyway, so must be segregated. It's a
> rather 
> large university, and we have dozens, maybe even hundreds of systems 
> like this.  Of course most small office environments are NATed and 
> firewalled, so this isn't as much of an issue for them, but your 
> suggestion is still probably best practice, if just from a system's 
> administration perspective.
> 
> 
> > 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
I think the biggest problem will come from 'home' users when Samba
finally removes SMBv1 (this isn't what Andrew is proposing). The
'home'
users will not even consider using SMBv2 or 3, they MUST be able to see
the shares in Network Neighbourhood, nothing else will do.

This isn't helped by the fact that the various gui 'helper' programs
do
not seem to understand that SMBv1 is going away and shouldn't be used
if possible.

Rowland

On 1/26/22 08:41, Rowland Penny via samba wrote:
> On Wed, 2022-01-26 at 08:26 -0600, Patrick Goetz via samba wrote:
>>
>> On 1/26/22 08:10, Dr. Thomas Orgis wrote:
>>> 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.
>>>
>>
>> The reality at my University is that any version of Windows which is
>> out
>> of maintenance (e.g. Windows <= 7) is considered insecure and
can't
>> be
>> open to the public network anyway, so must be segregated. It's a
>> rather
>> large university, and we have dozens, maybe even hundreds of systems
>> like this.  Of course most small office environments are NATed and
>> firewalled, so this isn't as much of an issue for them, but your
>> suggestion is still probably best practice, if just from a system's
>> administration perspective.
>>
>>
>>> 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
> 
> I think the biggest problem will come from 'home' users when Samba
> finally removes SMBv1 (this isn't what Andrew is proposing). The
'home'
> users will not even consider using SMBv2 or 3, they MUST be able to see
> the shares in Network Neighbourhood, nothing else will do.
>
I think Windows 10 doesn't even support SMBv1? If that's correct, how 
does the Network Neighborhood thing work for Windows 10 machines?  I've 
actually been wondering about this for a while; i.e. I'm about to set up 
Samba on my home network just to accommodate Sonos FLAC streaming, but 
am wondering if I'm going to run into this with that hardware.


> This isn't helped by the fact that the various gui 'helper'
programs do
> not seem to understand that SMBv1 is going away and shouldn't be used
> if possible.
> 
> Rowland
> 
> 
>