none
Вопрос про Kerberos, eventid 4771 RRS feed

  • Вопрос

  • Добрый день.

    Обратил внимание, что в логах в AD частый гость eventid 4771, причем с ошибкой 0x18, что введен неправильный пароль. Но по идее должен счетчик неправильно введенных паролей в учетке увеличиваться. В домене стоит политика, при вводе 10 раз неправильно паролей учетная запись блокируется на 30 минут. Но от некоторых пользователей этот запрос исчисляется в день тысячами, я думаю что это перебор пароля... но почему учетная запись не блокируется?

    Например 5 эвент событий в секунду по разным портам и через 6 секунд опять 5 эвент событий с разными исходящими портами, пользователь один и тот же на всех событиях.

    27 марта 2019 г. 6:02

Ответы

Все ответы

  • 1. Прилинкована ли политика безопасности (n не верных вводом = блок) на ту OU, где находится данный мользователь?

    2. Не установлена ли блокировка наследования политик на данной OU?

    3. Вообще посмотреть результирующую политику, применяется ли они на конкретного пользователя?

    4. Удостовериться, что вы снимаете правильные счётчики. Не знаю как смотрите вы, но предлагаю посмотреть powershell`ом:

    Get-ADUser -Identity ИМЯ -Properties badPwdCount,LastBadPasswordAttempt

    Покажет количество не верных вводов пароля и когда таковой был введён в последний раз

    5. Если домен конфигурировали не Вы, а кто-то до вас, то можно посмотреть в сторону наличия гранулированных политик. Т.е., например, ваши параметры безопасности работают от default domain policy, гранулированная политика может перекрывать эти параметры.

    Но! Работает она именно для группы безопаности.

    28 марта 2019 г. 4:50
  • 1. Политика паролей настроена на default domain policy.
    2. Блокировки нет, перепроверил, у меня те же самые политики накатываются.
    3. Политика применяется нормально, перепроверил. Но еще сделаю пару тестов.
    4. Счетчики снимаю так же, через Powershell, самое интересное,что счетчик на контроллере который последний обслуживал данного пользователя, показывает:
    badPwdCount            :  0
    LastBadPasswordAttempt : 19/11/2018 10:37:45 AM
    Но Event логи 4771 с ошибкой 0х18 присутствуют в больших количествах, с этого же контроллера, т.е. я смотрю на всех контроллерах кем он может обслуживаться и ситуация аналогичная. Странное поведение, которое я не могу понять.

    5. Параметры не перекрываются, потому как у меня и у него политики одинаковые.


    • Изменено Simba10 28 марта 2019 г. 6:43
    28 марта 2019 г. 6:40
  • Попробуйте ради инетерса изменить значение количества не верных вводов для блокировки

    Затем на тестовой станции сделайте gpupdate /force , перегрузитесь и попробуйте ввести не верно пароли.

    Вообще очень странная ситуация.

    Если не поможет, создайте отдельную политику блокировки и линканите на тестовую OU, и проверьте.

    Остаётся надеяться, что нет проблем с самой default domain policy

    28 марта 2019 г. 8:41
  • Добрый день,

    Если у вас включена история предыдущих паролей (более 2), то использование предыдущего пароля не вызовет увеличения счётчика неправильного пароля (допустим предыдущий пароль где-то сохранён у пользователя), но событие появится.  Почистите сохранённые пароли у "подозрительных" юзеров.

    https://social.technet.microsoft.com/wiki/contents/articles/32490.active-directory-bad-passwords-and-account-lockout.aspx#Account_Lockout_in_Windows_TwoThousandThree_and_Above

    ---------cut------------

    The first login attempt on this client is again a password among the 2 most recent in history, so nothing is updated

    ---------cut------------

    • Помечено в качестве ответа Simba10 31 марта 2019 г. 22:38
    28 марта 2019 г. 8:58
  • Mikhail Efimov: Вот этого не знал, спасибо за статью, поставил временно историю предыдущих паролей в 0, посмотрю что будет.

    DmitryG_IT: Спасибо за совет, буду это тоже тестировать.

    Отпишусь как все протестирую.


    28 марта 2019 г. 23:18
  • точно, сделал это значение в 0 и учетки начали блокироваться. Кроме одной, но тут надо разбираться глубже. Спасибо! 

    31 марта 2019 г. 22:38