Ноутбук, робочий обліковий запис і готельна мережа разом утворюють цикл входу, який не розривається жодною кількістю повторних спроб. Обліковий запис перебуває в Protected Users, що не дає Windows зберегти перевірне значення, потрібне для перевірки справжності користувача в автономному режимі. Будь-який план на кшталт «спершу увійдіть, потім підключіть тунель» має зворотний порядок, і захист робить саме те, що обіцяє. Далі припускається традиційний обліковий запис Active Directory на підтримуваному вузлі Windows.

Що захист насправді прибирає

Зазвичай Windows кешує перевірне значення, щоб обліковий запис домену міг увійти, коли контролер домену недоступний. Protected Users блокує це для облікового запису, що прибирає автономний вхід у домен як можливість, а не робить його ненадійним.

Це не звичайна проблема застарілого кешу, і звичайні засоби тут не діють. Повторний вхід у мережі, чергова зміна пароля або збільшення кількості кешованих входів не відновлять можливість, бо жодна з цих дій не створює перевірне значення, яке політика відмовляється зберігати. Обліковий запис поводиться так, як задумано, а задум припускає, що мережа є тоді, коли Windows її питає. Лікування симптому як збою кешу — це шлях, яким команди доходять до перебудови профілю, який ніколи не був зламаний.

Чому тунель має існувати до робочого столу

Пристрій має досягти перевірки справжності домену в ту мить, коли Windows її запитує, а це до появи будь-якого сеансу користувача. VPN-клієнт, який запускається лише після появи робочого столу, залишає новий вхід чекати шляху, який так і не з'являється. Залежність належить машині, а не користувачу, який ще не увійшов.

Використовуйте підтримувану схему попереднього входу, узгоджену з власниками кінцевих точок і ідентичностей. Тунель пристрою Always On VPN, автентифікований сертифікатом комп'ютера, підходить, коли керований пристрій відповідає передумовам такого розгортання. Підтримувана інтеграція екрана входу від постачальника — інший варіант. Звичайний профіль користувача з автоматичним тригером не є ні тим, ні іншим, хоч би як подібно він виглядав в інтерфейсі клієнта.

Цьому шляху потрібні розв'язання імен для домену, доступний контролер домену й ті протоколи автентифікації, які обліковий запис може використовувати, і жоден індикатор «підключено» цього не дає. Його маршрути й фільтри мають нести служби ідентичності й нічого зайвого, бо цей список префіксів і є та поверхня, яку отримує викрадений ноутбук до чийогось входу. Рішення про розділений тунель, ухвалені для тунелю користувача, не переносяться на тунель пристрою, тож розглядайте обидва окремо.

Доступність — це не сумісність автентифікації

Тунель може бездоганно передавати пакети, а перевірка справжності домену зазнає невдачі, бо випробуваний механізм — той, який обліковий запис не має права використовувати. У домені, що застосовує обмеження групи, NTLM недоступний учасникам, а Kerberos потребує сумісних з AES облікового запису й конфігурації. Шлях пакетів не може виправити ні того, ні того. Тому чистий ping до контролера домену не доводить, що вхід працюватиме.

У грі можуть бути й дві системи облікових даних. VPN може автентифікуватися в постачальника ідентичностей, тоді як Windows окремо потребує входу в домен, і прийняття першої нічого не каже про другу. «VPN підключився» і «користувач увійшов» — окремі спостереження, і виправлення одного не означає іншого.

Прочитайте докази автентифікації

Збирайте події від клієнта й від контролера домену для однієї спроби, а не лише з одного боку. Журнали Protected Users містяться в Applications and Services Logs\Microsoft\Windows\Authentication, і адміністратору, можливо, доведеться ввімкнути журнал, перш ніж він щось запише. Зіставте позначки часу з журналом підключення самого тунелю, бо помилка порядку з обох боків виглядає як збій облікових даних.

Перша команда нижче перелічує всі журнали автентифікації, які надає пристрій, тож ви читаєте той, що існує, а не той, який назвав якийсь допис у блозі. Друга читає останні записи, коли ім'я відоме. Шукайте пакет автентифікації, обліковий запис і умову відмови, бо відсутній мережевий шлях і відкинутий механізм залишають різні докази, і лише один із них — проблема VPN. Якщо тунель піднявся після спроби, порядок був неправильний, хоч би що казали ці записи.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

Доведіть межу з холодного завантаження

Виконайте тест зі стану виходу або щойно виконаного завантаження з обмеженим обліковим записом і тримайте відкритим схвалений шлях відновлення, перш ніж щось змінювати для привілейованих користувачів. Тест на вже робочому робочому столі не задіює жодної частини важливого шляху коду, і це пояснює більшість повідомлень про виправлення, яке трималося до наступного перезавантаження. Потім пройдіть чотири кроки в цьому порядку.

  1. Підтвердьте, що пристрій може знайти контролер домену до чийогось входу, за допомогою nltest /dsgetdc:corp.example.com.
  2. Спробуйте вхід у домен, потім запитайте, чи було взагалі отримано квиток, за допомогою klist.
  3. Прочитайте журнал автентифікації, який веде пристрій, двома командами вище, і занотуйте пакет та умову відмови.
  4. Підтвердьте, що схвалені резервні облікові дані досі працюють з екрана входу, бо це єдиний шлях назад, якщо тест межі не вдасться.

Відкриття файлового ресурсу з наданими обліковими даними теж не створює автономного інтерактивного входу, тож воно не замінює жодного кроку вище. Якщо організації справді потрібен вхід без підключення, відповідь — сумісний проєкт облікового запису й кінцевої точки, обраний свідомо. Вилучення облікового запису з групи або збереження одного необмеженого аварійного входу на кожному ноутбуці — це рішення політики ідентичностей, яке зміна VPN не може ухвалити за вас.

Документація Protected Users описує і поведінку перевірного значення, і доменні обмеження, від яких залежить цей проєкт. Сплануйте процес відновлення до того, як хтось вирушить у подорож, бо тест холодного завантаження — єдине місце, де його відпрацьовують.

Схожі статті