NTLMV1

• where the member server is acting in the role of the client because the client passes the username & password to the member server and the member server gets a logon token on behalf of the client via impersonation. In this scenario, the client computer’s configuration isn’t involved–just the member server’s.
• where the member server is just part of the authentication chain for the client (see “detailed description of NLTM authentication process” below). This scenario also means that #1 is a problem, i.e. the client LMCompatibilityLevel is incorrectly configured.

If you are using an old Mac device and can't upgrade, the MacOS Safari browser relies on an obscure Mac OS config setting in the nsmb.conf file   http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man5/nsmb.conf.5.html

For step-by-step instructions: Enabling NTLMv2 on Mac OS-X

Internet Explorer(soon to be deprecated) and Chrome (on Windows) rely on the Intranet zone configuration (see Control Panel: Internet Options) to determine what type of authN it uses.

1. If the computer is domain-joined, the best way is to use group policy. And there could be existing group policy
   that sets the LMCompatibilityLevel value. If so, the group policy value will override any value set at the local
   computer. The GPO setting is located at: Computer/Policies/Windows Settings/Local Policies/Security
   Options/Network Security: LAN Manager authentication level.
2. If the computer isn’t domain-joined, there are several ways to configure this setting: via the registry, via the
   local security policy or via a script.

Alternatively, to use the local security policy approach:

1) Use “Start->Run” and type in “gpedit.msc” in the “Run” dialog box.  A “Group Policy” window will open.
2) Click down to “Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings ->
Local Policies -> Security Options. 3) Find the policy “Network Security: LAN Manager authentication level”.
Right click on this policy and choose “Properties”. Choose “Send NTLMv2 response only/refuse LM & NTLM”. 
Click OK and confirm the setting change. 4) Close the “Group Policy” window.

c) Or alternatively, you can manually use the registry:

1) Open regedit.exe

2) Navigate to HKLM\System\CurrentControlSet\control\LSA. Click on LSA

3) If you don’t see LMCompatibilityLevel in the right window pane, then choose: Edit > New > REG_DWORD. Replace
“New Value #1” with “LMCompatibilityLevel”. 4) Double-click on LMCompatibilityLevel in the right window pane.
Enter “5”. (hexadecimal or decimal doesn’t matter)

 NOTE: Upgrade the MacOS VPN client. This means that even if you apply the above workaround,

Enter “about:config”

Locate:

network.negotiate-auth.trusted-uris

 Note: this setting is the successor to the deprecated network.automatic-ntlm-auth.trusted-uris

 http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html is reference material on this configuration file.

If you are mounting a share, you’ll also need to modify the sudo command to explicitly specify the security level.

If your DCs or member servers are Windows Server 2003 R2 or earlier, the only way to identify NTLMv1 use is via
packet captures. If you need to use packet captures, see 
https://learn.microsoft.com/en-us/archive/blogs/askds/purging-old-nt-security-protocols.

For the Ricoh MP 6001, the firmware NIB needs to be at least 8.72. The Ricoh version can be seen on the
configuration page.

 Solution #1: This is caused by problem #1/4/5/6, so apply solutions C/A/B/G as appropriate to all clients.

Solution #2: Reconfigure IIS to “Negotiate” instead of “Negotiate,NTLM”.

Solution #3: https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/authentication-package-listed-as-ntlmv1-security-audit-event describes a scenario (scenario B as labeled in that article)
that may explain this behavior. If this is the case, then fixing the LMCompabilityLevel of the client is needful.
Note that if the clients are non-Windows clients (or really old Windows clients) that the minimum security level
may be an important contributor to the cause/solution. HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0\NtlmMinClientSec is the Windows
location of that setting. Solution H (see above) may address some non-Windows clients.

If someone tries this out, we’d like to know so we know whether it’s a working workaround or just a theoretical one.

 For more reading material on IIS authentication, see:

• http://msdn.microsoft.com/en-us/library/aa292114(v=vs.71).aspx
• https://support.microsoft.com/en-US/help/215383
• https://support.microsoft.com/en-US/help/968867

You’d then tell customers with a browser that is incapable of doing Windows Integrated that the workaround
is to substitute the 2nd FQDN for any instance of the 1st FQDN, and then provide their credentials. This workaround
is tidier than workaround P, in that it doesn’t affect those clients who don’t have a problem.