Доверие домена сломалось после месяца офлайн? Сначала проверьте

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

Ошибка выглядит как доверие, но три состояния похожи

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

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

Знакомое значение по умолчанию в 30 дней — это политика изменения, а не срок истечения офлайн. Объяснение Microsoft о пароле учётной записи машины описывает согласованный процесс изменения, и организация может настроить другой интервал.

Значок VPN ничего не доказывает о безопасном канале

Связность должна быть достаточно хорошей, чтобы дойти до служб домена, прежде чем какой-либо тест что-то значит. Это значит нужный DNS-резолвер домена, обнаруживаемый контроллер, доступные службы аутентификации и часы, достаточно близкие для Kerberos.

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

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Запишите DNS-сервер, разрешённый контроллер и точный текст ошибки. VPN-клиент, сообщающий о подключении, говорит, что туннель существует, а не что путь к домену работает. Контроллер, отвечающий на порту Kerberos, но не на порту каталога, — это находка брандмауэра, а не находка доверия.

Проверьте член, прежде чем его ремонтировать

На авторизованном члене домена Windows Test-ComputerSecureChannel -Verbose — это проверка канала между машиной и доменом только для чтения. Запускайте её в контексте исследуемой машины, а не с контроллера домена, у которого другая роль и другие правила восстановления. Сохраните вывод и код выхода вместо слова прошло или не прошло. Если в этой сборке нет cmdlet, модуль — отдельная проблема.

Результату всё ещё нужен контекст. Если машина не может достичь выбранного контроллера или аутентифицироваться на нём, неудачный тест не является независимым доказательством того, что офлайн-пароль истёк. Сохраните фактическую ошибку и использованный контроллер и повторите тест, когда путь станет заведомо хорошим.

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

Ремонтируйте только то отношение, которое доказали

Когда связность стабильна и администратор подтвердил, что ремонт уместен, режим -Repair этой cmdlet с авторизованными учётными данными — одна поддерживаемая операция для рабочей станции-члена. Он меняет отношение, и это не ещё один тест только для чтения.

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

После ремонта проверьте новый тест безопасного канала и исходную доменную операцию. Сохраните профили пользователей и состояние приложений, и не делайте удаление-и-повторное-включение первым необъяснённым действием.

Что проверять, когда сбой возвращается

Если сбой возвращается, смотрите на откат, двойную идентичность и время изменений учётной записи, а не сбрасывайте ту же учётную запись снова. Восстановленный образ, снимок, клонированная идентичность машины или сброс учётной записи компьютера, выполненный в другом месте, — все заслуживают расследования.

Временно успешный сброс — полезное свидетельство восстановления, но не доказательство того, что прерывистый VPN вызвал исходное несовпадение. Следующий случай и скажет, была ли причина когда-либо устранена.

Запишите контроллер, DNS-сервер и вывод теста в заявку. Именно эта запись отличает настоящий сбой доверия от ноутбука, который просто не смог найти домен.