У меня есть сервер NPS для RADIUS с контроллера Aruba. Журнал учета и аутентификации включен и работает, за исключением случаев, когда вход не удается из-за неверного пароля.
Журналы безопасности
Все попытки проверки подлинности отображаются на сервере в журнале событий безопасности.
Категория задач - это сервер входа или сетевой политики.
Если категория "Сервер политики сети", указывается код причины , 8 для неверного имени пользователя, 7 для неверного домена и т.д.
Журналы NPS также указывают "идентификатор вызывающей станции", который представляет собой MAC-адрес устройства конечного пользователя (и информацию, которую я хочу получить для попыток ввода неверного пароля).
Плохие пароли
Попытки неверного пароля регистрируются в журнале событий безопасности с категорией задач входа в систему.
Они не отображаются в журналах NPS, а в событии не указан MAC-адрес.
Идентификатор события неудачного входа - 6273; "Код причины", который я не вижу в журналах, равен 16, несоответствие учетных данных пользователя.
Я проверил неверный пароль и неверное имя пользователя с одного устройства (моего телефона) с помощью одного контроллера.
Политики запроса соединения / Сетевые политики
Я полагаю, что порядок обработки входа в систему как-то важен, но я не знаю где.
У нас есть единая политика запросов на подключение для использования проверки подлинности Windows с поставщиком проверки подлинности в качестве локального компьютера (это НЕ контроллер домена).
У нас несколько сетевых политик, и та, которая подает заявку на беспроводную связь, является первой в списке.
Я полагаю, неверный пароль не удалось войти в систему "не делает это" на уровне NPS, но почему бы и нет? Почему плохое имя пользователя обрабатывается этим слоем, а не плохой пароль? Что насчет входов в систему, что они обрабатываются по-разному? (Разве это не просто другой код возврата от DC?)
редактирование: после более подробного изучения в журнале событий безопасности появляется запись 4624 (успешный вход в систему) непосредственно перед 6278 (NPS предоставляет полный доступ) для успешных подключений. Таким образом, кажется, что учетные записи должны пройти этот первоначальный (сетевой) вход в систему.
Тем не менее, для "плохих имен пользователей" я считаю, что они фильтруются в условиях сетевой политики. В настоящее время (среди прочего) одним из условий является то, что учетная запись должна быть в домене пользователей. Это не так для плохих имен пользователей.
В любом случае, я не уверен, почему попытка неверного пароля не будет обработана NPS, поскольку это должно быть недопустимым ограничением на этом этапе.