пятница, 20 ноября 2009 г.

Решаем проблему внезапной блокировки учетной записи

Впервые статья была опубликована в ноябрьском номере журнала "Системный администратор".

Доводилось ли вам сталкиваться с тем, что пользователи не могут войти в компьютер? Что же делать в случае, если учетная запись существует, она не отключена да еще и пароль правильный?

Иногда возникают ситуации когда, при попытке входа в компьютер, пользователь получает сообщение Unable to log you on because your account has been locked out, please contact your administrator.

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

Оказалось, что данная тема актуальна до сих пор. И мне постоянно приходиться отвечать на вопросы, не только начинающих, но и опытных администраторов.

Сообщение о блокировке учетной записи выглядит как показано на рисунке (см. рисунок 1).

image1

Рисунок 1 - Сообщение об ошибке, которое получает пользователь с заблокированной учетной записью

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

Для того, чтобы определить политику запустите Group Policy Management Consoleю.

По умолчанию политика выглядит так, как показано на рисунке (см. Рисунок 2):

image2 РиРисунок 2 - Политика Account Lockut Policy по умолчания

Предположим, что вы хотите, ограничить количество неправильных вводов пароля пятью попытками, а потом блокировать акаунт на 30 минут. Для этого вам нужно отредактировать Default Domain Policy (помним, что политики паролей в доменах Win 2003 применяются к уровню ДОМЕНА)- Выберите Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy. Затем отредактируйте параметры групповой политики. Значение параметрп Account lockout duration - определяет время, на которое акаунт будет заблокирован. Account lockout threshold – определяет количество попыток ввода, после которого акаунт будет заблокирован. И наконец последний параметр - Reset account lockout counter after – определяет время, по истечению которого будет сброшен счетчик попыток. Например, если вы определили, что после пяти попыток акаунт будет заблокирован, а сделали только две попытки входа, а потом, например ушли пить чай, то по истечении этого установленного времени счетчик обнулиться и у вас опять будет пять попыток.

Попробуйте изменить любой из параметров и система предложит вам оптимальные, с ее точки зрения, значения остальных параметров (см. Рисунок 3).

image3 

Рисунок 3 - Значения, которые предлагает система

Вы можете согласиться, а потом, при необходимости, изменить их по совему усморению. Например, если вы установите значение параметра Account lockout threshold соответствющее 5, а затем нажмете OK, то система предложит вам 30 минутное значение для остальных параметров. Как показано на рисунке 3.

После того, как политика будет определена Вы можете известить ваших пользователей о том, что после того как они введут неверный пароль несколько раз его учетная запись будет «заблокирована» (locked). Что бы снять блокировку нужно снять галочку «Account is locked out» в свойствах пользователя, как показано на рисунке 4.

image4

Рисунок 4 - «Account is locked out» в свойствах пользователя

Иногда блокировка акаунта происходит без видимых причин. И не смотря на то, что блокировка так просто снимается, в некоторых случаях, это не решает проблему. Через некоторое время пользователь может обнаружить, что его учетная запись опять заблокирована. Причин тому может быть несколько и я опишу их далее. Иногда определить причины бывает довольно сложно. Основная сложность в определении компьютера, с которого происходят попытки ввода неверных паролей.

В журнале безопасности, для отслеживания подобных событий, существует запись с кодом 680, от источника Security, категории Account Logon.

image5

Рисунок 5 - Вид сообщения из Журнала Событий

В  этой записи (см. рисунок 5) показана информация о том в какое время и с какого компьютера была предпринята попытка ввода неверного пароля. Конечно есть способ реагировать на событие немедленно. Я писал о нем в статье «Как отреагировать на событие». Если вы отслеживаете появления подобных записей и своевременно реагируете на них, то определить источник проблемы будет просто. Но, как правило, таких записей может быть ОГРОМНОЕ множество. И никто не реагирует на них немедленно, а расследует инцеденты потом. Пользователи часто ошибаются с вводом пароля. И не существует простого способа определить точное время того, когда акаунт был заблокирован. Как правило мы узнаем об этом через некоторое время, от самого пользователя.

В решении проблемы нам может помочь утилита Microsoft Account Lockout Status, которая входит в пакет утилит Account Lockout and Management Tools. Получить этот пакет можно на сайте Microsoft. Утилита была выпущена еще в 2003 году. Удивительно, что спустя много лет она все еще востребована.

Принцип работы утилиты заключается в том, что она анализирует журналы событий на всех контроллерах домена в сети и определяет на каком контроллере произошла блокировка, в какое время, а так же предоставляет дополнительную информацию, которая может помочь нам в расследовании. Так же утилита может помочь снять блокировку с учетной записи и многое другое.

Чтобы приступить к работе с утилитой вам нужно запустиь файл LockoutStatus.exe. Когда программа запуститься выберите меню File, а затем Select Target. В появившемся диалоговом окне,

image6

Рисунок 6 - Окно ввода данных о пользователе, учетная запись которого блокируется>

в поле Target User Name, введите имя пользователя, у которого возникает проблема с учетной записью, а в поле Target Domain Name, введите имя домена в котором находиться учетная запись пользователя.

Обратите внимание на галочку - «Use Alternate Credentials». В случае если программа запущена с правами обычного пользователя то установив эту галочку вы можете запустить проверку от имени другого пользователя, входящего в группу Администраторы домена. Если же вы запустили программу от имени пользователя с правами доменного администратора, то устанавливать галку не нужно.

После не продолжительного процесса сбора информации вы увидите результаты работ, в котором будет отражено на каком контроллере домена была заблокирована запись, в какое время, сколько попыток ввода неверного пароля было предпринято и т.д. Все это показано на рисунке (см. Рисунок 7).

Рисунок 7 - результат работы программы

Из меню этой же программы вы можете снять блокировку с учетной записи. Для этого выберите контроллер домена, нажмите правой кнопкой, и в контекстном меню нажмите Unlock Account (см. Рисунок 8).

image8

Рисунок 8 - Снимаем блокировку с учетной записи>

Это изменение моментально будет реплицировано на все контроллеры домена, и пользователь может тут же повторить попытку входа. Если пользователь забыл пароль, то выбрав Reset User’s Password вы можете его сменить.

Иногда, возникают ситуации, когда после удачного входа в систему проблема возвращается. Пользователь не может получить доступ к сетевому ресурсу, не может повтороно войти в систему и т.д. Причин такому поведению может быть несколько. Я приведу лишь несколько самых популярных из них. Но помните, что универсального решения нет и каждый случай нужно расследовать индивидуально.

Например в сети может действовать злоумышленник, который пытается подобрать пароль от учетной записи пользователя. Второй распространённый вариант это использование одной учетной записи несколькими пользователями одновременно. В этом случае кто-то может постоянно вводить неверный пароль, тем самым мешать работе остальных пользователей. Начиная расследование, первое, что мы должны установить – это точное время происшествия. Установив время, мы легко сможем найти запись в журнале безопасности и понять с какого компьютера в сети производились попытки ввода неверного пароля. Как видно на рисунке 7 программа сообщает нам эти сведения. Щелкнув правой кнопки мыши по контроллеру домена и выбрав в контекстном меню Open Event Viewer (Открыть Журнал Событий). Так как мы теперь знаем точное время, когда была попытка входа, которая привела к блокировку учетной записи, мы без труда сможем найти событие и определить с какого компьютера было произведено действие повлекшее блокировку. Проблема решена – виновные наказаны!

Но кроме человеческого фактора есть еще и другие причины. Пожалуй самая распространенная причина в том, что когда вы настраиваете Назначенное Задание, которое выполняется от имени пользователя, а затем меняете пароль этого пользовател. Ваше задание все еще пытается выполнить вход со старым паролем. Естественно у него это не получается и акаунт блокируется.

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

Михаил Даньшин

18 комментариев:

  1. Большое ПАСИБА! Возможно, Ваша заметка будет мне полезна. У меня похожая ситуация в одном из доменов: самопроизвольные блокировки учетных записей. Пока решил проблему настройкой политики снятия блокировки через 30 сек. Теперь попробую описанный Вами метод :)

    Qwert (qwertrob(собачка)rambler.ru)

    ОтветитьУдалить
  2. И Вам большое спасибо за Ваш отзыв!
    Всегда приятно осознавать, что пишу не зря.

    ОтветитьУдалить
  3. Только в этой статье так и не раскрыто как найти то что блолокирует учетную запись. да с помошью Altools можно быстро посмотреть и разблокировать юзверя.

    ОтветитьУдалить
  4. не забываем про вирусятину типа confiker (kido) за утиль пасибо, провереная штука.

    ОтветитьУдалить
  5. Все в этой статье отлично написано и работает!
    Только что остановил начавшуюся вирусную эпидемию только благодаря этой статье - респект, Михаил!!

    Открываете журнал безопасности, ищете событие 680 (их при эпидемии много) и смотрите с какого компьютера идет подбор паролей. Например, я знаю что на компьютере COMP1 работает Иванов, а с него идет событие 680 на совершенно другие учетки: Сидоров, Петров ...

    Вот и источник.

    Еще раз спасибо ;-)

    ОтветитьУдалить
  6. А как быть когда контроллеры обновлены до windows 2008 какие события искать?

    ОтветитьУдалить
  7. Автору РЕСПЕКТ и УВАЖУХА!
    У самого на 2008 такие же траблы были, помогла софтина lockoutstatus, выявил злоумышленика!
    Код события:4740
    Категория задачи: Управление учетными записями

    ОтветитьУдалить
  8. А если с одного и того же компьютера идут запросы... Да и комп сам по себе чистый - никаких вирусов. А блокирует и все...

    И не понял - как установить промежуток в 30 секунд. Там же только по минутам?

    ОтветитьУдалить
  9. огромное спасибо, подсказали про 680 событие, а то не знал, где копать (простая сеть, 6 компов без домена, с одного действительно шли на другой запросы авторизации от одной из программ с неправильным паролем)

    ОтветитьУдалить
  10. Я вот не пойму у меня короче вот чё читаю чё нить на сайте 30секунд чёрный фон включается заставка виндовс 7 и моя учётная запись Пишет дмитрий внизу Заблокировано ещё чуть ниже сменить пользователя, подскажите что делать

    ОтветитьУдалить
  11. Анонимный4 июля 2012 г., 13:28

    Спасибо за статью! Возможно для кого-то будет актуальна утилита от NetWrix для решения проблем блокировки учетных записей http://www.netwrix.com/ru/account_lockout_examiner.html

    ОтветитьУдалить
  12. Всем привет.
    Все это хорошо... а что делать, если поле Source Workstation в событии 680 пустое? Может быть кто сталкивался...

    ОтветитьУдалить
  13. Было подобное. При попытке сетевого доступа к файлам и ввода пароля, в 75% случаев блокировалась учетка. В остальных 25% был успешный доступ. Пароль был правильный. Такая же ситуация и при входе в систему того юзера, как локально, так и по RDP. Иногда пускало, иногда нет.
    Оказалось пароль состоит из пяти символов. А в груповых политиках минимальная длина пароля - 6 символов. Изменили пароль, и все хорошо.

    ОтветитьУдалить
  14. Модератор сознательно заблокировал учетную запись. Что делать?

    ОтветитьУдалить
  15. Анонимный12 июня 2015 г., 15:49

    Почему не блокируется аккаунт пользователя в случае когда при не завершенной rdp сессии пользователя на одной рабочей станции он меняет пароль на другой? Да ошибки аутентификации генерируются в большом количестве, но учетка не лочится. При этом при вводе несколько раз неверного пароля при интерактивном входе или сетевом - учетка блокируется в соответствии настройками групповой политики.

    ОтветитьУдалить
  16. А почему "когда при не завершенной rdp сессии пользователя на одной рабочей станции он меняет пароль на другой" должна блокироваться учетная запись?

    ОтветитьУдалить
  17. Вот у меня есть такая проблема и ни как не могу понять, что происходит.
    ПК находится в корп.сети. По логам видно, что учётка блокируется outlook.exe c ПК пользователя.
    Постоянно блокируется, несколько раз в день. Пока пользователь в отпуске, ПК включен, но блокировок нет.
    Как начинает работать - опять блокировки.
    На вирусы проверил, вирусов нет. Сохранённых паролей на ПК тоже нет.

    ОтветитьУдалить
    Ответы
    1. Странная ситуация. Попробуйте прислать на support@danshin.ms подробную информацию и те логи, по которым Вы понимаете, что блокируется outlook.exe. Попробуем решить.

      Удалить