Сервер сетевых политик Windows не регистрирует неверные пароли в журналах NPS

Сервер сетевых политик Windows не регистрирует неверные пароли в журналах NPS

У меня есть NPS сервер для RADIUS от контроллера Aruba. Учет и аутентификация логов включены и работают,кромедля случаев, когда вход в систему не удается из-за неверного пароля.

Журналы безопасности
Все попытки аутентификации видны на сервере в журнале событий безопасности.
Категория задачи — «Вход» или «Сервер сетевой политики». Если категория — «Сервер сетевой политики»,код причиныуказано, 8 для неверного имени пользователя, 7 для неверного домена и т. д.
В журналах NPS также указывается «идентификатор вызывающей станции», который является MAC-адресом конечного пользовательского устройства (и информация, которая мне нужна для попыток ввода неверного пароля).

Плохие пароли
Попытки ввода неверного пароля регистрируются в журнале событий безопасности с категорией задач «Вход».
Они не отображаются в журналах NPS, и событие ненетсписок MAC-адресов.
Идентификатор события неудачных входов в систему — 6273; «код причины» янетв журналах указано 16, несоответствие учетных данных пользователя.

Я протестировал неверный пароль и неверное имя пользователя с одного и того же устройства (моего телефона) с использованием одного и того же контроллера.

Политики запросов на подключение / Сетевые политики
Я полагаю, что порядок обработки входа в систему каким-то образом важен, но я не знаю, где именно.
У нас есть одна политика запроса на подключение для использования проверки подлинности Windows с поставщиком проверки подлинности в качестве локального компьютера (это НЕ контроллер домена).
У нас есть несколько сетевых политик, и та, которая применяется к беспроводной сети, первая в списке.

Я полагаю, что неудачный вход с неверным паролем "не попадает" на уровень NPS, но почему бы и нет? Почему этот уровень обрабатывает неверное имя пользователя, а не неверный пароль? Что такого в входах, что они обрабатываются по-разному? (Разве разница не в другом коде возврата от DC?)

правка: После небольшого расследования, похоже, в журнале событий безопасности есть запись 4624 (успешный вход в систему), которая находится непосредственно перед записью 6278 (предоставление полного доступа NPS) дляуспешныйсоединения. Таким образом, получается, что учетные записи должны пройти этот начальный (сетевой) вход в систему.

Однако, я считаю, что "плохие имена пользователей" фильтруются в условиях сетевой политики. В настоящее время (помимо прочего) одним из условий является то, что учетная запись должна быть в Domain Users. Этоне правдаза плохие имена пользователей.

В любом случае, я не уверен, почему попытка ввода неверного пароля не будет обработана NPS, поскольку она должна быть недействительной.ограничениев таком случае.

Связанный контент