Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
Такие статьи нужны) У каждого есть свои маленькие удобности в работе которыми полезно ими делиться)
домен Active Directory, причем преимущественно уровня WindowsXP\Server2003.У леса/домена AD не бывает уровня WindowsXP. Уберите это.
Не мешайте в одну кучу уровень домена (AD Functional Level) и ОС на десктопах в домене.
при таком скрипте достаточно настроить в оснастке AD отображение одного дополнительного столбца (в нашем случае department) и можно будет четко видеть где кто работает в данный моментЧётко и в одном месте вы будете это видеть только если у вас все юзеры лежат в одном OU. А в больших организациях нередко юзеров и компьютеры распределяют (из разных соображений) по нескольким разным OU. Поэтому не всегда вы будете видеть всех в одном плоском и удобном списке.
в Пользователя, т.е. в самого себя они и так могут записывать.А вот и неправда. В AD уровня 2003 у обычных пользователей (Domain Users) по умолчанию есть право на изменение далеко не всех своих атрибутов (т.е. права для SELF). Например, свои атрибуты physicalDeliveryOfficeName, telephoneNumber, wWWHomePage — пользователи по умолчанию могут сами менять. А многие другие свои пользовательские атрибуты (включая предлагаемый вами атрибут department) пользователь по умолчанию менять не может. Поэтому на изменение этого атрибута тоже придётся вручную давать права для SELF, если вы хотите, чтобы они писали именно в этот атрибут.
по пунктам.
1. имелось в виду версии ОС а не уровни леса\домена. Поправил, для большей ясности.
2. можно также настроить Saved Queries (как на приведенном скриншоте), и тоже видеть все в одном месте. Там тоже довольно много OU, но все собрано в одном месте с помощью Saved Queries.
3. про права на атрибут — вы меня просто повергли в ад. Да! сто тысяч раз да! причем когда писал пост — еще полез было проверить себя, а потом отвлекся и так и оставил. В общем поправил.
Спасибо.
1. имелось в виду версии ОС а не уровни леса\домена. Поправил, для большей ясности.
2. можно также настроить Saved Queries (как на приведенном скриншоте), и тоже видеть все в одном месте. Там тоже довольно много OU, но все собрано в одном месте с помощью Saved Queries.
3. про права на атрибут — вы меня просто повергли в ад. Да! сто тысяч раз да! причем когда писал пост — еще полез было проверить себя, а потом отвлекся и так и оставил. В общем поправил.
Спасибо.
идея в принципе инетесная, но
1. зачем писать данные в поле Departments? Насколько я помню, поля Custom Attributes 1..16 стандартные (поправье, если я не прав, и эти аттрибуты появляются только после расширения схемы exchange-м), и в них можно рисовать подобные данные. Достаточно много програм, в своей работе строят дерево организации на основе данных из полей Department и Manager.
2. Система будет нагладной только в случае плоской организации: когда все пользователи всех отделов лежат в одном OU
1. зачем писать данные в поле Departments? Насколько я помню, поля Custom Attributes 1..16 стандартные (поправье, если я не прав, и эти аттрибуты появляются только после расширения схемы exchange-м), и в них можно рисовать подобные данные. Достаточно много програм, в своей работе строят дерево организации на основе данных из полей Department и Manager.
2. Система будет нагладной только в случае плоской организации: когда все пользователи всех отделов лежат в одном OU
2. Система будет нагладной только в случае плоской организации: когда все пользователи всех отделов лежат в одном OUЯ тоже об этом написал, но потом автор добавил скриншот, на котором видно, что плоские списки юзеров и компьютеров там строятся отдельно от дерева OU через Query (видимо, по всему домену) в оснастке ADUC.
Поля Custom Attribute непросто вытащить в оснастке ADUC (если вообще можно, я не нашел как), а хотелось чтобы стандартными средствами можно было видеть и отслеживать состояние компьютеров\пользователей.
Если писать в Custom Attribute — то как потом оттуда доставать данные? еще один скрипт писать, который будет вытаскивать их и складывать в таблицу? как то громоздко… не находите? Программу отдельную — ну тоже… излишне мне кажется.
Что касается поля Department — то оно не обязательно, можно в любое другое, главное чтоб потом было удобно его просматривать, и оно не мешало остальным задачам (например один наш клиент пишет у компьютеров в Department а у пользователей в City, т.к. у Пользователей поле Department занято названиями их отделов, в которых они работают, и отказываться от этого клиент не хотел.
Если писать в Custom Attribute — то как потом оттуда доставать данные? еще один скрипт писать, который будет вытаскивать их и складывать в таблицу? как то громоздко… не находите? Программу отдельную — ну тоже… излишне мне кажется.
Что касается поля Department — то оно не обязательно, можно в любое другое, главное чтоб потом было удобно его просматривать, и оно не мешало остальным задачам (например один наш клиент пишет у компьютеров в Department а у пользователей в City, т.к. у Пользователей поле Department занято названиями их отделов, в которых они работают, и отказываться от этого клиент не хотел.
Поля Custom Attribute непросто вытащить в оснастке ADUC (если вообще можно, я не нашел как)Кстати, не все знают, что настройки отображения оснастки ADUC (Active Directory Users and Computers) частично хранятся не на клиентской стороне, а в конфигурации AD.
Например, там хранится список атрибутов, которые можно выбрать в качестве столбцов при отображении списков объектов в ADUC. И при желании можно поправить конфигурацию AD таким образом, чтобы в качестве колонок можно было выбрать любой нужный вам атрибут, который по умолчанию отсутствует в списке View — Add/Remove columns, например, EmployeeID, EmployeeNumber, CustomAttributeX или любой другой атрибут на свой вкус.
Если интересно, могу рассказать подробнее.
Интересно
Интересно. Конечно напишите.
Интересно
Допустим, example.org — это корневой домен вашего AD-леса.
Стоит задача в ADUC добавить колонку с пользовательским атрибутом EmployeeID, в котором хранится табельный номер сотрудника.
1. От имени Enterprise Admin'а запускаете любой продвинутый LDAP-браузер, например, родной виндовый ADSI Edit (adsiedit.msc из пакета Support Tools).
2. Если ещё не подключена, то подключаете Configuration-партицию вашего AD (CN=Configuration,DC=example,DC=org)
3. Раскрываете иерархию CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=org
4. Там ниже несколько контейнеров для настройки опций отображения для разных локалей. Если все админы в вашей организации используют системы с английской локалью, т.е. запускают только англоязычную оснастку ADUC, то достаточно будет сделать изменения в CN=409. Если же есть те, кто запускает русскоязычный ADUC, то те же настройки потом нужно будет повторить в CN=419.
5. Раскройте объект конфигурации:
CN=default-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=org
и посмотрите его атрибут extraColumns. В нём перечислены колонки, которые по умолчанию можно добавить (через меню View — Add/Remove columns) для отображения списка объектов в ADUC.
extraColumns — это многострочный параметр вида:
c,Country,0,-1,0
company,Company,0,150,0
department,Department,0,150,0
displayName,Display Name,0,100,0
и т.д.
Каждое значение описывает одну из расширенных колонок. Параметры разделены запятыми. Первый параметр — название атрибута объекта, второе значение — название колонки в ADUC, третий параметр — отображать колонку по умолчанию (0 — нет, 1 — да), третий параметр — ширина колонки в пикселах (-1 — автоматический подбор ширины), последний параметр — опциональная фича (не знаю, какие бывают, тут обычно всегда 0).
Добавляете туда ещё одну значение для колонки Employee ID:
employeeID,Employee ID,1,-1,0
6. Но значение атрибута extraColumns в CN=default-Display влияет только на дефолтовое отображение (в частности для Saved Queries). А если эту колонку нужно добавить также и для просмотра OU и для просмотра дефолтовых контейнеров, которые не являются OU, (типа Users или Computers), тогда нужно будет открыть соответственно
CN=organizationalUnit-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=org
CN=container-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=org
и в их атрибут extraColumns скопировать все значения из одноимённого атрибута объекта CN=default-Display вместе с добавленной колонкой.
По умолчанию в CN=organizationalUnit-Display и в CN=container-Display атрибут extraColumns вообще не задан.
7. Пункты 5-6 повторить для CN=419 (для русскоязычных оснасток ADUC).
8. Теперь можно открыть ADUC на любом компьютере в данном AD-лесу, перейти в любой OU, далее в меню View — Add/Remove columns добавить колонку «Employee ID» (хотя для тех, кто впервые запустит консоль ADUC, эта колонка будет выводиться по умолчанию).
Колонки с атрибутом extensionAttributeX я так добавлять не пробовал, но с некоторыми другими (в частности EmployeeID) без проблем.
P.S. Иногда в консоли ADUC в WinXP/2003 нужно не просто просматривать какие-то специфические атрибуты, которые в свойствах объекта по умолчанию даже не видны, но ещё и изменять их. В этом случае в контекстное меню объекта можно добавить соответствующий пункт и повесить на него скрипт. Это опять же делается через редактирование конфигурации AD.
Например, в контекстное меню для пользовательских объектов я добавил пункт Employee ID, при выборе которого появляется диалоговое окошко, отображающее текущий EmployeeID (табельный номер) сотрудника и дающее возможность поменять его на любое значение (или сделать пустым/незаданным). Таким образом в ADUC в WinXP/2003 я получил возможность просматривать и изменять атрибут EmployeeID, что по умолчанию там не реализовано.
Стоит задача в ADUC добавить колонку с пользовательским атрибутом EmployeeID, в котором хранится табельный номер сотрудника.
1. От имени Enterprise Admin'а запускаете любой продвинутый LDAP-браузер, например, родной виндовый ADSI Edit (adsiedit.msc из пакета Support Tools).
2. Если ещё не подключена, то подключаете Configuration-партицию вашего AD (CN=Configuration,DC=example,DC=org)
3. Раскрываете иерархию CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=org
4. Там ниже несколько контейнеров для настройки опций отображения для разных локалей. Если все админы в вашей организации используют системы с английской локалью, т.е. запускают только англоязычную оснастку ADUC, то достаточно будет сделать изменения в CN=409. Если же есть те, кто запускает русскоязычный ADUC, то те же настройки потом нужно будет повторить в CN=419.
5. Раскройте объект конфигурации:
CN=default-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=org
и посмотрите его атрибут extraColumns. В нём перечислены колонки, которые по умолчанию можно добавить (через меню View — Add/Remove columns) для отображения списка объектов в ADUC.
extraColumns — это многострочный параметр вида:
c,Country,0,-1,0
company,Company,0,150,0
department,Department,0,150,0
displayName,Display Name,0,100,0
и т.д.
Каждое значение описывает одну из расширенных колонок. Параметры разделены запятыми. Первый параметр — название атрибута объекта, второе значение — название колонки в ADUC, третий параметр — отображать колонку по умолчанию (0 — нет, 1 — да), третий параметр — ширина колонки в пикселах (-1 — автоматический подбор ширины), последний параметр — опциональная фича (не знаю, какие бывают, тут обычно всегда 0).
Добавляете туда ещё одну значение для колонки Employee ID:
employeeID,Employee ID,1,-1,0
6. Но значение атрибута extraColumns в CN=default-Display влияет только на дефолтовое отображение (в частности для Saved Queries). А если эту колонку нужно добавить также и для просмотра OU и для просмотра дефолтовых контейнеров, которые не являются OU, (типа Users или Computers), тогда нужно будет открыть соответственно
CN=organizationalUnit-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=org
CN=container-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=org
и в их атрибут extraColumns скопировать все значения из одноимённого атрибута объекта CN=default-Display вместе с добавленной колонкой.
По умолчанию в CN=organizationalUnit-Display и в CN=container-Display атрибут extraColumns вообще не задан.
7. Пункты 5-6 повторить для CN=419 (для русскоязычных оснасток ADUC).
8. Теперь можно открыть ADUC на любом компьютере в данном AD-лесу, перейти в любой OU, далее в меню View — Add/Remove columns добавить колонку «Employee ID» (хотя для тех, кто впервые запустит консоль ADUC, эта колонка будет выводиться по умолчанию).
Колонки с атрибутом extensionAttributeX я так добавлять не пробовал, но с некоторыми другими (в частности EmployeeID) без проблем.
P.S. Иногда в консоли ADUC в WinXP/2003 нужно не просто просматривать какие-то специфические атрибуты, которые в свойствах объекта по умолчанию даже не видны, но ещё и изменять их. В этом случае в контекстное меню объекта можно добавить соответствующий пункт и повесить на него скрипт. Это опять же делается через редактирование конфигурации AD.
Например, в контекстное меню для пользовательских объектов я добавил пункт Employee ID, при выборе которого появляется диалоговое окошко, отображающее текущий EmployeeID (табельный номер) сотрудника и дающее возможность поменять его на любое значение (или сделать пустым/незаданным). Таким образом в ADUC в WinXP/2003 я получил возможность просматривать и изменять атрибут EmployeeID, что по умолчанию там не реализовано.
Через ADO забрать данные в Excel :)
И результат будет не менее наглыдным, а последующую обработку/сортировку будет удобнее проводить
И результат будет не менее наглыдным, а последующую обработку/сортировку будет удобнее проводить
Одно дело, когда юзеры сами это постепенно заполняют по мере логона, и у вас в любой момент времени есть готовый актуальный список.
А другое дело, когда вы сами инициируете сбор данных по всем компьютерам.
Представьте, что вам прямо сейчас приспичило это узнать. Сколько будет отрабатывать скрипт по сбору залогиненных юзеров по нескольким тысячам компьютеров в организации?
А другое дело, когда вы сами инициируете сбор данных по всем компьютерам.
Представьте, что вам прямо сейчас приспичило это узнать. Сколько будет отрабатывать скрипт по сбору залогиненных юзеров по нескольким тысячам компьютеров в организации?
Полезная ссылка, но roman_tik правильно описал контраргументы про «автоматическую работу скрипта», и про «ручное инициирование запроса»
Рецепт хороший.
А то иногда даже ITIL не спасает
А то иногда даже ITIL не спасает
Мне интересно ;)
Скажите, а что в вашем случае обозначает PCW? Вообще, как понять, где комп находится?
Скажите, а что в вашем случае обозначает PCW? Вообще, как понять, где комп находится?
Как мне кажется — PCWxxx — имя компьютера.
По уму надо бы добавить поле Locations (ну и разумеется, держать его актуальным)
По уму надо бы добавить поле Locations (ну и разумеется, держать его актуальным)
в данном случае это означает Personal Computer Windows :) А номер сначала был просто порядковым, а потом решили чтоб добру не пропадать, переименовали всех по номеру ближайшего телефона, благо ситуации когда есть компьютер но нет телефона у них практически не встречается.
А вообще задачу «где комп находится» конкретно в этой сети решают вручную (заполняя поля Location для объекта Компьютер в AD, например так «10 каб, 234 роз»). Мне лично этот способ не нравится — из-за обилия ручной работы при выдаче\замене\поломке компа. Чревато забывчивостью и скатыванием в хаос.
Еще — называют компьютер именами, которые однозначно его идентифицируют (Glavbuh, BigDirector, Ohrana и т.п.), при замене компа — меняют имя.
Еще — рисуют картинки сетей, с помощью всяких сторонних программ, типа FrendlyPing, hardware Administrator ну или чего помонструознее OpenView там и иже с ними.
А вообще задачу «где комп находится» конкретно в этой сети решают вручную (заполняя поля Location для объекта Компьютер в AD, например так «10 каб, 234 роз»). Мне лично этот способ не нравится — из-за обилия ручной работы при выдаче\замене\поломке компа. Чревато забывчивостью и скатыванием в хаос.
Еще — называют компьютер именами, которые однозначно его идентифицируют (Glavbuh, BigDirector, Ohrana и т.п.), при замене компа — меняют имя.
Еще — рисуют картинки сетей, с помощью всяких сторонних программ, типа FrendlyPing, hardware Administrator ну или чего помонструознее OpenView там и иже с ними.
А когда AD сложная, у неё крышу во время репликации не сносит?
Для отслеживания выходов пользователя на компьютер есть жернал событий, в котором всё отображается. Его можно парсить и смотреть кто где и когда логинился.
На мой взгляд такое частое переименование объектов в AD нежелательно и доспустимо только в небольших организациях с 2-3-мя контроллерами домена, находящимися в одном сайте.
Для отслеживания выходов пользователя на компьютер есть жернал событий, в котором всё отображается. Его можно парсить и смотреть кто где и когда логинился.
На мой взгляд такое частое переименование объектов в AD нежелательно и доспустимо только в небольших организациях с 2-3-мя контроллерами домена, находящимися в одном сайте.
у меня была оговорка в самом начале про небольшие сети (30-500 компов),
По личному опыту никаких проблем с репликацией (в т.ч. межсайтовой, была одна компания, в которой было 6 сайтов, и 7 контролеров домена ) не было.
В очень крупных сетях, думаю можно смотреть в сторону стороннего софта.
А по поводу журнала событий, я думал его парсить, но так и не смог нарисовать простую и рабочую схему системы. Расскажите, как вы это предлагаете сделать, чтобы был результат, аналогичный описанному в посте?
По личному опыту никаких проблем с репликацией (в т.ч. межсайтовой, была одна компания, в которой было 6 сайтов, и 7 контролеров домена ) не было.
В очень крупных сетях, думаю можно смотреть в сторону стороннего софта.
А по поводу журнала событий, я думал его парсить, но так и не смог нарисовать простую и рабочую схему системы. Расскажите, как вы это предлагаете сделать, чтобы был результат, аналогичный описанному в посте?
А вот это нее пробовали?
не понял вопроса :)
имеете в виду PowerShell? — так какая разница на чем написан скрипт — лишь бы отрабатывал. VBS быстрее кажется, да и чтоб ан XP работал PowerShell его нужно туда ставить, а VBS «по умолчанию» есть
Или вопрос в другом?
имеете в виду PowerShell? — так какая разница на чем написан скрипт — лишь бы отрабатывал. VBS быстрее кажется, да и чтоб ан XP работал PowerShell его нужно туда ставить, а VBS «по умолчанию» есть
Или вопрос в другом?
Сам PowerGUI, для разбора логов. В нем можно придумать внешний вид по своему желанию на основе скриптов.
не — не хочу.
скачал — посмотрел.
В принципе это просто оболочка для powerShell скриптов. Которыми все равно лезть в журнал выкачивать логи, потом парсить их чем-то и как-то и т.д.
А если компов 300 штук, как оно все будет работать?
Как мне в любой момент «нажать кнопку и посмотреть кто где сидит»?
Я вот именно эту схему не смог придумать в ситуации с «парсингом логов». Так то какая разница чем парсить, хоть powerShell хоть VBS хоть CMD.
Справедливости ради признаю, что PowerGUI довольно удобен, но вопросы озвученные выше все равно остаются.
скачал — посмотрел.
В принципе это просто оболочка для powerShell скриптов. Которыми все равно лезть в журнал выкачивать логи, потом парсить их чем-то и как-то и т.д.
А если компов 300 штук, как оно все будет работать?
Как мне в любой момент «нажать кнопку и посмотреть кто где сидит»?
Я вот именно эту схему не смог придумать в ситуации с «парсингом логов». Так то какая разница чем парсить, хоть powerShell хоть VBS хоть CMD.
Справедливости ради признаю, что PowerGUI довольно удобен, но вопросы озвученные выше все равно остаются.
Так на контроллере должно все быть, кто с какой машины залогинился.
не обязательно, если контроллеров несколько.
Сбор логов на одну машину сделать.
можно и так, но на мой взгляд это было усложнением системы.
т.е. получается, что нужен отдельный комп, который отдельным процессом стягивает логи с контролеров, хитро их там сливает в единую базу и парсит потом по коду событий, вытаскивая описание событий, чтоб можно было понять кто откуда залогинился.
Мне показалось это громоздким, поэтому пошел путем логон-скриптов.
т.е. получается, что нужен отдельный комп, который отдельным процессом стягивает логи с контролеров, хитро их там сливает в единую базу и парсит потом по коду событий, вытаскивая описание событий, чтоб можно было понять кто откуда залогинился.
Мне показалось это громоздким, поэтому пошел путем логон-скриптов.
Можно с помощью Event Collector собирать. У себя собираю с 16 серверов 2008R2, 2003R2 и 2003 на 2008R2, два журнала с каждого сервера, сервера не контроллеры домена. Ежедневно сбрасывается в архив. За день метров до 100 набегает, ужимается очень хорошо. Посмотреть точнее не могу, в отпуске. Так бы глянул объемы и посмотрел время при обработке скриптом.
Сбор логов на одну машину это маст-хэв по многим причинам. Имеет смысл всегда когда есть несколько машин производящих логи.
плюс ситуация «300 компов» это не к тому, что по компам ходить надо и логи парсить, а к тому, что объем Security лога тогда нужно увеличить довольно сильно, для более-менее адекватной глубины хранения, а не дай Бог у вас еще аудит объектов включен где-нить — застрелитесь ворочать сотни мегабайт, а то и гигайбайты логов.
> А когда AD сложная, у неё крышу во время репликации не сносит?
Что такое сложная AD? И как вы себе представляете снос крыши при репликации?
> На мой взгляд такое частое переименование объектов в AD нежелательно
Какие-то странные у вас предрассудки. Юзеры логинятся всего несколько раз в сутки (часто вообще 1 раз). Разве это частая модификация объектов? Тем более и без того при логоне меняются некоторые атрибуты объекта (в частности lastLogon, lastLogonTimestamp), и изменение дополнительно ещё одного атрибута не сильно нагрузит контроллер.
Понятно, что в часы пик, когда все утром приходят на работу, будет увеличение LDAP-подключений к контроллеру. Но в целом каждое подключение для изменения одного атрибута будет давать несильную нагрузку на контроллер. Вряд ли стоит этого опасаться. В любом случае ваши несколько контроллеров с этим справятся, если справляются с регулярной работой пользователей.
А между тем, различные служебные объекты в AD модифицируются постоянно (и гораздо чаще нескольких раз в сутки) без всякого вашего участия. И ничего…
Что такое сложная AD? И как вы себе представляете снос крыши при репликации?
> На мой взгляд такое частое переименование объектов в AD нежелательно
Какие-то странные у вас предрассудки. Юзеры логинятся всего несколько раз в сутки (часто вообще 1 раз). Разве это частая модификация объектов? Тем более и без того при логоне меняются некоторые атрибуты объекта (в частности lastLogon, lastLogonTimestamp), и изменение дополнительно ещё одного атрибута не сильно нагрузит контроллер.
Понятно, что в часы пик, когда все утром приходят на работу, будет увеличение LDAP-подключений к контроллеру. Но в целом каждое подключение для изменения одного атрибута будет давать несильную нагрузку на контроллер. Вряд ли стоит этого опасаться. В любом случае ваши несколько контроллеров с этим справятся, если справляются с регулярной работой пользователей.
А между тем, различные служебные объекты в AD модифицируются постоянно (и гораздо чаще нескольких раз в сутки) без всякого вашего участия. И ничего…
Старый велосипед…
В незапамятные времена еще в NetBIOS описание компьютера тоже самое писали.
В незапамятные времена еще в NetBIOS описание компьютера тоже самое писали.
Писать логи в LDAP? Мьсе знают толк в извращениях :-). Но до 500 пользователей по идее не должно проблем возникнуть… Правильнее было бы раз в сутки парсить логи и сохранять в LDAP список машин на которых работал пользователь.
Я для этого использовал другую схему (сеть на >2K компов).
При логине пользователя подобные vbs скрипты пишут данные о залогиненном пользователе, имени компа, серийнике в csv файл на сервере.
Файл парсится Oracle SQL Loader'ом и забивается в Oracle DB.
Далее скрипт убирает неоднократные перезагрузки юзеров за 1 день на одном и том же компе (для экономии места с базе).
В итоге имеем постоянно накапливаемую статистику логинов.
При логине пользователя подобные vbs скрипты пишут данные о залогиненном пользователе, имени компа, серийнике в csv файл на сервере.
Файл парсится Oracle SQL Loader'ом и забивается в Oracle DB.
Далее скрипт убирает неоднократные перезагрузки юзеров за 1 день на одном и том же компе (для экономии места с базе).
В итоге имеем постоянно накапливаемую статистику логинов.
Я лепил на каждый комп этикетку с его именем.
вот этой тулзой пользуюсь… нраиица… sourceforge.net/projects/netopmanager/
есть кстати дока по установке, настройке и т.д.
есть кстати дока по установке, настройке и т.д.
А оно будет работать, если домен на Samba+OpenLDAP?
принцип работы следующий:
1) скрипт kix, который запускается на компе и собирает инфу с компа. Результат складывает в шару, хотя и локально можно.
2) админ запускает прогу (админку), которой указываешь где собранная инфа
Итого. Главное это запускать скрипт (1). В AD это делается групповыми политиками — logon script.
Все. Если ваша самба + опенлдап каким-либо образом это обеспечит, то будет работать.
Иначе, вам необходимо реализовать какой-то другой способ запуска скрипта (1). Может быть вы сделаете задание на клиентах. Может быть один раз всего запустите на компе, но тогда инфа будет статичная. Можно через WMI запускать, можно тем же psexec.
1) скрипт kix, который запускается на компе и собирает инфу с компа. Результат складывает в шару, хотя и локально можно.
2) админ запускает прогу (админку), которой указываешь где собранная инфа
Итого. Главное это запускать скрипт (1). В AD это делается групповыми политиками — logon script.
Все. Если ваша самба + опенлдап каким-либо образом это обеспечит, то будет работать.
Иначе, вам необходимо реализовать какой-то другой способ запуска скрипта (1). Может быть вы сделаете задание на клиентах. Может быть один раз всего запустите на компе, но тогда инфа будет статичная. Можно через WMI запускать, можно тем же psexec.
дополнительно!!!
Если AD нет, то нужно открыть cp.kix файл, найти переменную $ad и поменять значение этой переменной с 1 на 0:
найти $ad=1 и заменить на $ad=0
Если AD нет, то нужно открыть cp.kix файл, найти переменную $ad и поменять значение этой переменной с 1 на 0:
найти $ad=1 и заменить на $ad=0
>именование машин по именам пользователей
Вот эта зараза у нас есть. Лично я против привязки пользователя к компьютеру. Привязка должна быть к рабочему месту! Во-первых, не всегда один пользователь работает за компьютером (например, на у нас на телеграфе 4 дежурных телеграфиста). С такой организацией мне пришлось завести пользователя с фамилией руководителя. Понять кто и что сделал никак невозможно. К тому же требования политики безопасности требует смены пароля через определённые промежутки времени. Во-вторых, люди приходят и уходят — должность остаётся. В результате компьютер остаётся «привязанный» к старому пользователю, а пользуется им новый. Была бы привязка к рабочему месту, достаточно было бы завести пользователя в АД и заблокировать старого.
Увы, старая система именования компьютеров по рабочим местам ушла в прошлое, а на её место пришла стандартизированная система именования по пользователям нашей организации :(
Вот эта зараза у нас есть. Лично я против привязки пользователя к компьютеру. Привязка должна быть к рабочему месту! Во-первых, не всегда один пользователь работает за компьютером (например, на у нас на телеграфе 4 дежурных телеграфиста). С такой организацией мне пришлось завести пользователя с фамилией руководителя. Понять кто и что сделал никак невозможно. К тому же требования политики безопасности требует смены пароля через определённые промежутки времени. Во-вторых, люди приходят и уходят — должность остаётся. В результате компьютер остаётся «привязанный» к старому пользователю, а пользуется им новый. Была бы привязка к рабочему месту, достаточно было бы завести пользователя в АД и заблокировать старого.
Увы, старая система именования компьютеров по рабочим местам ушла в прошлое, а на её место пришла стандартизированная система именования по пользователям нашей организации :(
а почему нельзя совместить оба варианта? если есть как персонализированные ПК, так и «общедоступные» логично вторые именовать иначе. и юзеров пускать под своими собственными логинами.
я в этот пост пару дней назад примерно такой коммент-вопрос хотел написать — разделение личных и общих ПК.
возможно, вашим телеграфистам нужно использовать «общие документы» или есть еще какие-то сложности против того, чтобы комп назвать общим и каждому сотруднику сделать личную учетку?
я в этот пост пару дней назад примерно такой коммент-вопрос хотел написать — разделение личных и общих ПК.
возможно, вашим телеграфистам нужно использовать «общие документы» или есть еще какие-то сложности против того, чтобы комп назвать общим и каждому сотруднику сделать личную учетку?
А у меня пользователи все сидят за одними и теме-же машинами. Меняется не часто.
Я просто по расписанию запускаю коротенький ps-скриптик, который ил лога Безопасност на контролеле домена выгребает все события по категории «Проверка учетных данных». И из свойств события выбираются связка User — Computer. Затем просто убираются дубликаты и скалдывается в файлик. Раз в неделю вполне достаточно.
Я просто по расписанию запускаю коротенький ps-скриптик, который ил лога Безопасност на контролеле домена выгребает все события по категории «Проверка учетных данных». И из свойств события выбираются связка User — Computer. Затем просто убираются дубликаты и скалдывается в файлик. Раз в неделю вполне достаточно.
Напишите здесь или в отдельном посте свой скрипт, поделитесь знаниями.
Ну скрипт — это громко сказано.
Выглядит как-то так:
Запускается в конце дня.
Только в большой системе за три часа размер лога может быть весьма большой, так что первый этап работает медленно. Запускать кстати можно не на сервере.
Также в этот спсок попадают даже компьютеры, не входящие в домен, но пытающиеся обращаться к AD за авторизацией, например удаленные пользователи, заходящие в терминал.
Выглядит как-то так:
$tm1 = get-date 7:00 #ставим дату на 7:00 сегодня
$tm2 = get-date 10:00 #ставим дату на 10:00 сегодня
$au = Get-EventLog -ComputerName DC01 -LogName Security -After $tm1 -Before $tm2 -InstanceId 4776 #выгребаем нужные события за нужный период
$lst = $au | foreach {$_.replacementstrings[1] + " | " + $_.replacementstrings[2]} #выдергиваем нужные данные
$lst3 = "","" #самый простой способ создать массив строк
foreach ($ls in $lst) {$poi = [regex]::match($lst3,$ls); $poi.Success ; if ($poi.Success -ne "True") {$lst3 += $ls}} #вычленяем повторения
$lst3 > C:\<путь>\uc.txtЗапускается в конце дня.
Только в большой системе за три часа размер лога может быть весьма большой, так что первый этап работает медленно. Запускать кстати можно не на сервере.
Также в этот спсок попадают даже компьютеры, не входящие в домен, но пытающиеся обращаться к AD за авторизацией, например удаленные пользователи, заходящие в терминал.
У меня пользователей не много, поэтому спокойно обхожусь списком в txt. Поиском нахожу по логину. Но в принципе, если заморочится, можно по всякому оформить. Дописать, чтобы не перетирались данные в файле, а просто обновлялись. Или запускать не в конце дня, я в 10:00 чтобы иметь картинку на сегодня. В общем крутить дальше есть куда.
Вообще, если немного продолжить тему. То до глобального перехода на Windows Server 2008/2008R2 и Windows 7 на клиентских машинах. Был еще удобный способ.
Поднимается WINS. На машинах включается NetBIOS и по DHCP насовывается адрес WINS сервера. И в базе WINS сервера каждый компьютер регистрирует при входе еще и имя пользователя. Удобно было смотреть практически в реальном времени. К сожалению в Windows Vista, 7, 2008 и 2008R2 WINS поддерживается чисто символически, по стольку поскольку. И имя пользователя не регистрирует. Ну или я просто не раскопал как сделать так, чтобы регистрировал.
Вообще, если немного продолжить тему. То до глобального перехода на Windows Server 2008/2008R2 и Windows 7 на клиентских машинах. Был еще удобный способ.
Поднимается WINS. На машинах включается NetBIOS и по DHCP насовывается адрес WINS сервера. И в базе WINS сервера каждый компьютер регистрирует при входе еще и имя пользователя. Удобно было смотреть практически в реальном времени. К сожалению в Windows Vista, 7, 2008 и 2008R2 WINS поддерживается чисто символически, по стольку поскольку. И имя пользователя не регистрирует. Ну или я просто не раскопал как сделать так, чтобы регистрировал.
У меня пользователи всегда за своей машиной.
Поэтому я в Description пользователя пишу имя его компа. Учётки юзеров и их компьютеров хранятся вместе по каждому отделу. Надо поуправлять компом Иванова — смотрим Description и выбираем на этом же экране его рабочую станцию.
Поэтому я в Description пользователя пишу имя его компа. Учётки юзеров и их компьютеров хранятся вместе по каждому отделу. Надо поуправлять компом Иванова — смотрим Description и выбираем на этом же экране его рабочую станцию.
Delphi+Firebird на мой взгляд лучшее решение tdlite.ru/it/usernameservice/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опытные мелочи Windows-админа