SMBv1 no longer installed with latest Microsoft Windows 10 and 2016 update (version 1709)

Contents

1. Introduction
2. Resolution
3. Use Cases
4. References

Introduction

Microsoft recently announced¹ that they will not install SMBv1 by default with the next Redstone 3 (version 1709) update for Windows 10 and Windows 2016. While Windows 2012 R2 still ships SMBv1, Microsoft recommends to disable it as it is becoming increasingly targeted with vulnerabilities and man in the middle attacks. The security configuration baseline settings for Windows 10 Redstone 2 also recommends to disable SMBv1. The update release is expected to ship in fall 2017.

Server Message Block version 1 (SMBv1) is a 30-year-old network-oriented protocol used in Windows and Active Directory implementations and Microsoft customers have been advised² for a long time already to upgrade to a newer version,
either SMBv2 or SMBv3.

While this change will not have a major impact for Microsoft customers, it does have an impact for Red Hat customers operating their systems in a mixed environment. Red Hat Enterprise Linux has both server and client support for the SMBv1 protocol. The support is provided by various Samba versions, for both client and server, and by the kernel module cifs.ko (client). Red Hat Enterprise Linux 7.2, which includes samba-4.2, and later comes with proper support for SMBv2 protocol, but earlier releases of Red Hat Enterprise Linux only support SMBv1. With Red Hat Enterprise Linux 6 already in Maintenance Support 2 Phase and Red Hat Enterprise Linux 5 in Extended Life Phase only, new features, such as the SMBv2/v3 protocol, can not be included. Additionally, Red Hat's ABI stability policy means it is not feasible to backport the current Samba features as well as Linux kernel cifs.ko module.

Resolution

Red Hat recommends to upgrade to the following versions, at a minimum, to utilize the SMBv2 protocol.

• Red Hat Enterprise Linux 7.2
• samba-4.2

It is recommended to upgrade to the most current Red Hat Enterprise Linux release to leverage all the new features and security enhancements. Red Hat offers an inplace upgrade from RHEL 6 to RHEL 7; for details, see How do I upgrade from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7 KBase in the Red Hat Customer Portal.

If an upgrade is not an option at this point in time, then customers are advised to delay the installation of the 1709 update until plans to move to RHEL 7 plans are feasible.

Use Cases

The following use-cases will no longer work on RHEL-6.x and RHEL-7.0/RHEL-7.1 systems:

Linux as file sharing client

Linux clients will no longer be able to access shares on a Microsoft server when SMBv1 has been removed or disabled.

Linux as file sharing server

Windows clients with SMBv1 removed or disabled will no longer be able to access shares provided by a Linux Samba server over SMBv1 protocol. The samba4 package on RHEL6 provides experimental support for SMB2 protocol, but Red Hat does not support the file-server use-case with samba4. This package is only supported in Identity-Management (IdM) environments where a trust exists between a Windows AD forest and a Linux IdM server.

Enrollment of Linux clients into Windows Active Directory domains using SMB protocol

To enroll a Linux client into a Windows Active-Directory domain, use either the net or the adcli utility. The net utility uses the SMB protocol for the machine enrollment, which does not work in environments where SMBv1 has been removed or disabled. To resolve this issue, users can request a Kerberos ticket, using kinit, and then tell the net utility to perform the authentication using Kerberos credentials, with net -k rather than using the SMB protocol for authentication purposes.

Another option would be to use the adcli utility which is also available as part of Red Hat Enterprise Linux. This tool only uses LDAP and Kerberos for the machine enrollment.

Samba Winbind authentication on Linux clients directly enrolled into Windows Active Directory domains

Using Samba Winbind for authentication may no longer work when Active Directory domain controllers disable SMBv1 protocol. With some setups it might be feasible to switch to the System Security Services Daemon (SSSD) and use the SSSD ad-provider instead but this comes with the loss of some functionality. For instance, SSSD does not support the NTLM password-based authentication which relies on SMB protocol. NTLM is often used to authenticate users accessing services on Linux machines from Windows machines not joined to Active Directory domains or without direct access to domain controllers.

Group Policies used for Access Control

Access control in environments where the System Security Services Daemon (SSSD) has been configured to fetch and evaluate Group Policies (GPOs) from Windows AD will no longer work as SMB protocol is used to retrieve GPO content from a SYSVOL share.

POSIX extensions

Once SMBv1 has been disabled or removed, clients will no longer be able to leverage POSIX extensions. Those are only part of the SMBv1 protocol specification. Newer protocol versions (SMBv2 and SMBv3) do not support those extensions yet. There is some upstream work ongoing to add this feature also to newer SMB protocol versions, but the work is not complete yet and it's unclear when POSIX support will be available.

References