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 в удобном формате.
Кто логинился на компьютер
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
Сообщения: 1
Благодарности: 0
ваш способ работает, если вы запускаете с Comp1
если вы с Comp1 будете смотреть Comp2 — поле будет пустым Username
ваш способ к сожалению не актуален
Системная утилита quser.exe
Мы можем использовать системную программу quser, которая возвращает имя текущего пользователя и время его входа. Выглядит это так:
Quser так же может работать удаленно используя следующий синтаксис:
Первая проблема этого способа — это то, что quser работает через RPC. Если вы выполняете команду удаленно, а порты не открыты, вы получите ошибки:
- Error 0x000006BA enumerating sessionnames
- Error 1722:The RPC server is unavailable.
Для примера, следующие команды исправят эти проблемы на одном компьютере, но скорее всего вы будете менять настройки через политики. Так же обратите внимание, что правило устанавливается на «Any», а не только «Domain»:
Вторая проблема — если вы будете выполнять команду через Invoke-Command, то могут быть проблемы с кодировками:
И третья проблема — у нас возвращается строка, а не объект. Что бы мы могли все эти данные, в дальнейшем, экспортировать (например в CSV), мы должны ее парсить. Это можно сделать так:
Далее нам нужно преобразовать все в специальный массив — PSCustomObject, т.к. только он может быть экспортирован в CSV и представляет собой более удобный вывод:
Метод substring убирает первый символ, так как программа возвращает имя пользователя либо с пробелом начали или символом «>».
Такой скрипт мы можем объединить в один командлет, который сможет работать локально и удаленно:
В функцию добавлено несколько деталей:
- Функция имеет атрибут «ComputerName» в которую можно передать имя компьютера. Т.к. эта переменная является строкой мы не можем использовать одновременно несколько (конвейер передает по одному);
- По умолчанию «ComputerName» выполняет $env:computername, что возвращает имя текущего компьютера;
- Часть команды «quser /server:$ComputerName 2>Null » будет исключать некоторые ошибки, которые связаны с выключенными компьютерами. Иначе — будут выводиться красные сообщения мешающие выводу;
- Добавлено несколько условий, которые различают логические ошибки (например фаервол), физические (компьютер выключен) и условие в случае если все хорошо;
Мы можем вызывать скрипт несколькими приемами:
Отмечу, что в случаях выключенных компьютеров запросы идут очень долго (около 2-3 секунд на компьютер). Способа снизить конкретно таймаут — я не знаю. Один из вариантов ускорить работу — фильтровать вывод с Get-ADComputer исключая отключенные учетные записи компьютеров. Так же можно попробовать использовать параллелизм.
Легче всего такой скрипт запускать на компьютерах пользователей, по событию входа в систему. На примере ниже я экспортирую эти данные в единый, для всех пользователей, файл CSV расположенный в доступности для пользователей:
Сам файл будет выглядеть так:
Отмечу следующие моменты:
- Можно увидеть разницу во времени и датах. У меня одна ОС с американской локализацией, а другая с русской. В принципе у вас таких проблем быть не должно, но можно исправить через Get-Date (парсингом даты);
- Из-за предыдущего пункта у меня бывали проблемы с кодировками, но они самоустранились быстрее, чем я смог предпринять действия.
Windows: узнаём, кто где залогинен
Хорошо, если у вас есть инструмент а-ля BgInfo или ваши пользователи знают про шорткат Windows+Pause/Break и умеют его нажимать. Встречаются даже редкие экземпляры, которые успели выучить имя своей машины. Но часто у звонящего вдобавок к его основной проблеме появляется вторая: узнать имя/IP-адрес компьютера. И нередко на решение этой второй проблемы уходит куда больше времени, чем первой (а надо было всего лишь обои поменять или вернуть пропавший ярлык :).
А ведь намного приятнее услышать что-то вроде:
— Татьяна Сергеевна, не беспокойтесь, уже подключаюсь…
А надо для этого не так уж и много. Специалисту техподдержки достаточно лишь выучить наизусть имена машин и помнить, кто за какой работает.
Перед описанием решения, которым мы пользуемся сейчас, я кратко рассмотрю другие варианты, чтобы раскритиковать их в пух и прах объяснить свой выбор.
-
, Desktop Info и им подобные. Если много денег, есть и платные. Суть в том, что на десктоп выводится техническая информация: имя машины, IP-адрес, логин и т.д. В Desktop Info можно даже графики производительности запилить на половину экрана.
- Ярлык а-ля «Кто я» (не пытайтесь добавить ему знак вопроса в конце :). Классический ярлык на рабочем столе, за которым прячется аккуратный или не очень скрипт, выводящий нужную информацию в виде диалогового окна. Иногда вместо ярлыка на рабочий стол кладут сам скрипт, что ИМХО моветон.
Недостаток в том, что для запуска ярлыка, как и в первом случае, нужно сворачивать все открытые окна (баловней судьбы, у которых на рабочей машине открыто единственное окно с пасьянсом, в расчет не берём). Кстати, а ваши пользователи знают, куда нужно тыкнуть, чтобы свернуть все окна?Правильно, пальцем в глаз админу.
Не устраивает то, что для того же Bginfo, например, пользователю нужно сворачивать окна, чтобы увидеть нужные данные. Еще мы с коллегами не раз наблюдали у BgInfo характерный артефакт, когда новый текст выводится поверх старого.
Некоторых пользователей раздражает тот факт, что админы
Душу излил, а теперь к делу.
За основу была взята идея хабровчанина mittel из этой статьи.
Суть задумки в том, что при входе пользователя в Windows логон-скрипт заносит нужную информацию (время и имя машины) в определенный атрибут учётной записи пользователя. А при выходе из системы отрабатывает аналогичный логофф-скрипт.
- Групповая политика, в которой прописаны логон- и логофф-скрипты для пользователей, применяется ко всему домену, поэтому скрипты будут отрабатывать на любой машине, на которую логинятся пользователи. Если у вас наряду с рабочими станциями используются терминальные решения (например, Microsoft RDS или продукты Citrix), такой подход будет неудобным.
- Данные заносятся в атрибут Department учетной записи пользователя, на который у рядового пользователя есть доступ только на чтение. Помимо атрибута учётной записи пользователя, скрипт также вносит изменения в атрибут Department учётной записи компьютера, который по умолчанию пользователи также менять не могут. Поэтому чтобы решение работало, автор предлагает изменить стандартые настройки безопасности для объектов AD.
- Формат даты зависит от настроек локализации на конечной машине, поэтому с одной машины можем получить 10 ноября 2018 14:53, а с другой 11/10/18 2:53 p.m.
- GPO линкуется не к домену, а к OU с машинами (я разделяю пользователей и машины по разным OU и другим советую). При этом для loopback policy processing mode выставлен режим merge.
- Скрипт будет заносить данные только в учетную запись пользователя в атрибут Info, который пользователь может менять самостоятельно для своей учётной записи.
- Изменен кусок кода, генерирующий значение атрибута
Теперь скрипты выглядят так:
Кто первым найдет все отличия между логон- и логофф-скриптом, тому плюс в карму. 🙂
Также для получения наглядной информации создан такой небольшой PS-скрипт:
- создаем GPO с нужными настройками и линкуем его к подразделению с рабочими станциями пользователей:
- идем пить чай (если AD с большим количеством пользователей, то чая нужно много 🙂
- запускам PS-скрипт и получаем результат:
В верхней части окна есть удобный фильтр, в котором можно отбирать данные по значениям одного или нескольких полей. Клик по столбцам таблицы сортирует записи по значениям соответствующих полей.
Можно красиво «упаковать» наше решение.
Для этого добавим ярлык для запуска скрипта специалистам техподдержки, у которого в поле «объект» будет что-то такое:
powershell.exe -NoLogo -ExecutionPolicy Bypass -File «\servershareScriptsGet-UsersByPCsInfo.ps1»
Если сотрудников техподдержки много, то можно раздать ярлык с помощью GPP.
sysrtfm
И так, встала задача — нужно каким либо образом определять на каком компьютере залогинен пользователь AD либо наоборот какой пользователь залогинен на ПК в текущий момент. На разных админских форумах эту задачу решают по разному. Я как то давно нашел скрипт и хочу им с Вами поделится.
Вкратце — 2 скрипта VBS помещаются в групповые политики нужной Organisation Unit дальше пользователям дается право на запись в поле «Description» учетных записей их компьютеров. скрипт выполняющийся при входе записывает description logoff и наоборот.
Вот как это выглядит в итоге:
1) Группе… скажем Domain Users делегируем на OU, содержащий компьютеры, следующие разрешения: Computer Objects > Write Description. Далее приведенные действия отличаются немного от Windows Server 2003 и Windows Server 2008 ENG, т.к. я все делал в русской оснастке 2008 AD. Для этого правой кнопкой мыши на OU где находятся все ПК, выбираем первый пункт «Делегирование управления», «Далее», «Добавить», выбираем группу пользователей «Domain Users» например, «Далее», Выбираем «Создать особую задачу для делегирования», «Далее», «только следующими объектами в этой папке», спускаемся в самый низ и отмечаем «Компьютер объектов», «Далее», Убираем галку «Общие» и отмечаем «Разрешения для свойств» — список увеличится, почти в самом низу отмечаем «Запись Описание», «Далее» и «Готово». После этого Все пользователи домена смогут записывать в поле «Описание» компьютеров.
2) Дальше нужно добавить скрипты в GP
Вот сами скрипты:
Сохраняем их с расширением VBS.
Все теперь при логофелогоне пользователей в Поле Description компов будут появлятся соответствующие записи.
3) Открываем групповую политику OU в которой находятся пользователи. «Конфигурация пользователя», «Политики», «Конфигурация Windows», «Сценарии Вход/Выход из системы» и добавляем скрипты.
Создание политики во время входа в систему
Файл со скриптом у меня готов. Открываем оснастку «Управление групповой политикой». Выбираем нужное организационное подразделение к которому мы будем применять политику, в моем случае, это контейнер «Users», поэтому политику я буду применять на самый корень домена root.pyatilistnik.org. Кликаем по нему правым кликом и из контекстного меню выбираем пункт «Создать объект групповой политики в этом домене и связать его».
Задаем имя для нашей политики.
Далее нам необходимо изменить и настроить нашу политику. Для этого щелкаем по ней правым кликом и выбираем «Изменить».
Переходим по пути:
Конфигурация пользователя — Политики — Конфигурация Windows — Сценарии (вход/выход из системы) — Вход в систему
У вас откроется окно с вкладкой «Сценарии» и «Сценарии PowerShell». Нас будет интересовать первая вкладка, нажимаем кнопку «Добавить».
Через кнопку «Обзор» вам нужно будет выбрать ваш файл vbs. Я вам советую его скопировать в сетевую папку с политикой, либо в сетевую шару, где файл будет доступен для всех.
В итоге у вас должно появиться вот так, если скриптов более одного, то можно выставлять их позиции при применении. Начинаем тестирование. У меня есть тестовая учетная запись Барбоскина Геннадия, в оснастке ADUC она у меня лежит в контейнере «Users». Поле пейджер пустое.
Пробуем залогиниться Геннадием на рабочей станции с Windows 10 с именем W10-CL01. После входа на компьютер, проверяем свойство «Пейджер» у данного пользователя. Как видим, все прописалось.
Пробуем подключиться к еще одному компьютеру с Windows 10 под именем W10-CL02. Видим, что атрибут в AD изменил свое значение на имя второго компьютера.
Напоминаю, что записываться будут только локальные входы. Сама реализация до безобразия проста, но надежна. Надеюсь, что кому-то данная заметка оказалась полезной, а с вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.
