Добрый день!
Наверное, у всех системных администраторов была проблема определения имени компьютера пользователя. То есть мы знаем имя сотрудника, но какой у него компьютер, без понятия. И, зачастую, попытка заставить пользователя определить имя компьютера вызывает мучение. Они вместо этого называют имя пользователя, 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 оказывается быстрее и универсальнее.
Скрипт, записывающий данные в текущего пользователя:
On Error Resume Next
Set objSysInfo = CreateObject("ADSystemInfo")
Set objNetwork = CreateObject("WScript.Network")
Set objUser = GetObject("LDAP://" & objSysInfo.UserName)
objUser.Put "LabelComputer", objNetwork.ComputerName
objUser.SetInfo
Скрипт прост и примитивен. Скрипт и модель впрочем, можно расширить, сохранять не только компьютер, а, например, и время для актуальности, но в данном примере я не буду касаться этого.
Скрипт с помощью групповой политики назначаем на запуск во время Logon. Но не только. Возможна ситуация, когда человек залогинен на двух компьютерах, хочется чтобы информация все равно была актуальна, даже в этом случае. Для этого добавляем выполнение скрипта в планировщик со срабатыванием по событию разблокировки компьютера.
В этом случае, даже если логин был выполнен на нескольких компьютерах, актуальным будет записан тот компьютер который был разблокирован последним. Есть только одно разочарование. Этот метод работает исключительно на Vista+ компьютерах. То есть в XP нельзя в планировщике поставить такой триггер. И к великому сожалению, VBS тоже не позволяет определить, заблокирован ли компьютер или нет. Иначе можно было бы запускать скрипт раз в 15 минут с проверкой заблокирован ли компьютер или нет. В VBS можно только по субъективным признакам определять, например, по записям в евент логе Security, но тогда, как минимум, потребуется дать обычному пользователю права на просмотр этого журнала. Это неудобно, плохо применимо да и вообще XP становится все меньше, эту группу компьютеров можно игнорировать, для них будет достаточно Logon скрипта.
Т.к. нам хочется помечать не каждый вход, а только тот, который локальный, нам нужно исключить запуск Logon скрипта на терминальных и других серверах, не относящихся к локальным компьютерам. Я этого достигал включением замыкании групповой политики в режиме слияние и применением объекта групповой политики к области персональных компьютеров, серверов, в которой, нет. Метод, соглашусь, достаточно плохой и растрачивающий ресурсы, лучше использовать замыкание групповой политики только тогда, когда это точно надо, а не для всех компьютеров. Но, возможно, это будет следующим этапом улучшения. Тем не менее, таким образом мы четко ограничиваем на каких именно компьютерах будет выполняться нужная нам групповая политики с Logon скриптом и настройками планировщика.
Пример PowerShell скрипта для сбора данных
Главная задача выполнена. Мы начинаем видеть, что в пользователях начинает появляться информация о текущем компьютере.
Теперь нам надо что-то с этими данными сделать. Например, сделать удобную табличку с тем, какие пользователи на каких компьютерах сидят. Или увидеть у каких пользователей нет значения в атрибуте, несмотря на недавний вход в систему, чтобы проследить, выполняются ли групповые политки в системе, например, либо в пользователе почему-то не хватает прав для записи значения атрибута в своего пользователя. Такое бывает, если у пользователя отключено наследование прав, к примеру.
Я написал 3 PowerShell скрипта, помогающих работе.
Поиск пользователей без значений
Import-Module ActiveDirectory
Get-ADObject -filter {(sAMAccountType -eq "805306368") -and (LabelComputer -notlike "*")} -Properties DisplayName,GivenName,SN,LabelComputer,cn,sAMAccountName,lastLogonTimestamp, OperatingSystem -SearchBase "OU=Пользователи сети,DC=contoso,dc=com" | Select-Object @{Expression={$_.DisplayName};Label="Отображаемое имя"},@{Expression={$_.sAMAccountName};Label="Логин"}, @{label="Последний вход";expression={[datetime]::FromFileTime($_.lastLogonTimestamp)}} | Sort-Object "Последний вход"| Format-Table -Autosize
Read-Host "Отсортировано по дате последнего входа по возрастанию. Для выхода нажмите любую клавишу..."
Этот скрипт делает красивую таблицу, в которой будут показываться только пользователи, отображаемое имя, логин и дату последнего входа в систему. Тут мы сможешь посмотреть подозрительных пользователей и потом попытаться понять, почему же несмотря на недавний заход в систему, имя компьютера до сих пор отсутствует.
Все компьютеры с метками
Import-Module ActiveDirectory
Get-ADObject -filter {(sAMAccountType -eq "805306368") -and (LabelComputer -like "*")} -Properties DisplayName,GivenName,SN,LabelComputer,cn,sAMAccountName,lastLogon -SearchBase "OU=Пользователи сети,DC=contoso,dc=com" | Select-Object @{Expression={$_.DisplayName};Label="Отображаемое имя"},@{Expression={$_.sAMAccountName};Label="Логин"}, @{Expression={$_."LabelComputer"};Label="Последний компьютер"},@{label="Последний вход";expression={[datetime]::FromFileTime($_.lastLogon)}} | Sort-Object "Последний вход" | Format-Table -Autosize
Read-Host "Отсортировано по последней дате входа по возрастанию. Нажмите любую кнопку для выхода..."
Этот скрипт похож на предыдущий, но показывает список помеченных пользователей. Позволяет прикинуть относительное количество помеченных пользователей.
Поиск имя компьютера по пользователю
Import-Module ActiveDirectory
$exit = 0
do
{
Write-Host "Поиск по атрибутам пользователя: Имя, Фамилия, Отображаемое имя, Логин, Имя компьютера. Выход при пустом поле поиска."
$us = Read-Host -Prompt "Введите строку для поиска"
$find = ""
$find += '*' + $us + '*'
write-host = $find
Get-ADObject -filter {(sAMAccountType -eq "805306368") -and ((GivenName -like $find ) -or (sn -like $find ) -or (cn -like $find ) -or (DisplayName -like $find ) -or (LabelComputer -like $find ) -or (sAMAccountName -like $find ))} -Properties DisplayName,GivenName,SN,LabelComputer,cn,sAMAccountName | Select-Object @{Expression={$_.DisplayName};Label="Отображаемое имя"},@{Expression={$_.sAMAccountName};Label="Логин"},@{Expression={$_."LabelComputer"};Label="Последний компьютер"} | Format-Table -Autosize
} While ($us -ne "")
Ну и, непосредственно, поиск. 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 объекти и типа объекта. Нам интересен только первый параметр, по которому мы находим имя пользователя в скрипте.
On Error Resume Next
Set WshShell = CreateObject("WScript.Shell")
set fs=createobject("Scripting.FileSystemObject")
Dim CompName
Dim RunCMD
Dim FilePath
Set objAD = GetObject(Wscript.arguments.Item(0))
CompName = objAD.Get ("LabelComputer")
If CompName = "" Then WScript.Echo "Имя компьютера отсутствует для пользователя"
If CompName = "" Then WScript.quit
If MsgBox ("Подключиться к компьютеру " & CompName & "?",vbOKCancel+vbQuestion,"Серьезно?") = vbCancel Then WScript.quit
If fs.FileExists ("C:Program FilesDameWareDameWare Mini Remote Control 7.5DWRCC.exe") Then FilePath = """C:Program FilesDameWareDameWare Mini Remote Control 7.5DWRCC.exe"""
RunCMD = FilePath &" -c: -h: -x: -m:" & CompName & " -u:LocalAdmin -p:1072206713 -d:contoso"
RetCode = WshShell.Run (RunCMD,5)
Этот скрипт запускает программу Damware с учетными данными contosoLocalAdmin. Этот пользователь заранее был добавлен в список локальных администраторов на компьютерах пользователей. По сути, параметры -u:, -p: и -d: можно исключить и тогда DameWare будет запускаться от имени текущего пользователя. Если у вас есть права локального администратора на компьютерах пользователя, то так будет проще.
В дальнейшем хотелось бы развить эту тем перевести телефонию отдела технической поддержки на программные SIP телефоны и адаптировать всю схему работы под программу таким образом, чтобы при входящем звонке производились все нужные выборки и у сотрудника на экране сразу появлялась вся информация о звонящем. И наступит счастье!
Несмотря на то, что никакие уникальные знания здесь не описаны, надеюсь, что как минимум, примеры скриптов помогут начинающим админам в понимании этой области :) Все это можно продолжать улучшать, добавить новые атрибуты, добавлять метку не только пользователю, но и компьютеру добавлять Timestamp, сохранять последние компьютеры и т.п. В каждой компании могут найтись свои потребности.
Автор: foxnet
