[решено] SMB 1.0 - невозможно зайти на общую папку по имени сервера

[DJ Mogarych]

Привет!

Столкнулся со странностью: есть Windows Server 2003 с древней учётной системой, на которую заходят раз в несколько месяцев. Работа идёт через сетевые папки (по SMB 1.0, естественно).
Клиент сидит на Windows 7, последний раз заходил в конце ноября прошлого года.

Внезапно возникла проблема: нельзя зайти на сетевые папки, используя имя сервера, но можно, если использовать IP-адрес.
Т. е.,
\\server1\share - не работает (Unspecified error 0x80004005)
\\192.168.1.1\share - работает

По имени сервер пингуется, имя разрешается корректно.

То есть, проблема не в DNS и не в протоколе (по IP ведь заходит). Но в чём тогда?

Что пробовал:


Secpol.msc > Local Policies > Security Options > Microsoft network client: Digitally sign communications (always) => Disable (он и так уже был Disable) (ссылка (https://serverfault.com/questions/426010/server-2008-windows-7-samba-unspecified-error-80004005))
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v AllowInsecureGuestAuth /t REG_DWORD /d 1
net stop LanmanWorkstation && net start LanmanWorkstation
(ссылка (https://serveradmin.ru/kod-oshibki-0x80004005-neopoznannaya-oshibka-windows/))

[NickM]

А по FQDN работает?

[DJ Mogarych]

Нет, не работает. Когда пингуешь, NETBIOS-имя разрешается в FQDN, т. е., с DNS всё в порядке.

[Petya V4sechkin]

DJ Mogarych, покажите результаты с сервера и клиента:
ipconfig /all
nbtstat -n
и на обоих проверьте политики IPsec, не задано ли что-нибудь в ветке
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local

P.S. Также убедитесь, что служба Модуль поддержки NetBIOS через TCP/IP работает.

[DJ Mogarych]

На сервере куча всего

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecFilter{72385235-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecFilter{7238523a-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecISAKMPPolicy{72385231-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecISAKMPPolicy{72385234-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecISAKMPPolicy{72385237-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecISAKMPPolicy{7238523d-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{26d 227e7-0eb6-47c8-a6b3-3671c8a598aa}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{5ee 82003-565d-4886-8eaa-f692e1a2100b}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{723 85233-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{723 8523b-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{723 8523f-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{f35 a5a4e-06f6-413c-a3a4-f231cb1d3638}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNFA{6ce59973-4145-4b6c-a1fa-76e69d3c8c96}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNFA{78bdf453-ce8e-4a5c-b0e6-5a85203be571}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNFA{80bf3614-1128-4a73-b6ac-968c26b535f9}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNFA{9572a72a-00cf-4ba9-b72f-3592980f833b}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNFA{b8dae5fa-f908-4058-846c-1a31a91f8821}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNFA{cfa31a8e-3ad6-407f-b047-7735fe778a47}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNFA{e5533941-ae12-42b9-a1d1-a0bcf0753356}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecPolicy{72385230-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecPolicy{72385236-70fa-11d1-864c-14a300000000}
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000}


nbtstat -n


Подключение по локальной сети 3:
Адрес IP узла: [192.168.1.1] Код области: []

Локальная таблица NetBIOS-имен
Имя Тип Состояние
----------------------------------------------------
SERVER1 <00> Уникальный Зарегистрирован
EXAMPLE <00> Группа Зарегистрирован
SERVER1 <20> Уникальный Зарегистрирован
EXAMPLE <1E> Группа Зарегистрирован


ipconfig

Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : server1
Основной DNS-суффикс . . . . . . : example.com
Тип узла. . . . . . . . . . . . . : неизвестный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет
Порядок просмотра суффиксов DNS . : example.com

Подключение по локальной сети 3 - Ethernet адаптер:

DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Intel(R) PRO/1000 MT сетевое подключение
Физический адрес. . . . . . . . . : **-**-**-**-**-**
DHCP включен. . . . . . . . . . . : нет
IP-адрес . . . . . . . . . . . . : 192.168.1.1
Маска подсети . . . . . . . . . . : 255.255.0.0
Основной шлюз . . . . . . . . . . : 192.168.1.254
DNS-серверы . . . . . . . . . . . : 192.168.1.100
192.168.1.103


Тот клиент сейчас выключен, проверить не могу. Но на моей десятке, где та же картина (SMB 1.0 установлен и есть доступ через IP-адрес), у меня нет никаких записей там.

На компьютерах служба lmhosts (Модуль поддержки NetBIOS через TCP/IP) работает.

[Petya V4sechkin]

На сервере куча всего
Посмотрите, нет ли там ограничений для портов NetBIOS.

[DJ Mogarych]

Ничего похожего на NetBIOS я там не обнаружил. :dont-know

[Petya V4sechkin]

DJ Mogarych, 137, 138, 139?

[DJ Mogarych]

А в каком значении это должно быть?
Там куча параметров и в них белиберда какая-то типа

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\IPSec\Policy\Local\ipsecNegotiationPolicy{723 8523f-70fa-11d1-864c-14a300000000}]
"ClassName"="ipsecNegotiationPolicy"
"description"="Принимать небезопасную связь, но всегда требовать от клиентов применения методов доверия и безопасности. Не будет поддерживаться связь с ненадежными клиентами."
"name"="ipsecNegotiationPolicy{7238523f-70fa-11d1-864c-14a300000000}"
"ipsecName"="Требуется безопасность"
"ipsecID"="{7238523f-70fa-11d1-864c-14a300000000}"
"ipsecNegotiationPolicyAction"="{3f91a81a-7647-11d1-864d-d46a00000000}"
"ipsecNegotiationPolicyType"="{62f49e10-6c37-11d1-864c-14a300000000}"
"ipsecDataType"=dword:00000100
"ipsecData"=hex:b9,20,dc,80,c8,2e,d1,11,a8,9e,00,a0,24,8d,30,21,44,01,00,00,04,\
00,00,00,84,03,00,00,a0,86,01,00,00,00,00,00,00,00,00,00,01,00,00,00,03,00,\
...
"whenChanged"=dword:3fcc4df4
"ipsecOwnersReference"=hex(7):53,00,4f,00,46,00,54,00,57,00,41,00,52,00,45,00,\
5c,00,50,00,6f,00,6c,00,69,00,63,00,69,00,65,00,73,00,5c,00,4d,00,69,00,63,\
...


Это можно в каком-то более человеческом виде посмотреть где-то? Может, оснастка есть?

И если бы была такая политика, разве работало бы через IP-адрес?

[Petya V4sechkin]

DJ Mogarych, в оснастке (secpol.msc, Политики IP-безопасности).

разве работало бы через IP-адрес?
Ну если 445 порт открыт.

[DJ Mogarych]

Все политики имеют статус "Не назначены", а время последнего изменения - декабрь 2003 г.

Файрволл полностью выключен.

[DJ Mogarych]

Наиболее вероятное объяснение (https://social.technet.microsoft.com/Forums/windows/en-US/200ad716-a1d3-4100-b9fb-7ac1ebc054c2/smb-share-access-by-ip?forum=w7itpronetworking), которое я нашёл:

If we connect with DNS, a Kerberos authentication is used to give access.
but with IP address, kerberos is not supported, so NTLM is used


Непонятно пока, как это решать.

UPD: похоже, дело в KB5021249, выпущенном в ноябре 2022.
https://superuser.com/questions/1754030/windows-desktop-cant-connect-to-server-2003-share
Пока единственное решение - снести этот патч, либо ждать фикса, которого может и не быть.

[DJ Mogarych]

Тут ещё и непонятно, что сносить, без поллитра не разберёшься (апдейты с ноября).


DC1 Update KB5020620 EXAMPLE\admin 01.12.2022 0:00:00
DC1 Security Update KB5018922 EXAMPLE\admin 01.12.2022 0:00:00
DC1 Update KB5020878 EXAMPLE\admin 10.01.2023 0:00:00
DC1 Security Update KB5022352 EXAMPLE\admin 20.01.2023 0:00:00

DC2 Update KB5020620 EXAMPLE\admin 01.12.2022 0:00:00
DC2 Security Update KB5018922 EXAMPLE\admin 01.12.2022 0:00:00
DC2 Update KB5018519 EXAMPLE\admin 01.12.2022 0:00:00
DC2 Update KB5020878 EXAMPLE\admin 10.01.2023 0:00:00
DC2 Security Update KB5022352 EXAMPLE\admin 20.01.2023 0:00:00

DC3 Update KB5018519 NT AUTHORITY\СИСТЕМА 07.11.2022 0:00:00
DC3 Update KB5020620 EXAMPLE\admin 01.12.2022 0:00:00
DC3 Security Update KB5018922 EXAMPLE\admin 01.12.2022 0:00:00
DC3 Security Update KB5022352 EXAMPLE\admin 11.01.2023 0:00:00
DC3 Update KB5020878 EXAMPLE\admin 11.01.2023 0:00:00


Хотелось бы, конечно, без сноса апдейтов.
Проблема ещё в том, что на имя сервера много что завязано, поэтому просто по IP подключаться просто так не выйдет.

[dmitryst]

Хотелось бы, конечно, без сноса апдейтов. »
а древний костыль в виде записи в /etc/hosts не подойдет? ;)

[DJ Mogarych]

Я тоже об этом подумал. Проверил - к сожалению, нет.

[dmitryst]

похоже, дело в KB5021249, выпущенном в ноябре 2022. »
как я понял, это патч для серверной ОС, не 2003й и не клиентских "семёрок" и "десяток". Т.е. этот патч устанавливается на контроллер домена под 2022м сервером, и после этого доступ к рядовым 2003м по имени становится невозможным. В вашем случае доступ вроде как напрямую, без КД, да и номер патча не совпадает. Кстати, а с клиентской "десятки" на этот же 2003й зайти можете?

ПыСы. Вот чё нашел (https://community.spiceworks.com/topic/2277832-windows-10-2004-can-t-access-network-shares-and-old-2003-server#entry-8900409) - чел пишет, что если отключить smb2/3, то зайти таки можно будет:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi

sc.exe config mrxsmb20 start= disabled

ПыСы 3 раза )) Проверил на виртуалке - клиент 7 максимальная, сборка 7601, сервис-пак 1 + все обновления по 13 янв. 2023,
сервер 2003 R2, сборка 3790.srv03_sp2_rtm.070216-1710 Service Pack 2, обновлений нет.
Всё работает без лишних движений, хоть по адресу, хоть по имени.

[DJ Mogarych]

Это патч для контроллера домена, не только для 2022-го сервера.
Всё работало до ноября 2022 г. Доступ с КД, т. к. обе машины доменные. Дело в том, что при обращении к IP-адресу используется NTLM, и тогда всё работает, а если по имени - то это уже Kerberos, и тут облом.

Ни с какой машины зайти не могу по имени, и работает отовсюду по IP.

К сожалению, отключать SMB 2/3 не вариант, т. к. на клиентской тачке пользуются не только этим копролитом мамонта, но и вполне современными файловыми ресурсами.

Проблема характерна, видимо, только для доменного окружения и, наверное, не лечится ничем, кроме как избавлением от ОС двадцатилетней давности.

[NickM]

Проблема характерна, видимо, только для доменного окружения »
Угу, два года "Microsoft" предупреждала - почти год патчила "Kerberos".
А контроллер у Вас один? Под какой системой?
Или имеется какой, другой?

Я Сам испытываю проблему на контроллере "W2008", но пока никаким образом от оного уйти не могу - жду миграцию на "W2012R2" или на "SAMBA-DC".

[DJ Mogarych]

3 шт, все под 2012 R2.

[YuS_2]

Наиболее вероятное объяснение, которое я нашёл »
Там ситуация обратная, нет доступа по IP...

Итого, в комплексе:
Windows Server 2003 »
Внезапно возникла проблема »
Ни с какой машины зайти не могу по имени, и работает отовсюду по IP. »
Проблема ещё в том, что на имя сервера много что завязано, поэтому просто по IP подключаться просто так не выйдет. »
если такая картина на всех клиентах, то "ковырять" надо сервер и если ранее всё работало, то ковырять надо таки апдейты...
Поэтому, как бы ни хотелось обойтись без этого:
Хотелось бы, конечно, без сноса апдейтов. »
раз уж не помогают распространенные рецепты типа:
1. раз (https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/deployment/error-0x80004005-network-policy-server-role)
2. два (https://learn.microsoft.com/ru-ru/troubleshoot/windows-client/networking/cannot-access-shared-folder-file-explorer)
3. три (http://forum.oszone.net/nextoldesttothread-338201.html)
ну и тут (https://setupwindows.ru/errors/windows-ne-mozhet-poluchit-dostup), и тут (http://composs.ru/oshibka-0x80004005/) по кучке советов... думаю, ты и сам их видел пока искал решения...
всё же, придется использовать "метод научного тыка", то бишь сносить апдейты, проверять, восстанавливать апдейты пошагово, вручную и проверять какой из них породил эту ошибку...
наверное, не лечится ничем, кроме как избавлением от ОС двадцатилетней давности. »
и это вероятнее всего, ибо поддержка осуществляется, видимо, никак от слова совсем...