SAMBA, NTLM SSP, and A Gap in Enterprise Configuration Control

  • Article

Recently I had the opportunity to work with a customer on a Samba upgrade that broke connectivity to a Windows 2008 R2 domain.

Background: As reported by the customer, Samba 3.x on their version of Linux was able to connect to any Windows 2008 R2 domain controller, accepting referrals based on IP (\\xxx.yy.zzz) or name (\\<servername>). After upgrading to Samba 4.8.4, referrals by name could authenticate to any DC; referrals by IP address would authenticate only to selected domain controllers - they consistently failed against selected DC's.

Investigation: Network traces showed that referrals against server names were successfully using Kerberos to authenticate to any domain controller. Referrals by IP address were downgrading to NTLM authentication, and failing against selected DC's. In a failing authentication, the connection would attempt to authenticate with the user's credentials, then with NULL account, then fail with return code Status_Not_Supported (0xc00000bb).

Analysis: The results indicated that NTLMv2 authentication could not complete on certain DC's. An evaluation of group policy (gpresult) on each DC showed that the same policies and security settings were being applied to every DC. However, a dump of the registry settings showed differences in configuration between domain controllers. On those DC's where NTLM authentication was failing, the settings for NTLMMinServerSec and NTLMMinClientSec had been set to 0x20080000 (Require 128-bit encryption, Require NTLMv2 session security). On DC's where connections were successful, NTLMMinServerSec and NTLMMinClientSec were set to 0x0

HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0\NTLMMinServerSec
HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0\NTLMMinClientSec

These settings can and should be controlled via group policy, but this was not being done. The associated policies are:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

  • Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers
  • Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients

The TechNet article "Changes in NTLM Authentication" (https://technet.microsoft.com/en-us/library/dd566199(WS.10).aspx) describes "two significant changes in the NTLM authentication protocol in Windows 7 and Windows Server 2008 R2".

First, NTLM-based minimum session security policy is set to require a minimum of 128-bit encryption for both client computers and servers on new installs (upgrading from a previous OS version retains the setting found during the upgrade). All of the domain controllers were built from scratch, so all of them should have been set to require 128-bit encryption. It is likely that someone in the past had downgraded security on selected DC's for compatibility with some legacy application.

Second, Windows Vista and Windows Server 2008 would negotiate NTLM using the computer identity when connecting to earlier versions of Windows. Under Windows 7 and Windows Server 2008 R2, a system service can use either the computer identity or a NULL session. The connections we were seeing from SAMBA would attempt a NULL session and NTLM negotiation would fail. We needed the negotiation to happen using the computer identity, under which both signing and encryption are supported. To configure the servers to successfully negotiate an NTLM connection, we can set the following policy:

  • Network security: Allow Local System to use computer identity for NTLM

(See https://technet.microsoft.com/en-us/library/jj852275(v=ws.11).aspx for a full discussion of potential settings and implications for this policy).

We may have been able to get a successful NTLM connection with the higher security settings by enabling this policy, but the customer opted to eliminate the issue by switching all referrals to use server names.

In addition, the investigaton had exposed a gap in enterprise configuration management on selected DC's that were configured to allow NTLM connections with weak security, which was remediated using the appropriate policies.