Довіра домену зламалася після місяця офлайн? Спершу перевірте

Ноутбук шість тижнів перебуває поза 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-сервер і вивід тесту в заявку. Саме цей запис відрізняє справжній збій довіри від ноутбука, який просто не зміг знайти домен.