LastLogon и LastLogonTimestamp: дата последнего входа в привычном виде
Используя Active Directory, системный администратор постоянно сталкивается с необходимостью получить и систематизировать информацию о пользователях. Сегодня поговорим о двух атрибутах учётных записей, которые показывают дату и время последнего входа. Это LastLogon и LastLogonTimestamp. Если вы используете модуль Active Directory для PowerShell, то, скорее всего, замечали необычные значения этих атрибутов. Сделаем так, чтобы значения этих атрибутов имели привычный нам вид даты и времени.
Напомню, для просмотра атрибутов учётных записей в Active Directory через PowerShell нужно, чтобы последний был не ниже второй версии, а в операционной системе должен присутствовать модуль Active Directory для PowerShell. В этом случае мы можем посмотреть время последнего входа в систему через LastLogon или LastLogonTimestamp. Лучше использовать последний. Дальше вы поймёте почему. А начнём с LastLogon.
Для просмотра даты и времени последнего входа можно использовать вот такую конструкцию:
Таким нехитрым способом мы посмотрели время последнего входа у пользователей, что располагаются в конкретном OU, и расположили их в виде таблицы. Не забудьте заменить значения OU и DC на ваши.
Обратите внимание на скриншот ниже. Дата и время на нём, мягко говоря, не совсем читабельные. А у некоторых пользователей их и вовсе нет.
Что такое 132440351838433686? Это дата и время, записанные в системном формате. Он измеряется в тиках по 100 наносекунд, отсчёт которых идёт с 1 января 1601 года 00:00:00 UT. Давайте преобразуем эту запись в более привычный для нас формат:
Теперь читать дату и время намного удобнее. Если раньше у некоторых пользователей дата и время последнего входа отсутствовали вовсе, то теперь у таких пользователей мы видим дату 01.01.1601. Дата, конечно, не имеет ничего общего с реальностью. Но мы помним, что именно от неё начинает свой отсчёт системное время. К этой дате мы ещё вернёмся. А пока выгрузим полученную информацию в файл. Например, в CSV-файл. Для этого добавим ещё один элемент в наш конвейер.
Путь сохранения файла, разделитель и кодировка — по вкусу.
Пытливый читатель, возможно, заметил, что здесь мы использовали Select-Object. FT тут работать не будет.
Ну а теперь о пустых значениях LastLogon у некоторых пользователей. И о том, почему лучше использовать LastLogonTimestamp. Дело в том, что LastLogon не реплицируется контроллерами домена, а LastLogonTimestamp реплицируется. Правда и тут может быть погрешность от 9 до 14 дней. Потому что именно в такие сроки контроллеры домена реплицируют атрибут LastLogonTimestamp. Сделано это для минимизации трафика. При каждой регистрации пользователя контроллер анализирует значение LastLogonTimestamp, затем контроллер выбирает случайное число между 9 и 14. Если число дней между событием последней регистрации и текущим моментом меньше выбранного числа, то контроллер не обновляет значение LastLogonTimestamp у этого пользователя.
В этот раз дата и время последнего входа есть у всех пользователей. Но помните, что это не самые точные дата и время входа.
Напоследок приведу пример экспорта LastLogonTimestamp в CSV.
Теперь вы знаете как посмотреть дату последнего входа пользователя в PowerShell в удобном формате.
Информации о последнем входе в Windows на экране приветствия
В Windows есть полезная функция, позволяющая отобразить информацию о последней интерактивной попытке входа в систему прямо на экране приветствия Windows. Выглядит это следующим образом: каждый раз, когда пользователь набирает свой пароль для входа в систему, перед ним появляется информация с датой и временем последней удачной и неудачной попытке входа в систему (а также общее количество неудачных попыток входа). Если при попытке регистрации на компьютере будет введен неверный пароль (например, в случае попытки несанкционированного доступа), то при следующей загрузке системы пользователь увидеть уведомление о неудавшейся попытке войти на его компьютер.
В этой статье разберемся, как включить отображение информации о последнем интерактивном входе в систему на экране приветствия. Данный функционал будет работать на всех ОС Windows, начиная с Windows Vista, а для работы на доменном уровне требует функционального уровня домена не менее Windows Server 2008. Именно в этой версии в схеме Active Directory появился ряд новых атрибутов пользователя, которые содержат информацию о попытках интерактивного входа в систему.
Указанные выше атрибуты, в отличии от уже знакомым нам атрибутов lastLogon, lastLogontimeStamp, badPasswordTime и badPwdCount (появившихся еще в Windows 2000), реплицируются между всеми контроллерами домена.
Чтобы активировать политику, поменяем ее значение на Enabled и сохраним изменения.
Политика будет работать на всех компьютерам с ОС, выше Windows Vista. Машины с Windows XP и Windows Server 2003 эту групповую политику игнорируют.
Осталось применить политику к целевому компьютеру:
При следующем входе в систему после ввода пароля учетной записи появится сообщение с текстом:
Successful sign-in. The last time you interactively signed in to this account was: …
Unsuccessful sign-in. There have been no unsuccessful interactive sign-in attempts with this account since your last interactive sign-in
В русской версии Windows текст будет таким:
Успешный вход в систему. Последний интерактивный вход в систему был выполнен: «дата и время»
Неудачный вход в систему. Со времени последнего интерактивного входа в систему не предпринималось попыток входа в систему
Чтобы продолжить загрузку системы пользователю нужно нажать OK (или Enter).
На локальных ПК, но которых отсутствует редактор групповых политик, включить эту функцию можно через редактор реестра, для чего:
Функционал отслеживания последнего интерактивного входа удобно использовать, когда нужно обнаружить попытку атаки на каталог AD путем подбора пароля, а также в целях выполнения нормативных требований и обеспечения аудита, отслеживая источник и время попытки доступа к учетной записи пользователя.
Вывод информации о последнем входе в систему … при входе в систему
В одной из предыдущих статей я описал настройки, позволяющие скрыть имя пользователя с экрана приветствия и тем самым повысить безопасность компьютера. Продолжая тему безопасности, сегодня речь пойдет о настройке, позволяющей в процессе входа пользователя в систему вывести на экран данные о предыдущих попытках входа, как успешных, так и неудавшихся.
Данный функционал появился в операционных системах Microsoft начиная с Windows Vista\Server 2008. Включить отображение информации о последнем интерактивном входе в систему можно как локально, на отдельном компьютере, так и централизованно, с помощью доменных политик.
На локальном компьютере
На отдельном компьютере данные о последнем входе хранятся в локальном диспетчере безопасности SAM (Security Account Manager) и постоянно обновляются, достаточно только включить вывод этих данных на экран приветствия. Сделать это проще всего с помощью локальных групповых политик, поэтому открываем оснастку редактора локальных групповых политик (gpedit.msc) и переходим в раздел Computer Configuration\Administrative Templates\Windows Components\Windows Logon Options (Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Параметры входа Windows).
За вывод на экран информации о последнем входе отвечает политика «Display information about previous logons during user logon» (Отображать при входе пользователя сведения о предыдущих попытках входа), которую мы и включим.
Эту же опцию можно включить и через редактирование реестра. Для этого надо открыть редактор реестра (regedit.exe) и перейти в раздел HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System. Здесь нужно создать новый параметр типа DWORD с именем DisplayLastLogonInfo и указать для него значение 1. Соответственно для отключения опции можно задать значение параметра равным 0 либо удалить его совсем.
Стоит уточнить, что даже если компьютер является членом домена Active Directory и на него заходят под доменными учетными записями, при локальном включении политики отображаться будет только информация о локальных учетных записях. Для отображения информации о доменных пользователях необходимо воспользоваться доменными групповыми политиками.
В доменной среде
В доменной среде просто включить отображение информации о последнем входе недостаточно, тут все несколько сложнее. Данные о попытках входа хранятся в базе Active Directory, в свойствах пользователя, однако не все их можно использовать для отслеживания попыток входа. Для наглядности откроем свойства доменного пользователя и посмотрим, какие из пользовательских атрибутов хранят нужные нам данные.
Примечание. Атрибуты пользователя можно посмотреть из оснастки Active Directory Users and Computers, включив отображение дополнительных свойств (View->Advanced Features).
Данные о последнем входе в систему хранятся в атрибутах lastLogon и lastLogonTimestamp, а о неудачных попытках входа — в badPasswordTime и badPwdCount. Однако использовать их для отслеживания попыток входа не очень возможно, так как эти атрибуты привязаны к тому контроллеру домена, на котором была произведена авторизация. lastLogon, badPasswordTime и badPwdCount вообще не реплицируются на остальные контроллеры домена, а lastLogonTimestamp хотя и реплицируется, но очень редко, примерно один раз в 9-14 дней.
Поэтому, начиная с Windows Server 2008 в схеме AD у пользователя появилось несколько альтернативных атрибутов, связанных со входом в систему:
• msDS-FailedInteractiveLogonCount — общее количество неудачных попыток входа в систему с начала сбора статистики;
• msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon — количество неудачных попыток входа с момента последней успешной авторизации;
• msDS-LastFailedInteractiveLogonTime — время последней неудачной попытки входа;
• msDS-LastSuccessfulInteractiveLogonTime — время последней удачной попытки входа.
Эти атрибуты нормально реплицируются и их можно использовать для отслеживания попыток интерактивного входа пользователя в систему. Однако, как видно из рисунка, по умолчанию они неактивны, т.е. данные в них не собираются.
Включение отображения данных в доменной среде осуществляется в два этапа. Этап первый — это активация сбора нужных данных на контроллерах домена. Для этого создаем новый объект групповой политики (GPO), который привязываем к контейнеру Domain Controllers. Открываем его на редактирование, переходим в раздел Computer Configuration\Administrative Templates\System\KDC и включаем политику «Provide information about previous logons to client computers».
Эта политика как раз активирует сбор информации о предыдущих входах на контроллерах домена.
И этап второй — создаем еще один GPO, в котором включаем уже известную политику «Display information about previous logons during user logon», находящуюся в разделе Computer Configuration\Administrative Templates\Windows Components\Windows Logon Options. Этот GPO привязываем к тем подразделениям, для которых необходимо отображение данных о входе.
В результате после ввода пароля выводится информация о том, когда данный пользователь последний раз заходил в систему. В случае успешной авторизации выводится дата последнего входа
а в случае неуспешной — еще и дата неудачной попытки, а также число этих попыток. Эта информация может помочь определить попытки неавторизованного доступа к компьютеру.
В заключение напомню о важных моментах, необходимых для работы этого функционала:
• Для включения сбора данных о попытках входа в систему необходим функциональный уровень домена не ниже Windows Server 2008, так как только с этого уровня в схеме AD присутствуют необходимые атрибуты пользователя. У пользователя из домена с более низким функциональным уровнем при попытке зайти на компьютер, для которого включена политика отображения данных о последнем входе, могут возникнуть проблемы с авторизацией. Поэтому перед включением политики необходимо проверить, что уровень ваших доменов соответствует минимально необходимому.
• Также напомню, что отображение данных возможно только на компьютерах с ОС Windows Vista\Server 2008 и выше, более ранние ОС просто проигнорируют данную политику. Это не помещает пользователю зайти в систему, но информацию о последнем входе он не увидит.
Наводим порядок в Active Directory
Назначение ответственных за объекты службы каталога поможет управлять их жизненным циклом
Знаете ли вы, какие объекты в вашем каталоге AD уже не нужны? А к кому обращаться, если требуется изменить содержимое или структуру лесов AD?
Оказывая консультационные услуги по вопросам управления AD, я часто сталкиваюсь с ситуацией, когда в организации в течение длительного времени каталог AD развивался стихийно. Как правило, при этом накапливается огромное число неиспользуемых объектов, а также объектов, которые, по-видимому, для чего-то применяются, но трудно понять, кому именно и для чего они нужны. Содержать такие объекты довольно накладно: периодическая очистка AD — операция трудоемкая и дорогостоящая, реструктуризация или миграция AD становятся более трудоемкими, даже незначительное управление изменениями начинает требовать значительных усилий.
Чтобы разобраться и взять управление AD под контроль, необходимо установить три правила жизненного цикла объектов. Во-первых, следует установить правила создания, изменения и удаления объектов. Во-вторых, надо установить процедуры, обеспечивающие соблюдение этих правил для всех вновь создаваемых объектов. В-третьих, требуется совершить трудную, но необходимую работу по наведению порядка в уже существующих объектах AD, так что либо объект будет соответствовать установленным правилам, либо, после выполнения соответствующих процедур, он должен быть удален из каталога AD.
Ниже приводятся приемы и советы, как все это сделать. Для этого вводится концепция ответственных за объекты AD. Объектам AD назначаются ответственные — реальные сотрудники, которые помогут обеспечить регулярный контроль и порядок в среде AD.
Уточнение терминологии
Ответственный за объект AD — это конкретный человек, который непосредственно отвечает за объект или хотя бы просто знает, для чего служит данный объект. Можно было бы использовать термин «контакт», но это слово уже применяется для обозначения определенного типа объектов в AD. Можно было бы воспользоваться термином «владелец», но он тоже уже задействован в модели безопасности AD для обозначения создателя/владельца объекта.
Было бы замечательно, если бы в AD был предусмотрен атрибут «ответственный», который можно заполнять для указания ответственных за различные типы объектов AD. К сожалению, такого атрибута нет, и нам потребуется либо его создать, либо воспользоваться другими атрибутами, предусмотренными в схеме AD по умолчанию. Для простоты, а также потому, что многие компании придерживаются похвальной практики не расширять схему AD без необходимости, я воспользуюсь некоторыми из имеющихся атрибутов.
Зачем нужны ответственные?
Идентификация и удаление неиспользуемых объектов AD может оказаться делом неблагодарным и трудоемким. Некоторые полезные инструменты могут помочь обнаружить неиспользуемые объекты (например, утилита командной строки dsquery, а также AdFind и OldCmp от компании Joeware), но, поскольку удаление объектов потенциально опасно для систем и приложений, использующих AD, важно быть уверенным в том, что удаляемый объект действительно никем не используется. Как правило, для этого лучше всего переговорить с сотрудником, который отвечает за данный объект.
Во многих случаях этого человека трудно найти по атрибутам объекта. Часто у вас есть только имя объекта, с которым надо разобраться, например группа с названием OKP100 Staff. Хорошо, если название OKP100 вам о чем-то говорит, в противном случае разобраться будет трудно. Описание объекта может содержать некоторую полезную информацию («Прежде чем вносить изменения, свяжитесь с Дж. П. Картером»), но может оказаться, что нужный сотрудник уже не работает в организации.
Как можно убедиться, встроенная функциональность позволяет определить владельца объекта AD. Для этого мы введем концепцию ответственных за объекты.
Ответственные могут пригодиться и при работе с активными объектами. Например, при обработке запроса на включение пользователя в состав группы, сотрудники могут обратиться к ответственному для подтверждения или отклонения запроса.
Я рекомендую, чтобы вся информация о назначенных ответственных размещалась в самом каталоге AD. Впрочем, это не строгое требование.
Назначение ответственных за объекты пользователя
В реальной практике пользовательские объекты могут применяться для различных целей. Помимо стандартного применения — хранения учетных записей реальных людей, объекты пользователей могут создаваться для «должностных» учетных записей, используемых несколькими лицами (например, оператор автоматизированной системы), ресурсных учетных записей (почтовые ящики для переговорных комнат). Кроме того, это могут быть учетные записи системных служб или вспомогательные учетные записи для целей администрирования.
Я рекомендую назначать ответственных за все объекты пользовательских учетных данных, к какому бы виду они ни относились. Рассмотрим пример ресурсной учетной записи для почтового ящика переговорной комнаты Meeting Room C. Назначим хранителем учетной записи, скажем, Мэри Тейлор.
В оснастке Active Directory Users and Computers консоли MMC находим учетную запись Meeting Room C, открываем ее свойства и переходим на вкладку Organization. В разделе Manager нажимаем Change и с помощью выбора объектов находим и добавляем учетную запись пользователя Мэри Тейлор (см. экран 1).
Атрибут Manager является связанным атрибутом. Он представляет собой прямую ссылку, а парный ему атрибут directReports представляет собой соответствующую обратную ссылку.
Поскольку эти атрибуты являются связанными, после назначения Мэри менеджером учетной записи Meeting Room C при просмотре объекта Мэри Тейлор объект Meeting Room C будет отображаться в списке Direct reports (прямое подчинение; см. экран 2). Главное преимущество использования связанных атрибутов заключается в автоматическом поддержании целостности, так что объект может быть переименован или перемещен в AD, но связь при этом сохраняется. Она разрывается только в том случае, если объект, указанный в прямой или обратной ссылке удален. Другим преимуществом связанных атрибутов является возможность поиска средствами AD ответственного или объектов, за которые данный сотрудник отвечает.
Ниже приведены примеры результатов поиска с помощью средства AdFind, доступного на сайте www.joeware.net. В первом примере приведен запрос на выдачу всех пользовательских учетных записей, для которых Мэри Тейлор является хранителем.
На экране 3 приведен результат выполнения этого поискового запроса.
Следующий пример показывает, как найти ответственного за переговорную комнату:
Результат выполнения этого запроса будет выглядеть примерно следующим образом: CN=Mary Taylor, OU=Standard User Accounts, DC=ad, DC=fisheagle, DC=net.
Назначение ответственных за объекты групп
К сожалению, для объектов групп атрибуты manager и directReports не поддерживаются. Вместо них я рекомендую использовать аналогичную пару атрибутов managedBy и managedObjects.
Рассмотрим сказанное на примере группы Consulting Team, ответственным за которую мы назначим ту же Мэри Тейлор. Для этого в оснастке AD Users and Computers выберите данную группу, откройте свойства и перейдите на вкладку Managed By. В разделе Name нажмите Change и воспользуйтесь выбором объекта для поиска и добавления учетной записи Мэри Тейлор, как показано на экране 4.
Когда вы вносите изменения в оснастку AD Users and Computers, AD присваивает атрибуту managedBy группового объекта значение полного имени (DN) учетной записи Мэри Тейлор. Обратите внимание, что при установке значения параметра Managed By вы можете установить флажок Manager can update membership list для изменения менеджером состава группы, см. экран 4. Если вы назначаете ответственных за объект только для информационных целей, вероятно, следует убрать этот флажок. С другой стороны, это быстрый способ делегирования ответственному реальные полномочия по управлению составом группы.
Нужно иметь в виду, что в отличие от directReports, обратная ссылка managedObjects недоступна в оснастке Active Directory Users and Computers. Для просмотра обратной ссылки потребуется выполнить запрос LDAP или воспользоваться инструментарием типа ADSIEdit; отмечу, что необходимой возможностью обладает новая утилита Attribute Editor из комплекта Windows Server 2008.
Как и в случае атрибутов manager и directReport объектов пользователя, для просмотра взаимосвязей между группой и хранителем можно выполнить запрос к AD с помощью утилиты AdFind, как показано в следующем примере:
На экране 5 приведен результат выполнения запроса.
Чтобы определить ответственного для данного объекта, выполните следующий запрос AdFind:
Результатом его исполнения будет CN=Mary Taylor, OU=Standard User Accounts, DC=ad, DC=fisheagle, DC=net.
Указание ответственных для других типов объектов
Нетрудно распространить концепцию ответственных и на другие типы объектов AD. Например, компьютеры и организационные подразделения (OU) — следующие типы объектов, которые первыми приходят на ум. Они также поддерживают атрибуты связывания managedBy и managedObjects, так что можно задавать ответственного точно так же, как и для групп.
Ответственные и управление жизненным циклом объектов
Концепция ответственных будет работать хорошо только в том случае, когда она прописана в принятых в организации процедурах создания и удаления объектов. Очень важно, чтобы ответственный назначался сразу при создании всех объектов AD, для которых требуется вести учет.
Аналогично, при удалении стандартной учетной записи пользователя необходимо убедиться, что указание ответственного должно быть также удалено или перенесено на другого пользователя. Например, если наша Мэри Тейлор захочет покинуть компанию, необходимо решить, что делать с объектами, за которые она является ответственной. В случае с группами и переговорными комнатами разумно назначить новых ответственных за эти объекты. Если у Мэри была вторая учетная запись для выполнения административных задач, я бы сразу удалил ее.
Следует также помнить, что роль сотрудников в организации может меняться. Если такое происходит, ваши процедуры изменения должны предусматривать случаи, когда сотрудник перестает играть роль ответственного для объекта AD.
Наведение порядка в действующей инфраструктуре AD
Когда концепция ответственных для вновь создаваемых объектов будет внедрена, понадобится назначить ответственных за уже имеющиеся бесхозные объекты, а также установить соответствующие взаимосвязи между объектами. Перед этим, кстати, следует удалить неиспользуемые объекты AD.
Довольно часто встречается ситуация, когда объект AD создается для решения какой-то временной задачи, а потом про него все забывают. Например, для работы с новой системой управления документами часто создаются новые учетные записи и группы. Когда же через пару лет от этой системы управления документами отказываются, созданные для нее объекты продолжают оставаться в AD. Это может продолжаться сколь угодно долго, пока кто-нибудь не обратит на них внимание и не спросит, зачем они нужны.
Ниже приведены примеры применения средств командной строки для обнаружения неиспользуемых объектов. Эти примеры никоим образом не претендуют на полноту, но могут послужить хорошей отправной точкой. Из соображений единообразия для поиска неактивных пользователей и компьютеров я использую AdFind, хотя тех же результатов можно достичь с использованием OldCMP или dsquery.
Поиск неактивных пользователей
Приведенный ниже запрос (пишется в одну строку) использует AdFind для поиска учетных записей пользователей, которые никогда не выполняли регистрацию в домене или не регистрировались в домене с начала 2008 года. Результат выполнения запроса будет выдан в формате CSV.
Поделитесь материалом с коллегами и друзьями
