Как в Windows проверить, кто использовал компьютер и когда

Вы когда-нибудь хотели контролировать, кто входит в ваш компьютер и когда? В профессиональных выпусках Windows вы можете включить аудит входа в систему, чтобы запись всех входов в Windows.

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

Примечание. Аудит входа в систему работает только в профессиональной версии Windows, поэтому вы не можете использовать это, если у вас домашняя версия. Это должно работать на Windows 7, 8 и Windows 10. Мы рассмотрим Windows 10 в этой статье. В других версиях экраны могут выглядеть немного иначе, но этот процесс почти такой же.

Как включить аудит входа в систему

Чтобы включить аудит входа в систему, мы будем использовать редактор локальных групповых политик. Это довольно мощный инструмент, поэтому, если вы никогда не использовали его раньше, стоит потратить некоторое время на его изучение. Кроме того, если ваш компьютер подключен к сети компаний, сначала Вам придётся обратиться за разрешением к администратору. Если ваш рабочий компьютер является частью домена, также вероятно, что это часть политики группы доменов, которая в любом случае заменит политику локальной группы.

Чтобы открыть редактор локальной групповой политики, нажмите Win + R , введите gpedit.msc и нажмите Enter .

В редакторе локальных групповых политик в левой панели перейдите к политике Локального компьютера → Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Локальные политики → Политика аудита. В правой панели дважды щелкните параметр «Аудит входа в систему».

В открывшемся окне свойств включите параметр «Успех» для успешной попытки входа в систему Windows. Включите параметр «Сбой», если вы также хотите, чтобы Windows регистрировала неудачные попытки входа в систему. Нажмите кнопку ОК , когда закончите.

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

Просмотр событий входа в систему

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

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

В окне «Просмотр событий» в левой панели перейдите в раздел «Журналы Windows» → «Безопасность».

В центральной панели вы, вероятно, увидите ряд событий «Аудит успеха». Windows регистрирует отдельные сведения о таких вещах, как предоставление своих привилегий проверенным аккаунтом. Вам нужной найти события с идентификатором 4624 – они представляют собой успешные события входа в систему. Вы можете увидеть подробности о выбранном событии в нижней части этой средней панели, а также можете дважды щелкнуть событие, увидев его данные в отдельном окне.

Если Вы перейдёте к деталям, то сможете увидеть такую информацию, как имя учетной записи пользователя.

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

Аудит события входа Audit logon events

Область применения Applies to

Определяет, следует ли проверять каждый экземпляр пользователя, войдя в систему или выйдя из нее с устройства. Determines whether to audit each instance of a user logging on to or logging off from a device.

События для регистрации учетной записи создаются на контроллерах домена для действий с учетной записью домена и на локальных устройствах для действий с локальной учетной записью. Account logon events are generated on domain controllers for domain account activity and on local devices for local account activity. Если включены обе категории политики аудита входа и входа, входы в систему, которые используют учетную запись домена, создают событие входа или входа в систему на рабочей станции или сервере, а также создают событие входа в учетную запись на контроллере домена. If both account logon and logon audit policy categories are enabled, logons that use a domain account generate a logon or logoff event on the workstation or server, and they generate an account logon event on the domain controller. Кроме того, интерактивные входы в систему на рядовом сервере или рабочей станции, которые используют учетную запись домена, создают событие входа на контроллере домена при извлечении скриптов и политик входа при входе пользователя в систему. Additionally, interactive logons to a member server or workstation that use a domain account generate a logon event on the domain controller as the logon scripts and policies are retrieved when a user logs on. Дополнительные сведения о событиях для учетной записи для учетной записи см. в записи аудита событий. For more info about account logon events, see Audit account logon events.

Если вы определяете этот параметр политики, вы можете указать, следует ли проверять успехи, сбои аудита или вообще не проверять тип события. If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Аудит успешности создает запись аудита при успешной попытке входа. Success audits generate an audit entry when a logon attempt succeeds. Аудит сбоев создает запись аудита при неудачной попытке входа. Failure audits generate an audit entry when a logon attempt fails.

Чтобы установить для этого параметра значение «Нетаудита», в **** диалоговом окне «Свойства» **** для этого параметра политики установите флажок «Определить эти параметры политики» и установите флажки «Успешно» и «Сбой». **** To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Дополнительные сведения о дополнительных параметрах политики безопасности для событий входа см. в разделе «Вход и выйдите» в разделе «Дополнительные параметры политики аудита безопасности». For information about advanced security policy settings for logon events, see the Logon/logoff section in Advanced security audit policy settings.

Настройка этого параметра аудита Configure this audit setting

Этот параметр безопасности можно настроить, открыв соответствующую политику в области «Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Политика аудита». You can configure this security setting by opening the appropriate policy under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

События для логотипа Logon events	Описание Description
4624 4624	Пользователь успешно выполнил вход на компьютер. A user successfully logged on to a computer. Сведения о типе логоса см. в таблице «Типы для логотипа» ниже. For information about the type of logon, see the Logon Types table below.
4625 4625	Ошибка при работе с логотипом. Logon failure. Была предпринята попытка вводить данные с неизвестным именем пользователя или с неизвестным именем пользователя с некаленным паролем. A logon attempt was made with an unknown user name or a known user name with a bad password.
4634 4634	Для пользователя завершен процесс выйдите из сети. The logoff process was completed for a user.
4647 4647	Пользователь инициировал процесс выйдите из сети. A user initiated the logoff process.
4648 4648	Пользователь успешно выполнил вход на компьютер с использованием явных учетных данных, а уже вошел как другой пользователь. A user successfully logged on to a computer using explicit credentials while already logged on as a different user.
4779 4779	Пользователь отключил сеанс сервера терминалов, не выйдя из системы. A user disconnected a terminal server session without logging off.

При регистрации события 528 в журнале событий также регистрируется тип входа. When event 528 is logged, a logon type is also listed in the event log. В следующей таблице описаны все типы для логотипа. The following table describes each logon type.

Аудит событий входа в систему Audit account logon events

Область применения Applies to

Определяет, следует ли проверять каждый экземпляр пользователя, войдя в систему или выйдя из него с другого устройства, на котором это устройство используется для проверки учетной записи. Determines whether to audit each instance of a user logging on to or logging off from another device in which this device is used to validate the account.

Этот параметр безопасности определяет, следует ли проверять каждый экземпляр пользователя, войдя в систему или выйдя из него с другого компьютера, на котором этот компьютер используется для проверки учетной записи. This security setting determines whether to audit each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. События для регистрации учетной записи создаются при проверке подлинности учетной записи пользователя домена на контроллере домена. Account logon events are generated when a domain user account is authenticated on a domain controller. Событие регистрируется в журнале безопасности контроллера домена. The event is logged in the domain controller’s security log. События для локалки создаются при проверке подлинности локального пользователя на локальном компьютере. Logon events are generated when a local user is authenticated on a local computer. Событие регистрируется в локальном журнале безопасности. The event is logged in the local security log. События выйдите из учетной записи не создаются. Account logoff events are not generated.

Если вы определяете этот параметр политики, вы можете указать, следует ли проверять успехи, сбои аудита или вообще не проверять тип события. If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Аудит успешности создает запись аудита при успешной попытке входа в учетную запись. Success audits generate an audit entry when an account logon attempt succeeds. Аудит сбоев создает запись аудита при неудачной попытке входа в учетную запись. Failure audits generate an audit entry when an account logon attempt fails. Чтобы установить для этого параметра значение «Нетаудита», в **** диалоговом окне «Свойства» **** для этого параметра политики установите флажок «Определить эти параметры политики» и установите флажки «Успешно» и «Сбой». **** To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

По умолчанию: успех Default: Success

Настройка этого параметра аудита Configure this audit setting

Этот параметр безопасности можно настроить, открыв соответствующую политику в области «Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Политика аудита». You can configure this security setting by opening the appropriate policy under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

Windows → Журнал успешных входов пользователей в систему (Windows) и запись в MySQL(Linux)

Тут недавно, мне потребовалось, вести статистику какие пользователи и где входят в систему, вот стукнуло руководству в голову мысль из серии: «А давайте, будем ВСЕ записывать!», ну все так все, а что конкретно не знает, быстро загуглив и не найдя, готового решения, пришлось написать свой велосипед. В общем я решил поделиться собственной наработкой с общественностью, думаю что не я один с такой проблемой столкнулся.
Средства операционной системы Windows позволяют это делать, через настройку аудита успеха, но проблема в том что руководство хотело все это видеть в упрощенном виде и загонять генерального детектора в увлекательное чтение журналов системы, мне совершенно не хотелось.
На основной работе у нас реализовано через MSSQL, правда там реализовано все по другому принципу, все работает довольно надежно и позволяет выяснить какой пользователь когда и где заходил в систему т.е. записывается -дата, время, имя машины, логин. Это сильно облегчает жизнь при расследовании инцидентов, хоть и не часто, но они случаются, тут проблема в том что MSSQL стоит, сказать честно, «дохренища денег»…
Да и контора, которую я поддерживаю намного меньше, чем моя основная работа и ради ведения журналов покупать MSSQL не имеет смысла, а ставить без лицензии, тоже не правильно, т.к. возможностей MySQL и PHP тут хватит за глаза, а кому их покажется мало, можно все это перевести на PostgreSQL, но это уже сами.
В начале проконсультировавшись с коллегами, как это лучше реализовать, мне сказали что нужно ставить curl, он отлично отправляет данные, но это требует установки дополнительного софта, чего мне делать не хотелось и я добился того чтобы все работало используя штатные средства операционной системы Windows, а именно VBS.

Что требуется получить на выходе:

Собственно задача, поднять Web сервер, на котором можно установить Nginx + PHP5-FPM + MySQL.
В качестве примера, настройки WEB сервера NGINX, можно воспользоваться статьей: Настройка Nginx с поддержкой PHP-FPM
Ну а для установки phpMyAdmin, посмотрите статью: Установка phpMyAdmin на Nginx

Как все это будет работать

Есть WEB сервер, на котором работает СУБД, также там установлен Nginx, и один php скрипт, который принимает внешние параметры, а именно host -имя системы где заходит пользователь и логин пользователя, все остальные данные, а именно, дата, время, будут добавляться самой MySQL, при условии что часы, на сервере Linux, синхронизированны с контроллером домена, чтобы в записях не было расхождения во времени.
сервер принимает запросы вида:

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

Ну и переходим к реализации.

Для начала создадим базу данных и таблицу в ней, чтобы не взрывать мозг, я ее назвал test, а фигли… 😉
Ну и создал таблицу, я ее назвал userlog со следующими полями:

Где есть следующие поля:
date — Дата (заполняется MySQL сервером)
time — Время (заполняется MySQL сервером)
host — Имя машины где зашел пользователь (передается скриптом с рабочей станции)
user — Логин пользователя (передается скриптом с рабочей станции)
client_ip -IP адрес рабочей станции (передается php скриптом на WEB сервере)

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

Те кто периодически читает мои статьи уже догадались, что этот скрипт является доработанной версией из статьи: Собираем статистику изменений температуры и влажности с помощью Arduino и записываем ее в MySQL Так что старые наработки продолжают жить и дальше… 🙂

Ну и теперь VBS скрипт, который будет отправлять данные в таблицу, выполняя GET запрос.

Где:
httр://logsrv.example.org -адрес сервера который ведет логи
log.php -скрипт который принимает запрос и отправляет его в MySQL
host=» & strComputerName & — переменная которая определяет имя машины
user=» & strUserName — переменная которая определяет логин пользователя
Я не буду расписывать значение переменных, думаю что имена говорят сами за себя.
Собственно, засовываем данный скрипт, чтобы он запускался при входе пользователя в систему. После этого наслаждаемся результатом.
Таблица будет иметь вид:

На основной работе, у нас 2 домена в лесу и необходимо записывать помимо логина, еще и имя домена в котором находится учетная запись пользователя т.к. пользователь с логином Ivanov может быть например в домене contoso.com и совершенно другой пользователь в домене vladivostok.contoso.com
чтобы запись имела вид contoso/ivanov или vladivostok/ivanov для реализации этой задачи я немного модифицировал VBS скрипт:

Тогда записи в таблице принимают вид:

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