Приєднання до домену через користувацький VPN і виживання після перезавантаження

Приєднання до домену можна виконати через VPN «точка — сайт». Чого таке з'єднання зазвичай не вміє — залишатися підключеним під час наступного перезавантаження, коли перший користувач домену намагається увійти. Зараз я проходжу приєднання в три етапи: доводжу шлях і виявлення, доки виконано вхід локального адміністратора, виконую приєднання, а потім перевіряю перший вхід у домен до передавання ноутбука. Кожен етап має тест, який зривається в іншому місці.

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

Перед підключенням: випуск, локальний адміністратор, DNS

Машині потрібен випуск, що підтримує приєднання до домену, і локальний адміністратор, уповноважений його виконати. VPN має працювати в тому самому сеансі, бо приєднання виконується в контексті безпеки, який ви використовуєте.

Спрямуйте клієнт на DNS каталогу організації, а не на публічний резолвер і не на запис у файлі hosts. Для приєднання потрібно знайти записи служб а потім досягти вузлів, які ці записи називають. Застарілий суфікс або публічний резолвер відправляють виявлення зовсім в інше місце.

Перевірте й годинник. Kerberos не терпить розбіжності в часі, а ноутбук, який місяць був офлайн, — часте джерело заплутаних помилок приєднання.

Підтвердьте, що домен можна виявити, а не лише пінгнути

Розв'яжіть запис LDAP SRV домену, перш ніж намагатися приєднатися. Для показового середовища з одним доменом ad.corp.example запит такий:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

Отриманий запис необхідний, але недостатній. Розв'яжіть кожне вказане в ньому ім'я DC і підтвердьте, що потрібні служби доступні через тунель. Ping за іменем домену майже нічого не доводить про виявлення.

Дозвольте документовані залежності AD: автентифікацію, трафік SMB і RPC, а також синхронізацію часу. Перевірте кожну з них щодо правил брандмауера, які ви справді розгорнули. Публікація портів контролера домену в інтернеті — не той короткий шлях, який варто розглядати.

Виконайте приєднання й прочитайте помилку

Використайте підтримувану команду приєднання або системний діалог і зафіксуйте точний текст помилки. «Зазначений домен або не існує, або з ним не вдалося зв'язатися» вказує на виявлення чи доступність, а не на облікові дані.

Якщо об'єкт із таким самим іменем уже існує, не видаляйте його рефлекторно. Це може бути заздалегідь підготовлений обліковий запис, а посилення netjoin обмежує частину випадків повторного використання залежно від власності й політики. Попросіть власника каталогу перевірити або виправити об'єкт.

Успішне приєднання — це середина, а не фініш. Наступний крок — той, який користувач справді перевіряє.

Сплануйте перший вхід у домен

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

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

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

Збережіть локальний доступ для відновлення

Збережіть схвалений локальний шлях відновлення до передавання ноутбука. Якщо перший вхід у домен не вдасться, вам потрібен шлях назад, який не залежить від того самого тунелю, що щойно відмовив.

Запишіть, що ви довели: розв'язання SRV, доступність DC, помилку приєднання, метод першого входу й обліковий запис відновлення. Цей запис — різниця між відтворюваним складанням і ноутбуком, що працює лише в офісі.