Как найти причину блокировки аккаунтов в Active Directory?
Всем привет!
Помогите разобраться почему Active Directory блокирует пользователей, которые подключаются к корпоративной сети по vpn (l2tp).
Дано:
1. локальный Windows Server 2022 с последними обновлениями + Active Directory + файловое хранилище (samba)
2. фаервол Sophos XG 310, который выполняет роль шлюза и vpn сервера
3. клиентские машины с Windows 10 Pro
При подключении клиентской машины к vpn, сервер с AD пингуется, но если сразу попытаться войти на сетевой ресурс в файловом хранилище, аккаунт блокируется. В логах сервера есть информация о блокировке аккаунта, но нет информации почему. На клиенте в логах есть информация о блокировке winlogon.exe из-за неправильно введенного пароля. Иногда удается получить нормальный доступ к сетевым дискам, если после подключения к vpn, вылогиниться с Windows и залогиниться повторно. Не всегда это удается и аккаунт при попытке залогиниться повторно также блокируется.
При работе с сетевыми ресурсами с локальной сети или с удаленной сети, роутер в которой заранее установил подключения по vpn (создав таким обазом тунель), никакой проблемы с блокировкой аккаунта не возникает. Сетевые папки монтируются автоматически с помощью GPO в зависимости уровня доступа пользователя. Правило в GPO, которое могло бы блокировать пользователей отключено. Т.е. нет блокировки акканута при неправильно введенном пароле.
актуализация: аудит на сервере включен; правило GPO о периодической смене пароля выключено; пароли в менеджере паролей на клиентских машинах удалялись. результат тот же.
p.s. Cервер с AD 1,5 года назад был перенесен с Windows 2003 на Windows 2008, а потом на Windows 2022. пользователи подключались к vpn серверу по протоколу pptp. Потом протокол был заменен на l2tp для большей безопасности и шифрования тунелей. И скорее всего после этого начались проблемы с блокировкой аккаунтов.
p.p.s. Еще заметил, что на тестовой клиентской машине с чистым Windows блокировки аккаунта вообще не наблюдается, даже если пытаешься ввойти на сетевой ресурс сразу после подключения по vpn. Остальные служебные клиентские машины имеют Windows с подготовленного образа с предустановками, но и в локальных настройках я не могу найти правило, которые бы провоцировало блокировку доменных аккаунтов.
Дополнение от 04.10.2023: Причину блокировки пока не удалось найти. Зато нашел странные ошибки в журнале событий на серваке. Перед блокировкой тестового аккаунта в логах появляется событие 4769 с кодом 0х18 (Pre-authentication information was invalid), сообщающий о неудачной авторизации с помощью протокола Kerberos с указанием ip-адреса старой сети, от которой отключились перед подключением к vpn. Тип авторизации (logon type) при этом - 3 (сетевое подключение, как при открытии расшаренной папки). Похоже на то, что аккаунт блокируется уже в момент переключения с одной сети с доступом в интеренет на другую. Информации о том, какое приложение вызывает блокировку нет. Все PID и TID в логах указывают на lsaas.exe.
После этого следует куча похожих событий 4625 с кодом 0xC0000234 (user is currently locked out) уже с новым ip-адресом, выданным сервером vpn. Эти события отличаются только портом. Как будто идёт перебор и попытка подключиться, но уже с помощью протокола NTLS.
Вот такой вот полтергейст. Как найти причину блокировки аккаунтов?
aleks-th, те же доменные пользователи, которые работают локально и не имеют никаких проблем с блокировкой, при смене типа подключения и инициализации туннеля по vpn блокируются на AD в хаотичном порядке без конкретной причины.
aleks-th, я пока не до конца понимаю, что значит "обезличить компьютер" и можно ли это делать после того, как эти компьютеры уже несколько лет работают в домене? Речь идет об удалении привязки к аппаратным составляющим компьютера с помощью sysprep? Не слетит ли ключ активации или другие критически важные установки? Придется ли переустанавливать драйвера, дополнительное ПО, которое было установлено после установки Windows?
В общем причина пока не ясна. Усложняется все еще и тем, что пользователи блокируются не всегда. Поэтому поиск причины растягивается во времени.
На сервере AD заметил еще одну странную вещь: рассинхрон времени. Отставание от эталонных интернет-серверов на 10-60+ секунд. После замены сервера времени в установках по умолчанию на проверенные, разница стала меньше и сообщений о рассинхронизации гораздо меньше, но все равно присутствуют (по ночам или в выходные Zabbix по-прежнему информирует о разнице более, чем 60 сек.)
На другой виртуалке на том же физическом сервере, но на системе с Линукс таких проблем с синхронизацией времени нет. Все идеально совпадает с эталонным временем. В консоле сервера нет ошибки связанной с батарейкой CMOS.
Может проблема блокировки кроется в том, что время на сервере скачет в произвольном порядке, что приводит к непредвиденным последствиям, таким как блокировка аккаунтов при подключении к домену из другой сети? Если ответ да, то как на сервере Windows исправить эту ошибку?
Включите аудит неудачных попыток входа в систему (через групповую политику) и смотрите в журналах Security событий Windows на КД и на всех серверах, куда пользователи не могут получить доступ.
Предполагаемая причина, особенно, если у вас принята политика регулярной смены паролей для пользователей - устаревший запомненный пароль на устройствах пользователей. Обучите пользователей самостоятельно смотреть и удалять эти пароли.
Средний
Средний
Простой
