как узнать имя компьютера по имени пользователя в домене
Как узнать имя компьютера по имени пользователя в домене
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в России Pyatilistnik.org. В прошлый раз мы с вами производили поиск неактивных пользователей в домене. Сегодня мы сделаем еще одну полезную вещь для нашего AD, а именно научимся автоматически определять DNS-имя компьютера на котором локально залогинен пользователь и заносить эту информацию в атрибут Active Directory у пользовательской учетной записи.
Постановка задачи
В компаниях, где есть техническая поддержка пользователей, ее инженеры очень часто подключаются удаленно к компьютерам сотрудников для устранения всевозможных проблем. Чаще всего используются программы TeamViewer, встроенный помощник Windows или Dameware. Но для того, чтобы подключиться вам необходимо знать имя компьютера. Понятно, что можно каждый раз просить пользователя посмотреть его либо в окне системы или же на рабочем столе, если у вас выводится информация с помощью BGinfo. Но проще и правильнее всегда эту информацию иметь в базе Active Directory.
Поэтому мы сделаем так, что при локальном входе в компьютер, информация, о его DNS-имени будет автоматически записана в нужное нам поле. Это удобно и можно легко эту информацию выдергивать в любую программу, которая умеет работать с Active Directory, например SCCM.
Необходимо с помощью VBS скрипта записывать имя компьютера на котором пользователь произвел локальный вход, но игнорировать подключения к удаленному рабочему столу, например на терминальные сервера.
Реализация задачи
Делать мы все будет с помощью вот такого простенького скрипта.
Set objSysInfo = CreateObject(«ADSystemInfo»)
Set objUser = GetObject(«LDAP://» & strUserDN)
objUser.Put «Pager», WshNetwork.ComputerName
Давайте с вами пробежимся по каждой из строчек кода.
Вы вместо атрибута «Pager» можете подставлять любой, посмотреть атрибуты можно через редактор в Active Directory. Далее создаете текстовый документ и сохраняете его с расширением vbs.
Создание политики во время входа в систему
Файл со скриптом у меня готов. Открываем оснастку «Управление групповой политикой». Выбираем нужное организационное подразделение к которому мы будем применять политику, в моем случае, это контейнер «Users», поэтому политику я буду применять на самый корень домена root.pyatilistnik.org. Кликаем по нему правым кликом и из контекстного меню выбираем пункт «Создать объект групповой политики в этом домене и связать его».
Задаем имя для нашей политики.
Далее нам необходимо изменить и настроить нашу политику. Для этого щелкаем по ней правым кликом и выбираем «Изменить».
У вас откроется окно с вкладкой «Сценарии» и «Сценарии PowerShell». Нас будет интересовать первая вкладка, нажимаем кнопку «Добавить».
Через кнопку «Обзор» вам нужно будет выбрать ваш файл vbs. Я вам советую его скопировать в сетевую папку с политикой, либо в сетевую шару, где файл будет доступен для всех.
В итоге у вас должно появиться вот так, если скриптов более одного, то можно выставлять их позиции при применении. Начинаем тестирование. У меня есть тестовая учетная запись Барбоскина Геннадия, в оснастке ADUC она у меня лежит в контейнере «Users». Поле пейджер пустое.
Пробуем залогиниться Геннадием на рабочей станции с Windows 10 с именем W10-CL01. После входа на компьютер, проверяем свойство «Пейджер» у данного пользователя. Как видим, все прописалось.
Пробуем подключиться к еще одному компьютеру с Windows 10 под именем W10-CL02. Видим, что атрибут в AD изменил свое значение на имя второго компьютера.
Напоминаю, что записываться будут только локальные входы. Сама реализация до безобразия проста, но надежна. Надеюсь, что кому-то данная заметка оказалась полезной, а с вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.
Get-ADComputer: вывод информации о компьютерах в Active Directory через PowerShell
PowerShell командлет Get-ADComputer можно использовать для получения различных сведений об учётных записях компьютеров (серверах и рабочих станциях) в домене Active Directory. Это один из наиболее полезных командлетов для выборки и поиска компьютеров по разным критериям в домене AD ( для получения информации об учетных записях пользователей AD используется другой командлет — Get-ADUser).
Допустим, ваша задача – найти в Active Directory все неактивные компьютеры, которые не регистрировались в домене более 120 дней и заблокировать учетные записи этих компьютеров.
Прежде чем приступить к работе с командлетом Get-ADComputer, необходимо подключить модуль Active Directory Module for Windows PowerShell.
Основы синтаксиса и использование командлета Get-ADComputer
Справка о параметрах командлета Get-ADComputer вызывается стандартно с помощью Get-Help:
Чтобы получить информацию о доменной учетной записи конкретного компьютера или сервера, укажите его имя в качестве аргумента параметра —Identity:
Командлет вернул только базовые свойства объекта Computer из AD. Нас интересует время последней регистрации компьютера в домене AD, но этой информация в выводе команды нет. Выведем все доступные свойства данного компьютера из Active Directory:
Как вы видите, время последнего входа данного компьютера в сеть указано в атрибуте компьютера LastLogonDate – 21.09.2015 0:20:17.
Командлет Get-ADComputer позволяет вывести в результатах команды любые из свойств компьютера. Уберем всю лишнюю информацию, оставив в выводе только значения полей Name и LastLogonDate.
Итак, мы получили данные о последнем времени регистрации в домене для одного компьютера. Теперь нам нужно изменить команду так, чтобы она возвращала информацию о времени последней регистрации в сети для всех компьютеров домена. Для этого заменим параметр –Identity на —Filter:
Отсортируем результаты запроса по времени последнего логина в сеть (поле LastLogonDate) с помощью команды Sort:
Итак, мы получили список компьютеров домена и время их последнего входа в сеть Active Directory. Теперь мы хотим заблокировать учетные записи компьютеров, которые не использовались более 120 дней.
С помощью Get-Date получим в переменной значение текущей даты и вычтем из текущей даты 120 дней:
Полученную переменную с датой можно использовать в качестве фильтра запроса Get-ADComputer по полю LastLogonDate
Таким образом, мы получили список неактивных компьютеров, не регистрировавшихся в сети более 120 дней. С помощью командлета Set-ADComputer или Disable-ADAccount вы можете отключить эти учетные записи.
Теперь можно заблокировать все полученные учетные записи компьютеров:
Примеры использования командлета Get-ADComputer
Ниже представлены еще несколько полезных примеров команд с использованием командлета Get-ADComputer, которые можно использовать для выборки и поиска компьютеров домена по определенными критериям.
Получить общее количество активных (незаблокированных) компьютеров в Active Directory:
Почитать количество серверов с Windows Server в домене:
Получить список компьютеров в определенном OU, имена которых начинаются с BuhPC:
При поиске по OU вы можете использовать дополнительный параметр -SearchScope 1, который означает, что нужно искать только в корневом разделе. Параметр -SearchScope 2 означает рекурсивный поиск компьютеров во всех вложенных OU.
Выбрать все рабочие станции с ОС Windows 10:
На выходе получили такую красивую таблицу со списком Windows Server в AD.
Выбрать заблокированные компьютеры в определенном OU:
Чтобы удалить все аккаунты компьютеров в домене, не авторизовавшиеся в домене более 6 месяцев, можете воспользоваться командой:
Результат выполнения команды Get-ADComputer можно выгрузить в текстовый файл:
Также вы можете получить выборку компьютеров и экспортировать его в CSV файл:
Или получить HTML файл отчета со списком компьютеров и нужных атрибутов компьютера:
Чтобы выполнить определенной действие со всеми компьютерами из полученного списка нужно использовать цикл Foreach. В этом примере мы хотим получить список серверов в домене с моделью и производителем:
Либо можно использовать более короткий синтаксис цикла. Допустим нам нужно выполнить определенную команду на всех компьютерах в определенном OU (в этом примере мы хотим запустить на всех серверах команду обновления настроек групповых политик):
С помощью Get-AdComputer и логон скрипта PowerShell вы можете контролировать различные параметры компьютера. Я, например, контролирую состояние агента SCCM на компьютерах пользователей. При загрузке каждого компьютера на нем отрабатывает логон скрипт, который с помощью Set-ADComputer сохраняет состояние службы ccmexec в свободный атрибут компьютера — extensionAttribute10.
Затем с помощью следующей команды я могу найти компьютеры, на которых отсутствует или не запушена служба CCMExec:
Windows: узнаём, кто где залогинен
— Ой, у меня ничего не работает, помогите!
— Не переживайте, сейчас всё исправим. Назовите имя компьютера…
(классика жанра из звонков в техподдержку)
Хорошо, если у вас есть инструмент а-ля BgInfo или ваши пользователи знают про шорткат Windows+Pause/Break и умеют его нажимать. Встречаются даже редкие экземпляры, которые успели выучить имя своей машины. Но часто у звонящего вдобавок к его основной проблеме появляется вторая: узнать имя/IP-адрес компьютера. И нередко на решение этой второй проблемы уходит куда больше времени, чем первой (а надо было всего лишь обои поменять или вернуть пропавший ярлык :).
А ведь намного приятнее услышать что-то вроде:
— Татьяна Сергеевна, не беспокойтесь, уже подключаюсь…
А надо для этого не так уж и много. Специалисту техподдержки достаточно лишь выучить наизусть имена машин и помнить, кто за какой работает.
Перед описанием решения, которым мы пользуемся сейчас, я кратко рассмотрю другие варианты, чтобы раскритиковать их в пух и прах объяснить свой выбор.
Душу излил, а теперь к делу.
За основу была взята идея хабровчанина mittel из этой статьи.
Суть задумки в том, что при входе пользователя в Windows логон-скрипт заносит нужную информацию (время и имя машины) в определенный атрибут учётной записи пользователя. А при выходе из системы отрабатывает аналогичный логофф-скрипт.
Теперь скрипты выглядят так:
Кто первым найдет все отличия между логон- и логофф-скриптом, тому плюс в карму. 🙂
Также для получения наглядной информации создан такой небольшой PS-скрипт:
Буду признателен, если вы пройдете короткий опрос ниже.
Упрощаем жизнь администратору, ассоциируем имя пользователя и имя компьютера в автоматическом режиме в каталоге AD
Добрый день, хабр!
Наверное, у всех системных администраторов была проблема определения имени компьютера пользователя. То есть мы знаем имя сотрудника, но какой у него компьютер, без понятия. И, зачастую, попытка заставить пользователя определить имя компьютера вызывает мучение. Они вместо этого называют имя пользователя, mail, номер телефона, все что угодно, только не имя компьютера. А попытка объяснить пользователю где находится информация о системе вызывает баттхерт сотрудника и лютую ненависть. Можно, конечно, было бы написать какую-нибудь утилитку, позволяющая отображать имя компьютера на рабочем столе или где-нибудь еще на видном месте, но для этого надо каждый раз объяснять где находится эта информация. Немного упрощает задачу, но не решает ее полностью. Тем более что я склоняюсь к тому, что пользователю и во все положено не знать имя компьютера, на котором он сидит. В результате было решено сделать определение имени компьютера современным, удобным, правильным и, главное, автоматическим.
Примерно так может выглядеть подключение к компьютеру. При чем оснастку даже не обязательно открывать с помощью административной учетной записи. Для тех, кому интересно как все это работает и как это сделать в вашей инфраструктуре, добро пожаловать под кат.
Для выполнения описанного, вы должны понимать что такое AD, понимать хотя бы примерно структуру объектов в AD, понимать работу скриптов, а также любить котиков.
Общий принцип
Скрипт, запущенный из под пользователя определяет имя компьютера, на котором он работает, и от своего имени текущего пользователя записывает значение атрибута в самом себе в каталоге AD. Далее администратор уже волен сам решать что делать с этим значением атрибута. Я в этой статье приведу пример PowerShell скриптов и пример добавления пункта контекстного меню в оснастку Active Directory Users and Computers (далее ADUC).
Создаем атрибут
Многие не шли далеко и не мудрили, используя общедоступные для записи, например параметр «Веб страница» пользователя по-умолчанию доступен для записи самим собой. Однако мне эта идея не понравилась, хотелось создать специализированный атрибут для пользователя, который не имел бы двойного назначения и не требовал компромисса. А то кто знает, как в будущем сложится ситуация и потребует использование этого атрибута, а он уже занят…
Итак, для того, чтобы создать новый атрибут в схеме нужно сначала добавить оснастку. На компьютере с установленным пакетом удаленного администрирования, либо на контроллере домена, нужно запустить с правами локального администратора regsvr32 schmmgmt.dll. Сложно сказать почему эта оснастка по-умолчанию не зарегистрирована, видимо чтобы по незнанию не напортачили. Но тем не менее мы ее можем добавить, зарегистрировав DLL. После этого открываем оснастку Схема Active Directory и идем в раздел Attributes. Создаем новый атрибут. Тут, конечно, я должен предупредить, что атрибуты это не место для экспериментов и создаются они один раз и навсегда, удалить атрибут или переименовать невозможно. Это предупреждение есть во всех местах, где имеет место добавление атрибута, но все же 🙂 Для добавления нового атрибута также потребуются права Администратора схемы. Если ваш административный пользователь имеет права Администратор предприятия, то это больше, чем достаточно.
Для добавления нового атрибута потребуется ввести OID. Это уникальный идентификатор объекта. Почитать про него можно в гугле, углубляться не буду, но скажу что он должен быть уникальный. Пересечение OID недопустимо и если его вбить любым, то есть вероятность, что будут нерешаемые проблемы в будущем. OID обычно начинается с 1.2.840.113556 и далее циферки. Я особенно не заморачивался и т.к. третье число (840) это код страны, а четвертое это код компании (Microsoft), я ввел код несуществующей страны 800 и сгенерировал 2 случайных числа через точку. Список стран можно посмотреть здесь. На самом деле, по хорошему, в этом случае необходимо обратиться в ITU-T и запросить уникальный OID, но мне ответ так и не пришел и я не стал залезать в бутылку и создал на основе случайных чисел. Потом я нашел скрипт, который генерирует относительно уникальный идентификатор, но было уже поздно :))
В общем, с OID решили. Дальше нам нужно указать syntax атрибута. В моей конфигурации это Unicode String. Также, конечно, нужно имя атрибута. В этом примере я буду использовать имя LabelComputer, в рабочей конфигурации лучше придумать что-нибудь получше.
После того как мы создали атрибут, нам нужно его добавить в класс. Выбираем класс user и в закладе Attributes добавляем наш новый атрибут. Теперь пользователь с нужными правами будет иметь право записывать этот атрибут в пользователе. По-умолчанию эти правом владеет Account operator или выше. Но нас интересует ситуация, когда пользователь сам бы мог редактировать этот атрибут. Для подобных целей существует пользователь с именем SELF, который олицетворяем самого себя. Нам нужно дать права для всех пользователей пользователю SELF записывать атрибут LabelComputer. Т.к. наследование еще ни кто не отменял, переходим на столько высоко, на сколько это нужно и изменяем права. Я предлагаю изменить права на весь домен, для нас это будет dc=contoso,dc=com, входим в настройки безопасности объекта домен в оснастке ADUC. Входим в закладку разрешения и нажимаем кнопку Advanced. Добавляем права для пользователя SELF и разрешаем ему читать и записывать атрибут LabelComputer. Атрибут в списке, кстати, появляется не сразу после его создания. Должно пройти некоторое время от создания атрибута до того момента, как мы сможем видеть его в списке назначения прав и в свойствах атрибутов пользователя.
Маркировка
В итоге мы создали атрибут, права назначили. Переходим к рабочему этапу, нужно добавить имя компьютера в значение атрибута.
Для этого используется VBscript. Как показывает практика, Microsoft не пытается делать PowerShell заменой VBS. А жаль. Для таких задач VBS оказывается быстрее и универсальнее.
Скрипт, записывающий данные в текущего пользователя:
Скрипт прост и примитивен. Скрипт и модель впрочем, можно расширить, сохранять не только компьютер, а, например, и время для актуальности, но в данном примере я не буду касаться этого.
Скрипт с помощью групповой политики назначаем на запуск во время Logon. Но не только. Возможна ситуация, когда человек залогинен на двух компьютерах, хочется чтобы информация все равно была актуальна, даже в этом случае. Для этого добавляем выполнение скрипта в планировщик со срабатыванием по событию разблокировки компьютера.
В этом случае, даже если логин был выполнен на нескольких компьютерах, актуальным будет записан тот компьютер который был разблокирован последним. Есть только одно разочарование. Этот метод работает исключительно на Vista+ компьютерах. То есть в XP нельзя в планировщике поставить такой триггер. И к великому сожалению, VBS тоже не позволяет определить, заблокирован ли компьютер или нет. Иначе можно было бы запускать скрипт раз в 15 минут с проверкой заблокирован ли компьютер или нет. В VBS можно только по субъективным признакам определять, например, по записям в евент логе Security, но тогда, как минимум, потребуется дать обычному пользователю права на просмотр этого журнала. Это неудобно, плохо применимо да и вообще XP становится все меньше, эту группу компьютеров можно игнорировать, для них будет достаточно Logon скрипта.
Т.к. нам хочется помечать не каждый вход, а только тот, который локальный, нам нужно исключить запуск Logon скрипта на терминальных и других серверах, не относящихся к локальным компьютерам. Я этого достигал включением замыкании групповой политики в режиме слияние и применением объекта групповой политики к области персональных компьютеров, серверов, в которой, нет. Метод, соглашусь, достаточно плохой и растрачивающий ресурсы, лучше использовать замыкание групповой политики только тогда, когда это точно надо, а не для всех компьютеров. Но, возможно, это будет следующим этапом улучшения. Тем не менее, таким образом мы четко ограничиваем на каких именно компьютерах будет выполняться нужная нам групповая политики с Logon скриптом и настройками планировщика.
Пример PowerShell скрипта для сбора данных
Главная задача выполнена. Мы начинаем видеть, что в пользователях начинает появляться информация о текущем компьютере.
Теперь нам надо что-то с этими данными сделать. Например, сделать удобную табличку с тем, какие пользователи на каких компьютерах сидят. Или увидеть у каких пользователей нет значения в атрибуте, несмотря на недавний вход в систему, чтобы проследить, выполняются ли групповые политки в системе, например, либо в пользователе почему-то не хватает прав для записи значения атрибута в своего пользователя. Такое бывает, если у пользователя отключено наследование прав, к примеру.
Я написал 3 PowerShell скрипта, помогающих работе.
Поиск пользователей без значений
Этот скрипт делает красивую таблицу, в которой будут показываться только пользователи, отображаемое имя, логин и дату последнего входа в систему. Тут мы сможешь посмотреть подозрительных пользователей и потом попытаться понять, почему же несмотря на недавний заход в систему, имя компьютера до сих пор отсутствует.
Все компьютеры с метками
Этот скрипт похож на предыдущий, но показывает список помеченных пользователей. Позволяет прикинуть относительное количество помеченных пользователей.
Поиск имя компьютера по пользователю
Ну и, непосредственно, поиск. Like поиск происходит по всем основным параметрам пользователя. Возвращает таблицу найденного.
По всем скриптам, вывод можно делать не в Format-Table, а в Export-CSV и создавать сразу CSV файл и анализировать его уже в каком-нибудь табличном редакторе.
<<картинка с Леонардо Ди Каприо из фильма Начало>>
Добавление пункта в оснастку
Скрипты это красиво, но хочется большей автоматизации. И захотелось, чтобы при нажатии в контекстном меню происходило автоматическое подключение к компьютеру программой для удаленного управления DameWare. Безусловно, можно запускать любую удобную программу, можно таким образом удаленно перезагружать, например, машину, если надо. Тем не менее рассмотрим пример с DameWare.
Настройки контекстного меню оснастки ADUC находятся не локально, как может сначала показаться, а, опять же, в каталоге AD. Для того, чтобы добавить новый пункт, необходимо воспользоваться редактором конфигурации AD, утилитой ADSI Edit. Необходимо подключиться к конфигурации AD.
Требуемый атрибут для изменения находится в объекте
CN=user-Display,CN=419,CN=DisplaySpecifiers,CN=Configuration,DC=contoso,DC=com. При том CN=419 это, как не сложно догадаться, язык. Если нужно поменять параметр для англоязычной оснастки ADUC, то CN=419 нужно поменять на CN=409.
Добавляем в adminContextMenu пункт. Первое это, на сколько я понимаю, сортировочный номер, второе это непосредственно имя и третье это, собственно, адрес объекта для выполнения. Параметры разделяются запятыми. После перезапуска ADUC для объектов user в контекстном меню появится новосозданный пункт. Скрипт будет запускаться от прав пользователя, от имени которого оснастка и была запущена. Всего при запуске программы из контекстного меню ADUC скрипту или программе передается 2 значения в параметрах, это DN объекти и типа объекта. Нам интересен только первый параметр, по которому мы находим имя пользователя в скрипте.
В дальнейшем хотелось бы развить эту тем перевести телефонию отдела технической поддержки на программные SIP телефоны и адаптировать всю схему работы под программу таким образом, чтобы при входящем звонке производились все нужные выборки и у сотрудника на экране сразу появлялась вся информация о звонящем. И наступит счастье!
Несмотря на то, что никакие уникальные знания здесь не описаны, надеюсь, что как минимум, примеры скриптов помогут начинающим админам в понимании этой области 🙂 Все это можно продолжать улучшать, добавить новые атрибуты, добавлять метку не только пользователю, но и компьютеру добавлять Timestamp, сохранять последние компьютеры и т.п. В каждой компании могут найтись свои потребности.