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

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Microsoft Windows 7 (http://forum.oszone.net/forumdisplay.php?f=95)

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

Привет!

Столкнулся со странностью: есть 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) (ссылка)
Код:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v AllowInsecureGuestAuth /t REG_DWORD /d 1 net stop LanmanWorkstation && net start LanmanWorkstation

(ссылка)

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

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

DJ Mogarych, покажите результаты с сервера и клиента:

Код:

ipconfig /all

nbtstat -n

и на обоих проверьте политики IPsec, не задано ли что-нибудь в ветке
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local

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

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

Код:

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{26d227e7-0eb6-47c8-a6b3-3671c8a598aa}

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{5ee82003-565d-4886-8eaa-f692e1a2100b}

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{72385233-70fa-11d1-864c-14a300000000}

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{7238523b-70fa-11d1-864c-14a300000000}

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{7238523f-70fa-11d1-864c-14a300000000}

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecNegotiationPolicy{f35a5a4e-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) работает.

Цитата:

Цитата DJ Mogarych

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

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

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

DJ Mogarych, 137, 138, 139?

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

Код:

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\IPSec\Policy\Local\ipsecNegotiationPolicy{7238523f-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-адрес?

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

Цитата:

разве работало бы через IP-адрес?

Ну если 445 порт открыт.

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

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

Наиболее вероятное объяснение, которое я нашёл:

Цитата:

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/1754...ver-2003-share
Пока единственное решение - снести этот патч, либо ждать фикса, которого может и не быть.

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

Код:

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 подключаться просто так не выйдет.

Цитата:

Цитата DJ Mogarych

Хотелось бы, конечно, без сноса апдейтов. »

а древний костыль в виде записи в /etc/hosts не подойдет? ;)

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

Цитата:

Цитата DJ Mogarych

похоже, дело в KB5021249, выпущенном в ноябре 2022. »

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

ПыСы. Вот чё нашел - чел пишет, что если отключить 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, обновлений нет.
Всё работает без лишних движений, хоть по адресу, хоть по имени.

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

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

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

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

Цитата:

Цитата DJ Mogarych

Проблема характерна, видимо, только для доменного окружения »

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

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

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

Цитата:

Цитата DJ Mogarych

Наиболее вероятное объяснение, которое я нашёл »

Там ситуация обратная, нет доступа по IP...

Итого, в комплексе:

Цитата:

Цитата DJ Mogarych

Windows Server 2003 »

Цитата:

Цитата DJ Mogarych

Внезапно возникла проблема »

Цитата:

Цитата DJ Mogarych

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

Цитата:

Цитата DJ Mogarych

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

если такая картина на всех клиентах, то "ковырять" надо сервер и если ранее всё работало, то ковырять надо таки апдейты...
Поэтому, как бы ни хотелось обойтись без этого:

Цитата:

Цитата DJ Mogarych

Хотелось бы, конечно, без сноса апдейтов. »

раз уж не помогают распространенные рецепты типа:
1. раз
2. два
3. три
ну и тут, и тут по кучке советов... думаю, ты и сам их видел пока искал решения...
всё же, придется использовать "метод научного тыка", то бишь сносить апдейты, проверять, восстанавливать апдейты пошагово, вручную и проверять какой из них породил эту ошибку...

Цитата:

Цитата DJ Mogarych

наверное, не лечится ничем, кроме как избавлением от ОС двадцатилетней давности. »

и это вероятнее всего, ибо поддержка осуществляется, видимо, никак от слова совсем...

Цитата:

Цитата DJ Mogarych

Windows Server 2003 с древней учётной системой »

перенеос на новый сервер очень проблематичен по сравнению с

Цитата:

Цитата YuS_2

сносить апдейты, проверять, восстанавливать апдейты пошагово, вручную и проверять какой из них породил эту ошибку. »

?
Я бы взвесил все "за" и "против", что скажете?
У самого есть такой 2003й, еле шевелится на костылях, всё никак не переедем... ибо раз в месяц бывает нужен этот копролит, а переность всё довольно гиморно.

Цитата:

Цитата dmitryst

Я бы взвесил все "за" и "против", что скажете? »

Естественно... сначала 7 раз отмерить (попытаться поискать менее радикальные рецепты, тем более, не факт, что это поможет...), но если выхода другого не будет, как крайний вариант.
Попадался вариант похожий на описываемый случай, но там доступ по имени (при доступности по IP) пропадал периодически и наоборот от сервера на другие машины... кажется, там вопрос решился очисткой кэша DNS. Сомневаюсь, что здесь это поможет.

Я бы не стал сносить апдейты с контроллера, тем более, что обновления эти поэтапно будут делаться до октября 2023.
Лучше избавляться от старья.

Цитата:

Цитата DJ Mogarych

Лучше избавляться от старья. »

И я к тому же.
На мой взгляд, ниже 2012-го смотреть не стоит, ибо они тоже скоро уйдут туда же, куда уже ушел 2003й :biggrin:

В общем, решилось так: клиентскую часть я водрузил на сервер и дал юзеру доступ туда по RDP.

Софт - Галактика 5.8.
При запуске ругается, что "используется SQL Server ODBC Driver 03.86.1830, программа может работать некорректно", но работает.

Цитата:

Цитата DJ Mogarych

водрузил на сервер и дал юзеру доступ туда по RDP »

это ж не наш путь! :not-me:

Цитата:

Цитата DJ Mogarych

При запуске ругается »

в моем случае, кроме всего прочего, нужно делать экспорт в экселовские таблицы, а нужный компонент работает только под 32-битный 2003й, на 2008, например, он даже не ставится. Софт вроде как ещё "на Дельфях" писан в каком-то 1990-лохматом году. Так что вам еще повезло ;)

Цитата:

Цитата DJ Mogarych

SQL Server ODBC Driver 03.86.1830 »

На оф. сайте есть свежий драйвер, но версия - Release number: 18.1.2.1. Я бы не рискнул обновлять ))

Почему не наш путь? Юзер бесправный же, и заходит туда раз в 3 месяца.