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

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

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

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

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

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

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

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

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

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