Не удалось установить доверительные отношения между рабочей станцией и доменом: как починить за 10 минут

Ошибка «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» в девяти случаях из десяти лечится без переустановки Windows — командой Test-ComputerSecureChannel -Repair или nltest /sc_reset за 10 минут. Ниже — как понять, кто виноват: компьютер или сам домен, и когда без полного перевода машины в домен всё-таки не обойтись.

Что за ошибка и что именно ломается между компьютером и доменом

Пятнадцать лет я вижу одну и ту же панику при этой ошибке: пользователь не может войти под доменной учёткой, сосед по опенспейсу уверенно говорит «домен упал», и все начинают перезагружать контроллер домена, хотя чаще всего проблема — не в домене, а в одном конкретном компьютере. Сообщение «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» — не про сеть и не про DNS, это про пароль компьютерной учётной записи, который перестал совпадать с тем, что хранит Active Directory. Если совсем нет времени разбираться — переходите сразу к разделу с командами, там три рабочих способа. Если хочется понимать, что именно чините, — читайте по порядку; на таком же аудите я обычно заодно привожу в порядок Active Directory целиком, потому что сломанное доверие редко бывает единственной проблемой в инфраструктуре.

Технически это называется secure channel — защищённый канал между компьютером и контроллером домена, построенный поверх службы Netlogon. У каждого компьютера, как и у пользователя, есть собственная учётная запись с паролем; этот пароль компьютер и контроллер домена меняют синхронно, без участия человека, и в любой момент времени обязаны «знать» один и тот же секрет. Как только они расходятся, контроллер домена отказывается подтверждать подлинность компьютера, и в системном журнале появляется Event 3210 от источника NETLOGON с текстом о том, что компьютер не смог пройти аутентификацию и поэтому может отклонять запросы на вход. Официальная документация Microsoft описывает именно эту связку симптомов: ошибку на экране входа, Event 3210 и то, что зайти можно только под локальной учётной записью или по кэшированным доменным учётным данным — это не баг, а штатное поведение защиты.

Кто виноват — компьютер или домен: сравниваем pwdLastSet и cupdtime

Прежде чем что-то чинить, я всегда смотрю, с какой стороны разошёлся пароль, потому что от этого зависит, что именно чинить — компьютер или Active Directory. У Active Directory для каждого компьютерного объекта есть атрибут pwdLastSet — когда домен в последний раз видел смену пароля. У самой рабочей станции есть свой локальный секрет LSA, время его последнего обновления Microsoft называет cupdtime, и оно хранится в защищённой части реестра. Если pwdLastSet в AD новее, чем cupdtime на компьютере, — машину откатили назад: восстановили из бэкапа образа, вернули на старый снапшот виртуалки или подняли после сбойного System Restore. Если, наоборот, у компьютера пароль новее, чем видит домен, — проблема на стороне контроллеров: репликация не донесла свежий пароль до того DC, с которым сейчас общается клиент, либо этот DC сам недавно восстановлен из бэкапа.

Смотреть pwdLastSet проще всего через модуль Active Directory для PowerShell, а cupdtime — через реестр; ветка HKLM\SECURITY по умолчанию доступна только системной учётной записи, поэтому я либо запускаю reg query через PsExec с ключом -s, либо временно выдаю себе права на ветку и потом убираю. Вот минимальный набор команд, который я гоняю на затронутой машине и на контроллере домена:

# на контроллере домена или там, где стоит модуль ActiveDirectory
Get-ADComputer 'PC-KROY-03' -Properties PasswordLastSet | Format-List

# на самой рабочей станции, из cmd.exe от имени SYSTEM (например, psexec -s -i cmd.exe)
reg query "HKLM\SECURITY\Policy\Secrets\$MACHINE.ACC\CupdTime"

# reg query вернёт hex, например 26A38C1AA0F4DA01: переставляем байты в обратном
# порядке (01DAF4A01A8CA326), переводим в десятичное и отдаём w32tm
w32tm /ntte 133688107438220070

Если под рукой несколько контроллеров домена, я дополнительно сверяю pwdLastSet сразу по всем через repadmin /showobjmeta * "CN=PC-KROY-03,OU=Workstations,DC=corp,DC=example,DC=com" > C:\temp\pc-kroy-03-meta.txt — расхождение значений между разными DC само по себе говорит, что дело в репликации, а не в конкретном компьютере, и разбираться нужно уже не с рабочей станцией.

Три команды, которые чинят большинство случаев — без переустановки и почти всегда без потери профиля

Если причина — банальное расхождение пароля без более глубоких проблем на контроллерах, есть три инструмента, которые под капотом делают почти одно и то же: используют службу Netlogon, чтобы пересобрать защищённый канал или сразу сменить пароль компьютера. Первый — классика ещё со времён доменов NT: nltest /sc_reset:corp.example.com, выполняется из cmd.exe, запущенного от администратора; Microsoft в инструкции по восстановлению канала прямо пишет запускать его с учётными данными администратора домена (например, через runas), и я так и делаю. Второй — его PowerShell-аналог: Test-ComputerSecureChannel -Repair, который, по документации Microsoft, работает через тот же Netlogon и требует, чтобы текущий пользователь был членом локальной группы «Администраторы» на этой машине; а поскольку вы в этот момент сидите под локальной учёткой, доменные права передаются параметром -Credential — в инструкции Microsoft это -Credential * с учётной записью администратора домена:

Test-ComputerSecureChannel -Repair -Credential CORP\admin.ivanov

Оба варианта работают только с существующим объектом компьютера — они не помогут, если объект в AD удалили (например, скриптом чистки «мёртвых» учёток), а отключённый объект сначала нужно включить обратно в ADUC.

Третий инструмент — Reset-ComputerMachinePassword, он не проверяет канал, а сразу меняет пароль компьютерной учётной записи и одним действием записывает новое значение в Active Directory:

Reset-ComputerMachinePassword -Server "DC01.corp.example.com" -Credential CORP\admin.ivanov

Я использую его, когда Test-ComputerSecureChannel -Repair без дополнительных учётных данных отработал молча, но при следующем входе ошибка вернулась — значит, штатной попытки Netlogon было недостаточно, и пароль нужно продавить принудительно от имени учётки с правами на объект компьютера в AD. После любой из трёх команд, по официальной инструкции Microsoft, стоит перезагрузить компьютер: Netlogon подхватывает новый секрет и без перезагрузки, но кэш Kerberos-билетов на рабочей станции живёт до следующего логона, и часть служб может ещё какое-то время работать со старым токеном.

Чтобы не гадать, с чего начинать, я иду по возрастанию инвазивности: | Способ | Что делает | Чьи права нужны | Перезагрузка | |---|---|---|---| | nltest /sc_reset:domain | Пересобирает secure channel через Netlogon | Админ на машине; Microsoft советует — от доменного администратора | Рекомендована | | Test-ComputerSecureChannel -Repair | То же самое, PowerShell-обёртка над Netlogon | Локальный админ + доменная учётка в -Credential | Рекомендована | | Reset-ComputerMachinePassword | Принудительно меняет пароль компьютерного объекта и пишет его в AD | Права на смену пароля объекта в AD | Рекомендована | | Полный перевод из домена и обратно (Add-Computer) | Создаёт компьютерный объект заново | Права на создание объектов в нужном OU | Обязательна | Первые два способа я запускаю первыми — они самые дешёвые по времени и рискам. Не помогло — пробую Reset-ComputerMachinePassword. И только если объект в AD битый или удалён, берусь за полный перевод, о нём — в следующем разделе.

Когда ремонта канала недостаточно — нужен полный повторный ввод машины в домен

Бывает, что все три команды из предыдущего раздела просто не срабатывают — обычно по одной из трёх причин: компьютерный объект в Active Directory удалили, например автоматической чисткой стухших учёток, и восстановить его из корзины AD (если она вообще включена) уже нельзя; у машины повреждён сам Netlogon или локальная политика безопасности; либо в сети появился второй компьютер с тем же именем — текст Event 3210 прямо упоминает такую возможность, и тогда два клиента по очереди «перебивают» пароль одного объекта. В первых двух случаях чинить нечего — компьютер нужно вывести из домена в рабочую группу, а затем снова ввести в домен, создав объект заново; в третьем сначала переименуйте дубль. Microsoft, кстати, прямо называет повторный ввод в домен допустимым решением — просто оно не объясняет, почему доверие сломалось, и при повторяющихся сбоях причину всё равно придётся искать.

Из PowerShell это делается связкой Remove-Computer (или простым выходом в рабочую группу через параметры системы) и Add-Computer:

Add-Computer -DomainName 'corp.example.com' -Server 'dc01.corp.example.com' -Credential 'CORP\admin.ivanov' -OUPath 'OU=Workstations,DC=corp,DC=example,DC=com' -Restart

Важный нюанс, о котором часто забывают: с августа 2024 года из-за security hardening для join домена (KB5020276) параметр -Server в Add-Computer принимает только полное доменное имя контроллера, а не короткое NetBIOS-имя — если написать -Server DC01, команда завершится ошибкой уже на актуальных сборках Windows. Это тот же самый hardening, из-за которого у части клиентов с делегированными правами на компьютеры в AD отваливается повторный ввод в домен с кодом 0xaac — я разбирал этот смежный, но другой по природе кейс в статье про повторный ввод компьютеров в домен: там проблема не в пароле секур-канала, а во владельце объекта, и лечится она иначе.

Три типичные причины именно в небольшом офисе

За годы работы с компаниями до полусотни рабочих мест я вижу три повторяющихся сценария, и все три — не про домен, а про то, как устроена инфраструктура вокруг него. Первый и самый частый — откат виртуальной машины на снапшот. Если рабочая станция — это VDI или тестовая виртуалка на Hyper-V, а администратор откатывает её к более раннему checkpoint после неудачного теста, локальный секрет компьютера тоже откатывается назад. Если за это время прошла плановая смена пароля компьютерной учётки (по умолчанию раз в 30 дней — это значение политики «Domain member: Maximum machine account password age», задаётся числом от 1 до 999 дней), Active Directory уже знает новый пароль, а откаченная машина — всё ещё старый. Это ровно тот сценарий, который официальная документация Microsoft описывает как «Active Directory has a newer password value than the client device», и там же перечислены признаки: скачок дат в журнале событий, недавнее время безотказной работы (аптайм), событие запуска ядра Kernel-General с ID 12 сразу после отката.

На стороне самих контроллеров домена похожая история выглядит иначе и лечится не на клиенте, а на DC — если виртуализированный контроллер домена откатили по снапшоту без защиты VM-Generation ID, может сломаться уже не отдельная рабочая станция, а репликация или SYSVOL для всего домена; я разбирал похожий инцидент в статье про откат контроллеров домена по снимкам — там VM-Generation ID восстановил базу AD, но не связанную с ней службу DFS Replication для SYSVOL. Второй частый сценарий проще: восстановление рабочей станции из бэкапа образа или через точку восстановления системы — результат для secure channel тот же самый, только причина не в гипервизоре, а в агенте бэкапа или в штатном System Restore, который Windows иногда сама предлагает после сбойной загрузки.

Третья причина стоит немного особняком, но соседствует с первыми двумя чаще, чем кажется на первый взгляд: рассинхронизация времени между рабочей станцией и контроллером домена. Сама по себе она выдаёт другое сообщение — Kerberos начинает ругаться на рассинхронизацию времени, а не на доверие к домену, — но на практике я часто вижу обе проблемы вместе именно на восстановленных из снапшота машинах: часы после отката тоже уезжают назад, а служба точного времени не всегда успевает их поправить до первой попытки входа. Поэтому в диагностике я по умолчанию проверяю не только пароль, но и расхождение времени между клиентом и контроллером — это дёшево и иногда экономит повторный визит на ту же машину через день.

Кейс: VDI-рабочее место раскройного цеха на трикотажном производстве «Тёплая петля»

Ко мне обращалось трикотажное производство «Тёплая петля» — 21 рабочее место, из которых три — виртуальные рабочие столы для раскройного цеха на отдельном сервере с Hyper-V: раскройщицы работают в CAD-программе построения лекал, а сами виртуалки крутятся на выделенном хосте рядом с сервером 1С. В пятницу вечером их сисадмин тестировал обновление CAD-пакета на одной из VDI, сделал контрольную точку (checkpoint) перед обновлением, обновление повело себя не так, как ожидалось, и он откатил машину на снапшот, снятый тремя неделями ранее, решив, что вернуться назад безопаснее, чем разбираться в новых настройках CAD в разгар недели.

В понедельник утром раскройщица не смогла войти под доменной учёткой — тот самый экран с «не удалось установить доверительные отношения». Первым делом я поднял Event Viewer на VDI и увидел Event 3210 от NETLOGON и Kernel-General Event 12 со временем запуска, которое явно не билось с тем, что машина должна была работать без перезагрузок всю неделю. Дальше сверил даты: Get-ADComputer показал pwdLastSet двенадцатидневной давности — то есть уже после того, как был снят снапшот, живая машина по расписанию прошла плановую 30-дневную смену пароля компьютерной учётки, и AD запомнил новый секрет. Компьютер же после отката помнил пароль, действовавший три недели назад, а cupdtime из реестра показал дату старше pwdLastSet — классический случай «AD has a newer password value than the client device».

Чинил я стандартно: Test-ComputerSecureChannel -Repair -Credential CORP\admin прямо на VDI, затем перезагрузка — канал восстановился с первой попытки, без переноса профиля и без обращения к резервным копиям. На всё — от первого тикета до подтверждения входа пользователем — ушло 25 минут, из них добрую половину я потратил не на саму команду, а на то, чтобы убедиться, что расхождение именно в пароле, а не в репликации между контроллерами (благо у клиента домен с одним DC, и второй сценарий сразу отпал). По итогам я перевёл раскройные VDI на отдельную политику: снапшоты для доменных рабочих столов теперь живут не дольше 7 дней, а сразу после любого отката старше суток сисадмин обязан сам прогнать Test-ComputerSecureChannel -Repair, не дожидаясь жалобы пользователя, — это ушло в чек-лист процедуры отката, который мы оформили вместе.

Как снизить риск повторения: профилактика для малого офиса без выделенного AD-инженера

Если в инфраструктуре вообще есть виртуализированные рабочие места или тестовые VM, подключённые к домену, я всегда прошу выделить для них отдельную политику снапшотов — короткий срок жизни контрольной точки и обязательное правило чинить secure channel сразу после любого отката, а не ждать понедельничной жалобы пользователя. Второе правило — держать под рукой рабочий локальный администратор на каждой машине: пока доверие сломано, войти под доменной учёткой нельзя, а под локальной — можно, и именно так я обычно первым делом попадаю на проблемный компьютер, чтобы прогнать команды из раздела выше. Ротацию паролей локальных администраторов удобнее не держать в головах — это отдельная тема, я про неё писал в статье про локальных администраторов и LAPS.

Третье — мониторинг вместо героического реагирования постфактум. NETLOGON исправно пишет Event 3210 при обрыве канала и Event 5823 при успешной смене пароля; если в компании уже стоит система мониторинга логов, эти два ID стоит завести в оповещения отдельно от общего шума System-журнала — тогда о сломанном доверии узнаёте вы, а не сотрудник через заявку в техподдержку. Для разовых массовых проверок по всем рабочим станциям я не хожу по каждой машине руками, а гоняю Test-ComputerSecureChannel в цикле по списку компьютеров через Invoke-Command — со сценариями такой автоматизации я разбирался в статье про PowerShell-скрипты для администрирования AD; тот же подход годится и для регулярной профилактической проверки secure channel по всему парку машин без ручного обхода.

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