Комментарии 72
2. Overhead. А чего на наклейке сразу имя ПК не писать?
Бух такой важный…
бухи бывают разные… а если у него отчет в это время в фоне в ЦБ формируется/отправляется? или проводки по реестру от яндекс.такси?
налепить QR код
в организации с 20+ работниками это работает максимум полгода
Бух такой важный… когда хочет показать свою важность, а когда никого чужих нету, то и выключит и включит, не зависимо от количества открытых программ. Ну если альтернатива потратить полчаса пытаясь определить что за компьютер, то может быть и решение. Я же не предлагаю делать так всегда, только в граничных случаях, когда уже совсем туго.
А как насчет того, что после перезагрузки бух не сможет повторить дефект? Вообще гениальное предложение. А что? Действительно — сломалось что-то — выключи — включи.
Насчет первого — не соглашусь. Когда у бухов разгар работы — им бывает вообще не оторваться. Некритичные ошибки и проблемы откладываются на потом.
вида «организация.отдел.сотрудник».
1.технологи
2.производство.
…
5.бухгалтерия
…
9.отдел энергетика
на компе наклейка «12.7.21»
На русском означает «администрация.клининг-менеджер.Марина»
в саппорте по наклейке карточка компа, привязанная к карточке сотрудника, в которой есть в т.ч. номер мобильного, с которого Марина может позвонить, номер её местного телефона.
а в карточке — всё, чего душа пожелает, включая температуру дисков и обороты вентилятора БП.
зы: это для первой части задачи и чтобы не усложнять qr кодами.
чёй-то «предпросмотр» и «отправить» неактивны… :(
а если ПК заливаются с помощью WDS/SCCM и имена генерируются автоматически?
а если завтра бухгалтерия решит поменять формат инвентарных номеров (с 1234 на 60402-1234)?
Как раз использовал схему с инвентарным номером. При подготовке каждого ПК перед сдачей в работу на него клеился на видном для пользователя месте инвентарник, а имя ПК задавалось по стандарту "номер офиса-инвентарный номер". Соответственно при обращении просто спрашивали откуда человек звонит и просили продиктовать номер с наклейки.
Зачем добавлять в номер еще конкретного сотрудника — не очень понятно, ведь он сегодня за одним ПК, а завтра в другом офисе за другим.
Но это не отменяет удобства хранения информации о логинах в AD в удобном виде — когда нужно что-то сделать без присутствия человека (например ушел на обед, отправив тикет). И странно что в AD до сих пор нет удобного места для хранения и просмотра такой информации — либо парсить логи входа на всех контроллерах и агрегировать, либо как у автора — кастомные логон скрипты и кастомное поле у пользователя.
Вот со всеми описаниями http://winitpro.ru/index.php/2019/08/13/set-adcomputer-powershell/
Я немного по другому делаю. Оно ещё в базу пишет.
Сорри промахнулся
Хм. Логон и логофф скрипт. Отдельно на машины отдельно на юзверя. Работает 7 лет. В оснастке Ad видно кто на какой машине. Только права раздать на атрибуты правильно нужно. И вообще политики не на весь домен можно кидать. А на отдельные ou
Завтра утром по msk кину. И где правильно права дать
Так скрипт отрабатывает на пользователя. И он пишет на нужный атрибут.
Вот со всеми описаниями http://winitpro.ru/index.php/2019/08/13/set-adcomputer-powershell/
Я немного по другому делаю. Оно ещё в базу пишет
Командлет Set-ADComputer входит в состав модуля Active Directory для PowerShell и требует наличие установленного модуля на компьютере.
У Вас на всех рабочих станциях ADUC установлен?
VBS-скрипты из моего решения этого не требуют, будут запускаться даже на старых ОС, а скорость выполнения будет значительно выше, чем у их PS-аналогов из Вашей статьи.
И, как я писал выше с статье, вот эта модификация мне не очень нравится:
В первую очередь необходимо делегировать права группе Domain Users (или другой группе безопасности пользователей) на OU с компьютерами на изменение значений в полях объктов типа Computer: ManagedBy и description (Write Description + Write Managed By).
В моём же варианте всё работает «из коробки», со стандартными настройками безопасности.
У меня тоже через vbs скрипт сделано
On Error Resume Next
Set objSysInfo = CreateObject(«ADSystemInfo»)
Set objNetwork = CreateObject(«WScript.Network»)
Set objUser = GetObject(«LDAP://» & objSysInfo.UserName)
Set objComp = GetObject(«LDAP://» & objSysInfo.ComputerName)
strFullName = objUser.Get(«displayName»)
objUser.Put «description», objNetwork.ComputerName & " login " & Date
objUser.SetInfo
objComp.Put «description», strFullName & " login " & Date
objComp.SetInfo
И в оснастке Ад в поле комментарий видно кто куда залогинен. Как на машине так и у пользователя
Пользователю даны права в АД на изменения поля description
P.S. На компьютер может быть залогинено несколько пользователей одновременно.
В Security EventLog'а пишется событие ID 4624 (4625) с информацией о логине пользователя, если включить «Audit logon events» в полиси.
Вы пробовали парсить Security-логи, скажем, для организации, где тысяча пользователей и с десяток контроллеров домена?
P.S. На компьютер может быть залогинено несколько пользователей одновременно.
И что из этого следует?
и пользователь может логиниться на любом, что странно…
Что тут странного? Это стандартное поведение AD.
то посоветую запускать скрипты параллельно удалёно на каждом
Еще раз спрошу: Вы пробовали это в продакшне делать в крупной или хотя бы средних размеров организации перед тем, как подобные советы давать?
Что тут странного? Это стандартное поведение AD.
Странно не поведение AD, а то, что, по озвученным вами условиям, любой может залогинится при помощи любого из десятка AD, и складывается впечатление, что в вашей организации много контроллеров без географического разделения (т.е. без необходимости).
Еще раз спрошу: Вы пробовали это в продакшне делать в крупной или хотя бы средних размеров организации перед тем, как подобные советы давать?
Что вас пугает в параллельном запуске скриптов на контроллерах?
И что из этого следует?
Так как вы в вашем скрипте решили проблему одновременного логина пользователя на нескольких машинах? Ведь, если не ошибаюсь, то новый логин будет перезаписывать атрибут со старым, но ещё актуальным логином.
(Типичный пример в сетях 1Г и строже: пользователь имеет личную машину, но для вывода информации должен приходить со своей флешкой на машину с открытыми USB-портами).
складывается впечатление, что в вашей организации много контроллеров без географического разделения (т.е. без необходимости).
Совсем нет. К примеру, 5 площадок с парой DC в каждой.
Что вас пугает в параллельном запуске скриптов на контроллерах?
Я не про параллельный запуск, а вообще про парсинг. Не пугает ничего,, если это не в моей AD творится. :) Парсинг таких логов — ресурсоёмкая операция, и я бы не стал на DC ее запускать. Как Вы планируете это реализовать на практике? Вручную по мере надобности? По расписанию автоматом? За какой период будете смотреть, как и куда выгружать результаты?
Ведь, если не ошибаюсь, то новый логин будет перезаписывать атрибут со старым, но ещё актуальным логином.
Да, всё верно.
пользователь имеет личную машину, но для вывода информации должен приходить со своей флешкой на машину с открытыми USB-портами
Согласен, есть нюансы.
Как вариант. Кладём учётку такой «открытой» машины в отдельный OU, к которому не применяется GPO. В случае проблем на этой машине пользователь сообщает, что, мол, я сейчас не за своим ПК, а за «открытым». Техподдержка со своей стороны видит имя этой машины в ADUC. Либо на самой машине есть наклейка с номером/сетевым именем (если машин несколько).
Да, всё верно.
Но это же убивает изначальную идею на корню!?
Насчёт секьюрити — ивентов. Нет проблемы, если Вы их парсите и складываете в отдельный сторедж, а потом уже именно его опрашиваете. Минус такого решения, что нужно тащить ещё один компонент. В этом отношении ps-скрипты попросту выглядят проще (но совершенно необязательно, что это более хороший способ).
И если уж так рассуждать, то почему обязательно на АД садиться? Во многих компаниях есть что-то вроде Корп портала или системы учёта времени сотрудников. Вот по Корп порталу можно отследить кто и с какой машины залогинился (по айпи). Я не скажу, что это сильно лучше, чем с АД, но как вариант — почему нет?
Но это же убивает изначальную идею на корню!?
Почему Вы так считаете? Задача — оперативно узнать, за какой машиной сейчас работает пользователь, чтобы удаленно подключиться/выполнить диагностику. Сбор истории — это уже другая задача.
И если уж так рассуждать, то почему обязательно на АД садиться?
Описанное в статье решение для тех, кто уже «сидит» на AD, и оно позволяет добавить нужный функционал в уже работающую систему с минимальными трудозатратам. Если же инфраструктура поднимается с нуля, то, конечно, возможны варианты.
Почему Вы так считаете? Задача — оперативно узнать, за какой машиной сейчас работает пользователь, чтобы удаленно подключиться/выполнить диагностику. Сбор истории — это уже другая задача.
Потому что если у пользователя две активные сессии, то Вы об этом не узнаете.
Что хуже — если пользователь залогинился на компе А, потом на компе Б, а потом разлогинился на Б, но продолжил работу на А, то Вы об этом тем более не узнаете
Отслеживание таких гиперактивных пользователей — это уже другая задача. Решение, кстати, тоже есть, но оно выходит за рамки статьи. Возможно, опишу отдельно.
Но если у вас много таких людей, которые параллельно за несколькими машинами работают, возможно, имеет смысл подойти с другой стороны и пересмотреть процессы для них?
Почему гиперактивных?
это уже другая задача.
И да, и нет.
Но если у вас много таких людей, которые параллельно за несколькими машинами работают, возможно, имеет смысл подойти с другой стороны и пересмотреть процессы для них?
Процессы чего, простите? Поддержки? Вам просто указали на недостаток Вашей системы — она в определенных случаях может давать недостоверные данные. Решение есть у коллеги ниже — самое правильное — https://habr.com/ru/post/463579/?reply_to=20592497#comment_20592363
"Еще раз спрошу: Вы пробовали это в продакшне делать в крупной или хотя бы средних размеров организации перед тем, как подобные советы давать?"
Я делал несколько скриптов. Несколько тысяч пользователей. Больше сотни географически распределенных DC. Парсинг журналов DC. Раз в час параллельно парсились все журналы. В фильтре можно указать с какого времени читать файл. По id записи убиралось дублирование. Завели отдельную ВМ для этого. Запись в ms sql. Потом переделал на elastic search. Помимо этого ещё много чего собиралось с журналов. И не только с журналов безопасности. Например журналы direct access, rds gateway. Плюс раз в день опрос всех машин на список ПО. Все максимально параллезировалось. Пока хватит свободной памяти. Только через posh и wmi. И ещё много ещё чего. Брат жив.
Вы пробовали парсить Security-логи, скажем, для организации, где тысяча пользователей и с десяток контроллеров доменаADAudit успешно парсит, а если деньги важнее времени, то Powershell по расписанию сделает то же.
Но ламповой практической админской статье — лайк. Пользовался похожими скриптами на прошлой работе (было сделано до меня), только те скрипты писали не в AD, а в общую папку, что снимало проблему с перезаписью актуальных данных.
Разница в скриптах
«n» — «ff» (logon — logoff)
Имя пк соответствует имени пользователя, а имя пользователя в виде ФамилияИО.
Для совсем тяжёлых случаев распространяем групповой политикой rainmeter (отбражает инфу на рабочем столе, не затрагивая обои) с информацией «имя пк, имя пользователя, ip, домен, ОС и её разрядность».
Для совсем тяжёлых случаев…
Тяжёлые — это какие, например?
ИМХО, называть ПК по имени пользователя — путь в никуда, если у вас много пользователей/ПК и большая текучка кадров. Замучаетесь переименовать и всё равно не уследите в итоге.
В любом случае, с приходом нового пользователя, ПК нужно настроить. Переименование занимает не так много времени, зато соблюдается порядок.
Тяжёлые — это какие, например?
Когда имя ПК по какой-то причние не соответствует имени пользователя =) Обычно если одним ПК пользуются несколько человек, либо сотрудник, настраивающий ПК забыл\забил на преименование. Но ставим софтину всем пользователям — на всякий «тяжелый» случай.
З.Ы. В домене примерно 1.5к ПК.
любом случае, с приходом нового пользователя, ПК нужно настроить.
Не нужно. Перемещаемые профили? vdi? И пускай работает себе.
Зачем настраивать ПК под нового пользователя? Софт стандартный, настройки почта и т.д. ярлыки — подтягиваются из политики при логине. Документы на общем сетевом диске, с правами доступа по группам AD и с авто монтированием той же политикой.
И пусть пересаживаются хоть каждый день все.
ИМХО, называть ПК по имени пользователя — путь в никуда, если у вас много пользователей/ПК и большая текучка кадров.
Т.е. чуть чаще, чем всегда ) полностью согласен. Имя компа должно содержать инвентарный номер (PC-12345678 подойдёт), может кодировать тип оборудования или его местоположение (PC-MSK-01-3000)
Собирать онлогон скриптом через get запрос к своему собственному серверу с учётом вэйт нетворк полиси. А там сам себе Юи юикс делай. Хоть к телефонии прилепились и при звонке сразу открывается vnc например.
У меня все руки чешутся, наваять такой скрипт, который бы через asterisk AMI работал, но должно же быть уже что-то готовое.
Сделано всё проще:
echo %date% %time% > \server\reports\users\%username%_%computername%.txt
Пользователей 30 — 80. Способ далеко не лучший, но позволяет найти кто на каком компьютере вошел, в Radmin сделаны папки по отделам.
В итоге имеем массив компьютеров с отображением залогиненных в данный момент на них пользователей формирующийся в реальном времени. Ну и встроенный поиск работает по всем полям, в т.ч. по логину, по отображаемому имени (на русском), по имени ПК тоже можно но кто и зачем их помнит то…
Там же добавил шорткат который по нажатию Ctrl+1 на комп открывает радмин и параметром передаёт ему имя компа (ну и точно так же Ctrl+2 — радмин но в режиме просмотра)
Вот и всё. Успеваю подключиться еще пока человек не договорил фразу «привет, у меня тут $something не работает».
Помимо задачи из этого поста решается еще тьма всего — какой софт где установлен, какой комп давно не сканируется (=> либо ктото в отпуске либо учетку компа из домена забыли удалить), где какое железо, и еще миллион разных полезных штук. Настоятельно рекомендую.
p.s. а ещё есть PDQ Deploy который позволяет на всё это добро устанавливать пакеты который сам же и собираешь (то ли это установка софта то ли просто смена каких-то настроек).
- Настраиваем пересылку логов с рабочих станций на сервер. На сервере создаём новый вид (фильтр) журнала, в который будут попадать только эвенты логон и логофф. Профит.
- Либо на сервере-сборщике логов настраиваем скрипт отрабатывающий при возникновении событий логон/логофф, который пишет нужную нам информацию туда, куда нам надо.
- Либо всё тоже что и в предыдущем варианте, но скрипт отрабатывает на журнале безопасности рабочей станции и всё без сервера-сборщика.
И да, разница в скриптах в предпоследней строке в слове: strTimeStamp & " <logon". И я бы сделал один скрипт но с параметром, так удобней его поддерживать в актуальном варианте, если надо что-то добавить или изменить.
И да, разница в скриптах в предпоследней строке в слове: strTimeStamp & " <logon". И я бы сделал один скрипт но с параметром, так удобней его поддерживать в актуальном варианте, если надо что-то добавить или изменить.
Про это я тоже писал. Принципы DRY & KISS в полный рост.
страиваем пересылку логов с рабочих станций на сервер. На сервере создаём новый вид (фильтр) журнала, в который будут попадать только эвенты логон и логофф. Профит.
Тоже хороший вариант, спасибо за предложение.
1. Для удобства можно сделать формочку на PowerShell, куда вводишь фамилию(или часть) пользователя и она выводит список соответствующих пользователей/компьютеров. Тогда информация будет актуальнее.
2. GPO. Как альтернатива, чтобы не использовать loopback. Применять к OU с пользователями, но в фильтрах безопасности указать Domain Users и группу в которую входят все рабочие станции(у нас в такую группу раз в сутки простенький скрипт добавляет все не серверные компьютеры).
3. Из практики:
а) Как писали выше. Когда-то использовал logon скрипт, создававший на шаре файл вида %username%_%computername%.txt. Для не очень больших компаний работающее решение
б) bginfo. И сейчас используется на серверах.
в) Когда работал в it-аутсорсинге, то была схема: на системный блок наклейка с номером техподдежки и id компьютера, взятый из CMDB. С нашей стороны в широко известной немецкой программе для удалённого доступа составлялся список компьютеров. Указывалось имя, пользователь компьютера и id. Поиск быстро позволял найти компьютер по одному из этих параметров, а заодно увидеть в сети компьютер или нет.
Порядка нескольких тысяч пользователей, большей частью мигрирующих по рабочим местам либо логинящихся больше, чем на одном.
Применяется:
- logon/logoff скрипты, пишущие в атрибуты в AD: используются в основном для поиска вторичной машины, где пользователь залогинен и это приносит какие-то проблемы
- logon/logoff скрипты, пишущие в базу самописной интерактивной карты здания: решение не повсеместное, больше предназначенное для инженеров, решающих проблемы на месте, а не удаленно
- самописное ПО в трее: повсеместное решение как раз для общения с первой линией поддержки. кроме простоты объяснения как получить информацию о пользователе/компьютере ("наведите мышку на красную иконку с надписью IT у часиков") позволяет пользователю самостоятельно создать обращение в ServiceDesk (с передачей технической информации)
- DesktopInfo с IP-адресами в нижнем левом углу рабочего стола
- Интеграция с IP-телефонией (при звонке в тех.поддержку автоматически открывается окно подключения по VNC)
- logon-скрипт, отправляющий имя ПК в «базу»
- самописный клиент — часть корпоративного прокси, в которой также доступен текущий/последний IP-адрес с коротким интервалом обновления
- централизованный сбор журналов событий, где также видна история logon/logoff
- система инвентаризации, с агентами (косвенно, но тоже иногда можно узнать «кто где»)
Когда я начинал работать, из всего этого был только значок VNC в трее (и то не у всех) и клиент прокси, но в системе не было видно именно последнего IP-адреса, поэтому если клиент не запущен, то найти рабочий ПК острудника было весьма проблематично.
А в registry в HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D} прописать %Username% on %Computername% пробовали?
А за реализацию поставлю твёрдую пятёрку
А в registry в HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D} прописать %Username% on %Computername% пробовали?
«Чую, что дело бесовское, но обосновать не могу». Нет, не пробовал, колитесь, в чем гешефт!
А за реализацию поставлю твёрдую пятёрку
шорткат Windows+Pause
Windows-Break.
Однажды имел лаптоп с разнесением Pause и Break, и таки да… Это не Pause.
На контроллерах домена увеличиваете дефолтный максимальный размер security-лога. Можно с помощью групповых политик сделать.
В планировщик пихаете скрипт, который делает следующее.
1. С помощью командлетов Get-ADDomainController и Get-WinEvent парсит логи на всех контроллерах на предмет события с кодом 4624, учитывая последний EventID, полученный при предыдущем запуске (см. п. 2)
2. Агрегирует, сортирует по времени и сохраняет собранные данные (например, в CSV) и запоминает (сохраняет в файл) EventID для последнего полученного события для каждого из контроллеров
Максимальный размер логов и частота запуска скрипта, разумеется, подбираются исходя из ваших потребностей и особенностей ваших систем.
Windows: узнаём, кто где залогинен