SMB file server share access is unsuccessful through DNS CNAME alias

This article provides solutions for the issue that DNS CNAME alias can’t access SMB file servers.

Original product version: В Windows 10 — all editions, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 7 Service Pack 1
Original KB number: В 3181029

Symptoms

• You’re running an SMB file server, such as Windows Server. The server has files and resources that are configured by using their NetBIOS name, the DNS fully qualified domain name (FQDN), and their alias (CNAME).
• You have a client that’s running Windows 7, Windows Server 2008 R2, or a later version of Windows.

When an application or user uses the actual storage name (the NetBIOS name or the FQDN) for files or other resources on the server that’s using SMB, access is successful.

When an application or user uses the CNAME alias for files or other resources on the server that’s using SMB, and you try to connect to a share on the file server with its DNS CNAME alias. For example, you try to connect to a share on the file server by using its DNS CNAME alias:

In this case, you experience the following behaviors:

Access from a Windows Server 2008 R2 or Windows 7 client is successful.

Access from a Windows Server 2012 R2, Windows 8.1, or a later version of Windows client is unsuccessful. In this case, you receive an error message that resembles the following one:

\\uncpath is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

Logon Failure: The target account name is incorrect.

Cause

If you use Network Monitor, Wire Shark, or Microsoft Message Analyzer to examine the network trace when the SMB Session Setup is successful, the session goes to the TREE Connect.

However, if you examine the network trace when the SMB Session Setup is unsuccessful, the session fails with a Kerberos KRB_AP_ERR_MODIFIED error. Here’s an example of an unsuccessful SMB Session Setup request in a network trace:

In an unsuccessful SMB Session Setup request, the client forwards an incorrect CNAME SPN. The SPN may be incorrect because it’s registered for an old server. However in a successful SMB Session Setup request such as in the Windows Server 2008 R2 client case, the client forwards the SPN for the actual server name.

If the file server name was resolved through DNS, the SMB client appends the DNS suffix to the user-supplied name. That is, the first component of the SPN will always be the user supplied name as in the following example:

This try would fail on older SMB implementations (Like AIX Samba 3.5.8), that cannot be configured for Kerberos authentication and does not listen to SMB direct host port 445, but only on NetBIOS port 139.

If the file server name was resolved through some other mechanism such as

• NetBIOS
• Link-Local Multicast Name Resolution (LLMNR)
• Peer Name Resolution Protocol (PNRP) processes

the SMB client uses the user supplied name such as the following one:

Resolution

To resolve this issue on a file server that is running the SMB version 1 protocol, add the DisableStrictNameChecking value to the registry:

Registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD name: DisableStrictNameChecking
DWORD value: 1

Do not use DNS CNAMEs in the future for file servers. If you want to still give alternate names to servers, you can do so with the following command:
NETDOM COMPUTERNAME/ADD

This command automatically registers SPNs for the alternate names.

We don’t recommend that you resolve this issue for a file server that isn’t Windows-based by typing the following commands in an elevated Command Prompt window on a Windows-based computer. You would have to be logged on with Domain Administrator credentials. Then press Enter at the command prompt to register the SPN for the CNAME of the non-Windows-based File Server storage device:

• If you use Windows 2012 Clustering, install the hotfix for down-level clients in which Windows XP or Windows Server 2003 computers cannot connect: Can’t access a resource that is hosted on a Windows Server 2012-based failover cluster.
• If you create a CNAME for the clustered name the clients are connecting to, you have to make sure that you set the properties on that Clustered name so that it responds to the CNAMEs: How to configure an alias for a clustered SMB share with Windows Server 2012.

Network trace

To collect a network trace, follow these steps:

Open an elevated Command Prompt window, type the following command, and then press Enter:

Delete any existing File Server network connections by running the following command:

Initialize all name caching by deleting the existing cache:

To delete the DNS cache, type the following command, and then press Enter:

To delete the NetBIOS cache, type the following command, and then press Enter:

To delete the Kerberos cache, type the following command, and then press Enter:

To delete the ARP cache, type the following command, and then press Enter:

Try to connect to the network share by typing the following command and then pressing Enter:

To stop the network trace in an unsuccessful scenario, type the following command, and then press Enter:

Collect registry settings

To collect registry settings on the file server, select Start, select Run, type the command in the Open box, and then select OK. Repeat this step for the following commands:

The registry setting files (.HIV) are saved to the TEMP folder on the file server.

Check registry settings

Check the settings of the following registry values on the file server:

Apply hotfixes (server and client)

For Windows 7 and Windows Server 2008 R2, apply the following Windows 7 Enterprise hotfix rollup:

Additionally, apply the following hotfixes:

References

Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.

Поддержка SMB 1.0 в Windows Server 2012 R2 / Windows Server 2016

В Windows Server 2012 R2 была представлена новая версия протокола SMB 3 (технически это SMB 3.02, т.к. версия SMB 3.0 появлялась еще в Windows Server 2012), а драйвер устаревшего протокола SMB 1.0 теперь можно отключать, и блокировать загрузку его компонентов. Вследствии отсутствия поддержки SMB 1.0 устаревшие (Windows XP, Server 2003 ) и совместимые клиенты (Mac OSX 10.8 Mountain Lion, Snow Leopard, Mavericks, старые версии Linux) не смогут получить доступ к файлам, расположенным файловом сервере под управлением Windows 2012 R2 / 2016.

Версии протокола SMB в Windows

SMB (Server Message Block, иногда называется LAN-Manager) это сетевой протокол для удаленного доступа к файлам, принтерам и другим сервисам. Для подключения используется порт TCP 445. Различные версии протокола SMB появлялись в следующих версиях Windows:

• CIFS — Windows NT 4.0
• SMB 1.0 — Windows 2000
• SMB 2.0 — Windows Server 2008 и WIndows Vista SP1
• SMB 2.1 — Windows Server 2008 R2 и Windows 7
• SMB 3.0 — Windows Server 2012 и Windows 8 (появилась поддержка SMB шифрования)
• SMB 3.02 — Windows Server 2012 R2 и Windows 8.1
• SMB 3.1.1 – Windows Server 2016 и Windows 10

При сетевом взаимодействии по протоколу SMB между клиентом и сервером используется максимальная версия протокола, поддерживаемая одновременно и клиентом, и сервером.

Ниже представлена сводная таблица, по которой можно определить версию протокола SMB, которая выбирается при взаимодействии разных версий Windows:

Операционная система	Win 10, Server 2016	Windows 8.1, Server 2012 R2	Windows 8, Server 2012	Windows 7, Server 2008 R2	Windows Vista, Server 2008	Windows XP, Server 2003 и ниже
Windows 10 , Windows Server 2016	SMB 3.1.1	SMB 3.02	SMB 3.0	SMB 2.1	SMB 2.0	SMB 1.0
Windows 8.1 , Server 2012 R2	SMB 3.02	SMB 3.02	SMB 3.0	SMB 2.1	SMB 2.0	SMB 1.0
Windows 8 , Server 2012	SMB 3.0	SMB 3.0	SMB 3.0	SMB 2.1	SMB 2.0	SMB 1.0
Windows 7, Server 2008 R2	SMB 2.1	SMB 2.1	SMB 2.1	SMB 2.1	SMB 2.0	SMB 1.0
Windows Vista, Server 2008	SMB 2.0	SMB 2.0	SMB 2.0	SMB 2.0	SMB 2.0	SMB 1.0
Windows XP, 2003 и ниже	SMB 1.0	SMB 1.0	SMB 1.0	SMB 1.0	SMB 1.0	SMB 1.0

К примеру, при подключении клиентского компьютера с Windows 7 к файловому серверу с Windows Server 2012 R2 будет использоваться протокол SMB 2.1.

Чтобы на стороне сервера вывести список используемых клиентами версий протокола SMB и количество клиентов, используемых ту или иную версию протокола SMB, выполните команду:

Get-SmbSession | Select-Object -ExpandProperty Dialect | Sort-Object -Unique

В нашем примере имеется 825 клиентов, подключенных к серверу с помощью SMB 2.1 (Win 7 / 2008 r2) и 12 клиентов через SMB 3.02 (Win 8.1/ 2012 r2.

Согласно таблице Windows XP, Windows Server 2003 для доступа к общим файлам и папкам на сервере могут использовать только SMB 1.0, который в новых версиях Windows Server (2012 R2 / 2016) может быть отключен. Таким образом, если в вашей инфраструктуре одновременно используются компьютеры с Windows XP (снятой с поддержки), Windows Server 2003 / R2 и сервера с Windows Server 2012 R2 / Server 2016, нужно понимать, что устаревшие клиенты не смогут получить доступ к файлам и папкам на файловом сервере с новой ОС. А в том случае, если в Windows Server 2016 / 2012 R2 с отключенным SMB 1.0 используется в качестве контроллера домена, то это означает, что клиенты на Windows XP / Server 2003 не смогут выполнить логон скрипты (NETLOGON) и некоторые групповые политики, хранящиеся в сетевых папках на контроллерах домена (например, при использовании централизованного хранилища admx-шаблонов). На старых клиентах при попытке подключиться к ресурсу на файловом сервере с отключенным SMB v1 появляется ошибка:

Об опасности использования SMB1

На данный момент протокол SMB 1.0 является устаревшим и в нем присутствует большое количество критических уязвимостей (вспомните историю с эпидемиями вирусов-шифровальщиков wannacrypt и petya, которые использовали уязвимость именно в протоколе SMBv1). Microsoft и другие IT компании настоятельно рекомендуют отказаться от его использования.

В том случае, если в вашей сети остались клиенты с Windows XP и Windows Server 2003 их нужно как можно скорее мигрировать на более новые версии ОС Microsoft или тщательно изолировать.

Протокол SMB 1.0 в Windows Server 2012 R2

Если открыть список компонентов Windows Server 2012 R2, среди них можно увидеть функцию с именем SMB 1.0/CIFS File Sharing Support, которая не установлена. Но сам драйвер SMB 1.0 при этом работает. При установке данной роли в системе появляется служба Обозревателя компьютеров (Computer Browser). Это клиент SMB 1.0, без которого с данного сервера не получится подключиться к другим компьютерам, которые поддерживают только этот протокол.

Set-SmbServerConfiguration -EnableSMB1Protocol $false

В Windows Server 2012 по-умолчанию загружаются драйверы как SMB 1, так и SMB 2. Чтобы удостоверится в этом, откроем свойства системной службы Server (LanmanServer) и на вкладке Dependencies убедимся, что на сервере одновременно работают драйвера Server SMB 1.xxx Driver и SMB 2.xxx Driver.

Если открыть свойства службы LanmanServer на Windows 2012 R2 мы увидим, что драйвер, обеспечивающий поддержку SMB 1.0, исключен из зависимостей.

Но это не говорит о том, что драйвер SMB 1.0 не работает. Проверить, включен ли протокол SMB 1.0 на стороне сервера можно командой:

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Как вы видите, протокол SMB1 в WS 2012 R2 включен несмотря на отсутствие компонента SMB 1.0/CIFS File Sharing Support и зависимостей в службе LanmanServer.

В том случае, если устаревшие клиенты (XP / Server 2003 и т.д.) потеряли SMB доступ к файловым серверам / контроллерам домена на Windows Server 2012 R2 можно активировать поддержку SMB 1 следующим образом. Сначала включите протокол в настройках сервера:

Set-SmbServerConfiguration -EnableSMB1Protocol $true

Затем включите зависимости протокола SMB 1.0 в Windows Server 2012 R2 через реестр. Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer и измените значение параметра DependOnService с SamSS Srv2 на SamSS Srv.

После этого сервер нужно перезагрузить и убедится, что драйвер SMB 1.0 вновь работает.

Эту операцию нужно выполнить на всех файловых серверах и контроллерах домена, к которым подключаются устаревшие версии клиентов.

Протокол SMB 1.0 в Windows Server 2016

В Windows Server 2016 поддержка протокола SMB 1.0 на стороне клиента также включается в виде отдельного компонента, который можно найти в списке мастера установки Add/Remove Features. Данный компонент называется SMB 1.0 / CIFS File Sharing Support.

Отключить поддержку SMB v1 и полностью удалить компонент можно командами:

Remove-WindowsFeature FS-SMB1
sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

Начиная с Windows Server 2016 1709 (и Windows 10 Fall Creators ), компонент SMBv1 (как клиент, так и сервер) по-умолчанию отключен (отключен также гостевой доступ по протоколу SMBv2). Для доступа к старым системам, использующим устаревшую версию протокола его нужно устанавливать отдельно. Нужно установить компонент SMB 1.0/CIFS File Sharing Support и включить SMB 1.0 командами:

Add-WindowsFeature FS-SMB1
Set-SmbServerConfiguration -EnableSMB1Protocol $true