При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.
Содержание:
- Настройка политики аудита входа пользователей в Windows
- Поиск событий входа пользователей в журнале событий Windows
- Анализ событий входа пользователей в Windows с помощью PowerShell
Настройка политики аудита входа пользователей в Windows
Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).
- Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
- Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
- Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
- Закройте редактор GPO и обновите настройки политик на клиентах.
Поиск событий входа пользователей в журнале событий Windows
После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.
- Откройте оснастку Event Viewer (
eventvwr.msc
); - Разверните секцию Windows Logs и выберите журнал Security;
- Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
- В поле укажите ID события 4624 и нажмите OK;
- В окне события останутся только события входа пользователей, системных служб с описанием
An account was successfully logged on
; - В описании события указано имя и домен пользователя, вошедшего в систему:
New Logon: Security ID: WINITPROa.khramov Account Name: a.khramov Account Domain: WINITPRO
Ниже перечислены другие полезные EventID:
Event ID | Описание |
4624 | A successful account logon event |
4625 | An account failed to log on |
4648 | A logon was attempted using explicit credentials |
4634 | An account was logged off |
4647 | User initiated logoff |
Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.
Код Logon Type | Описание |
---|---|
0 | System |
2 | Interactive |
3 | Network |
4 | Batch |
5 | Service |
6 | Proxy |
7 | Unlock |
8 | NetworkCleartext |
9 | NewCredentials |
10 | RemoteInteractive |
11 | CachedInteractive |
12 | CachedRemoteInteractive |
13 | CachedUnlock |
При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.
В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.
Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.
Анализ событий входа пользователей в Windows с помощью PowerShell
Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.
Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.
$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView
Если нужно выбрать события входа за последние несколько дней, можно добавить pipe с таким условием:
|Where-Object {$_.TimeStamp -gt '5/10/22'}
Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:
'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}
Если протокол RPC закрыт между компьютерами, вы можете получить данные с удаленных компьютеров с помощью PowerShell Remoting командлета Invoke-Command:
Invoke-Command -ComputerName 'msk-comp1', 'msk-comp2' {Get-WinEvent -FilterXml $query | Select-Object $properties}
Вы когда-нибудь хотели следить за тем, кто и когда входил в систему, установленную на вашем компьютере. На профессиональных изданиях Windows специально для этого существует политика аудита входа, о которой мы сейчас и поговорим.
«Аудит событий входа в систему» отслеживает как локальные, так и сетевые входы. При каждом входе определяется учетная запись пользователя и время, в которое состоялся вход. Также вы сможете узнать, когда пользователь вышел из системы.
Включаем «Аудит входа в систему»
Во-первых, откройте «Редактор локальной групповой политики» – откройте меню «Пуск», в поисковую строку введите gpedit.msc и нажмите Enter.
В левой части окна проследуйте по следующему пути: Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита.
Дважды кликните по политике «Аудит событий входа в систему» в правой части окна. В диалоговом окне «Свойства» отметьте галочкой параметр «Успех» для того, чтобы позволить отслеживание успешных входов в систему. Также вы можете включить параметр «Отказ» – так вы позволите отслеживание неудачных попыток входа.
Просматриваем события входа в систему
После включения этого параметра, Windows начнет регистрировать (в журнал безопасности) все события входа в систему, в том числе имя пользователя и время. Чтобы увидеть эти события, запустите инструмент «Просмотр событий» – откройте меню «Пуск», в строку поиска введите текст «Просмотр событий» и нажмите клавишу Enter.
Далее перейдите в «Журналы Windows» и выберите категорию «Безопасность». Нас интересуют события с кодом 4624 – это события успешного входа в систему.
Чтобы увидеть больше информации, включая имя учетной записи пользователя, входившего в систему, дважды щелкните по событию. Прокручивая вниз текстовое поле, вы увидите всю необходимую информацию.
Если вы хотите, чтобы в журнале безопасности отображались исключительно события входа, нажмите на кнопку «Фильтровать текущий журнал», которая расположена в боковой панели справа и в появившемся окне отфильтруйте события как на скриншоте ниже:
Отличного Вам дня!
Сообщение от Джуниор
Указанный Вами скрипт выводит в качестве результата сам свой текст.
Это значит, что за прошедшие сутки таких событий не найдено.
Скрипт который вы запустили:
1. Ищет события за последние сутки от момента запуска — (Date).AddDays(-1). Можете поменять -1 на больший интервал.
2. Ищет события, у которых LogonType = 2, т.е. интерактивный вход/выход в систему. Подробности здесь.
Сообщение от Джуниор
Я нашел решение, обратился к коллеге программисту. Мне помог следующий код:
Этот код использует тот же Get-WinEvent из PowerShell, вот только выбирает он события о терминальном входе в систему (RemoteInteractive), о чём вы забыли уточнить в изначальном запросе + диапазон в вашем примере почти два года.
А вот учитывая, что вам необходимо выбирать события за очень длительный срок, выбор xml-фильтра, действительно более оправдан, т.к. Get-WinEvent с хеш-фильтром обрабатывает Security-журнал намного дольше (где-то даже есть об этом статья).
Однако, ваш код не выбирает события выхода и не показывает неудачные попытки. Если это добавить, получится примерно так:
PowerShell | ||
|
При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.
Содержание:
- Настройка политики аудита входа пользователей в Windows
- Поиск событий входа пользователей в журнале событий Windows
- Анализ событий входа пользователей в Windows с помощью PowerShell
Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).
- Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
- Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
- Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
- Закройте редактор GPO и обновите настройки политик на клиентах.
Поиск событий входа пользователей в журнале событий Windows
После того как вы включили политики аудита входа, при каждом входе пользователя в Windows в журнале Event Viewer будет появляться запись о входе. Посмотрим, как она выглядит.
- Откройте оснастку Event Viewer (
eventvwr.msc
); - Разверните секцию Windows Logs и выберите журнал Security;
- Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
- В поле укажите ID события 4624 и нажмите OK;
- В окне события останутся только события входа пользователей, системных служб с описанием
An account was successfully logged on
; - В описании события указано имя и домен пользователя, вошедшего в систему:
New Logon: Security ID: WINITPROa.khramov Account Name: a.khramov Account Domain: WINITPRO
Ниже перечислены другие полезные EventID:
Event ID | Описание |
4624 | A successful account logon event |
4625 | An account failed to log on |
4648 | A logon was attempted using explicit credentials |
4634 | An account was logged off |
4647 | User initiated logoff |
Если полистать журнал событий, можно заметить, что в нем присутствуют не только события входа пользователей на компьютер. Здесь также будут события сетевого доступа к этому компьютеру (при открытии по сети общих файлов или печати на сетевых принтерах), запуске различных служб и заданий планировщика и т.д. Т.е. очень много лишний событий, которые не относятся ко входу локального пользователя. Чтобы выбрать только события интерактивного входа пользователя на консоль компьютера, нужно дополнительно сделать выборку по значению параметра Logon Type. В таблице ниже перечислены коды Logon Type.
Код Logon Type | Описание |
---|---|
0 | System |
2 | Interactive |
3 | Network |
4 | Batch |
5 | Service |
6 | Proxy |
7 | Unlock |
8 | NetworkCleartext |
9 | NewCredentials |
10 | RemoteInteractive |
11 | CachedInteractive |
12 | CachedRemoteInteractive |
13 | CachedUnlock |
При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.
В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.
Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.
Анализ событий входа пользователей в Windows с помощью PowerShell
Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.
Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.
$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView
Если нужно выбрать события входа за последние несколько дней, можно добавить pipe с таким условием:
|Where-Object {$_.TimeStamp -gt '5/10/22'}
Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:
'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}
Если протокол RPC закрыт между компьютерами, вы можете получить данные с удаленных компьютеров с помощью PowerShell Remoting командлета Invoke-Command:
Invoke-Command -ComputerName 'msk-comp1', 'msk-comp2' {Get-WinEvent -FilterXml $query | Select-Object $properties}
Здравствуйте, уважаемое сообщество!
ИТ-инфраструктура всегда находится в динамике. Тысячи изменений происходят ежеминутно. Многие из них требуется регистрировать. Аудит систем является неотъемлемой частью информационной безопасности организаций. Контроль изменений позволяет предотвратить серьезные происшествия в дальнейшем.
В статье я хочу рассказать о своем опыте отслеживания событий входа (и выхода) пользователей на серверах организации, подробно описать те детали, которые возникли в ходе выполнения задачи анализа логов аудита, а также привести решение этой задачи по шагам.
Цели, которые мы преследуем:
- Контроль ежедневных подключений пользователей к серверам организации, в том числе терминальным.
- Регистрация события, как от доменных пользователей, так и от локальных.
- Мониторинг рабочей активности пользователя (приход/уход).
- Контроль подключений ИТ-подразделений к серверам ИБ.
Для начала необходимо включить аудит и записывать события входа в журнал Windows. В качестве контроллера домена нам предоставлен Windows Server 2008 R2. Включив аудит, потребуется извлекать, фильтровать и анализировать события, определенные политикой аудита. Кроме того, предполагается отправка в третью систему на анализ, например, в DLP. В качестве альтернативы предусмотрим возможность формирования отчета в Excel.
Анализ логов является рутинной операцией системного администратора. В данном случае объёмы фиксируемых событий в домене таковы, что это само по себе сложно. Аудит включается в групповой политике.
События входа в систему формируются:
1. контроллерами домена, в процессе проверки учетных записей домена;
2. локальными компьютерами при работе с локальными учетными записями.
Если включены обе категории политик (учетных записей и аудита), то входы в систему, использующие учетную запись домена, будут формировать события входа или выхода на рабочей станции или сервере и событие входа в систему на контроллере домена. Таким образом, аудит на доменные машины потребуется настроить через оснастку GPO на контроллере, аудит локальный — через локальную политику безопасности с помощью оснастки MMC.
Настройка аудита и подготовка инфраструктуры:
Рассмотрим этот этап подробно. Для уменьшения объемов информации мы смотрим только успешные события входа и выхода. Имеет смысл увеличить размер журнала security Windows. По умолчанию — это 128 Мегабайт.
Для настройки локальной политики:
Открываем редактор политик – Пуск, в строке поиска пишем gpedit.msc и нажимаем Ввод.
Открываем следующий путь: Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policy.
Дважды кликаем параметр групповой политики Audit logon events (аудит входа в систему) и Audit account logon events (аудит событий входа в систему). В окне свойств устанавливаем Success-чекбокс для записи в журнал успешных входов в систему. Чекбокс Failure устанавливать не рекомендую во избежание переполнения. Для применения политики необходимо набрать в консоли gpupdate /force
Для настройки групповой политики:
Создаем новый объект GPO (групповую политику) с именем «Audit AD». Переходим в раздел редактирования и разворачиваем ветку Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Configuration. В данной ветке групповых политик находятся расширенные политики аудита, которые можно активировать в ОС семейства Windows для отслеживания различных событий. В Windows 7 и Windows Server 2008 R2 количество событий, для которых можно осуществлять аудит увеличено до 53. Эти 53 политики аудита (т.н. гранулярные политики аудита) находятся в ветке Security SettingsAdvanced Audit Policy
Configuration и сгруппированы в десяти категориях:
Включаем:
- Account Logon – аудит проверки учетных данных, службы проверки подлинности Kerberos, операций с билетами Kerberos и других события входа;
- Logon/Logoff – аудит интерактивных и сетевых попыток входа на компьютеры и сервера домена, а также блокировок учетных записей.
После изменений выполняем gpupdate /force.
Сразу оговорим типы событий, которые будет анализировать наш будущий скрипт:
- Remote access — удаленный вход через RDP-сессию.
- Interactive — локальный вход пользователя с консоли.
- Computer unlocked — разблокировка заблокированной станции.
- Logoff — выход из системы.
В Windows 2008 событие успешного входа имеет идентификатор Event ID 4624, а logoff — Event ID 4672. Необходимо выбрать инструмент, позволяющий проанализировать огромное количество записей. Казалось бы, все можно написать, используя штатные инструменты. Однако, запросы на Powershell вида
get-eventlog security | where {$_.EventId -eq 4624 -and ($_.TimeGenerated.TimeOfDay
-gt '08:00:00' )}
хорошо себя показывают только на стенде с контроллером домена на два пользователя. В продакшене средах сбор логов с сервера занимал по 20 минут. Поиски решения привели к утилите LOG PARSER , ранее обзорно рассмотренной на Хабре.
Скорость обработки данных возросла в разы, полный прогон с формированием отчета с одного ПК сократился до 10 секунд. Утилита использует немало опций командной строки, поэтому мы будем вызывать cmd из powershell, чтобы избавиться от экранирования кучи специальных символов. Для написания запросов можно воспользоваться GUI — Log Parser Lizard. Он не бесплатен, но триального периода в 65 дней хватает. Ниже привожу сам запрос. Помимо интересующих нас, распишем и другие варианты входа в систему, на случай дальнейшего использования.
SELECT
eventid,
timegenerated,
extract_token(Strings, 5, '|' ) as LogonName,
extract_token(Strings, 18, '|' ) as LogonIP,
case extract_token(Strings, 8, '|' )
WHEN '2' THEN 'interactive'
WHEN '3' THEN 'network'
WHEN '4' THEN 'batch'
WHEN '5' THEN 'service'
WHEN '7' THEN 'unlocked workstation'
WHEN '8' THEN 'network logon using a cleartext password'
WHEN '9' THEN 'impersonated logons'
WHEN '10' THEN 'remote access'
ELSE extract_token(Strings, 8, '|' )
end as LogonType,
case extract_token(Strings, 1, '|' )
WHEN 'SERVER$' THEN 'logon'
ELSE extract_token(Strings, 1, '|' )
end as Type
INTO 127.0.0.1c$AUDITnewreport(127.0.0.1).csv
FROM 127.0.0.1Security
WHERE
(EventID IN (4624) AND extract_token(Strings, 8, '|' ) LIKE '10') OR (EventID IN (4624) AND extract_token(Strings, 8, '|' ) LIKE '2') OR (EventID IN (4624) AND extract_token(Strings, 8, '|' ) LIKE '7') OR EventID IN (4647) AND
TO_DATE( TimeGenerated ) = TO_LOCALTIME( SYSTEM_DATE() )
ORDER BY Timegenerated DESC
Далее привожу общее описание логики:
- Вручную формируем список хостов с настроенным локально аудитом, либо указываем контроллер домена, с которого забираем логи.
- Скрипт обходит список имен хостов в цикле, подключается к каждому из них, запускает службу Remote registry и, с помощью парсера, выполняет SQL-запрос audit.sql для сбора логов безопасности системы. Запрос модифицируется для каждого нового хоста с помощью примитивного регулярного выражения при каждой итерации. Полученные данные сохраняются в csv-файлах.
- Из файлов CSV формируется отчет в файле Excel (для красоты и удобства поиска) и тело письма в формате HTML.
- Создается почтовое сообщение отдельно по каждому файлу отчета и отправляется в третью систему.
Готовим площадку для теста скрипта:
Для корректной работы скрипта необходимо выполнение следующих условий:
Создаем каталог на сервере/рабочей станции, с которой выполняется скрипт. Размещаем файлы скрипта в каталог С:audit. Список хостов и скрипт лежат в одном каталоге.
Устанавливаем дополнительное ПО на сервер MS Log Parser 2.2 и Windows powershell 3.0 в составе management framework. Проверить версию Powershell можно, набрав $Host.version в консоли PS.
Заполняем список интересующих нас серверов list.txt для аудита в каталоге С:audit по именам рабочих станций. Настраиваем политику Аудита. Убеждаемся, что она работает.
Проверяем, запущена ли служба удаленного реестра (скрипт делает попытку запуска и перевода службы в автоматический режим при наличии соответствующих прав). На серверах 2008/2012 эта служба запущена по умолчанию.
Проверяем наличие прав администратора для подключения к системе и сбора логов.
Проверяем возможность запуска неподписанных скриптов powershell на удаленной машине (подписать скрипт или обойти/отключить restriction policy).
Внимание на параметры запуска неподписанных скриптов — execution policy на сервере:
Обойти запрет можно подписав скрипт, либо отключить саму политику при запуске. Например:
powershell.exe -executionpolicy bypass -file С:auditnewrun_v5.ps1
Привожу весь листинг скрипта:
Get-ChildItem -Filter report*|Remove-Item -Force
$date= get-date -uformat %Y-%m-%d
cd 'C:Program Files (x86)Log Parser 2.2'
$datadir="C:AUDITnew"
$datafile=$datadir+"audit.sql"
$list=gc $datadir"list.txt"
$data=gc $datafile
$command="LogParser.exe -i:EVT -o:CSV file:127.0.0.1c$auditnewaudit.sql"
$MLdir= [System.IO.Path]::GetDirectoryName($datadir)
function send_email {
$mailmessage = New-Object system.net.mail.mailmessage
$mailmessage.from = ($emailfrom)
$mailmessage.To.add($emailto)
$mailmessage.Subject = $emailsubject
$mailmessage.Body = $emailbody
$attachment = New-Object System.Net.Mail.Attachment($emailattachment, 'text/plain')
$mailmessage.Attachments.Add($attachment)
#$SMTPClient.EnableSsl = $true
$mailmessage.IsBodyHTML = $true
$SMTPClient = New-Object Net.Mail.SmtpClient($SmtpServer, 25)
#$SMTPClient.Credentials = New-Object System.Net.NetworkCredential("$SMTPAuthUsername", "$SMTPAuthPassword")
$SMTPClient.Send($mailmessage)
}
foreach ($SERVER in $list) {
Get-Service -Name RemoteRegistry -ComputerName $SERVER | set-service -startuptype auto
Get-Service -Name RemoteRegistry -ComputerName $SERVER | Start-service
$pattern="FROM"+" "+"$SERVER"+"Security"
$pattern2="report"+"("+$SERVER+")"+"."+"csv"
$data -replace "FROMs+\.+", "$pattern" -replace "report.+", "$pattern2"|set-content $datafile
<# #IF WE USE IP LIST
$data -replace "FROMs+\([0-9]{1,3}[.]){3}[0-9]{1,3}", "$pattern" -replace "report.+", "$pattern2"|set-content $datafile
#>
cmd /c $command
}
cd $datadir
foreach ($file in Get-ChildItem $datadir -Filter report*) {
#creating excel doc#
$excel = new-object -comobject excel.application
$excel.visible = $false
$workbook = $excel.workbooks.add()
$workbook.workSheets.item(3).delete()
$workbook.WorkSheets.item(2).delete()
$workbook.WorkSheets.item(1).Name = "Audit"
$sheet = $workbook.WorkSheets.Item("Audit")
$x = 2
$colorIndex = "microsoft.office.interop.excel.xlColorIndex" -as [type]
$borderWeight = "microsoft.office.interop.excel.xlBorderWeight" -as [type]
$chartType = "microsoft.office.interop.excel.xlChartType" -as [type]
For($b = 1 ; $b -le 5 ; $b++)
{
$sheet.cells.item(1,$b).font.bold = $true
$sheet.cells.item(1,$b).borders.ColorIndex = $colorIndex::xlColorIndexAutomatic
$sheet.cells.item(1,$b).borders.weight = $borderWeight::xlMedium
}
$sheet.cells.item(1,1) = "EventID"
$sheet.cells.item(1,2) = "TimeGenerated"
$sheet.cells.item(1,3) = "LogonName"
$sheet.cells.item(1,4) = "LogonIP"
$sheet.cells.item(1,5) = "LogonType"
$sheet.cells.item(1,6) = "Type"
Foreach ($row in $data=Import-Csv $file -Delimiter ',' -Header EventID, TimeGenerated, LogonName, LogonIP, LogonType, Tipe)
{
$sheet.cells.item($x,1) = $row.EventID
$sheet.cells.item($x,2) = $row.TimeGenerated
$sheet.cells.item($x,3) = $row.LogonName
$sheet.cells.item($x,4) = $row.LogonIP
$sheet.cells.item($x,5) = $row.LogonType
$sheet.cells.item($x,6) = $row.Tipe
$x++
}
$range = $sheet.usedRange
$range.EntireColumn.AutoFit() | Out-Null
$Excel.ActiveWorkbook.SaveAs($MLdir +''+'Audit'+ $file.basename.trim("report")+ $date +'.xlsx')
if($workbook -ne $null)
{
$sheet = $null
$range = $null
$workbook.Close($false)
}
if($excel -ne $null)
{
$excel.Quit()
$excel = $null
[GC]::Collect()
[GC]::WaitForPendingFinalizers()
}
$emailbody= import-csv $file|ConvertTo-Html
$EmailFrom = "audit@vda.vdg.aero"
$EmailTo = foreach ($a in (Import-Csv -Path $file).logonname){$a+"@"+"tst.com"}
$EmailSubject = "LOGON"
$SMTPServer = "10.60.34.131"
#$SMTPAuthUsername = "username"
#$SMTPAuthPassword = "password"
$emailattachment = "$datadir"+"$file" #$$filexls
send_email
}
Для полноценных отчетов в Excel устанавливаем Excel на станцию/сервер, с которой работает скрипт.
Добавляем скрипт в планировщик Windows на ежедневное выполнение. Оптимальное время —конец дня — поиск событий проводится за последние сутки.
Поиск событий возможен, начиная с систем Windows 7, Windows server 2008.
Более ранние Windows имеют другие коды событий (значение кода меньше на 4096).
Примечания и заключение:
Еще раз подытожим выполненные действия:
- Настроили локальные и доменные политики аудита на нужных серверах и собрали список серверов.
- Выбрали машину для выполнения скрипта, установили нужный софт (PS 3.0, LOG PARSER, Excel).
- Написали запрос для LOG PARSER.
- Написали скрипт, запускающий этот запрос в цикле для списка,.
- Написали оставшуюся часть скрипта, обрабатывающую полученные результаты.
- Настроили планировщик для ежедневного запуска.
Сгенерированные ранее отчеты лежат в каталоге до следующего выполнения скрипта. Список пользователей, выполнивших подключение, автоматически добавляется в получатели письма. Cделано это для корректной обработки при отправке отчета в систему анализа. В целом, благодаря LOG PARSER, получилось достаточно мощное, и, возможно, единственное средство автоматизации этой задачи. Удивительно, что такая полезная утилита с обширными возможностями не широко распространена. В минусы утилиты можно отнести слабую документацию. Запросы выполняются методом проб и ошибок. Желаю удачных экспериментов!
Вы никогда не задумывались о том, что если вы можете отслеживать деятельность залогиневшегося пользователя ОС Windows, то Вы так же можете и записывать информацию том, кто вошел в систему и, когда они из неё вышел? Это вполне возможно, если в системе Windows использовать функцию аудита входа. Отслеживание входа и выход пользователя очень полезно в организациях, где данные являются конфиденциальными и в ситуациях, когда Вы просто хотите узнать «кто это сделал» в вашей системе Windows. По умолчанию, функция аудита входа отключена в Windows. В этой статье, давайте посмотрим, как включить аудит авторизации и как отслеживания эти события в системе Windows.
Примечание: Аудит входа доступен только в Pro или Enterprise версий Windows 8.
Что такое Аудит входа
Аудит входа в систему — это встроенный параметр Windows, который можно найти в «Редакторе групповой локальной политики», который позволяет администратором Windows вести журнал и аудит каждого пользовательского входи и выхода на локальном компьютере или в сети. Также эта функция способна отслеживать любые неудачные попытки входа в систему. Это особенно полезно при определении и анализе любых несанкционированных подключений к Вашей машине Windows.
Включение аудита входа
Чтобы включить аудит входа в систему, мы должны настроить параметры групповой политики Windows. Нажмите сочетание клавиш “’Win + R”, введите gpedit.msc в диалоговом окне «Выполнить» и нажмите кнопку «ОК», чтобы открыть окно «Редактор локальной групповой политики».
После того, как редактор будет запущен, Перейдите в области навигации по следующему пути:
«Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита»
В открывшемся списке найдите и дважды кликните мышкой на политику «Аудит входа в систему». Пожалуйста, не путайте «Аудит входа в систему» с «Аудит событий входа в систему», так как это совершенно разных параметры.
После того, как откроется окно, выберите оба флажки «Успех» и «Отказ»’. Теперь нажмите на кнопку «Применить» и кнопку «ОК», чтобы сохранить изменения.
Вот и все, что нужно сделать. С этого момента, каждый вход и выход, а также попытки входа будут записываться в журнале событий.
Просмотр событий аудита входа в систему
Вы можете просмотреть все записи журнала входа, выхода и неудачных попыток входа в систему, в окне просмотра событий Windows. Вы можете запустить программу просмотра событий с помощью функции поиска в меню «Пуск». Если вы используете Windows 8, то Вы можете запустить то же самое окно с помощью меню сочетания клавиш «Win + X» и выбрав из меню пункт «Просмотр событий».
После того как вы запустите окно «Просмотра событий», перейдите к разделу «Журналы Windows», и выберете журнал «Безопасность».
Здесь Вы найдете все, что связанно с событиями безопасности, которые произошли в Вашей системе Windows. Если Вы дважды щелкните по ключевому слову «Аудит успеха», то Вы узнаете детальную информацию по данному событию.
Так же Вы можете фильтровать журнал событий с помощью различных параметров, нажав на кнопку «Фильтр текущего журнала…», расположенную на правой боковой панели окна «Просмотр событий».
Вот и все, что нужно сделать для того, чтобы просто отслеживать регистрацию пользователей в системе Windows.
Надеюсь, что статья была Вам интересна. Оставляйте комментарии, подписывайтесь на наши новости и оставайтесь с нами.
Случалось у вас так, что вы видите что за вашим компьютером кто-то работал, а вы не знаете когда и кто? Для того, чтоб система записывала в журнал событий информцию о том, кто входит в систему, нужно настроить групповые политики, а именно включить параметры аудита системы, относящиеся к событиям входа в систему (Audit logon events). События входа в систему отслеживают события как локального, так и сетевого входа в систему. Каждое событие содержит информацию об учетной записи, с помощью которой произведен вход в систему, а также время, когда это событие произошло. Помимо событий входа в систему, можно настроить аудит событий выхода из системы.
- Включаем аудит входов в систему
- Просмотр событий входа в систему
Открываем редактор групповых политик — Пуск — в строке поиска пишем gpedit.msc и нажимаем Ввод. Если вывляетесь администратором контроллера домена, можно нстроить данную групповую политику на контроллере домена.
Открываем следующий путь: Local Computer Policy –> Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Audit Policy.
Дабл кликаем параметр групповой политики Audit logon events. В окне свойств устанавливаем Success чекбокс для записи в журнал успешных входов в систему. Также можно установить чекбокс Failure для журналирования неудачных попыток входа в систему.
После включения данного параметра групповой политики, Windows будет записывать в журнал событий информацию об учетной записи с помощью которой произведен вход в систему, а также время, когда это событие произошло.
Для просмотра данных событий открываем Оснастку Просмотр событий — нажимаем меню Пуск — пишем Просмотр событий (Event Viewer) и нажимаем Ввод
Открываем путь Windows Logs –> Security.
Смотрим события:
- ID 4624 – это события успехов входа в систему.
- ID 4625 – это события отказов входа в систему.
Для того чтоб посмотреть полнюу информацию — даблкликайте интнресующее вас событие, и в открывшемся диалоговом окне смотрите детальную информацию.
Если у вас в журнале записано много событий, среди которых сложно отделить события с ID 4624 или 4625, можно воспользоваться фильтром. Для этого в правой части окна нажимаем кнопку Фильтр текущего журнала…
В открывшемся окне настроек фильтра, введите интересующий вас ID:
Как видно элементов в журнале существенно поубавилось:
На этом все. Если есть вопросы, уточнения, замечания — пишите.
В качестве дополения к данному материалу можно сказать, что помимо просмотра пост фактум журнала событий, в системе Windows 7 можно организовать отправку уведомлений по электронной почте, в случае ,если к вам в систему кто-то входит.
Содержание
- Аудит события входа
- Настройка параметра аудита
- Как посмотреть логи Windows?
- Просмотр событий для проверки логов.
- Фильтрация событий.
- Просмотр PowerShell логов.
- Получаем логи (историю) входа пользователя в домен AD
- Политика аудита входа пользователя в домен
- PowerShell: истории сетевых входов пользователя в домен
- Получаем информацию об активности пользователя в домене по событиям Kerberos
- Вертим логи как хотим ― анализ журналов в системах Windows
- Журналы и командная строка
- Работаем с журналами посредством запросов SQL
- Сбор и фильтрация событий входа в систему с помощью Log Parser
- Здравствуйте, уважаемое сообщество!
- Цели, которые мы преследуем:
- Настройка аудита и подготовка инфраструктуры:
- Готовим площадку для теста скрипта:
- Примечания и заключение:
Аудит события входа
Определяет, следует ли проверять каждый экземпляр входа пользователя на устройство или его отключение.
События логотипа учетной записи создаются на контроллерах доменов для действий учетных записей домена и на локальных устройствах для локальной активности учетной записи. Если включены как категории политик аудита для логотипов учетных записей, так и для политик аудита, логотипы, которые используют учетную запись домена, создают событие logon или logoff на рабочей станции или сервере и создают событие логотипа учетной записи на контроллере домена. Кроме того, интерактивные логотипы на сервере членов или рабочей станции, которые используют учетную запись домена, создают событие logon на контроллере домена, так как скрипты и политики логотипа извлекаются при входе пользователя в систему. Дополнительные сведения о событиях с логотипом учетной записи см. в сайте Audit account logon events.
Определяя этот параметр политики, можно задать аудит успехов, аудит неудач либо отключить аудит всех типов событий. Аудиты успешности создают запись аудита при успешной попытке логотипа. Аудиты сбоя создают запись аудита при сбое попытки логона.
Чтобы установить это значение без аудита, в диалоговом окне **** Свойства для этого параметра политики выберите флажок Определить эти параметры политики и очистить флажки Success и Failure. ****
Сведения о расширенных параметрах политики безопасности для событий с логотипами см. в разделе Logon/logoff в разделе Расширенные параметры политики аудита безопасности.
Настройка параметра аудита
Вы можете настроить этот параметр безопасности, открыв соответствующую политику в области конфигурации компьютераWindows ПараметрыSecurity ПараметрыLocal PoliciesAudit Policy.
События Logon | Описание |
---|---|
4624 | Пользователь успешно вошел на компьютер. Сведения о типе логотипа см. в таблице Типы logon ниже. |
4625 | Сбой Logon. Попытка логотипа была предпринята с неизвестным именем пользователя или известным именем пользователя с плохим паролем. |
4634 | Процесс входа был завершен для пользователя. |
4647 | Пользователь инициировал процесс входа. |
4648 | Пользователь успешно вошел на компьютер с использованием явных учетных данных, уже во время входа в систему в качестве другого пользователя. |
4779 | Пользователь отключил сеанс сервера терминала без входа. |
При входе в журнал события 528 в журнале событий также указан тип логотипа. В следующей таблице описывается каждый тип логотипа.
Источник
Как посмотреть логи Windows?
Ищете сервер с Windows? Выбирайте наши Windows VDS
Просмотр событий для проверки логов.
После нажатия комбинации “ Win+R и введите eventvwr.msc ” в любой системе Виндовс вы попадаете в просмотр событий. У вас откроется окно, где нужно развернуть Журналы Windows. В данном окне можно просмотреть все программы, которые открывались на ОС и, если была допущена ошибка, она также отобразится.
Аудит журнал поможет понять, что и кто и когда делал. Также отображается информация по запросам получения доступов.
В пункте Установка можно посмотреть логи ОС Виндовс, например, программы и обновления системы.
Фильтрация событий.
С помощью Фильтра текущего журнала (раздел Действия) можно отфильтровать информацию, которую вы хотите просмотреть.
Обязательно нужно указать уровень Событий:
Для сужения поиска можно отфильтровать источник событий и код.
Просмотр PowerShell логов.
В результате вы получите логи Системы
Также обязательно ознакомьтесь с перечнем аббревиатур:
Для выведения событий в командной оболочке только со столбцами «Уровень», «Дата записи события», «Источник», «Код события», «Категория» и «Сообщение события» для журнала «Система» используйте:
Get-EventLog –LogName ‘System’ | Format-Table EntryType, TimeWritten, Source, EventID, Category, Message
Если нужна подробная информация, замените Format-Table на Format-List на
Get-EventLog –LogName ‘System’ | Format-List EntryType, TimeWritten, Source, EventID, Category, Message
Формат информации станет более легким
Для фильтрации журнала, например, для фильтрации последних 20 сообщений, используйте команду
Get-EventLog –Logname ‘System’ –Newest 20
Если нужен список, позднее даты 1 января 2018 года, команда
Get-EventLog –LogName ‘System’ –After ‘1 января 2018’
Надеемся, данная статья поможет вам быстро и просто читать логи ОС Windows.
Желаем приятной работы!
Как установить свой образ на ВДС сервер с Виндовс, читайте в предыдущей статье.
Источник
Получаем логи (историю) входа пользователя в домен AD
Есть несколько различных инструментов получения информации о времени логина пользователя в домен. Время последней успешной аутентификации пользователя в домене можно получить из атрибута lastLogon (обновляется только на контроллере домена, на котором выполнена проверка учетных данных пользователя) или lastLogonTimpestamp (реплицируется между DC в домене, но по умолчанию только через 14 дней). Вы можете получить значение этого атрибута пользователя в редакторе атрибутов AD или командлетом Get-ADUser. Однако иногда нужно получить историю активности (входов) пользователя в домене за большой период времени.
Вы можете получить информацию об успешных входах (аутентфикации) пользователя в домене из журналов контроллеров домена. В этой статье мы покажем, как отслеживать историю входов пользователя в домен с помощью PowerShell.. Т.е. можно получить полную историю активности пользователя в домене, время начала работы и компьютеры, с которых работает пользователь.
Политика аудита входа пользователя в домен
Чтобы в журналах контроллеров домена отображалась информация об успешном/неуспешном входе в систему, нужно включить политику аудита событий входа пользователей.
Теперь при входе пользователя на любой компьютер домена Active Directory в журнале контроллера домена, который выполняет аутентификацию пользователя, появляется событие с Event ID 4624 (An account was successfully logged on). В описании этого события указана учетная запись, которая успешно аутентифицировалась (Account name), имя (Workstation name) или IP адрес (Source Network Address) компьютера, с которого выполнен вход.
Также в поле Logon Type указан тип входа в систему. Нас интересуют следующие коды
В событии 4768 также указана учетная запись пользователя (Account Name или User ID), который получил билет Kerberos (аутентифицировался) и имя (IP адрес) компьютера.
PowerShell: истории сетевых входов пользователя в домен
С помощью командлета PowerShell Get-Eventlog можно получить все события из журнала контроллера домена, отфильтровать их по нужному коду (EventID) и вывести данные о времени, когда пользователь аутентифицировался в домене, и компьютере, с которого выполнен вход. Т.к. в домене может быть несколько контроллеров домена и нужно получить история входов пользователя с каждого из них, нужно воспользоваться командлетом Get-ADDomainController (из модуля AD для Windows PowerShell). Данный командлет позволяет получить список всех DC в домене.
Следующий PowerShell скрипт позволяет получить все события входа пользователя в домен AD со всех контроллеров домена. На выходе вы получаете таблицу с историей входа пользователя и компьютеров, с которых аутентифицировался пользователь.
Получаем информацию об активности пользователя в домене по событиям Kerberos
Также вы можете получить историю аутентификации пользователя в домене по по событию выдачи билета Kerberos (TGT Request — EventID 4768). В этом случае в итоговых данных будет содержаться меньшее количество событий (исключены сетевые входы, обращения к папкам на DC во время получения политик и выполнения логон-скриптов). Следующий PowerShell скрипт выведет информацию о всех входах пользователей за последние 24 часа:
Обратите, что в этом случае вы не увидите события входов пользователей, которые аутентифицировались с клиентов или приложений, которые используют NTLM вместо Kerberos.
Источник
Вертим логи как хотим ― анализ журналов в системах Windows
Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.
В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.
Журналы и командная строка
До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:
Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.
Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:
Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:
Смотрим за ходом обновления Windows.
Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:
Смотрим, кто пытается пролезть на наш дедик.
При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:
Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:
Для получения списка доступных системных журналов можно выполнить следующую команду:
Вывод доступных журналов и информации о них.
Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:
Последние записи в журнале System.
Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.
Для примера получим все события из журнала System с кодом события 1 и 6013.
В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:
Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:
Ошибки и предупреждения журнала System.
Аналогичным образом можно собирать таблицу, фильтруя непосредственно по тексту события и по времени.
Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:
PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.
Работаем с журналами посредством запросов SQL
Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.
О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.
Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:
Посмотрим на результат:
Смотрим журнал Windows Firewall.
Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.
Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.
Работать будем с журналом TerminalServices-LocalSessionManagerOperational.
Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%System32WinevtLogsMicrosoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%test.evtx.
Данные будем получать таким запросом:
Смотрим, кто и когда подключался к нашему серверу терминалов.
Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.
В качестве примера посмотрим статистику количества писем по дням таким запросом:
Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.
Выполняем запрос и открываем получившуюся картинку…
Любуемся результатом.
Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.
Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.
Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.
Интерфейс Log Parser Studio.
Основной особенностью здесь является библиотека, которая позволяет держать все запросы в одном месте, без россыпи по папкам. Также сходу представлено множество готовых примеров, которые помогут разобраться с запросами.
Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.
В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:
Выборка наиболее активных ящиков.
При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.
Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.
Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.
Источник
Сбор и фильтрация событий входа в систему с помощью Log Parser
Здравствуйте, уважаемое сообщество!
ИТ-инфраструктура всегда находится в динамике. Тысячи изменений происходят ежеминутно. Многие из них требуется регистрировать. Аудит систем является неотъемлемой частью информационной безопасности организаций. Контроль изменений позволяет предотвратить серьезные происшествия в дальнейшем.
В статье я хочу рассказать о своем опыте отслеживания событий входа (и выхода) пользователей на серверах организации, подробно описать те детали, которые возникли в ходе выполнения задачи анализа логов аудита, а также привести решение этой задачи по шагам.
Цели, которые мы преследуем:
Анализ логов является рутинной операцией системного администратора. В данном случае объёмы фиксируемых событий в домене таковы, что это само по себе сложно. Аудит включается в групповой политике.
События входа в систему формируются:
1. контроллерами домена, в процессе проверки учетных записей домена;
2. локальными компьютерами при работе с локальными учетными записями.
Если включены обе категории политик (учетных записей и аудита), то входы в систему, использующие учетную запись домена, будут формировать события входа или выхода на рабочей станции или сервере и событие входа в систему на контроллере домена. Таким образом, аудит на доменные машины потребуется настроить через оснастку GPO на контроллере, аудит локальный — через локальную политику безопасности с помощью оснастки MMC.
Настройка аудита и подготовка инфраструктуры:
Рассмотрим этот этап подробно. Для уменьшения объемов информации мы смотрим только успешные события входа и выхода. Имеет смысл увеличить размер журнала security Windows. По умолчанию — это 128 Мегабайт.
Для настройки локальной политики:
Открываем редактор политик – Пуск, в строке поиска пишем gpedit.msc и нажимаем Ввод.
Открываем следующий путь: Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policy.
Дважды кликаем параметр групповой политики Audit logon events (аудит входа в систему) и Audit account logon events (аудит событий входа в систему). В окне свойств устанавливаем Success-чекбокс для записи в журнал успешных входов в систему. Чекбокс Failure устанавливать не рекомендую во избежание переполнения. Для применения политики необходимо набрать в консоли gpupdate /force
Для настройки групповой политики:
Создаем новый объект GPO (групповую политику) с именем «Audit AD». Переходим в раздел редактирования и разворачиваем ветку Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Configuration. В данной ветке групповых политик находятся расширенные политики аудита, которые можно активировать в ОС семейства Windows для отслеживания различных событий. В Windows 7 и Windows Server 2008 R2 количество событий, для которых можно осуществлять аудит увеличено до 53. Эти 53 политики аудита (т.н. гранулярные политики аудита) находятся в ветке Security SettingsAdvanced Audit Policy
Configuration и сгруппированы в десяти категориях:
Сразу оговорим типы событий, которые будет анализировать наш будущий скрипт:
Скорость обработки данных возросла в разы, полный прогон с формированием отчета с одного ПК сократился до 10 секунд. Утилита использует немало опций командной строки, поэтому мы будем вызывать cmd из powershell, чтобы избавиться от экранирования кучи специальных символов. Для написания запросов можно воспользоваться GUI — Log Parser Lizard. Он не бесплатен, но триального периода в 65 дней хватает. Ниже привожу сам запрос. Помимо интересующих нас, распишем и другие варианты входа в систему, на случай дальнейшего использования.
Далее привожу общее описание логики:
Готовим площадку для теста скрипта:
Для корректной работы скрипта необходимо выполнение следующих условий:
Создаем каталог на сервере/рабочей станции, с которой выполняется скрипт. Размещаем файлы скрипта в каталог С:audit. Список хостов и скрипт лежат в одном каталоге.
Заполняем список интересующих нас серверов list.txt для аудита в каталоге С:audit по именам рабочих станций. Настраиваем политику Аудита. Убеждаемся, что она работает.
Проверяем, запущена ли служба удаленного реестра (скрипт делает попытку запуска и перевода службы в автоматический режим при наличии соответствующих прав). На серверах 2008/2012 эта служба запущена по умолчанию.
Проверяем наличие прав администратора для подключения к системе и сбора логов.
Проверяем возможность запуска неподписанных скриптов powershell на удаленной машине (подписать скрипт или обойти/отключить restriction policy).
Внимание на параметры запуска неподписанных скриптов — execution policy на сервере:
Обойти запрет можно подписав скрипт, либо отключить саму политику при запуске. Например:
Привожу весь листинг скрипта:
Для полноценных отчетов в Excel устанавливаем Excel на станцию/сервер, с которой работает скрипт.
Добавляем скрипт в планировщик Windows на ежедневное выполнение. Оптимальное время —конец дня — поиск событий проводится за последние сутки.
Поиск событий возможен, начиная с систем Windows 7, Windows server 2008.
Более ранние Windows имеют другие коды событий (значение кода меньше на 4096).
Примечания и заключение:
Еще раз подытожим выполненные действия:
Источник
Мониторинг внешнего входа и выхода пользователей Windows
Данные будем брать из Журнал событий (англ. Event Log)
Панель управленияВсе элементы панели управленияАдминистрированиеПросмотр событий
или (Win+R) команду eventvwr.msc
eventlog-Microsoft-Windows-TerminalServices-LocalSessionManager-Operational
LSM — Local Session Manager
RCM — Remote Connection Manager
Запрос для Ключа eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]
- eventlog-Microsoft-Windows-TerminalServices-LocalSessionManager-Operational
Пример Просмотр и анализ логов RDP подключений в Windows
Ключ в zabbix будет использоваться eventlog
eventlog[имя,<регулярное выражение>,<важность>,<источник>,<eventid>,<макс. кол-во строк>,<режим>]
eventlog[имя»Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,<регулярное выражение>пропускаем пусто,<важность>пропускаем пусто,<источник>пропускаем пусто,<eventid>^(21|23|24|25)$,<макс. кол-во строк>пропускаем пусто,<режим>skip]
skip — пропустить обработку старых данных
eventlog[имя,<регулярное выражение>,<важность>,<источник>,<eventid>,<макс. кол-во строк>,<режим>]
Мониторинг журналов событий.
Журнал (лог)
имя — имя журнала событий
регулярное выражение — регулярное выражение описывающее требуемый шаблон содержимого
важность — регулярное выражение описывающее важность
Параметр может принимать следующие значения:
“Information”, “Warning”, “Error”, “Critical”, “Verbose” (начиная с Zabbix 2.2, работающих на Windows Vista или на более новых версиях)
источник — регулярное выражение, описывающее идентификатор источника (регулярное выражение поддерживается начиная с версии Zabbix 2.2.0)
eventid — регулярное выражение описывающее идентификатор(ы) событий
макс. кол-во строк — максимальное количество новых строк в секунду, которое агент будет отправлять Zabbix серверу или прокси. Этот параметр заменяет значение ‘MaxLinesPerSecond’ в zabbix_agentd.win.conf
режим — возможные значения:
all (по умолчанию), skip — пропустить обработку старых данных (влияет только на недавно созданные элементы данных).
Элемент данных должен быть настроен активной проверкой.
Примеры:
⇒ eventlog[Application]
⇒ eventlog[Security,,»Failure Audit»,,529|680]
⇒ eventlog[System,,»Warning|Error»]
⇒ eventlog[System,,,,^1$]
⇒ eventlog[System,,,,@TWOSHORT] — здесь используется ссылка на пользовательское регулярное выражение с именем TWOSHORT (заданное с типом Результат ИСТИНА, само выражение равно ^1$|^70$).
Обратите внимание, агент не может отправлять события из «Пересланные события» журнала.
Параметр режим поддерживается начиная с версии 2.0.0.
“Windows Eventing 6.0” поддерживается начиная с Zabbix 2.2.0.
Обратите внимание, что выбор не журнального типа информации для этого элемента данных приведет к потере локального штампа времени, а также важности журнала и информации о источнике.
Смотрите дополнительную информацию о мониторинге файлов журналов.
СПЕЦИФИЧНЫЕ КЛЮЧИ ЭЛЕМЕНТОВ ДАННЫХ
Триггер
logeventid
Проверка, совпадает ли ID события последней записи из журнала указанному регулярному выражению.
шаблон — регулярное выражение описывающее требуемый шаблон, в формате расширенных регулярных выражений POSIX.
Поддерживаемые типы значений: log
Возвращает:
0 — не совпадает
1 — совпадает
Изначально шаблон был взят с Windows Server Login monitor далее путь на гитхаб Server-Login-monitor-Zabbix
Для начала оригинальный шаблон автора который был скачен с гитхаба
# Server-Login-monitor-Zabbix
uses Microsoft-Windows-TerminalServices-LocalSessionManager windows log to find logins and logouts to server.
and fires alarm when a user logs in to a server
Simply import to zabbix and add the template to desired hosts.
#Сервер-Логин-монитор-Zabbix
использует журнал Windows Microsoft-Windows-TerminalServices-LocalSessionManager для поиска логинов и выходов на сервер.
и подает сигнал тревоги, когда пользователь входит на сервер
Просто импортируйте в zabbix и добавьте шаблон на желаемые хосты.
Имя шаблона Windows external login monitor
Группы Windows
Описание Monitor non administrator logins on server
Макросы
{$HIDELOGINS} => Administrator
(не проверять, не выводить триггер когда заходит пользователь Administrator)
- Windows external login monitor
Группы элементов данных
Log
RDP
Элементы данных
Имя Login to Remote desktop
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23)$,,skip]
Тип информации Журнал (Лог)
Интервал обновления 15s
Период хранения истории 90d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных
Log
RDP
Описание Monitor RDP login and logout
Активировано V
Предобработка
Шаги предобработки Имя Регулярное выражение Параметры User: (.*)n Вывод 1
Для Русскоязычных систем Windows в Логе вместо User по Русскому пишется Пользователь получаем
Шаги предобработки Имя Регулярное выражение Параметры Пользователь: (.*)n Вывод 1
- Элемент данных Windows external login monitor
Триггер
Имя {ITEM.LASTVALUE1} RDP login
Важность Высокая
Выражение проблемы
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23)$,,skip].logeventid(21)}=1
Генерация ОК событий Выражение восстановления
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23)$,,skip].logeventid(21)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание Fires alarm unless RDP login is administrator
Активировано V
- Триггер Windows external login monitor.jpg
Скачать шаблон
Далее первые изменения в шаблоне
Переведён полностью на Русский язык
Добавлены описания
Добавлен триггер на повторный вход 25
Имя шаблона Windows external login monitor
Видимое имя Монитор внешнего входа Windows
Описание Monitor non administrator logins on server
Мониторинг Логинов без прав администратора на сервере
Макросы
{$HIDELOGINS} => No я решил показывать все входы, не скрывая
- Windows external login monitor rus.jpg
Группы элементов данных
LOG-RDP&Local
Элементы данных
Имя Вход на удаленный рабочий стол
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]
Тип информации Журнал (Лог)
Интервал обновления 15s
Период хранения истории 90d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных
LOG-RDP&Local
Описание
Login to Remote desktop
Monitor RDP login and logout
Вход на удаленный рабочий стол
Монитор РДП вход и выход
17 — ошибка Не удалось запустить службу удаленного рабочего стола
21 — успешный Вход
22 — получено уведомление о запуске оболочки
23 — выход из сеанса
24 — отключен
25 — успешное пере подключение
Скрыть вход добавить макрос {$HIDELOGINS} Administrator
Активировано V
Предобработка
Для Русскоязычных систем Windows в Логе вместо User по Русскому пишется Пользователь получаем
Шаги предобработки Имя Регулярное выражение Параметры Пользователь: (.*)n Вывод 1
- Элемент данных Windows external login monitor rus.jpg
Триггеры 2
Имя {ITEM.LASTVALUE1} RDP login
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(21)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(21)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Fires alarm unless RDP login is administrator
21 — успешный Вход
Пожары сигнализации, если RDP логин администратора
Активировано V
- Триггер Windows external login monitor rus.jpg
Имя {ITEM.LASTVALUE1} RDP login povtor
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(25)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(25)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Fires alarm unless RDP login is administrator
25 — успешное переподключение
Пожары сигнализации, если RDP логин администратора
Активировано V
- Триггер 2 Windows external login monitor rus.jpg
Скачать Шаблон
Дальнейшие доработки
Мало инфы в триггере 1.Пользователь который подключился 2.IP-адресс откуда подключился 3.Код Сеанса 4.Имя ПК с которого выполнено подключение
Отключенные пользователи которые не завершили сеанс, а просто его закрыли! Корректно нужно завершать сеанс, так же нужно проверять.
Сперва текущий актуальный шаблон на 12.01.2021, ниже как это делалось какие проблемы возникали и тд.
Скачать
Скачать
19.08.2022
Для элемента данных «Получаем предыдущее значение для Windows LSM»
если Windows включен но никто не заходил данные пустые строки нет и элемент уходит в ошибку что тип не числовой, в предобработке при пустом значении делаем 0.
- Если пустое значение а тип числовой делаем 0
Имя шаблона Windows external login monitor
Видимое имя Монитор внешнего входа Windows
Группы Windows и Windows Server
Описание
Monitor non administrator logins on server
Мониторинг Логинов без прав администратора на сервере
Макрос
{$HIDELOGINS} => No
- Шаблон Монитор внешнего входа Windows.jpg
Группы элементов данных LOG-RDP&Local
Элементы данных 5
- Элементы данных Монитор внешнего входа Windows
Элемент данных
Имя Вход в Windows LSM
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip]
Тип информации Журнал (лог)
Интервал обновления 15s
Период хранения истории Storage period 31d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных LOG-RDP&Local
Описание
Login to Remote desktop
Monitor RDP login and logout
Вход на удаленный рабочий стол
Монитор РДП вход и выход
17 — ошибка Не удалось запустить службу удаленного рабочего стола
21 — успешный Вход
22 — получено уведомление о запуске оболочки
23 — выход из сеанса
24 — отключен
25 — успешное переподключение
39 — (Session <A> has been disconnected by session <B>) – пользователь сам отключился от своей RDP сессии, выбрав соответствующий пункт меню (а не просто закрыл окно RDP клиента).
Если идентификаторы сессий разные, значит пользователя отключил другой пользователь (или администратор).
40 — Здесь нужно смотреть на код причины отключения в событии. Например:
Описание: «Сеанс <X> был отключен, код причины <Z>»
Сенас * был отключен, код причины 0
reason code 0 (No additional information is available)– обычно говорит о том, что пользователь просто закрыл окно RDP клиента, обычно в паре с идентификатором события 24
reason code 1 Отключение было инициировано административным инструментом на сервере в другом сеансе.
reason code 2 Отключение произошло из-за принудительного выхода из системы, инициированного административным инструментом на сервере в другом сеансе.
reason code 3 Таймер ограничения сеанса простоя на сервере истек.
reason code 4 Таймер ограничения активных сеансов на сервере истек.
reason code 5 (The client’s connection was replaced by another connection) – пользователь переподключился к своей старой сессии.
Сенас * был отключен, код причины 5 — Другой пользователь подключился к серверу, принудительно отключив текущее соединение. «Соединение клиента было заменено другим соединением». (Происходит, когда пользователь повторно подключается к сеансу RDP, обычно в паре с идентификатором события 25)
reason code 6 На сервере закончились доступные ресурсы памяти.
reason code 7 Сервер отказал в соединении.
reason code 8 Сервер отказал в соединении из соображений безопасности.
reason code 9 Пользователь не может подключиться к серверу из-за недостаточных прав доступа.
reason code 10 Сервер не принимает сохраненные учетные данные пользователя и требует, чтобы пользователь вводил свои учетные данные для каждого подключения.
reason code 11 (User activity has initiated the disconnect) – пользователь сам нажал на кнопку Disconnect в меню (Пуск отключение).
Отключение было инициировано пользователем, отключившим свой сеанс на сервере, или инструментом администрирования на сервере.
reason code 12 Отключение было инициировано пользователем, завершившим сеанс на сервере.
Сенас * был отключен, код причины 12 — Отключение было инициировано пользователем, завершившим сеанс на сервере
Определяет расширенную информацию о причине отключения элемента управления
Windows Vista — Server 2008 билиотека MsTscAx.dll
typedef enum _ExtendedDisconnectReasonCode {
exDiscReasonNoInfo = 0, Никакой дополнительной информации нет.
exDiscReasonAPIInitiatedDisconnect = 1, Приложение инициировало отключение.
exDiscReasonAPIInitiatedLogoff = 2, Приложение вышло из системы клиента.
exDiscReasonServerIdleTimeout = 3, Сервер отключил клиента, потому что клиент бездействовал в течение периода времени, превышающего назначенный период ожидания.
exDiscReasonServerLogonTimeout = 4, Сервер отключил клиента, поскольку клиент превысил период, отведенный для подключения.
exDiscReasonReplacedByOtherConnection = 5, Подключение клиента было заменено другим подключением.
exDiscReasonOutOfMemory = 6, Нет свободной памяти.
exDiscReasonServerDeniedConnection = 7, Сервер отказал в соединении.
exDiscReasonServerDeniedConnectionFips = 8, Сервер отказал в соединении из соображений безопасности.
exDiscReasonServerInsufficientPrivileges = 9, Сервер отказал в соединении из соображений безопасности.
exDiscReasonServerFreshCredsRequired = 10, Требуются новые учетные данные.
exDiscReasonRpcInitiatedDisconnectByUser = 11, Действия пользователя привели к отключению
exDiscReasonLogoffByUser = 2, Пользователь вышел из системы, отключив сеанс.
exDiscReasonLicenseInternal = 256, Ошибка внутреннего лицензирования.
exDiscReasonLicenseNoLicenseServer = 257, Сервер лицензий недоступен.
exDiscReasonLicenseNoLicense = 258, Действующей лицензии на программное обеспечение не было.
exDiscReasonLicenseErrClientMsg = 259, Удаленный компьютер получил недействительное лицензионное сообщение.
exDiscReasonLicenseHwidDoesntMatchLicense = 260, Идентификатор оборудования не соответствует идентификатору, указанному в лицензии на программное обеспечение.
exDiscReasonLicenseErrClientLicense = 261, Ошибка клиентской лицензии.
exDiscReasonLicenseCantFinishProtocol = 262, Проблемы с сетью возникли во время протокола лицензирования.
exDiscReasonLicenseClientEndedProtocol = 263, Клиент преждевременно прервал лицензионный протокол.
exDiscReasonLicenseErrClientEncryption = 264, Сообщение о лицензировании было зашифровано неправильно.
exDiscReasonLicenseCantUpgradeLicense = 265, Не удалось обновить или продлить лицензию на клиентский доступ локального компьютера.
exDiscReasonLicenseNoRemoteConnections = 266, Удаленный компьютер не имеет лицензии на прием удаленных подключений.
exDiscReasonLicenseCreatingLicStoreAccDenied = 267, При создании раздела реестра для хранилища лицензий была получена ошибка отказа в доступе.
exDiscReasonRdpEncInvalidCredentials = 768, Обнаружены неверные учетные данные.
exDiscReasonProtocolRangeStart = 4096, Начало диапазона внутренних ошибок протокола. Дополнительные сведения см. В журнале событий сервера.
exDiscReasonProtocolRangeEnd = 32767 Конец диапазона внутренних ошибок протокола.
} ExtendedDisconnectReasonCode;
Скрыть вход добавить макрос {$HIDELOGINS} Administrator
(Win+R) команду eventvwr.msc
- Элемент данных Вход в Windows LSM
Элемент данных
Имя Получаем предыдущее значение для Windows LSM
Тип Zabbix агент
Ключ system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»»]
Тип информации Числовой (целое положительное)
Интервал обновления 1m
Пользовательские интервалы Переменный
Период хранения истории Storage period 31d
Период хранения динамики изменений Storage period 31d
Отображение значения Как есть
Группы элементов данных LOG-RDP&Local
Описание
Получаем значение, для закрытия триггера на пользователь отключен
Если RDP закрыт, а не завершен то в журнале
24 — отключен
после триггер действие завершение и
23 — выход из сеанса (закрывает триггер)
А если завершен, в логе
23-выход из сеанса
24 — отключен
И по этому триггер на отключение не закрывается
Поэтому смотрим предпоследнюю запись если она 23 триггер не срабатывает.
Активировано V
Предобработка
Шаги предобработки
1 Имя Обрезать Параметры [2] Event ID
2 Имя Обрезать Параметры :
- Вход в Windows RCM
Элемент данных
Имя Вход в Windows Security
Тип Zabbix агент (активный)
Ключ eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip]
Тип информации Журнал (лог)
Интервал обновления 15s
Период хранения истории Storage period 31d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных LOG-RDP&Local
Описание
1100 — Завершение работы
1102 — Очистка журнала
4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
Тип входа» указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).
4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи: Целевой сервер: — Имя целевого сервера: (Попытка входа)
(Имя целевого сервера: FS Имя учетной записи: User) Были использованы учетные данные следующей учетной записи:
Имя учетной записи:Admin
4634 — выход (23 в 2 журнале)
4647 — выход
4778 — Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID)
4799 — Отключение от RDP сеанса
9009 — Пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен
(Win+R) команду eventvwr.msc
Активировано
- Элемент данных Вход в Windows Security
Элемент данных
Имя Вход в Windows RCM
Тип Zabbix агент (активный)
Ключ eventlog[«Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational»,,,,^(1149|4624|4625)$,,skip]
Тип информации Журнал (лог)
Интервал обновления 15s
Период хранения истории Storage period 31d
Формат времени в журнале (логе) ddMMyyyy:hhmmss
Группы элементов данных LOG-RDP&Local
Описание
1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)
4624 — успешная аутентификация
4625 — ошибка аутентификации
При входе через терминальную службу RDP — LogonType = 10 или 3.
Если LogonType = 7, значит выполнено переподключение к уже имеющейся RDP сессии.
Account Name — имя пользователя
Workstation Name — имя компьютера
Source Network Address — имя пользователя
TargetLogonID – уникальный идентификатор сессии пользователя
(Win+R) команду eventvwr.msc
Активировано
- Элемент данных Вход в Windows RCM
Элемент данных
Имя ClientName
Тип Zabbix агент (активный)
Ключ 1
Тип информации Текст
Интервал обновления 60s
Период хранения истории Storage period 90d
Группы элементов данных LOG-RDP&Local
Описание
через power shell запрашиваем Get-TSSession -State Active | Format-List ClientName
Активировано
- Элемент данных ClientName
Проверка со стороны сервера
zabbix_get -s 192.168.ххх.ххх -k 1
На стороне заббикс агента в конфигурации прописываем следующее
Конфигурация агента ссылается на скрипт повершела
UserParameter=1, powershell C:zabbixScripts1.ps1
Содержание скрипта 1.ps1
Get-TSSession -ComputerName Program
или
Get-TSSession
или
Get-TSSession | Format-List ClientName
или
Get-TSSession -State Active | Format-List ClientName
Триггеры 4
- Триггеры Монитор внешнего входа Windows
Триггер
Имя RDP auth {{ITEM.VALUE}.iregsub(«(Пользователь: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(источника: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(Код сеанса: .*)», «1»)}
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(21)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(21)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Fires alarm unless RDP login is administrator
21 — успешный Вход
Пожары сигнализации, если RDP логин администратора
Активировано V
Теги
Trigger tags
Имя {{ITEM.VALUE}.iregsub(«Код сеанса: (.*)», «1»)} Значение
- Триггер Входа Аунтификации Монитор внешнего входа Windows
Триггер
Имя RDP auth povtor {{ITEM.VALUE}.iregsub(«(Пользователь: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(источника: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(Код сеанса: .*)», «1»)}
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(25)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(25)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Fires alarm unless RDP login is administrator
25 — успешное переподключение
Пожары сигнализации, если RDP логин администратора
Активировано V
Теги
Trigger tags
Имя {{ITEM.VALUE}.iregsub(«Код сеанса: (.*)», «1»)}
- Триггер Повтора Входа Аунтификации Монитор внешнего входа Windows
Триггер
Имя RDP auth otkl {{ITEM.VALUE}.iregsub(«(Пользователь: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(источника: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(Код сеанса: .*)», «1»)}
Важность Информация
Выражение проблемы
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(24)}=1 and
{Windows external login monitor:system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»»].last()}<>23 and
{Windows external login monitor:system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»»].diff(0)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(24)}=0 or
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip].logeventid(24)}=1 and
{Windows external login monitor:system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»»].last()}=23
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
23 — выход из сеанса (закрывает триггер)
24 — отключен
Срабатывает если последняя запись 24 и предпоследняя не равна 23
не создавалось множество указано diff
Активировано V
Теги
Trigger tags
Имя {{ITEM.VALUE}.iregsub(«Код сеанса: (.*)», «1»)} Значение
- Триггер Отключен Входа Аунтификации Монитор внешнего входа Windows
Триггер
Имя RDP auth {{ITEM.VALUE}.iregsub(«(Тип входа: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(Имя рабочей станции: .*)», «1»)}
Важность Информация
Выражение проблемы {Windows external login monitor:eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip].logeventid(4624)}=1
Генерация ОК событий Выражение восстановления
Выражение восстановления {Windows external login monitor:eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip].logeventid(4624)}=0
Режим генерации событий ПРОБЛЕМА Множественный
ОК событие закрывает Все проблемы
Разрешить закрывать вручную V
Описание
Вход с Имя компьютера подключенного по RDP Лог 4624
Активировано
- Триггер Входа Имя ПК Аунтификации Монитор внешнего входа Windows
Про Инфу в триггер 1.Пользователь который подключился 2.Код Сеанса 3.IP-адресс откуда подключился или локальный вход 4.Имя ПК с которого выполнено подключение
На примере диспетчера задач вкладка пользователи
Windows 10
- RDP-подключение.jpg
Windows 7
- Имя клиента.jpg
Из журнала Microsoft-Windows-TerminalServices-LocalSessionManager/Operational можем получить
Пользователь: источника: Код сеанса:
Локально: 21
Службы удаленных рабочих столов: Успешный вход в систему:
/Пользователь: COMPTVМедиа
Код сеанса: 1
Адрес сети источника: ЛОКАЛЬНЫЕ
Посети: 21
Службы удаленных рабочих столов: Успешный вход в систему:
/Пользователь: COMPTVМедиа
Код сеанса: 2
Адрес сети источника: 192.168.175.8
Посети: 25
Службы удаленных рабочих столов: Успешное переподключение сеанса:
Пользователь: COMPTVМедиа
Код сеанса: 1
Адрес сети источника: 192.168.175.8
По сети: 24
Службы удаленных рабочих столов: Сеанс был отключен:
Пользователь: COMPTVМедиа
Код сеанса: 1
Адрес сети источника: 192.168.175.8
Локально 23
Службы удаленных рабочих столов: Успешный выход из сеанса:
Пользователь: COMPTVМедиа
Код сеанса: 1
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)
Триггер RDP auth Пользователь: ДоменMamzikovAA источника: 192.168.175.8 Код сеанса: 4
21
Службы удаленных рабочих столов: Успешный вход в систему:
/Пользователь: ДоменMamzikovAA
Код сеанса: 4
Адрес сети источника: 192.168.175.8
23
Службы удаленных рабочих столов: Успешный выход из сеанса:
Пользователь: ДоменMamzikovAA
Код сеанса: 4
24
Службы удаленных рабочих столов: Сеанс был отключен:
Пользователь: ДоменMamzikovAA
Код сеанса: 4
Адрес сети источника: 192.168.175.8
25
Службы удаленных рабочих столов: Успешное переподключение сеанса:
Пользователь: ДоменАдминистратор
Код сеанса: 1
Адрес сети источника: 192.168.175.10
Но Имя ПК с которого выполнено подключение в данном логе нет
оно есть в eventlog[«Security»,,,,^(1100|1102|4624|4634|4647)$,,skip]
Журналы Windows — Безопасность
Вход с Имя компьютера подключенного по RDP Лог 4624
Тип входа: Имя рабочей станции:
Описание Кодов:
1100 — Завершение работы
1102 — Очистка журнала
4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи: Целевой сервер: — Имя целевого сервера: (Попытка входа)
4634 — выход (23 в 2 журнале)
4647 — выход
4778 — Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID)
4799 — Отключение от RDP сеанса
9009 — Пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен
(Win+R) команду eventvwr.msc
4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
Вход с учетной записью выполнен успешно.
Субъект:
ИД безопасности: S-1-5-18
Имя учетной записи: FSServer$
Домен учетной записи: WORKGROUP
Код входа: 0x3e7
Тип входа: 10 не совпадает с кодом сеанса
Новый вход:
ИД безопасности: S-1-5-21-52705171-3967056117-1643963046-500
Имя учетной записи: Администратор
Домен учетной записи: FSServer
Код входа: 0x163d7532
GUID входа: {00000000-0000-0000-0000-000000000000}
Сведения о процессе:
Идентификатор процесса: 0xdf0
Имя процесса: C:WindowsSystem32winlogon.exe
Сведения о сети:
Имя рабочей станции: FSServer
Сетевой адрес источника: 192.168.175.8
Порт источника: 41509
Сведения о проверке подлинности:
Процесс входа: User32
Пакет проверки подлинности: Negotiate
Промежуточные службы: —
Имя пакета (только NTLM): —
Длина ключа: 0
Данное событие возникает при создании сеанса входа. Оно создается в системе, вход в которую выполнен.
Поля «Субъект» указывают на учетную запись локальной системы, запросившую вход. Обычно это служба, например, служба «Сервер», или локальный процесс, такой как Winlogon.exe или Services.exe.
В поле «Тип входа» указан тип выполненного входа. Самыми распространенными являются типы 2 (интерактивный) и 3 (сетевой).
Поля «Новый вход» указывают на учетную запись, для которой создан новый сеанс входа, то есть на учетную запись, с которой выполнен вход.
В полях, которые относятся к сети, указан источник запроса на удаленный вход. Имя рабочей станции доступно не всегда, и в некоторых случаях это поле может оставаться незаполненным.
Поля сведений о проверке подлинности содержат подробные данные о конкретном запросе на вход.
— GUID входа — это уникальный идентификатор, который позволяет сопоставить данное событие с событием KDC.
— В поле «Промежуточные службы» указано, какие промежуточные службы участвовали в данном запросе на вход.
— Поле «Имя пакета» указывает на подпротокол, использованный с протоколами NTLM.
— Поле «Длина ключа» содержит длину созданного ключа сеанса. Это поле может иметь значение «0», если ключ сеанса не запрашивался.
4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи: Целевой сервер: — Имя целевого сервера:
Выполнена попытка входа в систему с явным указанием учетных данных.
Субъект:
ИД безопасности: ДоменАдминистратор
Имя учетной записи: Администратор
Домен учетной записи: Домен
Код входа: 0x27854ae
GUID входа: {a5064763-d331-b7a3-1f58-df1c9bbdb9e9}
Были использованы учетные данные следующей учетной записи:
Имя учетной записи: back
Домен учетной записи: Домен
GUID входа: {00000000-0000-0000-0000-000000000000}
Целевой сервер:
Имя целевого сервера: nas2
Дополнительные сведения: nas2
Сведения о процессе:
Идентификатор процесса: 0x4
Имя процесса:
Сведения о сети:
Сетевой адрес: —
Порт: —
Данное событие возникает, когда процесс пытается выполнить вход с учетной записью, явно указав ее учетные данные. Это обычно происходит при использовании конфигураций пакетного типа, например, назначенных задач, или выполнении команды RUNAS
4647 — выход
Выход, запрошенный пользователем:
Субъект:
ИД безопасности: S-1-5-21-59707171-3867655147-1643063056-500
Имя учетной записи: Администратор
Домен учетной записи: FSServer
Код входа: 0x163d7532
Данное событие возникает, когда выход начат. Дальнейшие действия, запрошенные пользователем, не выполняются. Данное событие можно рассматривать как событие выхода.
4634 — выход (23 в 2 журнале)
Выполнен выход учетной записи из системы.
Субъект:
ИД безопасности: ДоменMamzikovAA
Имя учетной записи: MamzikovAA
Домен учетной записи: Домен
Код входа: 0x28a9692
Тип входа: 3
Данное событие возникает при уничтожении сеанса входа. Его можно однозначно связать с событием входа с помощью значения «Код входа». Коды входа остаются уникальными после перезагрузки, но они уникальны только на одном компьютере.
- Пример eventlog Security 4624.jpg
Сделать 2 элемента в 1 триггер {ITEM.VALUE} получаем только значение с одного элемента которое первее отработает, второй элемент уже не попадает вариант отпадает. Сделать 2 триггера для того чтобы видеть имя подключившегося ПК как то не целесообразно.
В общем Элемент Вход в Windows Security — Отключен и Триггер так же отключен RDP auth {{ITEM.VALUE}.iregsub(«(Тип входа: .*)», «1»)} {{ITEM.VALUE}.iregsub(«(Имя рабочей станции: .*)», «1»)}
Вход в Windows RCM-Remote Connection Manager
- Windows RCM-Remote Connection Manager
1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)
4624 — успешная аутентификация
4625 — ошибка аутентификации
При входе через терминальную службу RDP — LogonType = 10 или 3.
Если LogonType = 7, значит выполнено переподключение к уже имеющейся RDP сессии.
Account Name — имя пользователя
Workstation Name — имя компьютера
Source Network Address — имя пользователя
TargetLogonID – уникальный идентификатор сессии пользователя
(Win+R) команду eventvwr.msc
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operationa
1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)
Службы удаленных рабочих столов: Успешная проверка подлинности пользователя:
Пользователь: Администратор
Домен: FSServer
Адрес источника сети: 192.168.175.8
Следующая проблемка
Отключенные пользователи которые не завершили сеанс, а просто его закрыли! Корректно нужно завершать сеанс, так же нужно проверять.
Копятся не закрываются триггеры
- Откл копятся.jpg
Разница Завершения Сеанса пользователя и отключения
- Вход и Завершение сеанса RDP.jpg
- Вход и Закрытие RDP на крестик.jpg
Так как
- По завершению и закрытию сеанса RDP
Завершение сеанса
23 — выход из сеанса (закрываем триггер все хорошо или не даем триггеру открыться)
24 — отключен
При закрытии сессии RDP на крестик
24 — отключен сработал триггер (выполним действие на завершение пользователя) и дальше его ничто уже не закроет так как 23 уже было в логе
23 — выход из сеанса, сработало действие на завершение сеанса пользователя по триггеру отключен
Открытие Срабатывание триггера отключённых пользователей происходить по 24 значению лога
а закрытие триггера по 23 значению лога
23 — выход из сеанса (закрывает триггер)
24 — отключен
Срабатывает если последняя запись 24 и предпоследняя не равна 23
не создавалось множество указано diff
По этому пришлось сделать еще один элемент который берет предыдущее значение из лога , уже не раз 15 секунд, а раз в 1 минуту.
Хотелось бы получать все с одного элемента но что делать.
system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»»]
По отключенным триггер срабатывает если 24 и предыдущая строка не 23
Триггер на отключение срабатывает
С журнала последний код 24 — отключен .logeventid(24)}=1
И
Предыдущее значение не равно 23 выход из сеанса .last()}<>23
И
не создавалось множество указано .diff(0)}=1
Закрытие триггера на отключение
С журнала последнее значение не 24 — отключен .logeventid(24)}=0
Или
С журнала последний код 24 — отключен .logeventid(24)}=1
И
Предпоследнее значение 23 — выход из сеанса .last()}=23
Так же была попытка сделать через теги , корреляцию.
Идея была в чем до функции diff создавалось множество триггеров на отключение с обычного элемента, их надо было закрывать старые или не открывать новые , чтоб они не дублировались. у нас есть значение тега код сеанса например 2 зная имя триггера и код сеанса даем параметр не открывать больше 1 если уже открыт, но тег 2 как только триггер сработал он у нас есть в значении переменной {EVENT.TAGS} но спустя 15 секунд повторного запроса элемента или раз в 1 минуту предыдущего значения элемента , переменная тега {EVENT.TAGS} обнуляется пустая и корреляция не работает, хотя тег сбоку триггера при открытии запоминается и держится пока триггер не закроется.
Теги и регулярное выражение {{ITEM.VALUE}.iregsub(«…….)», «1»)}
Добрый день! Поясните правильно ли я понимаю работу тегов или нет.
Есть элемент данных для мониторинга пользователей windows на основе лога
eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]
Запрашиваю каждую 1 минуту
Описание
17 — ошибка Не удалось запустить службу удаленного рабочего стола
21 — успешный Вход
22 — получено уведомление о запуске оболочки
23 — выход из сеанса
24 — отключен
25 — успешное переподключение
Триггер на отключившихся пользователей которые просто закрыли на крестик сессию RDP , а не завершили сеанс.
Проблема
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(24)}=1
Восстановление
{Windows external login monitor:eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip].logeventid(24)}=0
В имени тега есть регулярка которая показывает код сеанса данного пользователя {{ITEM.VALUE}.iregsub(«Код сеанса: (.*)», «1»)}
Суть вопроса в чем
Кто то отключился Сработал триггер, регулярка отработала присвоила триггеру тег например 2
Дальше у меня действие спустя 5 минут завершить сессию данного пользователя (мало ли просто обрыв инет пропал даю 5 минут ожидания)
Элемент за это время у нас еще отпроситься 4 раза, естественно там регулярки не будет, так как изменений в логе нет по этой сессии
Сам же отвечу пустые Логи не приходят, только идут по штампу времени значит значение тега сохраняется, так же если будут изменения лога присвоится другой ID и триггер закроется или сработает другой или действия.
И когда срабатывает действие выполнить команду logoff «{EVENT.TAGS}» /server:{HOST.CONN}
то макрос {EVENT.TAGS} выходит пустой
Сам отвечу не будет пустым, выше ответ почему.
но сбоку сработавшего триггера значение тега есть никуда не пропало выходит что он это значение никак не берет? и его никак не взять?
Т.е. действие нужно выполнять сразу пока элемент повторно не получил пустое значение ?
- tags-vopros0
- tags-vopros1
В некоторых попытках в триггер можно получить предыдущее значение журнала (лога) но уже нельзя сравнить id
Открываем Журнал событий Run (Win+R) команду eventvwr.msc
Откуда можем взять данные:
1. Журналы Windows — Безопасность eventlog[«Security»,,,,^(1100|1102|4624|4648|4634|4647)$,,skip]
1100 — Завершение работы
1102 — Очистка журнала
4624 — Вход в систему для обычной windows Новый вход: — Имя учетной записи: Сведения о сети: — Имя рабочей станции
4648 — Вход Windows (серверов) Были использованы учетные данные следующей учетной записи: Имя учетной записи:
Целевой сервер: — Имя целевого сервера:
4634 — выход (23 в 2 журнале)
4647 — выход
4778 — Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID)
4799 — Отключение от RDP сеанса
9009 — Пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен
2. Microsoft-Windows-TerminalServices-LocalSessionManager/Operational eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25)$,,skip]
17 — ошибка Не удалось запустить службу удаленного рабочего стола
21 — успешный Вход
22 — полученно уведомление о запуске оболочки
23 — выход из сеанса (закрывает триггер) (4634 в 1 журнале)
24 — отключен
25 — успешное переподключение
39 — (Session <A> has been disconnected by session <B>) – пользователь сам отключился от своей RDP сессии, выбрав соответствующий пункт меню (а не просто закрыл окно RDP клиента).
Если идентификаторы сессий разные, значит пользователя отключил другой пользователь (или администратор).
40 — Здесь нужно смотреть на код причины отключения в событии. Например:
reason code 0 (No additional information is available)– обычно говорит о том, что пользователь просто закрыл окно RDP клиента.
reason code 5 (The client’s connection was replaced by another connection) – пользователь переподключился к своей старой сессии.
reason code 11 (User activity has initiated the disconnect) – пользователь сам нажал на кнопку Disconnect в меню.
3. Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operationa eventlog[«Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational»,,,,^(1149|4624|4625)$,,skip]
1149 — установление сетевого подключение к серверу от RDP клиента пользователя (не аунтификация)
4624 — успешная аутентификация
4625 — ошибка аутентификации
При входе через терминальную службу RDP — LogonType = 10 или 3.
Если LogonType = 7, значит выполнено переподключение к уже имеющейся RDP сессии.
Account Name — имя пользователя
Workstation Name — имя компьютера
Source Network Address — имя пользователя
TargetLogonID – уникальный идентификатор сессии пользователя
Об значениях в триггерах как формируются
Регулярное выражение Совпадение значения с регулярным выражением <шаблона> и замена значения в соответствии с <выводом>.
Регулярное выражение поддерживает извлечение до 10 захваченных групп в N последовательности.
Элемент данных станет неподдерживаемым в случае ошибки при поиске соответствия во входящем значении.
Параметры:
шаблон — регулярное выражение
вывод — шаблон форматирования вывода. N (где N=1..9) — управляющая последовательность заменяется N-нной совпадающей группой.
Управляющая последовательность заменяется совпадающим текстом
Поддерживается начиная с 3.4.0.
Пожалуйста, обратитесь в разделу регулярных выражений для ознакомления с некоторыми существующими примерами.
{ITEM.LASTVALUE<1-9>}
Последнее значение элемента данных N-го элемента данных в выражении триггера вызвавшего это оповещение.
Поддерживается начиная с 1.4.3. Это алиас для {{HOSTNAME}:{TRIGGER.KEY}.last(0)}
> Оповещения, основанные на триггерах
> Имена триггеров и описания Последнее значение N-го элемента данных из выражения триггера, который вызвал оповещение.
В веб-интерфейсе раскрывается в *НЕИЗВЕСТНО*, если последнее значение истории собрано более чем ZBX_HISTORY_PERIOD секунд назад (задается в defines.inc.php).
Поддерживается начиная с 1.4.3. Является алиасом к {{HOST.HOST}:{ITEM.KEY}.last()}
{ITEM.VALUE<1-9>}
Последнее значение N-го элемента данных в выражении триггера, если используется для отображения триггеров.
Историческое значение (точно когда произошло событие) N-го элемента данных из выражения триггера, если используется для отображения событий и оповещений.
Поддерживается начиная с Zabbix 1.4.3.
{HOSTNAME<1-9>}
Имя узла сети N-го элемента данных из триггера вызвавшего это оповещение.
Поддерживается в оповещениях авторегистрации начиная с версии 1.8.4.
{$MACRO}
Пользовательские макросы. Поддерживается в именах триггеров и в описаниях элементов данных начиная с версии 1.8.4.
Имя клиента из реестра
Есть query session, query user, quser /server 192.168.128.50, query user /server 192.168.128.50, query session /server 192.168.128.50,
query session /server 192.168.128.50 /counter, Qwinsta, tasklist , но они показывают только имя пользователя.
переменная %CLIENTNAME%
echo %CLIENTNAME%
echo %SESSIONNAME%
HKCUEnvironmentClientname
HKEY_CURRENT_USERVolatile Environment1 — CLIENTNAME (SESSIONNAME)
HKEY_USERSS-1-5-21-3002483080-1650114603-3144430796-1000Volatile Environment1 — CLIENTNAME
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer, параметр «LOGON USER NAME»
Поставьте, PSTerminalServices (http://psterminalservices.codeplex.com/ … view/65937) и с помощью
Имена пользователей я вырезал. Модуль можно ставить на любой машине с powershell
PS C:Windowssystem32> Get-TSSession -ComputerName TSFarm501
WshShell = Новый COMОбъект(«WScript.Shell»);
WshSysEnv = WshShell.Environment(«Process»);
Сообщить(«Имя компьютера «+WshSysEnv.Item(«CLIENTNAME»));
Работает только в терминальной сессии
%USERPROFILE%AppDataLocalTemp
%USERPROFILE%AppDataLocalTemp
для команды для текущего пользователя
reg query «HKCUVolatile Environment»
Для конкретного пользователя
HKEY_USERSS-1-5-21-3002483080-1650114603-3144430796-1000Volatile Environment
реестр всех пользователей
C:mkdir c:Temp
Regedit.exe /e c:tempyourname.reg
Вычисляемый элемент
last(«eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip]») не катит поле не числовое
logeventid(«eventlog[«Microsoft-Windows-TerminalServices-LocalSessionManager/Operational»,,,,^(21|23|24|25|39|40)$,,skip]»,23) получаем 0 или 1
date
Текущая дата в формате ГГГГММДД. Поддерживаемые типы значений: любые Пример результата: 20150731
time
Текущее время в формате ЧЧММСС. Поддерживаемые типы значений: любые Пример возвращаемого значения: 123055
fuzzytime (сек)
Проверка, на сколько отличается значение элемента данных (как штамп времени) от времени Zabbix сервера. сек — секунды Поддерживаемые типы значений: float, int
Возвращает:
1 — если разница между штампом времени значения элемента данных и штампом времени Zabbix сервера меньше или равна сек секунд
0 — в противном случае.
Обычно используется с system.localtime для проверки, что локальное время синхронизировано с локальным временем Zabbix сервера. Обратите внимание, что элемент данных ‘system.localtime’ должен быть настроен пассивной проверкой.
Также можно использовать с ключом vfs.file.time[/путь/к/файлу,modify] для проверки, что файл не обновлялся длительное время.
Пример: fuzzytime(60)=0 > обнаружение проблемы, если разница во времени больше 60 секунд
Имя Time diff
Тип Вычисляемое
Ключ system.localtime.fuzzytime
Формула fuzzytime(system.localtime,60)
Тип инфы Числовой (целое положительное)
Интервал 1m
Если 3 последних 0 т.е. 0+0+0 = 0 значит триггер срабатывает у нас есть расхождение более чем на 1 минуту
Триггер
system.localtime.fuzzytime.sum(#3)}=0
system.localtime -формат ДД.ММ.ГГГГ ЧЧ:ММ:СС
wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /f:text|FIND /I «Event ID» — от самых старых к новым 2строки
wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID» — от новых к старым строкам пример 2строки
wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»
/c:<Count> Задает максимальное число событий для чтения.
/rd:<Direction> Указывает направление чтения событий. <Direction>может иметь значение true или false. Если значение равно true, то первыми возвращаются самые последние события.
/f:<Format> Указывает, что выходные данные должны быть в формате XML или текстовый формат. Если <Format> параметр имеет значение XML, выходные данные отображаются в формате XML. Если <Format> является текстом, выходные данные отображаются без XML-тегов. Значение по умолчанию — Text.
FIND /I — Поиск без учета регистра символов «строка» — Искомая строка
FIND /N — Вывод номеров отображаемых строк.
FIND /V — Вывод всех строк, НЕ содержащих заданную строку.
Проверка через заббикс
zabbix_get -s 192.168.ХХХ.ХХХ -p 10050 -k system.run[«wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:2 /rd:true /f:text|FIND /I «Event ID»|find /n «2»|find /v «1»»]
Кото для теста хочет подключатся к учетной записи по RDP без пароля не обходимо выполнить следующее
При попытке подключиться к компьютеру под управлением Windows с помощью средства дистанционного управления рабочим столом появляется следующее сообщение об ошибке: Вход в систему невозможен из-за ограничений для учетной записи.
Подобное поведение наблюдается, если используемая для подключения учетная запись имеет пустой пароль. Невозможно установить подключение к удаленному рабочему столу, используя учетную запись с пустым паролем.
Чтобы устранить эту проблему и подключиться к удаленному рабочему столу, войдите в систему с консоли компьютера и установите пароль для используемой учетной записи.
Такое поведение является особенностью данного продукта
Ограничения, накладываемые пустым паролем, можно отключить, используя политику. Найдите и измените соответствующую политику, выполнив следующие действия:
Нажмите кнопку Пуск, выберите пункт Выполнить (win + R), введите команду gpedit.msc и нажмите кнопку OK, чтобы запустить редактор объектов групповой политики.
Откройте раздел Конфигурация компьютераКонфигурация WindowsПараметры безопасностиЛокальные политикиПараметры безопасностиУчетные записи: Limit local account use of blank passwords to console logon only.
Дважды щелкните элемент Limit local account use of blank passwords to consol logon only.(:ограничить использования пустых паролей только для консолей входа)
Выберите отключен и нажмите кнопку OK.
Закройте редактор групповой политики.
Примечание. По умолчанию данная политика включена.