Windows 10 1709 and SMBServerNameHardeningLevel
Recently old colleague of mine call me from my previous job. During their testing they found when they went to Windows 10 1709 their configuration baseline tool was unable to scan for compliance on 1709 Windows clients. I worked with him over the weekend to find root cause to the issue and to submit a ticket to the software vendor. Unfortunately they cannot use the workarounds as a permanent fix that our provided below. Due to the fact their customer will not allow the change nor the risk.
Overview
There is a particular issue with Windows 10 1703 (Creators Update) and the application of the Microsoft network server: Server SPN target name validation level Group Policy Object that can negatively impact the ability to navigate network shares, including administrative shares (e.g. IPC$ and ADMIN$).
However, this bug was supposed to be fixed with KB4020102 is installed on the machine running Windows 1703. This has been shown to resolve the issue in certain cases (but not all). During our test we found Windows 1703 would found the GPO settings to run as intended. The issue we run into now is that build 1709 (With the latest patches) still has this issue.
What is SPN ?
A Service Principal Name is a concept from Kerberos. It’s an identifier for a particular service offered by a particular host within an authentication domain. The common form for SPNs is service class/fqdn@REALM (e.g. IMAP/mail.example.com@EXAMPLE.COM). There are also User Principal Names which identify users, in form of user@REALM (or user1/user2@REALM, which identifies a speaks-for relationship).
When a user accesses a service that uses Kerberos for authentication (a “Kerberized” service) they present an encrypted ticket obtained from KDC (in a Windows environment an Active Directory Domain Controller). The ticket is encrypted with the service key. By decrypting the ticket the service proves it possesses the key for the given SPN. Services running on Windows hosts use the key associated with AD computer account, but to be compliant with the Kerberos protocol SPNs must be added to the Active Directory for each kerberized service running on the host — except those built-in SPNs mentioned above. In the Active Directory the SPNs are stored in the servicePrincipalName attribute of the host’s computer object.
More can be found here
https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx
What GPO Setting ?
Microsoft network server: Server SPN target name validation level
From Microsoft
“This policy setting controls the level of validation that a server with shared folders or printers performs on the service principal name (SPN) that is provided by the client device when the client device establishes a session by using the Server Message Block (SMB) protocol. The level of validation can help prevent a class of attacks against SMB services (referred to as SMB relay attacks). This setting affects both SMB1 and SMB2.
Servers that use SMB provide availability to their file systems and other resources, such as printers, to networked client devices. Most servers that use SMB validate user access to resources by using NT Domain authentication (NTLMv1 and NTLMv2) and the Kerberos protocol.”
Windows 10 Policy as of Dec 2017
Accept if provided by client: The SMB server will accept and validate the SPN provided by the SMB client and allow a session to be established if it matches the SMB server’s list of SPN’s. If the SPN does not match, the session request for that SMB client will be denied.
More info can be found here
Why the issue ?
When setting DWORD SmbServerNameHardeningLevel to 1 (Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters)
By default, the SMB server will allow the following list of names and IPs:
- “localhost” as a string in English
- All the variants of IP (IPv4 and IPv6) of your own server or computer
- 127.0.0.1 & ::1
- Host name in NetBIOS format
- Host name in FQDN format
- (Failover Cluster nodes only) Cluster host name in NetBIOS format
- (Failover Cluster nodes only) Cluster host name in FQDN format
All of the above is true for Windows 7. However, in testing we are seeing the 1709 machines Pv4 address and 127.0.0.1 are not trusted.
- If you try to open a CIFS SMB connection using \127.0.0.1 or \IPv4_Address, then you will get an “Access is denied” message asking for credentials.
- If you use \localhost then the connection is successful. Same for the FQDN.
What about previous builds ?
In Windows 1703 this bug was reported and fixed via KB4020102. However, admins are still reporting issues with SMB hardening with 1709.
1703 introduced a new behavior with service host (Svchost.exe)
“Service hosts are split into separate processes on PCs with 3.5 GB+ of RAM: If your PC has 3.5+ GB of memory, you may notice an increased number of processes in Task Manager. While this change may look concerning at first glance, many will be excited to find out the motivation behind this change. As the number of preinstalled services grew, they began to get grouped into processes known as service hosts (svchost.exe’s) with Windows 2000. Note that the recommended RAM for PC’s for this release was 256 MB, while the minimum RAM was 64MB. Because of the dramatic increase in available memory over the years, the memory-saving advantage of service hosts has diminished. Accordingly, ungrouping services on memory-rich (3.5+ GB of RAM) PCs running Windows now offers us the opportunity to do the following:”
More can be found here
Any workarounds ?
Workaround One
Adding “SeTcbPrivilege” to lanmanserver. This worked but required “Act as the Operating System” by default nothing is populated.
- Open regedit
- Navigate to HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer
- Edit RequiredPrivileges and add SeTcbPrivilege
Workaround Two
Add IPv4Address to SrvAllowedServerNames (Mulit-String Value) Adding the IP to SrvAllowedServerNames (Mulit-String Value) worked however would cause management nightmare and doesn’t seem variable solution.
Example
1709 Client IP is 172.28.0.60 you would add that IP to SrvAllowedServerNames String value.
- Open regedit
- Navigate to HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
- Create or Edit Multi-String Value name “SrvAllowedServerNames”
Workaround Three
(Set Microsoft network server: Server SPN target name validation level to “Off”)
- Open Group Policy Management Console
- Create or Edit Group Policy Object
- Under Computer Configuration go to Windows Settings –> Security Settings –> Local Policies –> Security Options
- Edit “Microsoft network server: Server SPN target name validation level”
- Configure it to “off”
References
https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx