У клонов Windows Server 2025 разные имена, но не работают SMB и RDP: как обнаружить одинаковые SID?

Если после клонирования Windows Server 2025 SMB-шара выдаёт «Отказано в доступе», а RDP не пускает при верном пароле — проверьте SID компьютера утилитой PsGetSid. С обновлений от 29 августа 2025 года Windows отклоняет аутентификацию между машинами с одинаковым SID, а разные имена серверов тут ничего не значат. Разбираю диагностику по событию 6167 и клонирование через Sysprep на реальном кейсе.

Одинаковые SID после клонирования: почему у серверов с разными именами не работает SMB и RDP

Клонировали виртуальную машину с Windows Server 2025, дали новое имя, новый IP-адрес — вроде всё как положено. А общая папка выдаёт «Отказано в доступе», RDP роняет сессию с ошибкой учётных данных при стопроцентно верном пароле, а в кластере вылезает «Access denied» там, где вчера всё работало. Я с осени 2025 года регулярно вижу этот тикет у клиентов, и почти всегда причина одна: два сервера с разными именами компьютеров на самом деле имеют один и тот же security identifier (SID) — внутренний идентификатор системы, по которому Windows теперь проверяет подлинность строже, чем по имени или IP.

С обновлений, вышедших 29 августа 2025 года и позже, Microsoft усилила проверку SID при аутентификации по Kerberos и NTLM в Windows 11 версии 24H2, Windows 11 версии 25H2 и Windows Server 2025 — это официально описано в статье поддержки KB5070568 «Kerberos and NTLM authentication failures due to duplicate SIDs». До этих обновлений дубликат SID мог годами оставаться незамеченным: аутентификация его почти не проверяла, сервер отвечал на запрос — и всё работало. Теперь при совпадении SID рукопожатие аутентификации отклоняется целиком, и вы получаете один из знакомых по описанию Microsoft симптомов: повторяющиеся запросы пароля, ошибку «имя пользователя или пароль указаны неверно» с заведомо верными данными, невозможность открыть общую папку ни по IP, ни по имени, обрывы RDP-подключений и отказ доступа в Failover Clustering. Если проблема всплыла на домене, а не только на двух отдельно стоящих серверах, я обычно заодно прогоняю более широкий аудит Active Directory — дубликаты SID там редко бывают единственной находкой.

Прежде чем чинить, стоит зафиксировать, что вы вообще видите — вот сжатый список симптомов именно этой проблемы, который отличает её от обычных сетевых сбоев.

• Одна и та же ошибка аутентификации повторяется на разных серверах после клонирования или после развёртывания из шаблона/снапшота
• SMB-шара недоступна и по IP, и по имени хоста, хотя пинг и разрешение имени работают нормально
• RDP обрывается с ошибкой учётных данных при подтверждённо верном пароле
• Failover Clustering отказывает в доступе узлам кластера, которые до обновления работали штатно
• В системном журнале есть событие с источником LsaSrv и текстом про «partial mismatch in the machine ID»

Что такое SID компьютера и почему разные имена ничего не значат

SID компьютера — это не имя и не запись в DNS, а внутренний идентификатор безопасности, который Windows генерирует при установке и использует для локальных учётных записей, разрешений на ресурсы и, в конечном счёте, для доверия между машинами при аутентификации. Официальная документация Microsoft по подготовке образов прямо говорит: генерализация образа удаляет специфичную для компьютера информацию, включая установленные драйверы и SID компьютера — то есть SID именно то, что должно становиться уникальным при каждом новом развёртывании, а имя компьютера для этого процесса вообще не имеет значения.

Проблема в том, что клонирование виртуальной машины «в лоб» — экспорт и импорт в Hyper-V, клон в VMware, превращение снапшота в отдельную рабочую машину — меняет только то, что вы явно поменяли: имя, IP, иногда MAC-адрес. SID самого компьютера при этом остаётся точно таким же, каким был у эталона на момент клонирования. Когда-то его переписывали утилитой NewSID от Sysinternals, но её сняли с распространения ещё в 2009 году, и для современных версий Windows она не годится. Раньше на это нарушение правил разворачивания часто закрывали глаза — сеть продолжала работать, несмотря на формальную ошибку, хотя Microsoft всегда прямо писала, что перенос установленной Windows на другой компьютер без Sysprep /generalize не поддерживается. Обновления с 29 августа 2025 года сделали её заметной: усиленная проверка SID отклоняет аутентификацию между машинами-близнецами, и именно поэтому у серверов с давно и явно разными именами вдруг перестаёт работать SMB и RDP — имя никогда не было тем, что проверяет Windows.

Как обнаружить дубликат SID: PsGetSid и событие 6167

Первым делом сверяю SID подозрительной пары серверов утилитой PsGetSid из набора Sysinternals PsTools — она переводит SID в читаемое имя и обратно, работает и с локальными, и с доменными учётками. Без параметров она показывает SID локального компьютера; если указать имя удалённой машины — её SID, причём имён можно перечислить несколько через запятую или подать список из файла:

psgetsid
psgetsid \\SRV-FILE,SRV-TS
psgetsid @servers.txt -u CONTOSO\admin

Ключ -u нужен, только если вы работаете из-под учётки без прав администратора на опрашиваемой машине; пароль при этом лучше не передавать через -p, а ввести в ответ на запрос — так он не останется в истории консоли.

Если SID компьютеров совпадают — вот и причина. Второй источник подтверждения — системный журнал: ищу событие с источником LsaSrv и кодом 6167 в разделе System, текст там характерный: «There is a partial mismatch in the machine ID. This indicates that the ticket has either been manipulated or it belongs to a different boot session. Failing authentication» — именно эту формулировку Microsoft приводит дословно в статье про восстановление Exchange Server на неподготовленном образе Windows Server 2025. В журнале Security на той же временной отметке параллельно видны ошибки SEC_E_NO_CREDENTIALS. Если в компании уже есть привычка разбирать историю входов по RDP, полезно поднять её заодно — я показывал, как читать события 4624 и 4625 для этого, в отдельном разборе аудита RDP-подключений, хотя там разбирается сам факт и время входа, а не дубликат SID.

Стоит сразу отделить эту проблему от вопроса «а у меня вообще RDP настроен правильно?». Если вы только разворачиваете терминальный доступ с нуля и разбираетесь с портом 3389, проверкой подлинности на уровне сети (NLA) и лицензированием, это отдельная тема — я закрывал её в руководстве по настройке удалённого рабочего стола. Здесь же сценарий другой: RDP годами работал штатно, а сломался именно после клонирования сервера и установки очередных обновлений — и чинить его нужно не пересозданием правил файрвола, а устранением дубликата SID.

Как правильно клонировать сервер: Sysprep и типичные ошибки

Единственный поддерживаемый способ подготовить образ для клонирования — прогнать Sysprep с параметром /generalize перед снятием образа или превращением машины в шаблон. Генерализация убирает SID компьютера вместе с установленными драйверами и прочей машинно-специфичной информацией, после чего каждая развёрнутая копия получает свой уникальный SID при первой загрузке — на проходе specialize, ещё до экрана OOBE. Команда для генерализации перед выключением и захватом образа выглядит так: %WINDIR%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown. Если вы генерализуете VHD, который будет разворачиваться как виртуальный диск на том же гипервизоре, Microsoft отдельно рекомендует добавить ключ /mode:vm. Два ограничения: запускать его можно только внутри виртуальной машины, а разворачивать такой VHD — только на гипервизоре с тем же профилем оборудования (сделали в Hyper-V — разворачиваете в Hyper-V с такими же параметрами ВМ): %WINDIR%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown /mode:vm.

Два нюанса, на которых я видел, как ломался Sysprep уже после того, как о нём вспомнили. Первый: если на эталонной машине перед генерализацией обновили хотя бы одно приложение из Microsoft Store через сам Store, а не офлайн-лицензированием для всех пользователей, Sysprep откажется отрабатывать — приложение оказывается привязанным к конкретной учётной записи, и в логах по пути %WINDIR%\System32\Sysprep\Panther появляется запись, что пакет установлен для пользователя, но не подготовлен для всех. Второй: у Sysprep есть предел по количеству запусков генерализации на одном образе — для Windows Server 2012 и новее, включая Windows Server 2025, это 1001 раз; после этого образ нужно пересоздавать заново, а не пытаться прогнать Sysprep ещё раз. Для парка одинакового железа, где не хочется терять настроенные устройства при каждой генерализации, в файле ответов есть параметр Microsoft-Windows-PnpSysprep | PersistAllDeviceInstalls — он сохраняет установленные устройства вместо их деинсталляции.

Эта же дисциплина обязательна, если вы разворачиваете сразу несколько узлов — например, ферму терминальных серверов клонированием одного подготовленного образа под каждую роль. Я разбирал саму сборку такой фермы в статье про настройку фермы RDP с балансировкой нагрузки; там принцип «один эталон — много копий» ровно тот случай, где пропущенный Sysprep всплывёт не сразу, а через несколько недель эксплуатации, когда прилетят обновления с усиленной проверкой SID.

• Настроить и проверить эталонный сервер целиком, включая роли и компоненты
• Прогнать sysprep.exe /generalize /oobe /shutdown непосредственно перед захватом образа
• Для VHD на том же гипервизоре — добавить ключ /mode:vm
• Не обновлять приложения из Microsoft Store через сам Store перед генерализацией
• После развёртывания копии проверить SID через PsGetSid, а не поверить на слово мастеру клонирования

Как чинить уже сломанные клоны — и почему смена имени или пароля не поможет

Если дубликат SID уже подтверждён PsGetSid и событием 6167, переименование компьютера, смена пароля учётной записи, выход и повторный вход в домен ничего не исправят — SID компьютера не привязан ни к одному из этих параметров и остаётся прежним. Единственное постоянное решение, которое называет сама Microsoft: пересобрать операционную систему на затронутых машинах, используя поддерживаемый способ клонирования с обязательной генерализацией образа через Sysprep. Для сервера с ролями это означает полную переустановку или разворачивание из корректно подготовленного образа — не косметическое исправление поверх текущей установки.

Если немедленная переустановка невозможна, а сервис нужно поднять здесь и сейчас, временное решение — обратиться в Microsoft Support for Business за специальной конфигурацией групповой политики; публичного ключа реестра или готового GPO-шаблона для самостоятельного применения Microsoft для этого случая не публикует, так что импровизировать с реестром я не советую — рискуете откатить заодно часть новой защиты. Обратите внимание и на масштаб последствий: в документации Microsoft отдельно разобран случай, когда дубликат SID на неподготовленном образе Windows Server 2025 ломал не только SMB и RDP, а Exchange Server целиком — письма зависали в очереди, репликация базы в группе доступности баз данных (DAG) сыпалась ошибками, а сами базы отказывались монтироваться. Это к тому, что если на клонированном сервере крутится что-то ещё, кроме файловых шар, — проверяйте SID превентивно, не дожидаясь жалоб пользователей.

Чем это отличается от проблем SMB-подписи и гостевого доступа в Windows Server 2025

На первый взгляд «шара недоступна на Windows Server 2025» — это как будто всегда одна и та же история, но за одинаковым симптомом «не могу открыть \\сервер\ресурс» в 2025–2026 годах прячутся минимум две разные причины с разными исправлениями. Я отдельно разбирал вторую — обязательную подпись SMB и отключённый по умолчанию гостевой доступ — в статье про SMB-подпись и гостевой вход на Windows Server 2025; там сервер и клиент вообще разные, а проблема — в политике подписи пакетов и в NAS, который пытается подключиться как гость. Здесь же, при дубликате SID, участники доступа — это два клона одного образа, и подпись SMB тут ни при чём: соединение отклоняется на уровне проверки идентификатора машины ещё до того, как дело доходит до согласования подписи пакетов.

Проще всего развести эти два сценария по паре признаков: | Признак | Дубликат SID | Проблема SMB-подписи/гостевого доступа | |---|---|---| | Когда началось | После клонирования без Sysprep + обновления с 29.08.2025 | После изменения политики подписи SMB, обычно с NAS или старым клиентом | | Кто участвует | Два сервера — клоны одного образа | Сервер Windows и NAS/устройство с гостевым или неподписанным SMB | | Событие в журнале | System, источник LsaSrv, код 6167 | События SMB-клиента/сервера о требовании подписи или отказе гостевого входа | | Диагностика | PsGetSid на обеих машинах | Проверка политики SMB signing и гостевого доступа на сервере и NAS | | Исправление | Пересборка ОС с генерализацией через Sysprep | Настройка подписи SMB и/или гостевого доступа на стороне NAS/клиента | Если по этой таблице признаки сходятся из обеих колонок сразу — например, клонированный сервер вдобавок раздаёт шару на старый NAS, — придётся закрывать обе проблемы по отдельности, они друг друга не устраняют.

Кейс: «Нитки и пуговицы» — 11 рабочих мест и дубликат SID при переходе на Windows Server 2025

Магазин швейных принадлежностей «Нитки и пуговицы», 11 рабочих мест — торговый зал, склад и бухгалтерия, — держал на старом сервере 1С, файловый архив накладных и печать этикеток. В середине августа 2025 года решили обновиться на Windows Server 2025 и заодно поднять второй сервер — для терминального доступа бухгалтеру, которая часть недели работает из дома. Штатный админ у них приходящий, появляется раз в неделю, поэтому для скорости он подготовил один сервер с нужными ролями и компонентами, а второй получил клонированием виртуальной машины в Hyper-V — экспортом и импортом, без Sysprep, потому что «оба сервера всё равно с разными именами и IP, какая разница».

Почти месяц всё работало: файловые шары открывались, RDP на терминальный сервер пускал бухгалтера без вопросов. После установки сентябрьского накопительного обновления KB5065426 (вышло 9 сентября 2025 года и принесло ту самую усиленную проверку SID) терминальный сервер перестал пускать по RDP: интерфейс требовал пароль повторно, хотя он вводился верно, а на файловом сервере часть папок вдруг стала недоступна с терминального сервера и по имени, и по IP. Админ две ночи сбрасывал пароли и переподключал серверы, после чего позвали нас. Я запустил psgetsid на обоих серверах и получил два одинаковых SID, совпадающих до последней цифры, — источник проблемы нашёлся за 20 минут. В системном журнале файлового сервера обнаружились те самые события LsaSrv 6167 с меткой времени, совпадающей с началом жалоб.

Так как терминальный сервер не хранил уникальных данных — только профили и настройки, которые были задокументированы, — переустановка обошлась дешевле, чем разбирательство с временным исправлением через поддержку Microsoft. Подготовили новый эталонный образ, прогнали Sysprep с /generalize /oobe /shutdown перед превращением машины в шаблон, развернули из него терминальный сервер заново, перенесли профиль бухгалтера и настройки удалённых рабочих столов. На всё — включая повторную проверку psgetsid на обоих серверах после пересборки — ушло три с половиной часа работы админа, без остановки работы магазина: пересборку делали вечером, а утром терминальный сервер уже принимал подключения с новым, уникальным SID. С тех пор в процессе разворачивания любой новой копии сервера у клиента обязательный пункт — Sysprep перед захватом образа, а не после первой жалобы пользователя.

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