Как узнать кто выключил сервер
Всем привет, сегодня небольшая заметка для начинающих системных администраторов, рассмотрим вопрос как определить кто перезагрузил сервер Windows. Бывают ситуации, что по какой то причине отваливается сервер его удаленно перезагрузили, зайдя на которой вы не видите что у него был синий экран BSOD, и значит надо искать кто то его отправил в ребут. Вам необходимо выяснить кто это был.
И так рассматривать кто перезагрузил сервер Windows я буду на примере Windows Server 2008 R2, но все действия абсолютно одинаковы в любой версии Windows начиная с Vista. Поможет нам в реализации нашей задачи оснастка Просмотр событий. Открыть его можно Пуск-Администрирование-Просмотр событий или нажать WIN+R и ввести там evenvwr.msc.
у вас откроется оснастка Просмотр событий. Вам нужно выбрать журнал Windows Система. В нем как раз и находится нужная нам информация в виде события. Проблема в том что их генерируется порой очень много, для этого придумали фильтр. Жмем справа в колонке действия Фильтр текущего журнала.
В открывшемся окне вам нужно отфильтровать данный журнал. Задаем дату, я выставил период за последнюю неделю,
можете выставить и меньше и больше. Выбираем уровень событий, ставим все и самое главное какой будет источник событий. В источнике событий выбираете USER32, он и хранит нужный лог.
В итоге у меня получилась вот такая картина
После нажатия кнопки ок вы получите отфильтрованный журнал система, у меня нашлось одно событие. Код события 1074 о том что сервер с Windows Server 2008 R2 был перезагружен системой после установки программы Microsoft SOAP Toolkit.
Мне этого мало и нужно понять кто начал установку данного приложения. Для этого так же переходив уже в журнал Приложения, делаем фильтр, дату ставим например тоже неделю
Еще отфильтруем по кодам событий с 1035-1040
И в итоге мы видим вот такое событие
Вот мы и выяснили кто он мистер Х. В качестве эксперимента можете удаленно перезагрузить тестовую машину или например я рассказывал как перезагрузить компьютер через командную строку.
Сервер Windows сам выключается – событие user32 event 1074
Привет. Недавно столкнулся с очень неприятной ситуацией — часть серверов начала самопроизвольно выключаться. Какой — либо закономерности в выключениях проследить не удавалось. Единственное что объединяло серверы — это то что на них была установлена ОС Windows Server 2012 или выше, и большая их часть имеет роль терминальных. Ах да, еще все эти серверы — виртуальные и работают под управлением Hyper V. Хочу сегодня рассказать, в чем была проблема.
Конечно, любая диагностика должна начинаться с анализа логов. И вот какое событие удалось обнаружить непосредственно перед выключениями серверов – событие 1074, user32:
The process C:\Windows\system32\winlogon.exe (DC) has initiated the power off of computer DC on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found
Reason Code: 0x500ff
Shutdown Type: power off
По ним становится понятно, что работа завершается штатно. Что в общем то позволяет исключить влияние железа, хотя оно и так было исключено, т. к. все серверы виртуальные. Под подозрение попал гипервизор, но рысканье вдоль и поперек по логам ни какого результата не дало. События относящиеся к завершениям работы не имели отношения к инициализации завершения работы. Говорят, что виртуальные машины могут в редких случаях произвольно выключаться, если есть проблемы со свободной памятью, но в моем случае памяти было более чем достаточно.
В общем думаю хватит томить, и пора рассказать вам, в чем же в итоге было дело. Подключившись по RDP, я сидел и размышлял, что же может быть причиной подобного завершения работы. И вот из-за бездействия меня выбило на экран ввода пароля, где я обнаружил вот такой экран:
Обратите внимание на нижний угол:
Да, это мать его, завершение работы системы. Оказывается с 2012 винды MS сделали эту кнопку доступной при подключении по RDP.
Computer Configuration – Policies – Windows Settings – Local Policies – Security Options – Shutdown: Allow system to be shut down without having to log on.
Отключаем его и всё, возможности выключить сервер у пользователей не будет.
В общем и целом, после изменения этого параметра мистические выключения прекратились.
Как разрешить (запретить) обычному пользователю перезагрузку (выключение) Windows?
В этой статье мы рассмотрим несколько способов, позволяющих управлять правами пользователей на перезагрузку и выключение компьютеров и серверов Windows. По умолчанию пользователи могут перезагружать и выключать только десктопные версии Windows, и не могут перезагрузить сервер (кнопки выключения и перезагрузки не доступны). Возможно ли разрешить пользователю без прав локального администратора перезагружать Windows Server? Возможна и обратная задача – запретить пользователям перезагружать компьютер с Windows 10, который используется в качестве некого информационного киоска, диспетчерского пульта и т.д.
Разрешить (запретить) пользователю перезагрузку Windows с помощью политики
Обратите, что по-умолчанию права на выключение/перезагрузку Windows различаются в десктопных версиях Windows 10 и в редакциях Windows Server.
Откройте редактор локальной политики gpedit.msc и перейдите в указанную выше секцию. Как вы видите, в Windows 10 права на перезагрузку (выключение) компьютера есть у членов локальных групп: Администраторы, Пользователи и Операторы архива.
В то время как в Windows Server 2012 R2 выключить или перезагрузить сервер могут только Администраторы или Backup Operators. Это правильно и логично, т.к. у пользователей в подавляющем большинстве случаев не должно быть прав на выключение сервера (даже случайное). Представьте себе RDS сервер, который периодически выключается из-за того, что пользователи случайно нажимают на кнопку выключения в стартовом меню…
Но из всякого правила бывают исключения. Соответственно, если вы хотите разрешить определенному пользователю (без права администратора) перезагружать ваш Windows Server, достаточно добавить его учетную запись в эту политику.
Или наоборот, вы хотите запретить пользователям десктопной редакции Windows 10 перезагружать компьютер, который выполняет некую серверную функцию. В этом случае вам достаточно удалить группу Users из локальной политики “Завершение работы системы”.
Аналогичным образом вы можете запретить (или разрешить) выключение или перезагрузку компьютеров для всех компьютеров в определённом OU домена Active Directory с помощью доменной политики. С помощью редактора доменных GPO (gpmc.msc) создайте новую политику Prevent_Shutdown, настройте параметр политики “Shut down the system” в соответствии с вашими требованиями и назначьте политику на OU с компьютерами или серверами.
Право на удаленное выключение/перезагрузку Windows
Вы также можете разрешить определенным пользователям перезагружать ваш Windows Server удаленно с помощью команды shutdown, не предоставляя пользователю права локального администратора и право на RDP вход на сервер.
Для этого необходимо добавить учетную запись нужного пользователя в политику “Принудительное удаленное завершение работы” (Force shutdown from a remote system) в той же самой секции GPO Назначение прав пользователя (User Rights Assignment).
По умолчанию выключить сервер удаленном могут только администарторы. Добавьте в политику нужную учетную запись пользователя.
В результате пользователю будет назначена привилегия SeRemoteShutdown и он сможет перезагрузить данный сервер удаленно с помощью команды:
Скрыть от пользователя Windows кнопки выключения и перезагрузки
После включения этой политики пользователь сможет завершить работу с Windows, только выполнив логофф. Кнопки выключения, сна и перезагрузки компьютера станут недоступными.
Как узнать, кто перезагрузил (выключил) Windows сервер?
После того, как вы представили определенному пользователю права на перезагрузку серверов вы, вероятно, захотите узнать кто перезагружал определенный сервер: пользователь или один из администраторов.
Как вы видите, в журнале событий остались события перезагрузки сервера в хронологическом порядке. В описании события указано время перезагрузки, причина и учетная запись, которая выполнила рестарт.
Log Name:System
Source: User32
EventID: 1074
The process C:\Windows\system32\winlogon.exe (MSK-RDS1) has initiated the restart of computer MSK-RDS1 on behalf of user CORP\AAIvanov for the following reason: No title for this reason could be found.
Reason Code: 0x500ff
Shutdown Type: restart
Comment:
Аналогичным образом можно получить информацию о последних событиях перезагрузки Windows. Для этого нужно искать по событию с кодом 1076.
Просмотр и анализ логов RDP подключений в Windows
В этой статье мы рассмотрим, особенности аудита / анализа логов RDP подключений в Windows. Как правило, описанные методы могут пригодиться при расследовании различных инцидентов на терминальных / RDS серверах Windows, когда от системного администратора требуется предоставить информацию: какие пользователи входили на RDS сервер, когда авторизовался и завершил сеанс конкретный пользователь, откуда / с какого устройства (имя или IP адрес) подключался RDP-пользователь. Я думаю, эта информация будет полезна как для администраторов корпоративных RDS ферм, так и владельцам RDP серверов в интернете (Windows VPS как оказалось довольно популярны).
Как и другие события, логи RDP подключения в Windows хранятся в журналах событий. Откройте консоль журнала событий (Event Viewer). Есть несколько различных журналов, в которых можно найти информацию, касающуюся RDP подключения.
В журналах Windows содержится большое количество информации, но быстро найти нужное событие бывает довольно сложно. Когда пользователь удаленно подключается к RDS серверу или удаленному столу (RDP) в журналах Windows генерируется много событий. Мы рассмотрим журналы и события на основных этапах RDP подключения, которые могут быть интересны администратору:
В результате у вас получится список с историей всех сетевых RDP подключений к данному серверу. Как вы видите, в логах указывается имя пользователя, домен (используется NLA аутентификация, при отключенном NLA текст события выглядит иначе) и IP адрес компьютера, с которого осуществляется RDP подключение.
При этом имя пользователя содержится в описании события в поле Account Name, имя компьютера в Workstation Name, а имя пользователя в Source Network Address.
Вы можете получить список событий успешных авторизаций по RDP (событие 4624) с помощью такой команды PowerShell.
Событие с EventID – 21 (Remote Desktop Services: Shell start notification received) означает успешный запуск оболочки Explorer (появление окна рабочего стола в RDP сессии).
При этом в журнале Security нужно смотреть событие EventID 4634 (An account was logged off).
Событие Event 9009 (The Desktop Window Manager has exited with code ( ) в журнале System говорит о том, что пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен.
Ниже представлен небольшой PowerShell, который выгружает из журналов терминального RDS сервера историю всех RDP подключений за текущий день. В полученной таблице указано время подключения, IP адрес клиента и имя RDP пользователя (при необходимости вы можете включить в отчет другие типы входов).
Иногда бывает удобно с логами в таблице Excel, в этом случае вы можете выгрузить любой журнал Windows в текстовый файл и импортировать в Excel. Экспорт журнала можно выполнить из консоли Event Viewer (конечно, при условии что логи не очищены) или через командную строку:
WEVTUtil query-events Security > c:\ps\security_log.txt
Список текущих RDP сессий на сервере можно вывести командой:
Команда возвращает как идентификатор сессии (ID), имя пользователя (USERNAME)и состояние (Active/Disconnect). Эту команду удобна использовать, когда нужно определить ID RDP сессии пользователя при теневом подключении.
Список запущенных процессов в конкретной RDP сессии (указывается ID сессии):
На RDP-клиенте логи не такие информационные, основное чем часто пользуются информация об истории RDP подключений в реестре.
4 способа узнать, пользовался ли кто-то компьютером в ваше отсутствие
Если у вас есть подозрения, что кто-то пользовался вашим компьютером втайне от вас, то это можно легко проверить. Это может понадобиться как дома, так и на работе. Существует несколько способов проверить, когда включался компьютер, в том числе с помощью сторонних программ.
Как узнать, когда включали и выключали компьютер
Проще всего воспользоваться встроенным приложением «Просмотр событий». Зайдите в поиск через меню «Пуск» и наберите название программы. Если так найти не получилось, то кликните правой кнопкой мыши по ярлыку «Этот компьютер» и выберите «Управление». Далее, в левой части экрана выберите «Просмотр событий».
Ищите папку «Журналы Windows» на левой панели. Затем выберите пункт «Система».
Теперь нужно оставить только те события, которые нас интересуют. Для этого кликните правой кнопкой мыши на пункте «Система» и выберите «Фильтр текущего журнала» или же найдите фильтр на панели в правой части окна программы.
В окне фильтра нужно совершить всего одно действие. В поле «Источники событий» найдите пункт Winlogon. Поставьте галочку и подтвердите свой выбор.
В журнале останутся только записи о входе и выходе из системы. На основании этого уже можно понять, когда компьютер включали и выключали. Если запись показывает время, когда вы не пользовались компьютером, значит, это сделал кто-то другой.
В качестве альтернативы можно использовать стороннюю программу. Это проще и не придется заходить в системные настройки системы. Скачайте бесплатную программу TurnedOnTimesView. У нее есть русскоязычный интерфейс, но его нужно устанавливать отдельно. Файл локализации нужно скинуть в папку с программой.
Как узнать, какие программы и файлы открывались
Через события Windows можно увидеть и другие действия пользователя. Однако представлены они в неудобном виде: кроме пользовательских программ отображаются еще и многочисленные системные процессы. Некоторую информацию можно посмотреть в реестре системы, куда мы не рекомендуем заходить неопытным пользователям. Поэтому гораздо проще использовать сторонние программы.
Будем использовать программы LastActivityView и ExecutedProgramsList. Они берут данные из уже упомянутого реестра и журнала Windows, поэтому сразу покажут всю картину. А не только то, что было сделано после установки.
Хорошо, что программа не только показывает, что было запущено, но и какой именно файл был открыт. Не забывайте, что в выдаче присутствуют и системные процессы, которые могли обращаться к файлам. Но если, к примеру, был открыт фильм в медиаплеере, то это точно дело рук пользователя.
Рекомендуем пользоваться сразу всеми инструментами, чтобы избежать ошибок. Убедитесь, что вы проверяете именно тот промежуток, когда компьютер использовался не вами.
Проверить историю браузера
Историю браузера легко почистить, поэтому вряд ли кто-то будет оставлять такие очевидные улики. Кроме того, в режиме инкогнито история тоже не сохраняется. Но если «нарушитель» плохо разбирается в компьютерах, то вероятность найти запросы все же есть.
Еще как вариант можно проверить поисковые запросы, которые хранятся в аккаунте Google. Как это сделать, мы подробно рассказали в материале «Как удалить историю поисковых запросов в Google».
Кроме того, даже если кто-то и почистил историю, он вполне мог стереть заодно и ваши запросы. Обращайте на это внимание.
Удаленные файлы и корзина
Еще один маловероятный вариант. После удаления файлов корзину, скорее всего, почистят. Учитывая, что удалять можно отдельные файлы, при этом ваши останутся висеть в корзине, заметить такие действия нельзя. Можно попробовать воспользоваться программами для восстановления данных, например Recuva. Она найдет удаленные файлы, и вы сможете увидеть, что именно удаляли без вашего ведома.
