Код ошибки 0xC000006A означает вход в учетную запись с ошибкой или неверным паролем, но не обязательно заблокированным.
Код ошибки 0xC000006D означает, что причиной является неправильное имя пользователя или данные аутентификации.
Эти журналы с идентификатором события 4625 регистрируются в разделе «Безопасность имени журнала с ошибкой аудита».
В этой статье мы обсудим коды ошибок 0xC000006A и 0xC000006D, причину неудачного входа в систему и идентификатор события 4625, а также лучший способ найти источник идентификатора события 4625 на Windows Server.
0xc000006a.
Причиной неудачного входа в систему с кодом ошибки 0xc000006a является «неизвестное имя пользователя или неверный пароль».
Код ошибки 0xC000006D
Событие с идентификатором 4625 содержит информацию об ошибке для статуса кода ошибки 0xC000006D и дополнительного статуса 0xC0000064.
Причиной сбоя для кода состояния 0xC000006D является неизвестное имя пользователя или неверный пароль.
Полезный совет. Как выполнить объединение строк в PowerShell!
Описание события с идентификатором 4625
Событие с идентификатором 4625 генерируется на рабочей станции, где была предпринята попытка входа в систему.
Причиной сбоя может быть неизвестное имя пользователя или неправильный пароль.
Он генерируется на контроллерах домена, рабочих станциях и серверах Windows.
Полезный совет. Идентификатор события 4634 – выход из учетной записи!
Обратитесь к таблице кодов состояния входа в Windows, чтобы найти причину неудачного входа в систему для кодов состояния.
В настоящее время нет доступных серверов входа в систему для обслуживания запроса на вход.
Вход в систему с неправильно написанной или неверной учетной записью пользователя.
Вход пользователя с неправильно написанным или неверным паролем
Указывает, что указанное имя пользователя и данные аутентификации действительны, но некоторые ограничения учетной записи пользователя помешали успешной аутентификации (например, ограничения по времени суток).
Вход пользователя в нерабочие часы
Вход пользователя с неавторизованной рабочей станции
Вход пользователя с истекшим паролем
Вход пользователя в учетную запись отключен администратором
Указывает, что сервер Sam находился в неправильном состоянии для выполнения требуемой операции.
Часы между DC и другим компьютером слишком сильно рассинхронизированы.
Пользователю не предоставлен запрошенный тип входа (также называемый правом на вход) на этом компьютере.
Запрос на вход не выполнен, поскольку не удалось установить доверительные отношения между основным доменом и доверенным доменом.
Была предпринята попытка входа в систему, но служба Netlogon не была запущена.
Вход пользователя с истекшим сроком действия учетной записи
Пользователь должен сменить пароль при следующем входе в систему.
Очевидно, ошибка в Windows, а не риск.
Вход в систему с заблокированной учетной записью
Причина сбоя: произошла ошибка при входе в систему.
Ошибка входа в систему: машина, на которую вы входите, защищена брандмауэром аутентификации. Указанной учетной записи не разрешена проверка подлинности на компьютере.
Полезный совет. Идентификатор события 4776, код состояния 0xc0000234. Исправьте ошибку, чтобы найти источник попытки!
Решение для поиска источника кода состояния идентификатора события 4625 0xC000006D или 0xC000006A.
Чтобы узнать источник попытки входа в систему, нам необходимо включить подробное ведение журнала входа в сеть на контроллере домена.
Вы можете запустить команду Nltest в PowerShell.
Откройте PowerShell с помощью «Запуск от имени администратора» и выполните приведенную ниже команду.
Nltest /DBFlag:2080FFFF
Restart-Service Netlogon
Результат включения подробного журнала на рабочей станции:
Чтобы прочитать события из вышеуказанного файла, откройте файл журнала, запустив его от имени администратора.
Файл netlogon.log содержит информацию о попытке входа пользователя в систему и ее исходное местоположение.
Полезный совет. Идентификатор события 4771 – не удалось выполнить предварительную аутентификацию Kerberos!
Это поможет вам отследить рабочую станцию, с которой была сделана попытка входа.
Вы можете включить или отключить ведение журнала входа в сеть, используя метод регистрации.
В приведенном выше файле netlogon.log отображается источник, из которого произошла попытка входа в систему.
Это событие также регистрирует код ошибки: 0xC000006A, что означает, что пользователь входит в систему с ошибкой или неверным паролем.
Если вы откроете Идентификатор события 4625 и посмотрите раздел сведений, он отобразит источник, из которого была предпринята попытка входа в систему.
В поле информации об ошибке регистрируется это событие с указанием причины неудачного входа в систему, статуса ошибки: 0xC000006D и дополнительного статуса: 0xc000006a.
Полезный совет. Идентификатор события 4670 – разрешения для объекта были изменены!
Заключение
Я надеюсь, что приведенная выше статья о коде состояния ошибки 0xc000006a или 0xc000006d в журналах безопасности Windows идентификатор события 4625 будет полезна для вас. ты.
Код ошибки 0xc000006a означает «Вход в учетную запись с ошибкой или неверным паролем, но не обязательно заблокированным».
Код ошибки 0xc000006d означает: «Причиной является неправильное имя пользователя или данные аутентификации».
Включение подробного журналирования для службы входа в сеть на контроллере домена поможет вам определить местоположение попытки входа в систему.
Дополнительные темы о командах PowerShell Active Directory и основах PowerShell можно найти на домашней странице ShellGeek.
Вы можете прочитать больше о других журналах безопасности и системных событий Windows, как указано:
Время на прочтение
Необходимые исходные условия.
Да, чудес не бывает, и для поиска причины блокировки пользователей потребуется некоторая настройка аудита безопасности на контроллерах домена. Должны быть включены следующие подкатегории аудита на контроллерах домена:
Алгоритм поиска источника блокировки
Этих действий будет достаточно для быстрого поиска ПК с вредоносным ПО, подбирающим пароли пользователей. Как правило достаточно быстро вычислить источник проблемы и изолировать его для дальнейшего расследования. Алгоритм поиска процесса непосредственно вызывающего блокировку пользователя сильно зависит от ПО, установленного на конечном ПК.
Используемые командлеты PowerShell
В чём «магия» Get-WinEvent?
Во-первых он ищет события с конца и имеет параметр -MaxEvents, позволяющий найти только самое последнее событие или неколько самых последних событий.
Во-вторых он имеет прекрасный параметр -FilterHashtable, который позволяет очень гибко задать условия поиска события.
Скрипт поиска
Для себя я подготовил небольшой PowerShell скрипт.
На входе скрипт принимает либо имя пользователя, для которого необходимо найти источник блокировки, либо количество (по умолчанию — 1) последних заблокированных пользователей.
Вместо P.
Да, есть Account Lockout and Management Tools с прекрасной утилитой LockoutStatus.exe, но она долго опрашивает все контроллеры домена (а некоторый из них могут быть и недоступны).
Предложенный скрипт никак не претендует на замену LockoutStatus.exe (у них совершенно разный принцип работы). Обычно я использую их вместе.
Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!
Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.
Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).
Политики аудита Windows
Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.
Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера – Конфигурация Windows – Параметры безопасности – Локальные политики – Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.
Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра – следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.
Настройка Windows Event Forwarding, интеграция с IBM QRadar
Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.
Для включения сервиса сбора логов следует выполнить нижеописанные шаги:
2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.
3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).
5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITYNETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTINEvent Log Readers («Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).
где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.
7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):
8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.
9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.
Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US (где SubscriptionName – имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.
10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).
После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM-системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.
Утилита Sysmon
Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .
Установка Sysmon предельно проста и также может быть легко автоматизирована:
1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
Все исполняемые файлы подписаны.
2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.
3. Установка sysmon для x64 производится командой:
C:oldersysmon64.exe -accepteula -i C:oldersysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe – файл-установщик.
Поддерживается запуск установки из сетевой папки.
4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.
Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:Windowssysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.
XPath-запросы
Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации – Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box «Отобразить аналитический и отладочный журналы».
Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку «Подробности», а там выбрать radio-button «Режим XML», в котором в формате «ключ-значение» будут представлены данные события безопасности.
Приведем несколько полезных XPath запросов с комментариями.
2. Поиск по значению конкретного свойства события в журнале Sysmon – возьмем для примера поиск событий, в которых фигурировал целевой порт 443:
4. Поиск по трем условиям – дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:
5. Рассмотрим функционал исключения из выборки данных по определенным критериям – это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):
IRP-система штатными средствами Windows
Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий – мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.
Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант «При событии», а в открывшейся форме отображения установить radio-button «Настраиваемое». После этих действий появится кнопка «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.
Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:
Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.
Рэнди Франклин Смит (CISA, SSCP, Security MVP) имеет в своем арсенале очень полезный документ, рассказывающий о том, какие события (event IDs) обязательно должны отслеживаться в рамках обеспечения информационной безопасности Windows. В этом документе изложена крайне полезная информация, которая позволит Вам “выжать” максимум из штатной системы аудита. Мы подготовили перевод этого материала. Заинтересованных приглашаем под кат.
О том, как настроить аудит, мы уже обстоятельно писали в одном из наших постов. Но из всех event id, которые встречаются в журналах событий, необходимо остановить свое внимание на нескольких критических важных. На каких именно – решать каждому. Однако Рэнди Франклин Смит предлагает сосредоточить внимание на 10 важных событиях безопасности в Windows.
Контроллеры доменов
Event ID — (Категория) — Описание
2) 676, или Failed 672 или 4768
(Аудит событий входа в систему)
Событие 676/4768 логгируется для других типов неудачной аутентификации. Таблица кодов Kerberos приведена ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 672 вместо 676.
3) 681 или Failed 680 или 4776
(Аудит событий входа в систему)
Событие 681/4776 на контроллере домена указывает на неудачную попытку входа в систему через
NTLM с доменной учетной записью. Код ошибки указывает, почему именно аутентификация была неудачной.
Коды ошибок NTLM приведены ниже.
ВНИМАНИЕ: В Windows 2003 Server событие отказа записывается как 680 вместо 681.
4) 642 или 4738
(Аудит управления учетными записями)
Событие 642/4738 указывает на изменения в указанной учетной записи, такие как сброс пароля или активация деактивированной до этого учетной записи. Описание события уточняется в соответствие с типом изменения.
5) 632 или 4728; 636 или 4732; 660 или 4756
(Аудит управления учетными записями)
Все три события указывают на то, что указанный пользователь был добавлен в определенную группу. Обозначены Глобальная (Global), Локальная (Local) и Общая (Universal) соответственно для каждого ID.
6) 624 или 4720
(Аудит управления учетными записями)
Была создана новая учетная запись пользователя
7) 644 или 4740
(Аудит управления учетными записями)
Учетная запись указанного пользователя была заблокирована после нескольких попыток входа
8) 517 или 1102
(Аудит системных событий)
Указанный пользователь очистил журнал безопасности
Вход и выход из системы (Logon/Logoff)
Event Id — Описание
528 или 4624 — Успешный вход в систему
529 или 4625 — Отказ входа в систему – Неизвестное имя пользователя или неверный пароль
530 или 4625 Отказ входа в систему – Вход в систему не был осуществлен в течение обозначенного периода времени
531 или 4625 — Отказ входа в систему – Учетная запись временно деактивирована
532 или 4625 — Отказ входа в систему – Срок использования указанной учетной записи истек
533 или 4625 — Отказ входа в систему – Пользователю не разрешается осуществлять вход в систему на данном компьютере
534 или 4625 или 5461 — Отказ входа в систему – Пользователь не был разрешен запрашиваемый тип входа на данном компьютере
535 или 4625 — Отказ входа в систему – Срок действия пароля указанной учетной записи истек
539 или 4625 — Отказ входа в систему – Учетная запись заблокирована
540 или 4624 — Успешный сетевой вход в систему (Только Windows 2000, XP, 2003)
Типы входов в систему (Logon Types)
Тип входа в систему — Описание
2 — Интерактивный (вход с клавиатуры или экрана системы)
3 — Сетевой (например, подключение к общей папке на этом компьютере из любого места в сети или IIS вход — Никогда не заходил 528 на Windows Server 2000 и выше. См. событие 540)
4 — Пакет (batch) (например, запланированная задача)
5 — Служба (Запуск службы)
7 — Разблокировка (например, необслуживаемая рабочая станция с защищенным паролем скринсейвером)
8 — NetworkCleartext (Вход с полномочиями (credentials), отправленными в виде простого текст. Часто обозначает вход в IIS с “базовой аутентификацией”)
9 — NewCredentials
10 — RemoteInteractive (Терминальные службы, Удаленный рабочий стол или удаленный помощник)
11 — CachedInteractive (вход с кешированными доменными полномочиями, например, вход на рабочую станцию, которая находится не в сети)
Коды отказов Kerberos
Код ошибки — Причина
6 — Имя пользователя не существует
12 — Ограничение рабочей машины; ограничение времени входа в систему
18 — Учетная запись деактивирована, заблокирована или истек срок ее действия
23 — Истек срок действия пароля пользователя
24 — Предварительная аутентификация не удалась; обычно причиной является неверный пароль
32 — Истек срок действия заявки. Это нормальное событие, которое логгируется учетными записями компьютеров
37 — Время на рабочей машины давно не синхронизировалось со временем на контроллере домена
Коды ошибок NTLM
Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание
Еще раз продублируем ссылку на скачивание документа на сайте Рэнди Франклина Смита www.ultimatewindowssecurity.com/securitylog/quickref/Default.aspx. Нужно будет заполнить небольшую форму, чтобы получить к нему доступ.
P. S. Хотите полностью автоматизировать работу с журналами событий? Попробуйте новую версию NetWrix Event Log Manager 4.0, которая осуществляет сбор и архивирование журналов событий, строит отчеты и генерирует оповещения в режиме реального времени. Программа собирает данные с многочисленных компьютеров сети, предупреждает Вас о критических событиях и централизованно хранит данные обо всех событиях в сжатом формате для удобства анализа архивных данных журналов. Доступна бесплатная версия программы для 10 контроллеров доменов и 100 компьютеров.