Optional Windows NTLM SSO authentication changes

Microsoft is releasing an optional security enhancement to NT LAN Manager (NTLM), limiting which network resources various clients in the Windows 10 or the Windows Server 2016 operating systems can use NTLM Single Sign On(SSO) as an authentication method. When you deploy the new security enhancement with a Network Isolation Policy defining your organization's resources, attackers can no longer redirect a user to a malicious resource outside your organization to obtain the NTLM authentication messages. This new behavior is optional, and requires customers who wish to enable it to opt in via a Windows Registry Setting or other means described below.

Customers should be aware that enabling this new behavior will prevent NTLM SSO authentication with resources that are not marked as internal by the Windows Firewall. This may break some functionality by preventing NTLM SSO authentication to resources marked external, though other authentication methods will remain available. Examples where NTLM SSO authentication appear would be Internet Explorer or Edge, or a service calling WinHTTP to access a web resource; a user trying to connect to an SMB file share; or processes making RPC calls. Microsoft is releasing this new functionality as a mitigation to NTLM dictionary attacks. Microsoft continues to recommend that customers move to public key authentication methods for applications which do not support modern authentication, and use negotiate with Kerberos authentication whenever possible.

The new functionality works by denying NTLM SSO authentication as a method for public resources. This is achieved when the NTLM client leverages the Windows Firewall’s ability to determine if a resource is a Public, Private, or Enterprise resource as defined by the customer-configured Windows Information Protection settings. Depending on this determination, the connection will either be allowed or denied.

FAQ

1. Which registry setting should I set to enable this behavior?

Customers can add a DWORD32 key named “EnterpriseAccountSSO” to the Windows Registry location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0 with the following options:

• 2 – Always allow SSO. (This is the default state.)
• 1 – Deny SSO if the resource is public. Allow if the resource is private or enterprise. Allow SSO if the resource is unspecified.
• 0 – Deny SSO if the resource is public. Allow if the resource is private or enterprise. Deny SSO if the resource is unspecified.

2. Is any other configuration necessary for this new behavior?

Yes. Customers need to configure a Network Isolation Policy(NIP) that defines which networks should be considered internal/enterprise and thus will permit NTLM as an SSO Authentication method. A correctly configured NIP is critical for NTLM SSO to continue to function.

3. Which operating systems are vulnerable to this type of attack?

All versions of Windows that use NTLM are susceptible to this type of attack. Microsoft is releasing this new behavior only on the Windows 10 and Server 2016 platforms due to limitations in the older versions of the Windows Firewall, which preclude older operating systems from using this new behavior. Microsoft recommends customers upgrade to the newest, and most secure offerings.

4. Where can I find more information about Windows Information Protection?

• For general information, see Introducing Windows Information Protection
• For configuration deatils, please see the "Choose where apps can access enterprise data" section of: Create and deploy a Windows Information Protection (WIP) policy using System Center Configuration Manager

5. Where can I find details about enabling this functionality through Group Policy?

See [https://docs.microsoft.com/en-us/windows/access-protection/windows-firewall/isolating-apps-on-your-network#step-1-define-your-network](See https://docs.microsoft.com/en-us/windows/access-protection/windows-firewall/isolating-apps-on-your-network#step-1-define-your-network)

6. Are there other ways to opt-in to this new behavior?

Yes. Both the Group Policy network isolation settings and Windows Information Protection cover the same area, both for Apps and for NTLM SSO Authentication. Using either is equally effective at mitigating NTLM SSO hash theft, but customers should select between these options. Mixing various means could create unexpected behavior.

7. Is a reboot required to enable this new behavior?

A reboot will be required to install the security update. When you then enable this new behavior with a Windows Registry change, the new behavior will be immediately take effect and not require a reboot. The changes to the Windows Firewall will have a varied delay depending on whether WIP or GP was used, and when this configuration is refreshed.

8. My enterprise has enabled this behavior, and now users are being prompted for credentials where they previously were not. Why is this happening?

This is an indication that the resource is marked as public or that its designation is uncertain, if the strictest mode has been enabled. This is most likely a symptom of the resource being inaccurately represented in your enterprise’s NIP, or you have configured 0 and the application is not using SMB, RPC, or HTTP.

To check whether a resource is public, please enable the “Network Isolation Operational” logs under Windows Firewall with Advanced Security in Event Viewer. For the purposes of the log, enterprise resources are considered private. Please note that Network Isolation policies from Group Policy and WIP settings only affect networks whose profile is “Domain”. For more information about network profiles, please see: Understanding Firewall Profiles.