После перехода на Windows Server 2025 не открывается NAS: разбираем SMB-подпись и гостевой вход

Сеть исправна, пинг идёт, а сетевой диск не открывается — и всё это началось ровно в день перехода на Windows Server 2025 или Windows 11 24H2. Разбираю по шагам: какая сторона требует SMB-подпись, почему «разрешить гостевой вход» почти никогда не помогает, какими командами это диагностируется за десять минут и что чинить в первую очередь. С разбором условного стенда венчурного фонда на 48 рабочих мест и с честным ответом на вопрос, когда подпись всё-таки можно отключить.

Симптом один, причины две — и они между собой не связаны

Звонок в пятницу вечером: «Перенесли сервер 1С на Windows Server 2025, теперь регламентное задание не выгружает файлы на NAS. Сеть проверили — всё пингуется». Через час — второй звонок, уже от другого клиента: шесть новых ноутбуков на Windows 11 24H2 Pro не видят общую папку на четырёхдисковой коробке, которая мирно раздавала файлы шесть лет. Обе истории — про одно и то же изменение поведения SMB-клиента в новых системах, но лечатся они по-разному, и это первое, что нужно развести в голове.

У проблемы ровно две ветки, и различить их можно по тексту ошибки. Первая — про подпись: клиент требует подписывать трафик, а сервер на той стороне подпись не предлагает. Вторая — про гостя: NAS пытается пустить вас как неаутентифицированного гостя, а Windows такие сеансы отвергает. Ошибки при этом выглядят совершенно по-разному, и если вы прочитали текст, вы уже наполовину нашли причину.

# Ветка «подпись»: сервер не умеет или не отдаёт подпись
0xc000a000
-1073700864
STATUS_INVALID_SIGNATURE
The cryptographic signature is invalid.

# Ветка «гость»: сервер пускает как guest, клиент отказывается
You can't access this shared folder because your organization's security
policies block unauthenticated guest access.
Error code: 0x80070035 - The network path was not found.
System error 3227320323 has occurred.

Скажу сразу, чтобы вы не потратили вечер зря: по моей практике за последний год примерно два случая из трёх — это гость, а не подпись. Народ читает статьи про «Microsoft сломала SMB подписью», идёт отключать подпись, ничего не меняется, и дальше начинается копание в маршрутизации и антивирусе. Между тем настоящий виновник — учётная запись, точнее её отсутствие: на шаре стоит анонимный доступ, а новый клиент анонимов не принимает. Подпись же реально ломает связь заметно реже, потому что почти все современные NAS работают на Samba, а Samba для SMB2 подпись отдаёт всегда.

• STATUS_INVALID_SIGNATURE, 0xc000a000, -1073700864 — разбираемся с подписью на стороне NAS.
• 0x80070035, «политики безопасности организации блокируют неаутентифицированный гостевой доступ», системная ошибка 3227320323 — разбираемся с гостевым входом.
• Ошибка про пароль или Access denied без упоминания гостя — это уже права на шару, отдельная история.
• Ничего из перечисленного и вообще нет коннекта на 445/tcp — сначала сеть и файрвол, статья не про это.

Кто требует подпись: раскладка по версиям и сторонам

Требование подписи в Windows двустороннее и настраивается независимо: есть исходящая подпись — это трафик от SMB-клиента, и есть входящая — трафик к SMB-серверу. Система может требовать только исходящую, только входящую, обе или ни одной. В 2025–2026 годах Microsoft раздала эти требования по редакциям так: Windows Server 2025 требует только исходящую подпись; Windows 11 версии 24H2 в редакциях Pro, Enterprise и Education требует и исходящую, и входящую; Windows 11 24H2 Home не требует ничего. Плюс к этому контроллеры домена по умолчанию требуют входящую подпись от всех, кто к ним подключается, — ради SYSVOL и NETLOGON, откуда клиенты берут групповые политики и сценарии входа.

Отсюда понятная картина для типового офиса. Ваш новый сервер на WS2025, обращаясь к NAS, выступает клиентом — и он требует подпись. Ваш новый ноутбук на 24H2 Pro тоже клиент — и он требует подпись. А старый файловый сервер на Windows Server 2019 или 2022 подпись не требует, поэтому «на старом-то работает» — не аргумент и не диагноз, а просто разные дефолты.

Дальше — важная деталь, на которой спотыкаются регулярно. В реестре живут два похожих параметра: RequireSecuritySignature и EnableSecuritySignature. Для SMB 2.02 и новее второй параметр просто игнорируется — он работает только для древнего SMB1, которого у вас в 2026 году быть не должно. То есть настраивается ровно один флаг: требовать или не требовать. Ветки реестра разные для клиента и сервера, и это тоже путают.

; Клиент (исходящая подпись)
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
RequireSecuritySignature = REG_DWORD : 0 (не требовать) | 1 (требовать)

; Сервер (входящая подпись)
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
RequireSecuritySignature = REG_DWORD : 0 (не требовать) | 1 (требовать)

; EnableSecuritySignature для SMB2+ ИГНОРИРУЕТСЯ — не тратьте на него время

И последнее по этому разделу, но по важности первое: соединение подписывается, если подпись требует хотя бы одна сторона. Подписи не будет только в одном случае — когда RequireSecuritySignature равен нулю и у клиента, и у сервера. Практический вывод: чтобы соединение с NAS сломалось, недостаточно «включить подпись у себя» — нужно, чтобы NAS вообще не умел или не отдавал подпись. Если он умеет — соединение просто подпишется, и вы этого даже не заметите.

• Windows Server 2025 — требует исходящую подпись (как клиент).
• Windows 11 24H2 Pro / Enterprise / Education — требует и исходящую, и входящую.
• Windows 11 24H2 Home — не требует ни одной.
• Контроллеры домена — по умолчанию требуют входящую подпись (SYSVOL, NETLOGON).
• Windows Server 2019 / 2022 и Windows 10 — по умолчанию не требуют, отсюда «а раньше работало».

Почему «разрешить гостевой вход» не помогает: гость и подпись несовместимы

Теперь про вторую ветку, которая встречается чаще. Гостевой сеанс SMB — это сеанс без нормальной аутентификации, а значит, и без нормального сессионного ключа. А вся криптография SMB 2/3 — и подпись, и шифрование — выводится именно из сессионного ключа. Нет ключа — нечем подписывать. Поэтому гостевые сеансы принципиально не поддерживают ни подпись, ни шифрование, и требование подписи автоматически убивает гостевой доступ. Это не баг и не недокрутка, это следствие архитектуры протокола.

Из этого вытекает ловушка, в которую попадают почти все. Человек видит сообщение про «неаутентифицированный гостевой доступ», гуглит, находит параметр AllowInsecureGuestAuth, ставит единицу, перезагружается — и ничего не меняется. Потому что он разрешил гостя, но клиент по-прежнему требует подпись, а гостевой сеанс её не даёт. Чтобы этот путь заработал, надо ослабить обе настройки сразу: и разрешить небезопасного гостя, и снять требование подписи. Ровно поэтому я этот путь и не рекомендую — вы одним движением отключаете и аутентификацию, и защиту от подмены.

# Так это выглядит на клиенте (я привожу для понимания, а не как рекомендацию)
Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force
# ключ реестра:
# HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\AllowInsecureGuestAuth = 1
# GPO: Конфигурация компьютера → Административные шаблоны → Сеть →
#      Рабочая станция Lanman → Enable insecure guest logons

Отказ гостевого входа хорошо виден в журнале: «Журналы приложений и служб → Microsoft → Windows → SMBClient → Security», событие 31017 «Rejected an insecure guest logon». Если оно у вас сыпется пачками — диагноз поставлен, и лечится он не реестром, а заведением нормальной учётной записи на NAS. Небезопасный гостевой вход опасен ровно тем, что подставного «файлового сервера» в сети поднять несложно, а клиент к нему подключится молча и без пароля — вместе со всеми последствиями вроде запуска чужого содержимого с сетевого пути.

• Гостевой сеанс = нет сессионного ключа = нет подписи и шифрования. Это неустранимо.
• Требование подписи всегда выключает гостевой доступ — это ожидаемое поведение, а не сбой.
• Событие SMBClient/Security 31017 — прямое доказательство, что дело в госте.
• Правильное лечение — учётная запись на NAS, а не AllowInsecureGuestAuth.

Диагностика за десять минут: что я реально выполняю

Первым делом смотрю фактическое состояние обеих сторон на проблемной машине. Не то, что написано в политике, а то, что реально в конфигурации SMB-стека. Это три команды, и они отвечают на вопрос «кто требует подпись» без телепатии.

# Что требует клиент (исходящие соединения)
Get-SmbClientConfiguration | Format-List RequireSecuritySignature, EnableSecuritySignature, EnableInsecureGuestLogons

# Что требует сервер (входящие соединения)
Get-SmbServerConfiguration | Format-List *sign*

# Что реально происходит на живых соединениях
Get-SmbConnection | Format-Table ServerName, ShareName, Dialect, Signed, Encrypted -AutoSize

Колонка Signed в Get-SmbConnection — самая полезная вещь во всём наборе. Она показывает не намерения, а факт: подписано соединение или нет. Если к NAS соединение поднимается и Signed равно True — значит, подпись он умеет, и искать причину надо в другом месте. Если соединение вообще не поднимается — смотрим текст ошибки и идём по веткам из первого раздела.

Дальше — решающий тест на гостя, он занимает пятнадцать секунд и снимает 90 % вопросов. Подключаемся к той же шаре с явным указанием логина; звёздочка вместо пароля заставит net use спросить его интерактивно, чтобы пароль не остался в истории команд и в логах. Если с явными учётными данными шара открывается, а без них нет, — вопрос закрыт, вы упирались в гостевой вход, и подпись тут вообще ни при чём.

net use \\nas01\exchange /user:nas01\svc_1c *
dir \\nas01\exchange
net use \\nas01\exchange /delete

Отдельно — режим аудита, который появился начиная с Windows 11 24H2 и Windows Server 2025. Он позволяет заранее, до массового обновления парка, найти всех контрагентов, которые не умеют подпись или шифрование. Я включаю его на пилотной группе за пару недель до раскатки и потом просто читаю журналы: клиентские события 31998 и 31999 в SMBClient/Audit, серверные 3021 и 3022 в SMBServer/Audit. В домене те же четыре переключателя удобнее раздать политикой: они лежат в «Конфигурация компьютера → Административные шаблоны → Сеть → Сервер Lanman» (Audit client does not support encryption / signing) и «… → Рабочая станция Lanman» (Audit server does not support encryption / signing).

Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportEncryption $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

И самая частая процедурная ошибка, из-за которой «мы всё поменяли, а оно вернулось»: параметры подписи в домене обычно приезжают групповой политикой из раздела «Параметры безопасности». Локальная правка реестра или PowerShell-команда живут до ближайшего применения политики, после чего молча откатываются. Поэтому прежде чем что-то менять на доменной машине, я всегда смотрю gpresult /h и убеждаюсь, что параметр не задан централизованно. Если задан — правим политику, а не машину.

• Get-SmbClientConfiguration и Get-SmbServerConfiguration — намерения сторон.
• Get-SmbConnection, колонки Dialect / Signed / Encrypted — факт по живым сессиям.
• SMBClient/Security событие 31017 — отказ гостевого входа.
• SMBClient/Audit 31998, 31999 и SMBServer/Audit 3021, 3022 — режим аудита совместимости.
• gpresult /h — проверка, не прилетает ли настройка политикой.

Разбор стенда: венчурный фонд на 48 рабочих мест

Возьму условный венчурный фонд «ВенчурКапитал» — 48 рабочих мест, один домен, сервер приложений с 1С и SQL, четырёхдисковый NAS на 3,2 ТБ в роли хранилища документов по сделкам и приёмника выгрузок. Летом 2026 года мы переносили сервер приложений с Windows Server 2019 на Windows Server 2025 — плановая миграция, всё по регламенту. На следующее утро встало регламентное задание, которое каждые полчаса выкладывало на NAS пакеты для инвестиционного комитета и отчётность по портфельным компаниям: около 350 файлов в сутки, путь вида \\192.168.10.20\exchange, доступ анонимный, как его сделали в 2019 году «чтобы не мучиться с паролями».

В логе 1С — банальное «путь не найден». В журнале Windows — событие 31017 в SMBClient/Security, за первые сутки 1638 записей. Диагноз ставится за минуту: сервер 2025 отверг гостевой сеанс. Проверка через net use с явными учётными данными подтвердила: под заведённым пользователем шара открывается мгновенно. Подпись тут была вообще ни при чём, хотя все первые сорок минут мы, честно скажу, копали именно в её сторону — потому что в статьях из поиска речь только про неё.

Лечение заняло полчаса. На NAS завели отдельного локального пользователя svc_1c, выдали ему права только на каталог exchange, пароль на 24 символа положили в парольный менеджер. На сервере приложений прописали учётные данные в хранилище Windows под той учётной записью, от которой работает служба 1С, и заменили обращение по IP на обращение по DNS-имени — чтобы смена адреса NAS больше ничего не ломала. Оговорюсь честно: с локальным пользователем NAS аутентификация всё равно идёт по NTLM, Kerberos появится только после ввода NAS в домен, поэтому длинный пароль здесь не формальность — от него зависит стойкость ключа подписи. После этого Get-SmbConnection показал Dialect 3.1.1 и Signed = True — подпись поднялась сама собой, потому что Samba на этой коробке её прекрасно умеет, а требование клиента её включило. Никакие RequireSecuritySignature мы не трогали вообще.

Второй эпизод на том же стенде был уже настоящим: старая коробка резервного копирования 2014 года выпуска, прошивка последний раз обновлялась в 2019-м. Она поддерживала только ранний SMB2 на древней сборке встроенного SMB-сервера, подпись в интерфейсе не настраивалась, и на подключение с сервера 2025 клиент получал честный STATUS_INVALID_SIGNATURE. Вот тут вариантов было ровно два — либо отключать требование подписи на сервере 2025, либо выводить коробку из схемы. Мы выбрали второе: перевесили резервную копию на второй NAS, а старую коробку оставили в изолированном VLAN без выхода в основную сеть, доживать свой срок как офлайн-архив. По деньгам это не стоило ничего, по времени — два часа, и никаких ослабленных настроек в домене мы не завели.

Итог по стенду: из трёх «отвалившихся после обновления» ресурсов два лечились заведением учётной записи, один — выводом древнего железа из эксплуатации. Отключать SMB-подпись не пришлось нигде. Это ровно та пропорция, которую я вижу у большинства клиентов, и именно поэтому я так настойчиво прошу не начинать с отключения подписи.

• Что было: анонимная шара на NAS + сервер приложений, обновлённый до Windows Server 2025.
• Что увидели: 1638 событий 31017 за сутки, ошибка «путь не найден» в 1С.
• Что сделали: сервисный пользователь на NAS с длинным паролем, учётные данные в хранилище Windows, обращение по DNS-имени вместо IP.
• Что получили: Dialect 3.1.1, Signed = True, ноль изменений в политиках безопасности.
• Отдельный случай: коробка 2014 года без обновлений прошивки — выведена в изолированный VLAN, а не «полечена» отключением подписи.

Как чинить правильно: порядок приоритетов

Мой порядок действий жёсткий и не меняется от клиента к клиенту. Сначала убираем гостя — то есть заводим на NAS нормального пользователя и раздаём права. Потом, если ошибка была про подпись, включаем подпись на самом NAS: в Synology DSM 7 это «Панель управления → Файловые службы → SMB → Дополнительные настройки → Enable server signing», где нужно выбрать вариант Client defined («определяется клиентом»). На Samba-системах, до которых есть доступ по SSH, параметр называется server signing, и он принимает значения default, auto, mandatory и disabled. Значение default означает mandatory для роли контроллера домена Active Directory и disabled во всех остальных случаях. Полезно знать, что для SMB2 Samba трактует disabled как auto — подпись всё равно предлагается, потому что в SMB2 её нельзя отключить по дизайну, а mandatory требует подпись и от SMB2-клиентов. Для шифрования есть отдельный параметр server smb encrypt со значениями off, if_required (он же default), desired и required.

; /etc/samba/smb.conf на стороне NAS или Linux-файлсервера
[global]
    server signing = mandatory
    server min protocol = SMB2_10
    server smb encrypt = desired

Дальше — гигиена подключения, которая влияет на стойкость подписи. Ключ сеанса выводится из аутентификации, поэтому Microsoft прямо рекомендует использовать Kerberos вместо NTLMv2, не подключаться к шарам по IP-адресу и не заводить CNAME-записи для файловых серверов. Обращение по IP или по CNAME гарантированно сваливает вас на NTLM: подпись при этом работает, но её криптостойкость упирается в качество пароля. Альтернативные имена для сервера правильно назначать через netdom computername, а не записями в DNS.

И только если всё вышеперечисленное невозможно — например, у вас устройство, где подпись в веб-интерфейсе не настраивается, SSH закрыт, а вендор давно не выпускает прошивок, — тогда обсуждаем отключение требования подписи на клиенте. Это осознанный размен: вы возвращаете доступ ценой снятия защиты от вмешательства в трафик. Microsoft этот путь прямо не рекомендует, и я тоже, но иногда выбор стоит между «не работает бизнес-процесс» и «канал внутри доверенного VLAN не подписан».

# Крайняя мера. Требует прав администратора, -Force подавляет запрос подтверждения
Set-SmbClientConfiguration -RequireSecuritySignature $false -Force   # исходящие
Set-SmbServerConfiguration -RequireSecuritySignature $false -Force   # входящие

# Проверка результата
Get-SmbClientConfiguration | Format-List RequireSecuritySignature
Get-SmbServerConfiguration | Format-List RequireSecuritySignature

Если уж отключаете — делайте это адресно. Не общедоменной политикой на весь парк, а отдельным объектом групповой политики на конкретную OU с конкретными машинами, которым нужен доступ к конкретной проблемной железке. И заведите в трекере задачу с датой пересмотра: «заменить NAS до такого-то числа, после замены вернуть требование подписи». Иначе временное послабление 2026 года вы найдёте включённым в 2030-м — я такое вижу постоянно.

• Шаг 1. Завести реального пользователя на NAS, убрать анонимный доступ.
• Шаг 2. Включить подпись на стороне NAS (Synology — Enable server signing → Client defined, Samba — server signing = auto или mandatory).
• Шаг 3. Подключаться по имени хоста, не по IP и не по CNAME; альтернативные имена — через netdom computername.
• Шаг 4. Обновить прошивку NAS до версии с поддержкой SMB 3.1.1.
• Шаг 5. Если ничего из этого невозможно — отключать требование подписи точечно, отдельной GPO, с датой пересмотра.
• Чего не делать никогда: включать AllowInsecureGuestAuth доменной политикой на весь парк.

Что прилетит дальше и как не собрать эти грабли второй раз

Подпись и гость — это не разовая история, а часть последовательной линии Microsoft на закручивание SMB. В Windows Server 2025 и Windows 11 24H2 в том же наборе едут управление минимальным диалектом на стороне сервера, возможность блокировать NTLM для исходящих SMB-соединений, требование шифрования на клиенте и ограничитель скорости неудачных попыток аутентификации. Каждая из этих настроек по отдельности разумна, а вместе они означают, что любой «старый добрый» сетевой ресурс, живущий на анонимном доступе и SMB1, рано или поздно отвалится. Не в это обновление, так в следующее.

Практический вывод для эксплуатации простой: инвентаризация SMB-ресурсов должна быть в вашем регламенте, а не в голове у одного человека. Я держу по каждому клиенту табличку: адрес ресурса, кто владелец, какой диалект, подписывается ли соединение, под какой учётной записью ходят, есть ли анонимный доступ, дата последнего обновления прошивки. Собирается она одной командой Get-SmbConnection с нескольких ключевых хостов плюс обход журналов аудита. Занимает полдня раз в год, экономит вечера пятниц.

Второй вывод — про закупку. Когда клиент выбирает NAS, я смотрю не на терабайты и не на скорость, а на то, поддерживает ли устройство SMB 3.1.1, доменную аутентификацию и настраиваемую подпись, и выпускает ли вендор прошивки прямо сейчас. Коробка без обновлений прошивки — это не «дёшево», это отложенный простой файловых операций, причём в самый неподходящий момент. И, честно говоря, разница в цене между устройством, которое проживёт до 2030 года, и тем, которое умрёт на следующем обновлении Windows, обычно меньше стоимости одного дня простоя обмена.

И третье. Прежде чем массово катить Windows 11 24H2 или Windows Server 2025, включите режим аудита совместимости на пилотной группе и дайте ему поработать пару недель. События 31998 и 31999 покажут вам список всех серверов, которые не тянут подпись или шифрование, — заранее, спокойно и без звонков в пятницу. Это самый дешёвый инструмент во всей истории, и им почти никто не пользуется.

• Управление минимальным диалектом SMB на сервере — старые клиенты отвалятся.
• Блокировка NTLM для исходящих SMB-соединений — сломает всё, что ходит по IP.
• Требование шифрования на клиенте — следующий рубеж после подписи.
• Ограничитель скорости неудачных аутентификаций — заметно замедлит перебор паролей и заодно кривые скрипты.

Частые вопросы