Мы в нашем отделе внедряем новую административную политику: каждый в отделе, который мы поддерживаем, получит административный доступ к своим компьютерам. Нам нужно знать (пока мы выполняем политику «пилотной программы» в этом отделе), кто и когда вошел в систему на любой машине. Итак, как я мог (с помощью сценария PowerShell, сценария cmd или других автоматических средств) узнать, кто вошел в систему на данном компьютере с Windows 7 или XP?
Следите за журналами событий на контроллерах домена для событие 672. Он покажет все успешные события входа в систему для пользователей AD и с какого компьютера они вошли в систему. Фильтруйте по компьютеру, чтобы получать события входа только для тех компьютеров, которые вам интересны.
Вы можете создать сценарий входа в систему и связать его в групповой политике для тех компьютеров, которые %date% %time% %username% %computername% в файл где-нибудь на скрытом ресурсе. Тогда у вас будет централизованный журнал всех входов в систему.
Я думаю, что вы, вероятно, ищете, чтобы знать, когда контроллер домена / активный каталог аутентифицирует пользователя. Некоторое объяснение можно найти в http://www.windowsecurity.com/articles/windows-active-directory-auditing.html
Аудит событий входа в систему - Это будет проверять каждое событие, связанное с входом пользователя в систему, выходом из системы или установлением сетевого подключения к компьютеру, настроенному для аудита событий входа в систему. Хорошим примером регистрации этих событий является интерактивный вход пользователя на свою рабочую станцию с использованием учетной записи пользователя домена. Это вызовет событие на рабочей станции, но не на контроллере домена, выполнившем аутентификацию. По сути, события входа в систему отслеживаются там, где происходит попытка входа, а не там, где находится учетная запись пользователя. Этот параметр не включен ни для одной операционной системы, за исключением контроллеров домена Windows Server 2003, которые настроены на аудит успешности этих событий. Обычно и рекомендуется регистрировать эти события на всех компьютерах в сети.
Включенный на всех машинах и используемый с системой, которая будет извлекать журналы со всех машин, я считаю это наиболее надежным.
После того, как вы предоставили доступ группе администраторов, вы можете фактически «потерять» компьютер, и его будет сложно вернуть.
Вернувшись на предыдущую работу, The Powers That Were (вместо Be) решили, что заставить меня быть в группе администраторов назначенной мне рабочей станции XP Pro было удачной идеей. Поскольку я был администратором других систем, присоединенных к этому домену, у меня была другая учетная запись для административных целей, которую я мог использовать по своему усмотрению (периодическая установка или обновление программного обеспечения или тому подобное). Было непрактично менять ролями этих двух учетных записей (Exchange, членство в группах различных серверов, списки управления доступом к объектам FS и т. Д.). Я просто не соглашался с тем, что меня заставляют ежедневно входить в систему как администратор. Поэтому, как само собой разумеется, я настраивал политику локального компьютера (gpedit) для асинхронного и видимого запуска сценариев запуска и установил тот, который запускал CMD. Естественно, это показало свое окно на winstation входа в систему (думаю, я правильно это описываю, не уверен) с токеном безопасности суперпользователя (SYSTEM). Оттуда я мог делать практически все, что хотел, включая удаление моего повседневного SID домена из локальной группы администраторов (в некоторой степени), добавление предполагаемой учетной записи администратора локальному администратору и настройку повторяющегося задания планировщика заданий для выполнения. это каждые несколько часов (чтобы обойти автоматическое обновление GPO).
Предоставление им администратора также позволит им создавать локальные учетные записи и использовать их вместо учетных записей домена и просто использовать "net use / user: DOM \ user" для аутентификации в вашем домене для доступа к любым сетевым ресурсам, и только тогда, когда они этого хотят. . Так что все, что угодно, например, попытки отслеживать входы / выходы из системы, может быть немного рискованным и неточным. Если я не ошибаюсь, с доступом администратора будет не так уж сложно «замести следы», по крайней мере, локально (например, очистить журналы событий, настроить характеристики службы регистрации событий, изменить политику аудита. , и т.д.)
Я бы долго и усердно думал о том, почему вы это делаете, и, возможно, нашел бы другой способ предоставить им полный доступ администратора. Модель безопасности Windows чрезвычайно детализирована, и практически любой объект (файл, служба, запись реестра и т. Д.) Может иметь ACL, а идентификаторы безопасности (например, группы) имеют богатый набор прав, которые им можно предоставить.
Локальные аккаунты или домен? Вы имеете в виду, что их основные учетные записи являются администраторами или они получат учетную запись администратора специально для изменений? Если он центральный в домене, вы можете проверить журналы событий безопасности на контроллерах домена и / или журналы событий безопасности на локальных компьютерах.
Вот это Документация Microsoft записей журнала событий безопасности и что искать. Имейте в виду, что если вы проверите локальные машины, администраторы могут очистить журналы.
Аудит входа в систему - хороший термин Google для большего чтения.
Вы можете отслеживать, кто входит в систему и выходит из нее. Должно работать в Windows 7 и Windows Server 2008 R2: http://teusje.wordpress.com/2012/09/11/windows-server-logging-users-logon-and-logoff-via-powershell/