Почему ноутбуку с Protected Users нужен VPN до входа в систему
Protected Users не даёт Windows кэшировать проверочное значение входа, поэтому туннель должен существовать до рабочего стола. Докажите границу, затем проверьте резервный путь.
Ноутбук, работающая учётная запись и гостиничная сеть вместе дают цикл входа, который не разрывается никаким числом повторных попыток. Учётная запись находится в 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Докажите границу из холодной загрузки
Проведите тест из состояния выхода или только что выполненной загрузки с ограниченной учётной записью и держите открытым одобренный путь восстановления, прежде чем что-либо менять для привилегированных пользователей. Тест на уже работающем рабочем столе не задействует ни одной части важного пути кода, и это объясняет большинство сообщений об исправлении, которое держалось до следующей перезагрузки. Затем пройдите четыре шага в этом порядке.
- Подтвердите, что устройство может найти контроллер домена до чьего-либо входа, с помощью
nltest /dsgetdc:corp.example.com. - Попробуйте вход в домен, затем спросите, был ли вообще получен билет, с помощью
klist. - Прочитайте журнал проверки подлинности, который ведёт устройство, двумя командами выше, и отметьте пакет и условие отказа.
- Подтвердите, что одобренные резервные учётные данные всё ещё работают с экрана входа, потому что это единственный путь назад, если тест границы не удастся.
Открытие файлового ресурса с переданными учётными данными тоже не создаёт автономного интерактивного входа, поэтому не заменяет ни одного шага выше. Если организации действительно нужен вход без подключения, ответ — совместимый проект учётной записи и конечной точки, выбранный осознанно. Исключение учётной записи из группы или хранение одного неограниченного аварийного входа на каждом ноутбуке — это решение политики удостоверений, которое изменение VPN не может принять за вас.
Документация Protected Users описывает и поведение проверочного значения, и доменные ограничения, от которых зависит этот проект. Спланируйте процесс восстановления до того, как кто-то отправится в поездку, потому что тест холодной загрузки — единственное место, где он отрабатывается.