Scan to folder - NTLM - Connection Error

[Koldov]

Anybody full on DENY NTLM throughout their Domain....?

 

I can't really tell if it's just that Server 2019 is suddenly more secure (which is probably obvious) or it is suddenly taking notice of GPOs that the previous 2012R2 DC wasn't.

 

I haven't changed any settings or GPOs, but suddenly things aren't working...

 

Scan to folder has died... after a LOT of investigation I have ruled out SMBv1 and can see it is using SMBv2, then settled on NTLM being the problem (which I already thought I was blocking through GPO - but now it appears I actually am and the MFD doesn't like it).

 

We have a Kyocera Model : TASKalfa 5052ci and have a 2012R2 file server which it has happily scanned to for years.

 

Now I have introduced a SERVER 2019 DC (no change in GPOs) it is suddenly not connecting.

 

I have checked on the DC and changed a GPO:

 

Network security: Restrict NTLM: Audit NTLM authentication in this domain to 'Disable' and it works - however previously it had been set to 'Deny All'... but scanning still worked... now with the 2019 DC it actually seems to be taking notice of it and denying the NTLM request from the MFD (I have also tried adding the file server as an NTLM exception - maybe it should be the DC... but I don't want that)!

 

As I have never had 'member servers' (only DCs) What I can't seem to get my head around is how do I allow the NTLM to hit the 2012R2 File Server (is it the DC that is denying the scanner to log-on)....?

 

Basically I'm just really confused why it suddenly stopped working as I thought I was already denying NTLM (but I guess I can't have been)...

[psydii]

I can confirm that setting it to deny breaks pretty much everything that isn't a domain joined windows PC, and even those stop working properly. Even things I was convinced were already using Kerberos properly broke when I tried it "just to see what would happen". - (Got to love the school holidays when on occasional days its just you, a receptionist watching netflix and the premises team)

 

I doubt what ever settings you may had were actually denying it before, even if you had it configured to. Perhaps 2019 honours some setting that it previously ignored.

 

Microsoft's most recent blog on the matter (2009 but occasionally updated) advises that disabling NTLM is currently a resume generating event. https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/ntlm-blocking-and-you-application-analysis-and-auditing/ba-p/397191

 

However a colleague of the author at Microsoft just release a PowerPoint deck on removing NTLM completely, which further illustrated the challenges

Edited August 6, 2022 by psydii

[Koldov]

Strange... I had somehow got it into my head a while ago that it was MS 'security' best practise and 'recommended' thing to disable NTLM...

 

I think there is a regular waring that comes up in my server event log saying so.

 

Now I have completely trashed my server by poking it with a big stick trying to get it to do something I didn't even need to!

[psydii]

So disabling NTLM used to be a recommendation. But these days its is gone and we're all probably really talking about NTLMv2, which also really should be disabled, but *always* breaks something when you do. Apparently with a lot of effort you can selectively allow systems and services that need it... however based on my experience poking a network built in 2014 you have to make so many exceptions, that you shouldn't have bothered.

 

You might of course choose to design from the ground up with the principle that NTMLv2 is disabled by default and refuse to implement anything that requires you to compromise. Not sure how far you'd get though.