Блокируется учетная запись в домене

Выявляем источник блокировки учетной записи пользователя в Active Directory

В этой статье мы опишем, как отслеживать события блокировки учетных записей пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы выполняется постоянная блокировка. Рассмотрим использование для поиска источника блокировки журнала безопасности Windows и скриптов PowerShell.

Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory в случае n-кратного неправильного набора пароля пользователем. Обычно учетная запись блокируется контроллером домена после нескольких попыток ввести неправильный пароль на несколько минут (5-30), в течении которых вход пользователя в систему невозможен. Через определение время, заданное политиками безопасности, учетная запись домена автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) учетных записей пользователей AD.

В том случае, если учётная запись пользователя в домене заблокирована, при попытке авторизации в Windows появляется предупреждение:

Политики блокировки учетных записей в домене

Политики блокировки учетных записей и паролей обычно задается сразу для всего домена политикой Default Domain Policy. Интересующие нас политики находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Account Policy -> Account Lockout Policy (Конфигурация Windows -> Параметры безопасности -> Политики учетных записей -> Политики блокировки учетных записей). Это политикии:

• Account lockout threshold (Пороговое значение блокировки) – через сколько неудачных попыток набора пароля учетная запись должна быть заблокирована
• Accountlockoutduration (Продолжительность блокировки учетной записи) – на какое время будет заблокирована учетная запись (по истечении этого времени блокировка будет снята автоматически)
• Resetaccountlockoutcounterafter (Время до сброса счетчика блокировки)– через какое время будет сброшен счетчик неудачных попыток авторизации

Совет. Вручную снять блокировку учетной записи, не дожидаясь автоматической разблокировки, можно с помощью консоли ADUC . Для этого в свойствах учетной записи пользователя на вкладке Account, поставив чекбокс на Unlock account. This account is currently locked out on this Active Directory Domain Controller.

Довольно полезную информацию о времени блокировки, задания пароля, количестве попыток набора пароля и прочее можно получить в свойствах учетной записи в консоль ADSIEdit или на дополнительной вкладке Additional Account Info в свойствах пользователя (проще).

Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться «клянется», что ничего особого не делал, не разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.

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

Поиск компьютера, с которого была заблокирована учетная запись

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

В том случае, если ближайший к пользователю контроллер домена определил, что пользователь пытается авторизоваться под неверным паролем , он перенаправляет запрос аутентификации на DC с FSMO ролью эмулятора PDC (именно он отвечает за обработку блокировок учетных записей). Если проверка подлинности не выполнялась и на PDC, он отвечает первому DC о невозможности аутентификации.

При этом в журнале обоих контроллеров домена фиксируются события 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Логично, что в первую очередь необходимо проверить журналы безопасности на PDC контроллере. Найти PDC в домене можно так:

Событие блокировки учетной записи домена можно найти в журнале Security на контролере домена. Отфильтруйте журнал безопасности по событию с Event ID 4740. Должен появится список последних событий блокировок учетных записей на контроллере домена. Начиная с самого верхнего переберите все события и найдите событие, в котором указано что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).

Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.

Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:

$Username = ‘username1’
$Pdce = (Get-AdDomain).PDCEmulator
$GweParams = @<
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = «*[System[EventID=4740] and EventData[Data[@Name=’TargetUserName’]=’$Username’]]»
>
$Events = Get-WinEvent @GweParams
$Events | foreach

$Username = ‘username1’
Get-ADDomainController -fi * | select -exp hostname | % <
$GweParams = @<
‘Computername’ = $_
‘LogName’ = ‘Security’
‘FilterXPath’ = «*[System[EventID=4740] and EventData[Data[@Name=’TargetUserName’]=’$Username’]]»
>
$Events = Get-WinEvent @GweParams
$Events | foreach <$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated>
>

Выявляем программу, причину блокировки учетной записи в AD

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

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

1. Монтирование сетевого диска через net use (Map Drive)
2. В заданиях планировщика Windows (Task Scheduler)
3. В службах Windows, которые настроены на запуск из-под доменной учетной записи
4. Сохранённые пароли в менеджере паролей в панели управления (Credential Manager)
5. Браузеры
6. Мобильные устройства (например, использующееся для доступа к корпоративной почте)
7. Программы с автологином
8. Незавершенные сессии пользователя на других компьютерах или терминальных серверах
9. И др.

Для более детального аудита блокировок на найденной машине необходимо включить ряд локальных политик аудита Windows. Для этого на локальном компьютере, на котором нужно отследить источник блокировки, откройте редактор групповых политик Gpedit.msc и в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy включите политики:

• Audit process tracking: Success , Failure
• Audit logon events: Success , Failure

Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:

Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.

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

В том случае, если вы так и не смогли выяснить причину блокировки учетной записи на конкретном компьютере, чтобы избежать постоянной блокировки учетки, стоит попробовать переименовать имя учетной записи пользователя в Active Directory. Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя.

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

Архив номеров / 2009 / Выпуск №11 (84) / Решаем проблему внезапной блокировки учетной записи

МИХАИЛ ДАНЬШИН, эксперт в области ИТ. Специализируется на Exchange и смежных технологиях. Ведет блог (http://danshin.ms), выступает на конференциях и в MCP-клубе.Награжден премией Microsoft MVP

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

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

Иногда возникают ситуации, когда при попытке входа в компьютер пользователь получает сообщение:

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

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

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

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

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

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

Рисунок 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).

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

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

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

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

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

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

В журнале безопасности для отслеживания подобных событий существует запись с кодом 680 от источника Security категории Account Logon. В этой записи (см. рис. 5) показана информация о том, в какое время и с какого компьютера была предпринята попытка ввода неверного пароля. Конечно, есть способ реагировать на событие немедленно. Я писал о нем в статье «Как отреагировать на событие?» [1].

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

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

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

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

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

Также утилита может помочь снять блокировку с учетной записи и многое другое.

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

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

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

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

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

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

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

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

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

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

Второй распространённый вариант – это использование одной учетной записи несколькими пользователями одновременно. В этом случае кто-то может постоянно вводить неверный пароль и тем самым мешать работе остальных пользователей.

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

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

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

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

Учётная запись пользователя заблокирована и не может быть использована для входа в сеть

Сегодняшняя статья пригодится в первую очередь корпоративным пользователям компьютеров на базе Windows, работающим со стандартными локальными учётными записями. Тогда как вход в учётные записи со статусом администратора могут выполнять только доверенные лица компании в виде сотрудников IT-раздела. Хотя при определённом семейном микроклимате с описываемой ниже проблемой можно столкнуться, используя домашние устройства. Что же за проблема такая? А это невозможность доступа к Windows с уведомлением на экране блокировки «Учётная запись пользователя заблокирована и не может быть использована для входа в сеть». Что за блокировка такая, и как с ней бороться?

Учётная запись пользователя заблокирована и не может быть использована для входа в сеть

Итак, не можем войти в Windows, потому что на экране блокировки видим это.

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

Блокировка учётных записей Windows

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

Здесь вводится пороговое значение блокировки, т.е. допустимое число попыток ввода пароля.

При установке такого порогового значения другие параметры политики – время до сброса счётчика блокировки и длительность самой блокировки – автоматически будут установлены на 30 минут.

Их при необходимости можно сменить. И, к примеру, установить меньшее время для сброса счётчика неудачных попыток ввода пароля.

А время блокировки самой учётной записи, наоборот, увеличить.

Распространяется такая защита только на локальные учётки и не работает при попытках подбора пароля или пин-кода для подключённых аккаунтов Microsoft.

Разблокировать заблокированную учётную запись можно несколькими путями:
• Дождаться завершения времени блокировки. Но здесь есть нюанс: сколько времени нужно ждать, система не уведомляет. Об этом знает только администратор компьютера;
• Войти в систему с учётки администратора и снять блокировку;
• Если доступ к учётке администратора невозможен, снять блокировку, загрузившись со съёмного устройства и подправив кое-что в реестре Windows.

Как разблокировать свою учётную запись Windows, если есть доступ к администратору

Если своя учётка заблокирована, но есть доступ к учётке администратора, необходимо войти в последнюю и разблокировать свою таким образом. Жмём клавиши Win+R, вводим:

В открывшемся окне в папке «Пользователи» ищем свою учётную запись и делаем на ней двойной клик.

В окошке открывшихся свойств снимаем галочку «Заблокировать учётную запись». Применяем.

Пробуем войти в свою учётку.

Примечание: если у вас нет пароля к учётке администратора, не стоит пытаться войти с помощью подбора. Защита от подбора паролей действует на все локальные учётные записи, в том числе и на администратора. Его учётка после определённого количества неудачных попыток авторизации также будет заблокирована.

Как разблокировать свою учётную запись Windows, если нет доступа к администратору

Если доступа к учётной записи администратора нет, добываем DVD-диск или флешку с процессом установки любой версии Windows или Live-диск с возможностью правки реестра операционной системы. Загружаем компьютер со съёмного устройства, в нашем случае это флешка установки Windows 10. Важно: запуск со съёмного устройства должен проводиться только при перезагрузке систем Windows 8.1 и 10. Нельзя использовать обычное завершение работы, поскольку в этих версиях из-за функции ускоренного запуска системное ядро загружается из ранее сохранённого на диске файла. Нам же нужно, чтобы ядро загрузилось с изменёнными параметрами реестра.

На первом этапе установки Windows жмём Shift+F10. Запускаем реестр командной строкой:

Кликаем раздел HKEY_LOCAL_MACHINE. Далее жмём меню «Файл», здесь нам нужен пункт «Загрузить куст».

В окне обзора выходим в корень устройств «Этот компьютер» и заходим в раздел Windows. У нас он обозначен как диск (C:), но диск системы также может значиться и под другой буквой. Тут нужно ориентироваться по объёму раздела. На системном разделе раскрываем папки «Windows», далее – «System32», далее – «config». Внутри последней нам нужен файл SAM, это так называемый куст реестра, открываем его.

Открытый куст нужно как-то назвать, имя непринципиально. Назовём его 777.

Внутри раздела реестра HKEY_LOCAL_MACHINE теперь наблюдаем новую ветвь 777. Раскрываем внутри неё путь:
777 – SAM – Domains – Account – Users – Names

Находим имя своей учётки в папке «Names». Нам, например, нужен пользователь Вася. Смотрим, что при выборе Васи отображается на панели реестра справа. У нас значение 0x3f8. Такое же значение, но только в ином формате написания — с лишними нулями спереди и капсом – ищем теперь выше, внутри папки «Users».

Ставим курсор теперь на это значение с нулями и капсом. В правой панели реестра ищем параметр «F» и двойным кликом раскрываем его.

В окошке параметра нам нужна строка 0038. Её первые два значения (у нас это 10 и 00) заменяем.

Двойным кликом ЛКМ щёлкаем по очереди на каждом из двух значений, и когда те выделятся синим, вписываем другие значения. А эти другие значения должны быть 10 и 02 соответственно. В итоге жмём «Ок».

Теперь в окне реестра кликаем на загруженный и отредактированный куст, у нас это 777. И выгружаем его: жмём «Файл», далее- «Выгрузить куст».

Перезагружаемся. И можем снова пытаться войти в свою учётку. Друзья, если блокировка вашей учётки – это следствие превышения допустимого числа авторизаций из-за того, что вы забыли пароль (или его, возможно, сменил кто-то без вашего ведома), вы можете просто убрать пароль. Сделать это можно, в частности, тем же способом путём правки реестра со съёмного носителя, что описан выше, только там нужны чуть другие действия.

Защищаем учетную запись Administrator

Компьютеры и домены имеют встроенную учетную запись Administrator по умолчанию, и, возможно, вы уже создали целый ряд учетных записей для ИТ-персонала, пользуясь правами администратора. Из-за того что встроенная учетная запись Administrator обладает соответствующими наименованию полномочиями, она является самой полезной и в то же время самой опасной учетной записью в операционной системе. Опасность состоит в том, что злоумышленник может воспользоваться учетной записью Administrator и подвергнуть сеть риску взлома или раскрытия конфиденциальной информации. Нарушители пытаются получить доступ к учетной записи Administrator и использовать ее, потому что это проще, чем отгадывать имена других учетных записей, имеющих равные полномочия с учетной записью Administrator.

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

Элементарные сведения

Каждый компьютер Windows Server 2003, Windows XP и Windows 2000 локальной сети, за исключением контроллеров доменов (DC), имеет локальную учетную запись с названием Administrator. Каждый домен также имеет учетную запись Administrator. Чтобы не допустить ситуации, когда администратор сам себя лишает контроля над своими компьютерами или над своим доменом, разработчики Microsoft установили некоторые ограничения на встроенную учетную запись Administrator: ее нельзя ни удалить, ни отключить, ни блокировать (даже если используется политика блокировки учетных записей, к учетной записи Administrator она не применяется).

Во всей документации Microsoft по администрированию регистрироваться в системе с учетной записью Administrator не рекомендуется. Но усилия по обеспечению безопасности должны заключаться не только в том, чтобы реже пользоваться учетной записью Administrator. Ограничения, которые Microsoft устанавливает на манипулирование учетной записью Administrator, несколько затрудняют процесс обеспечения безопасности этой учетной записи. Злоумышленники, зная, что удалить, отключить или заблокировать данную учетную запись нельзя, могут пользоваться программами угадывания паролей, не опасаясь блокировки после нескольких неудачных попыток.

Переименование записи Administrator

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

• Щелкнуть правой кнопкой мыши на My Computer и выбрать Manage, чтобы открыть оснастку Computer Management консоли Microsoft Management Console (MMC).
• Раскрыть объект Local Users and Groups.
• Выбрать папку Users.
• Дважды щелкнуть новую учетную запись (ловушку) Administrator в панели сведений, чтобы открыть диалоговое окно Properties.
• Перейти на вкладку Member Of, выбрать группу Users и щелкнуть Remove.
• Закрыть оснастку.

Прежде чем полагаться на эту процедуру как на способ оградить реальную учетную запись администратора от использования хакерами, следует знать, что по крайней мере одна программа (RedButton) позволяет злоумышленнику найти реальную учетную запись и воспользоваться ею. Программа выдает идентификаторы защиты (SID) всех учетных записей, а SID встроенной учетной записи Administrator всегда оканчивается на 500. Переименование учетной записи не меняет ее SID; этого можно добиться только путем удаления учетной записи и создания ее заново, а такие действия нельзя производить с учетной записью Administrator. Тем не менее Windows позволяет воспрепятствовать отображению SID учетных записей.

Отключаем отображение SID

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

• Выбрать Start, Run и ввести secpol.msc, чтобы открыть оснастку MMC Local Security Settings.
• В панели консоли раскрыть объект Local Policies, затем выбрать объект Security Options.
• Для рабочих станций и рядовых серверов Windows 2000 в панели подробностей следует дважды щелкнуть настройку Additional restrictions for anonymous connections. В поле со списком Local policy setting нужно выбрать Do not allow enumeration of SAM accounts and shares. Для рядовых серверов Windows 2003 и компьютеров Windows XP в панели сведений требуется выбрать настройку Network access: Allow anonymous SID/Name translation и убедиться, что политика отключена.
• Щелкнуть OK и закрыть оснастку.

Для применения политики к домену нужно выполнить следующие действия.

• Открыть оснастку Active Directory Users and Computers.
• В панели консоли щелкнуть правой кнопкой на домене и выбрать Properties, чтобы открыть диалоговое окно свойств.
• Перейти на вкладку Group Policy.
• Выбрать Default Domain Policy и щелкнуть Edit.
• В панели консоли перейти к настройке Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.
• В домене Windows 2000 дважды щелкнуть Additional restrictions for anonymous connections. Выбрать пункт Define this policy и в поле со списком указать Do not allow enumeration of SAM accounts and shares. В домене Windows 2003 следует дважды щелкнуть Network access: Allow anonymous SID/Name translation и убедиться, что политика отключена.
• Щелкнуть OK и закрыть оснастку.

Аудит регистрации

Если есть основания полагать, что кто-то использует настоящую (переименованную) учетную запись администратора для регистрации на компьютере или в домене, то нужно выполнять аудит событий регистрации соответствующего компьютера или домена. Для этого следует воспользоваться оснасткой Local Security Settings компьютера или оснасткой Default Domain Policy домена. Название политики — Audit account logon events. Для компьютеров политика доступна в разделе Local PoliciesAudit Policy. Для доменов эта политика доступна в разделе Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy.

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

Исключение администраторов из групповых политик

Если на предприятии устанавливаются групповые политики для управления компьютерами и пользователями, действующие в масштабе домена, не следует применять ограничивающие политики к тем членам ИТ-персонала, которым даются административные полномочия. В документации Microsoft рекомендуется создавать организационную единицу (OU) для пользователей и компьютеров, которые решено освободить от доменной политики по умолчанию, и создавать новую политику, применяемую только к новой OU. Я считаю более эффективным использование ACL для доменной политики по умолчанию, когда необходимо исключить часть членов из группы Administrators (или для исключения любых других пользователей и групповых объектов по выбору). Если вы не знали, что доменная политика по умолчанию имеет списки ACL, то теперь, возможно, воспользуетесь этой функцией как альтернативой созданию и настройке OU. Редактировать ACL для доменной политики по умолчанию в доменах Windows 2003 и Windows 2000 нужно следующим образом.

• Откройте оснастку Active Directory Users and Computers.
• В панели консоли щелкните правой кнопкой на домене и выберите Properties.
• Перейдите на вкладку Group Policy. Если установлена консоль Group Policy Management Console (GPMC) в Windows 2003, то при выборе вкладки Group Policy система выдаст сообщение о том, что вкладка больше не используется, и приглашение открыть оснастку.
• Выберите Default Domain Policy и щелкните Properties.
• Перейдите на вкладку Security, показанную на экране 1.
• Если группа или пользователь, которого нужно освободить от политики, в список не включены, следует щелкнуть Add и выбрать подходящий объект.
• Выберите группу, которую требуется исключить из доменной политики по умолчанию (в моем случае это группа Administrators) и укажите параметр Deny для настройки Apply Group Policy, как показано на экране.
• Повторите эти действия для других групп, которые решено исключить из доменной политики по умолчанию.

Учетная запись Administrator и учетные записи пользователей, которые являются членами администраторских групп, дают определенную власть и поэтому опасны в чужих руках. На самом деле опасность исходит не только от взломщиков. Мне довелось видеть «побоище» с участием сотрудников, имеющих повышенные полномочия, причиной которого была беспечность этих сотрудников (или их недостаточная компетентность). Поэтому добавлять пользователей в административные группы следует очень осторожно.

Кэти Ивенс ( kivens@win2000mag.com) — редактор Windows & .NET Magazine. Является соавтором более 40 книг по компьютерной тематике, включая «Windows 2000: The Complete Reference»

Поделитесь материалом с коллегами и друзьями

DmitSh

Blog about IT.

Блокировка учетной записи Event ID: 529, 680

Системным администраторам часто приходится сталкиваться с проблемой блокировки учетной записи пользователя. Часто причиной блокировки учетной записи является банальная невнимательность или забывчивость пользователя. Но иногда бывают случаи когда пользователь не имеет отношения к блокировки учетной записи. В данной заметке описан один из таких случаев. Один из пользователей стал жаловаться что с утра прийдя на работу не может зайти на свой компьютер под своей учетной записью. Посмотрев в консоле Active Directory — пользователи и компьютеры свойства учетной записи выяснил что запись была заблокирована. Разблокировал запись. В течении дня учетная запись пользователя снова заблокировалась. Стал выяснять что стало причиной блокировки учетной записи. Для начала запустил утилиту LockoutStatus.exe из набора утилит ALTools, для определения контроллера домена (КД) на котором запись была заблокирована. Запускаем утилиту LockoutStatus.exe последовательно выбираем меню File->Select Target… в открывшемся окне вводим в поле Target User Name — имя заблокированной учетной записи, в поле Target Domain Name — имя домена. Так же можно указать альтернативные учетные данные для доступа к каталогу AD.

Затем нажимаем OK и ждем завершения процесса сбора данных. После окончания сбора данных в окне программы будут отображены имена всех КД в данном домене и информация о состоянии учетной записи на каждом из них. Интересующая нас информация распологается в столбцах: Last Bad Pwd — время когда пользователь последний раз неправильно ввел пароль и Orig Lock — имя КД на котором выполнилась блокировка учетной записи пользователя.

Определив время и КД на котором была заблокирована учетная запись переходим к поиску причины блокировки записи. Основным источником информации о блокировки является журнал «Безопасность» на КД (при условии что включена политика аудита). Открываем журнал «Безопасность» на КД, это можно выполнить непосредственно из утилиты щелкнув правой клавишей мыши по строке с нужным КД и в открывшемся контекстном меню выбрать пункт «Open Event Viewer«. В журнале «Безоспасность», времени блокировки записи, соответствовали две записи аудита отказов с кодами событий 680 и 529. Событие с кодом 680 не дает много полезной информаци, а вот событие с кодом 529 более информативно.

Тип события: Аудит отказов
Источник события: Security
Категория события: Вход/выход
Код события: 529
Дата: 2011-05-17
Время: 08:53
Пользователь: NT AUTHORITYSYSTEM
Компьютер: SRV-MAIL
Описание:
Сбой входа в систему:
Причина: неизвестное имя пользователя или неверный пароль
Пользователь: smirnaya@domen.ru
Домен:
Тип входа: 3
Процесс входа: Advapi
Пакет проверки: Negotiate
Рабочая станция: SRV-MAIL
Имя вызывающего пользователя: SRV-MAIL$
Домен вызывающего: DOMEN
Код входа вызывающего: (0x0,0x3E7)
Код процесса вызывающего: 5524
Промежуточные службы: —
Адрес сети источника: —
Порт источника: —

Из события видно что причиной блокировки учетной записи является неправильно введеный пароль т.к. имя учетной записи указано верно. Но не указан адрес источника, но есть код вызываещего процесса. Данный код процесса соответсвует процессу inetinfo.exe. На данном КД так же расположен Exchange сервер и настроен Outlook Web Access. Проверив все настройки на данном сервере обнаружить причину блокировки записи не удалось. В логах Exchange много различных записей и разобрать является ли причиной вход на Exchange не представлялось возможным.

Использование Debugging Tools For Windows

Для того чтобы определить что же является причиной блокировки учетной записи воспользуемся утилитами Debugging Tools For Windows для отладки работы процесса inetinfo.exe. Я использую версию 6.11.1.404 . Cкачиваем желаемую версию и устанавливаем на наш контроллер домена. Для работы отладчика необходим набор символов (symbols). Скачиваем с сайта [3] набор символов для своей версии операционной системы. Скачав набор символов распаковываем его в папку c:symbols и переходим к работе с отладчиком. Идем в меню Пуск->Все программы->Debugging Tools for Windows (x86)->WinDbg. Перед началом работы необходимо указать путь от куда отладчик будет брать набор символов, для этого идем в меню File->Symbol File Path.. В открывшемся окне нажимаем кнопку Browse и указываем папку куда был установлен набор символов. У меня это папка C:Symbols.

Затем переходим непосредственно к отладке процесса inetinfo.exe для этого в окне программы WinDbg выбираем в меню File->Attach to a Process… В открывшемся дереве процессов находим процесс inetinfo.exe выбираем его и нажимаем OK. Запустится окно отладчика WinDbg в нем последовательно вводим следующие команды:
.symfix c:symcache
bp ADVAPI32!LogonUserA «k 100;.time;g»
g

По прошествии некоторого времени в журнале безопасности было зарегистрировано новое событие с id 529. Используя время записи события в журнале смотрим какое событие было в данное время в окне отладчика WinDbg. Времени возникновения события соответсвуют следующие записи в отладчике:
Как видно из отладочной информации причиной блокировки учетной записи является почтовое сообщение которое кто то пытается отправить через наш SMTP серер. Теперь необходимо выяснить какая служба или хост пытается отправить письмо от имени пользователя и с какого хоста идет соединение. Для определения откуда исходит проблема я воспользовался сетевым снифером Wireshark. Скачиваем и устанавливаем снифер на сервер. Запускаем Wireshark и ждем когда в журнале безопасности будет зарегистрировано новое событие с кодом 529. После регистрации события останавливаем захват трафика. Т.к. записий довольно много то для более быстрого поиска необходимой информации используем фильтр для этого в панели фильтра (View->Filter Toolbar) нажимаем Expression. В отрывшемся окне настроек фильтра устанавливаем курсов на любое поле окна Field name и вводим нужный нам протокол SMTP:

Раскрываем содержимое протокола SMTP и выбираем параметр smtp.rsp.parameter — Response parametr в поле Relation выбираем constains в поле Value вводим строку Authentication unsuccessful и нажимаем кнопку OK.

Затем применяем наш фильтр нажав на кнопку Apply на панели фильтра. После применения фильтра будут отображены только пакеты удовлетворяющие нашему фильтру. Щелкаем по одному из показанных пакетов правой клавишей мыши и в открывшемся контекстном меню выбираем пункт Follow TCP Stream:

Будет отображен весь процесс SMTP сессии с нашим почтовым сервером. Необходимо убедиться что данная SMTP сессия соответствует искомой учетной записи. Учетные данные отображаются в кодировке Base64. Нас интересуют два основных поля сессии, это ip — адрес клиентского компьютера и имя пользователя. Если с определением ip адреса проблем не возникает, то для определения имени пользователя необходимо использовать Base64 Decoder. Копируем строку содержащую логин пользователя см. рис. и декодируем ее на сайте.

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

Соотвественно из SMTP -сессии определяем что отправка почты от имени пользователя происходит с клиентской машины с ip — адресом 192.168.1.1. Если клиентская машина является частью корпоративной сети, то возможно она заражена (в моем случае служба rphost.exe — 1C Предприятие, пыталась отправить почту от имени пользователя и использовала просроченный пароль) вирусом. Если ip-адрес не принадлежит корпоративной сети, то скорее всего идет подбор пароля учетной записи. Eof.