NTLM authentication problem

[Jonathan Leslie]

On a small domain I manage I enacted a GP that disabled NTLM authentication. Since then I've disabled the policy to revert things back to the way they were, but now I'm still having a problem with non-domain computers and printers being unable to either map to domain shares or RDP to domain systems.

When I try to RDP from the non-joined systems I get an error that says it's either a problem with NTLM authentication or with (and I can't recall this exactly) CredSSP or something like that.

I can't find any event log errors on the domain system to which I'm attempting to RDP nor on the non-joined system.

What should I be looking for?

Jonathan

[Kurt Buff]

When you turn off NTLM, you force use of kerberos. 

My first guess is that a non-domain-joined machine can't participate, and my second guess is that there's no certificate on that machine that would be recognized by the DC.

Or both.

Kurt

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/50df1060-acbb-440c-a178-8b4c327902fan%40googlegroups.com.

[HDSupport (Free)]

Hi Jonathan,

Not sure if the below link gives some light to your issue!

community.spiceworks.com

RDP Fails from Domain to Non-Domain computer w/ Authentication Error

Trying to connect from a Domain Computer to a Non-Domain computer with RDP. The error is: An Authentication error has occurred. The function requested is not supported. This could be due to ScredSSP encryption oracle re…

🔗 https://community.spiceworks.com/t/rdp-fails-from-domain-to-non-domain-computer-w-authentication-error/833113

 
Kind regards
Sutha

[Aakash Shah]

Instead of simply disabling the GP to revert back to the enabling NTLM, change the GP to explicitly allow NTLM since in some cases disabling the GP doesn’t revert the computer back to the original configuration and an explicit configuration change is needed.

 

Also consider enabling NTLM auditing to help identify what NTLM usage is being observed (3 settings under gpedit.msc | Windows Settings | Local Policies | Security Options | Network security: Restrict NTLM: Audit* and “Outgoing NTLM traffic to remote servers”).

 

Something I’ve used when troubleshooting with Protected Users (this also disables NTLM along with other weak ciphers and enforces Kerberos) is to enable the logs under Applications and Services Logs | Microsoft | Windows | Authentication. I don’t know if these are populated when Protected Users are not used though.

 

Note that non domain joined clients can often connect but the UPN needs to be used instead of just netbiosdomain\username.

 

-Aakash Shah

--

[Eric Pagan]

I can confirm simply disabling the policy doesn’t revert settings for all machines and NTLM needs to be set to allowed again. I ran into that a while back..

 

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Aakash Shah
Sent: Thursday, November 13, 2025 2:27 AM
To: ntsys...@googlegroups.com
Subject: RE: [ntsysadmin] NTLM authentication problem

 

This message was sent by someone outside of The Citizens Bank. Please be cautious when opening attachments or clicking links.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/IA2P221MB1453A46E34CFD3655FCC3AB3F2CDA%40IA2P221MB1453.NAMP221.PROD.OUTLOOK.COM.

DISCLAIMER: This message is intended only for specified recipients. If you are not the intended recipient you are notified that disclosing, copying, distributing, or taking any action in reliance on the contents of this information is strictly prohibited. This communication represents the originator's personal views, which may not reflect those of The Citizens Bank. Security Warning: This message is being sent over an unsecured medium (the Internet). Recipients should not reply to this message with sensitive or confidential account information. If the need arises to communicate sensitive or confidential account information, customers should visit or contact the nearest branch office. If you received this email in error, please immediately notify postm...@tcbsc.bank.

[Philip Elder]

Change RDP over to Kerberos. Do you have the instructions for doing so?

 

I’m in the process of working on building some knowledge as that’s on the To Do List for all managed properties. So, my references are pretty bare at the moment.

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

MPECS Inc.

E-mail: Phili...@mpecsinc.ca

Phone: +1 (780) 458-2028

Web: www.mpecsinc.com

Blog: blog.mpecsinc.com

Twitter: Twitter.com/MPECSInc

Teams: Phili...@MPECSInc.Cloud

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Jonathan Leslie
Sent: Wednesday, November 12, 2025 19:54
To: ntsysadmin <ntsys...@googlegroups.com>
Subject: [ntsysadmin] NTLM authentication problem

 

On a small domain I manage I enacted a GP that disabled NTLM authentication. Since then I've disabled the policy to revert things back to the way they were, but now I'm still having a problem with non-domain computers and printers being unable to either map to domain shares or RDP to domain systems.

--

[Jonathan Leslie]

Thanks for the help everyone, much appreciated. Philip, I had no idea Kerberos could be used for RDP so no,I don't know how to do so.

[Mike]

Use the FQDN of the host (server.domain.tld) and the full UPN of the account (user...@domain.tld). You may be pleasantly surprised to find that it just works. Yes, even from non-domain joined machines.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/07e7483f-bec6-46fa-bf6f-b8587f3e8ff3n%40googlegroups.com.

[Philip Elder]

I’m working on that but the caveat is that I’ve not found a Microsoft property that outlines _how_ to get it set up. ☹

 

I’ve just been told to do it by security folks.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/07e7483f-bec6-46fa-bf6f-b8587f3e8ff3n%40googlegroups.com.

[Jonathan Leslie]

Okay the policy "Network security:Restrict NTLM: Incoming NTLM traffic" I changed to Allow all, the policy "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" I changed to Audit all. The policy "Network security: LAN Manager authentication level" has been set for a long time to Send NTLMv2 response only. Refuse LM & NTLM.

But over 12 hours later (and this is plenty long enough for policy changes to be read) I still can't connect to domain servers from a non-domain PC nor can I scan to network folders from a networked printer. 

And on the DCs I'm still seeing warning events of 4002:

NTLM server blocked incoming NTLM traffic to servers that is blocked,

NTLM authentication requests to this server have been blocked.

If you want this server to allow NTLM authentication, set the security policy Network Security: Restrict NTLM: Incoming NTLM Traffic to Allow All.

Before I first changed GP to block all NTLM (NTLMv2 has been the only type allowed for quite some time) I was able to RDP to domain shares from a non-domain PC and scan to network folder worked fine.

Jonathan

[James Iversen]

have you rebooted your domain controllers after making the change back? Because it has to do with an encryption setting, the course of action may require reboot for new “allow all” setting to be recognized. 

Sent from my iPhone

On Nov 14, 2025, at 6:34 AM, Jonathan Leslie <jples...@gmail.com> wrote:

Okay the policy "Network security:Restrict NTLM: Incoming NTLM traffic" I changed to Allow all, the policy "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" I changed to Audit all. The policy "Network security: LAN Manager authentication level" has been set for a long time to Send NTLMv2 response only. Refuse LM & NTLM.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/33bd4233-44d4-43ed-aa83-0bac0cb9e416n%40googlegroups.com.

[Eric Pagan]

Jump into the registry on the affected member servers / DCs. You may need to toggle the setting manually for them to pay attention to GPO again.

 

HKLM\System\CurrentControlSet\Control\Lsa\MSV1_0\

 

Dword: RestrictReceivingNTLMTraffic

 

0 allows all

 

Dword: restrictsendingntlmtraffic

 

1 sets audit all

 

I suggest verifying this before implementing, but this should be what you’re looking for.

 

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of James Iversen
Sent: Friday, November 14, 2025 7:19 AM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] NTLM authentication problem

 

This message was sent by someone outside of The Citizens Bank. Please be cautious when opening attachments or clicking links.

have you rebooted your domain controllers after making the change back? Because it has to do with an encryption setting, the course of action may require reboot for new “allow all” setting to be recognized. 

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/E37ECEE9-DF72-4D2C-A02D-397C372F769F%40gmail.com.

[Kurt Buff]

When you restrict the domain from using NTLM, kerberos is the alternative.

non-domain-joined machines do not know anything about kerberos, therefore RDP sessions from those machines to a domain-joined machine will fail.

I seem to recall that exceptions can be made for machines that need to use NTLM, so your best alternative might be to search for that and see if it helps.

Kurt

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/33bd4233-44d4-43ed-aa83-0bac0cb9e416n%40googlegroups.com.

[Philip Elder]

There must be something else going on there.

 

Every client we manage, along with our own company, has mostly workgroup Windows machines connecting to their RD Farms. None have an issue.

 

So, change everything back to the original defaults before any changes were made.

 

Move over to a lab setup with your DC and RD servers recovered and stand up a couple of VMs to use as client machines. You can either leave them all in a Private network or set up WANEm and a central DNS server to mimic remote connectivity. Use Untangle, a free trial of SonicWALL NSv, or RRAS in Windows Server 2008 R2 as your firewall (two vNICs LAN and WAN).

 

It’s important to figure out where in the chain the link is getting broken and that ain’t on production.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/33bd4233-44d4-43ed-aa83-0bac0cb9e416n%40googlegroups.com.

[Jonathan Leslie]

Further testing has shown me that I can connect just fine via RDP to some of the domain servers (DC and member) but not others. One that I can connect to is the file server which the printer was unable to connect to for scans until I changed the one registry value from 2 to 1. However, on 2 of the other servers which I can't connect to, I had changed their registry value from 2 to 1 so that registry entry value seems to affect just file share access but not RDP. And why I can RDP to some servers but not others is even more puzzling to me.

Jonathan

[Jonathan Leslie]

Eric,

I checked the Dword in the registry of the member server to which I'm attempting to again RDP (like I used to) and its value was 2 which is deny all. I changed it to 1 which is Audit and rebooted it. I still could not RDP and got the same error message on the non-domain joined computer. I re-checked the value on the member server and it is still 1 as I set it.

I then checked the value on the file server which the printer would no longer connect to for scans. It was also 2. I changed it to 1 and without rebooting I was now able to connect from the printer.

So apparently all domain systems had this value changed to 2 but it won't change back to 1 via GP and I don't know why. Nor do I still know why RDP won't work though file share access does after changing the value from 2 to 1 on that Dword.

Kurt,

If nothing else helps, I'll look into adding an exception, thanks.

Jonathan

On Friday, November 14, 2025 at 7:54:53 AM UTC-6 Kurt Buff wrote:

[Jonathan Leslie]

I hadn't thought of that, thanks, doing it now.

Jonathan

[Eric Pagan]

Check your domain controller registry settings too if you haven’t already. In our case, making a GPO change on one didn’t replicate to the others.

 

 

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Jonathan Leslie
Sent: Friday, November 14, 2025 8:18 AM
To: ntsysadmin <ntsys...@googlegroups.com>
Subject: Re: [ntsysadmin] NTLM authentication problem

 

This message was sent by someone outside of The Citizens Bank. Please be cautious when opening attachments or clicking links.

I hadn't thought of that, thanks, doing it now.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/9ca5844f-e1aa-479c-92e2-3e8f635c61d0n%40googlegroups.com.

[Philip Elder]

As a side-note, I believe that this situation is aptly called a “Group Policy Tattoo” of the settings into the OS.

 

There are plenty of them. Ask me how I know! 😉

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

MPECS Inc.

E-mail: Phili...@mpecsinc.ca

Phone: +1 (780) 458-2028

Web: www.mpecsinc.com

Blog: blog.mpecsinc.com

Twitter: Twitter.com/MPECSInc

Teams: Phili...@MPECSInc.Cloud

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

 

From: 'Eric Pagan' via ntsysadmin <ntsys...@googlegroups.com>
Sent: Friday, November 14, 2025 14:39
To: ntsys...@googlegroups.com
Subject: RE: [ntsysadmin] NTLM authentication problem

 

Check your domain controller registry settings too if you haven’t already. In our case, making a GPO change on one didn’t replicate to the others.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DM4PR12MB76930C4EEA6682F121E80F91ABCAA%40DM4PR12MB7693.namprd12.prod.outlook.com.

[Jonathan Leslie]

Y'all,

While I don't yet have details of just how this has happened nor how to revert the situation, I do now have a method for getting past the problem.

A few exchanges back, Mike suggested using the FQDN and UPN to RDP from the non-domain system to a domain server. So I did some testing and this is what I found. If I change just the login credentials to the UPN then I connect and login without any problem. I really don't understand  how this change makes a difference, I'm just glad it does.

Jonathan

[Mike]

Glad it worked. Try using the UPN and FQDN (\\fileserver.domain.tld\sharename) for your non-domain machines that need to connect to file shares and see how that goes.

As for the printer/scanners, you can try the UPN/FQDN combos but it’s possible they just don’t support Kerberos. We are going through something similar with moving scanners from Basic Auth SMTP to OAuth SMTP in Exchange Online. Some of them need firmware updates to gain that support but some may just never support it.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/7be40bf4-07b5-4dff-9263-c840b964ffben%40googlegroups.com.