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

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'.

What do folks think?

This would be for Samba 4.17.

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

On 2022-01-26 at 16:50 +1300 Andrew Bartlett via samba sent
off:
> 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'.
> 
> What do folks think?
my gut feeling is that many users will be very unhappy with such a change. I
know many setups where the clients say that ntlm auth is still required for
them and where guest auth would not be an option. Even on AD DCs sometimes. For
sure on member servers.

Best regards
Bj?rn
-- 
SerNet GmbH - Bahnhofsallee 1b - 37081 G?ttingen
phone: +495513700000  mailto:contact at sernet.com
AG G?ttingen: HR-B 2816 - https://www.sernet.com
Manag. Directors Johannes Loxen and Reinhild Jung
data privacy policy https://www.sernet.de/privacy

On 1/26/22 04:50, Andrew Bartlett via samba wrote:
> What do folks think?
Has this something to do with "server min protocol = NT1"?
If the answer is yes...



Normally I would say, go ahead!

However, I have more than one customer with some MFP printers that will 
drop scanned documents onto an SMB share and refuse to work with recent 
security standards.
As much as I'd like to see these legacy wagons go away, that's not going
to happen any time soon.

Normally I'd just drop SMB completely and configure SMTP instead, but 
this isn't always possible or desired by the customer.



If answer is no, please ignore the noise.

  bye & Thanks
	av.

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
>

On 1/26/22 04:50, Andrew Bartlett via samba wrote:
> What do folks think?
I would vote for removing it and if people still require it to work with 
old shit they can just continue using the latest Samba version that 
supports it.

Cheers!
-slow
-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20220207/7984ff85/OpenPGP_signature.sig>