Допустим, 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, что по умолчанию там не реализовано.
> А когда AD сложная, у неё крышу во время репликации не сносит?
Что такое сложная AD? И как вы себе представляете снос крыши при репликации?
> На мой взгляд такое частое переименование объектов в AD нежелательно
Какие-то странные у вас предрассудки. Юзеры логинятся всего несколько раз в сутки (часто вообще 1 раз). Разве это частая модификация объектов? Тем более и без того при логоне меняются некоторые атрибуты объекта (в частности lastLogon, lastLogonTimestamp), и изменение дополнительно ещё одного атрибута не сильно нагрузит контроллер.
Понятно, что в часы пик, когда все утром приходят на работу, будет увеличение LDAP-подключений к контроллеру. Но в целом каждое подключение для изменения одного атрибута будет давать несильную нагрузку на контроллер. Вряд ли стоит этого опасаться. В любом случае ваши несколько контроллеров с этим справятся, если справляются с регулярной работой пользователей.
А между тем, различные служебные объекты в AD модифицируются постоянно (и гораздо чаще нескольких раз в сутки) без всякого вашего участия. И ничего…
Поля Custom Attribute непросто вытащить в оснастке ADUC (если вообще можно, я не нашел как)
Кстати, не все знают, что настройки отображения оснастки ADUC (Active Directory Users and Computers) частично хранятся не на клиентской стороне, а в конфигурации AD.
Например, там хранится список атрибутов, которые можно выбрать в качестве столбцов при отображении списков объектов в ADUC. И при желании можно поправить конфигурацию AD таким образом, чтобы в качестве колонок можно было выбрать любой нужный вам атрибут, который по умолчанию отсутствует в списке View — Add/Remove columns, например, EmployeeID, EmployeeNumber, CustomAttributeX или любой другой атрибут на свой вкус.
Если интересно, могу рассказать подробнее.
Одно дело, когда юзеры сами это постепенно заполняют по мере логона, и у вас в любой момент времени есть готовый актуальный список.
А другое дело, когда вы сами инициируете сбор данных по всем компьютерам.
Представьте, что вам прямо сейчас приспичило это узнать. Сколько будет отрабатывать скрипт по сбору залогиненных юзеров по нескольким тысячам компьютеров в организации?
2. Система будет нагладной только в случае плоской организации: когда все пользователи всех отделов лежат в одном OU
Я тоже об этом написал, но потом автор добавил скриншот, на котором видно, что плоские списки юзеров и компьютеров там строятся отдельно от дерева OU через Query (видимо, по всему домену) в оснастке ADUC.
домен Active Directory, причем преимущественно уровня WindowsXP\Server2003.
У леса/домена AD не бывает уровня WindowsXP. Уберите это.
Не мешайте в одну кучу уровень домена (AD Functional Level) и ОС на десктопах в домене.
при таком скрипте достаточно настроить в оснастке AD отображение одного дополнительного столбца (в нашем случае department) и можно будет четко видеть где кто работает в данный момент
Чётко и в одном месте вы будете это видеть только если у вас все юзеры лежат в одном OU. А в больших организациях нередко юзеров и компьютеры распределяют (из разных соображений) по нескольким разным OU. Поэтому не всегда вы будете видеть всех в одном плоском и удобном списке.
в Пользователя, т.е. в самого себя они и так могут записывать.
А вот и неправда. В AD уровня 2003 у обычных пользователей (Domain Users) по умолчанию есть право на изменение далеко не всех своих атрибутов (т.е. права для SELF). Например, свои атрибуты physicalDeliveryOfficeName, telephoneNumber, wWWHomePage — пользователи по умолчанию могут сами менять. А многие другие свои пользовательские атрибуты (включая предлагаемый вами атрибут department) пользователь по умолчанию менять не может. Поэтому на изменение этого атрибута тоже придётся вручную давать права для SELF, если вы хотите, чтобы они писали именно в этот атрибут.
Поймите одну простую истину: «разместить в социальной сети» = «опубликовать в интернете»
Как только к вам придёт осознание этого, так сразу вы начнёте взвешивать всё, что собираетесь поместить в социальную сеть. И тут же пропадут все проблемы с приватностью.
Поймите, в публичных интернет-проектах приватности нет по определению. А если и есть, то весьма условная.
Ну сколько можно?
Хакер (от англ. hack — разрубать) — чрезвычайно квалифицированный ИТ-специалист, человек, который понимает самые основы работы компьютерных систем. (wiki)
Взломщики, кардеры, спамеры, DDoS-еры, дефейсеры и прочие сетевые хулиганы и мошенники — это не хакеры.
Хотя бы на Хабре используйте этот термин правильно. И нечего равняться на дилетантские высеры каких-то журналистов-недоучек.
Да кто вас всех угнетает-то, хоспади… Вы же сами туда пришли, и сами стали публиковать там что надо и что не надо. Не нравится сервис — не пользуйтесь. Какое тут угнетение?
Я вот не пользуюсь и сплю спокойно.
> Некоторые личности там оставляют свои номера телефонов, следовательно…
… следовательно сами себе злобные буратины.
Вы идите ещё на стене дома напишите все свои контакты, номер банковского счёта, пароль от интернет-банка и почтового ящика, а потом заявите, что владелец дома теперь является оператором персональных данных.
Проблема многих пользователей социальных сетей в том, что они изначально неверно понимали назначение социальной сети, видели в ней то, чем она в действительности не является, и потому неверно позиционировали себя в этой сети и неверно наполняли данными свой профиль.
⚫ Кто-то видел в социальной сети средство общения (обмена сообщениями), а свой профиль воспринимал исключительно как список личных контактов.
⚫ Кто-то воспринимал свой профиль в социальной сети, как личную записную книжку, где он хранит персональную информацию, личные контакты, приватные записи («Здравствуй, дорогой дневничок...»).
⚫ Кто-то видел в социальной сети хранилище, которое ему безвозмездно предоставил сервис, чтобы он там мог изолированно от всех хранить в личных целях любое своё приватное видео, любые свои приватные фотографии, любые свои приватные связи (любовники/любовницы).
Всем этим социальная сеть в действительности не является, даже если вам изначально и казалось, что это так.
И если воспринимать социальную сеть таким образом, то потом при каких-то изменениях политик начинаются проблемы с приватностью: «Аааа, они нарушают закон о хранении персональных данных», «Аааа, они нарушают мои конституционные права и вторгаются в мою личную жизнь», «Аааа, теперь все видят что у меня написано в профиле и кого я добавил в друзья», «Аааа, они опубликовали мой личный список контактов» и т.д.
Надо просто изначально воспринимать свой профиль в социальной сети не как «моё личное», а как «моё публичное». Т.е. это ваш публичный профиль, помещайте туда только ту информацию, которую сами хотите о себе публиковать.
А всё остальное не тащите туда (даже если думаете, что это никто не увидит). Не хотите, чтобы все видели ваши бухие фотки и фотки с проститутками — не тащите их в свои альбомы в социальной сети. Не хотите, чтобы все знали, что вы смотрите зоофильское порно — не тащите его в свой профиль в социальной сети. Стесняетесь некоторых своих знакомств — не афишируйте их в списке друзей в социальной сети. Не хотите, чтобы кто-то знал какие-то ваши контакты или приватные данные — не вносите их в профиле социальной сети.
Если изначально воспринимать свой профиль в социальной сети как «моя публичная сторона» и соответствующим образом его наполнять, то потом не будет никаких проблем с приватностью.
На мой вкус отдельный скрипт наоборот лучше тем, что его можно без проблем запускать от имени любого юзера, а также через sudo. А вот с запуском функции из вашего bashrc от другого юзера или через sudo надо ещё как-то заморочиться.
Лечить (обычно методами нетрадиционной медицины). П. больного. П. травами. П. от простуды.
За пару часов такой зарядки у вас сам телефон расплавится.
Стоит задача в 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, что по умолчанию там не реализовано.
Что такое сложная AD? И как вы себе представляете снос крыши при репликации?
> На мой взгляд такое частое переименование объектов в AD нежелательно
Какие-то странные у вас предрассудки. Юзеры логинятся всего несколько раз в сутки (часто вообще 1 раз). Разве это частая модификация объектов? Тем более и без того при логоне меняются некоторые атрибуты объекта (в частности lastLogon, lastLogonTimestamp), и изменение дополнительно ещё одного атрибута не сильно нагрузит контроллер.
Понятно, что в часы пик, когда все утром приходят на работу, будет увеличение LDAP-подключений к контроллеру. Но в целом каждое подключение для изменения одного атрибута будет давать несильную нагрузку на контроллер. Вряд ли стоит этого опасаться. В любом случае ваши несколько контроллеров с этим справятся, если справляются с регулярной работой пользователей.
А между тем, различные служебные объекты в AD модифицируются постоянно (и гораздо чаще нескольких раз в сутки) без всякого вашего участия. И ничего…
Например, там хранится список атрибутов, которые можно выбрать в качестве столбцов при отображении списков объектов в ADUC. И при желании можно поправить конфигурацию AD таким образом, чтобы в качестве колонок можно было выбрать любой нужный вам атрибут, который по умолчанию отсутствует в списке View — Add/Remove columns, например, EmployeeID, EmployeeNumber, CustomAttributeX или любой другой атрибут на свой вкус.
Если интересно, могу рассказать подробнее.
А другое дело, когда вы сами инициируете сбор данных по всем компьютерам.
Представьте, что вам прямо сейчас приспичило это узнать. Сколько будет отрабатывать скрипт по сбору залогиненных юзеров по нескольким тысячам компьютеров в организации?
Не мешайте в одну кучу уровень домена (AD Functional Level) и ОС на десктопах в домене.
Чётко и в одном месте вы будете это видеть только если у вас все юзеры лежат в одном OU. А в больших организациях нередко юзеров и компьютеры распределяют (из разных соображений) по нескольким разным OU. Поэтому не всегда вы будете видеть всех в одном плоском и удобном списке.
А вот и неправда. В AD уровня 2003 у обычных пользователей (Domain Users) по умолчанию есть право на изменение далеко не всех своих атрибутов (т.е. права для SELF). Например, свои атрибуты physicalDeliveryOfficeName, telephoneNumber, wWWHomePage — пользователи по умолчанию могут сами менять. А многие другие свои пользовательские атрибуты (включая предлагаемый вами атрибут department) пользователь по умолчанию менять не может. Поэтому на изменение этого атрибута тоже придётся вручную давать права для SELF, если вы хотите, чтобы они писали именно в этот атрибут.
«разместить в социальной сети» = «опубликовать в интернете»
Как только к вам придёт осознание этого, так сразу вы начнёте взвешивать всё, что собираетесь поместить в социальную сеть. И тут же пропадут все проблемы с приватностью.
Поймите, в публичных интернет-проектах приватности нет по определению. А если и есть, то весьма условная.
А школота уже гуляет.
Ну сколько можно?
Хакер (от англ. hack — разрубать) — чрезвычайно квалифицированный ИТ-специалист, человек, который понимает самые основы работы компьютерных систем. (wiki)
Взломщики, кардеры, спамеры, DDoS-еры, дефейсеры и прочие сетевые хулиганы и мошенники — это не хакеры.
Хотя бы на Хабре используйте этот термин правильно. И нечего равняться на дилетантские высеры каких-то журналистов-недоучек.
Да кто вас всех угнетает-то, хоспади… Вы же сами туда пришли, и сами стали публиковать там что надо и что не надо. Не нравится сервис — не пользуйтесь. Какое тут угнетение?
Я вот не пользуюсь и сплю спокойно.
… следовательно сами себе злобные буратины.
Вы идите ещё на стене дома напишите все свои контакты, номер банковского счёта, пароль от интернет-банка и почтового ящика, а потом заявите, что владелец дома теперь является оператором персональных данных.
⚫ Кто-то видел в социальной сети средство общения (обмена сообщениями), а свой профиль воспринимал исключительно как список личных контактов.
⚫ Кто-то воспринимал свой профиль в социальной сети, как личную записную книжку, где он хранит персональную информацию, личные контакты, приватные записи («Здравствуй, дорогой дневничок...»).
⚫ Кто-то видел в социальной сети хранилище, которое ему безвозмездно предоставил сервис, чтобы он там мог изолированно от всех хранить в личных целях любое своё приватное видео, любые свои приватные фотографии, любые свои приватные связи (любовники/любовницы).
Всем этим социальная сеть в действительности не является, даже если вам изначально и казалось, что это так.
И если воспринимать социальную сеть таким образом, то потом при каких-то изменениях политик начинаются проблемы с приватностью: «Аааа, они нарушают закон о хранении персональных данных», «Аааа, они нарушают мои конституционные права и вторгаются в мою личную жизнь», «Аааа, теперь все видят что у меня написано в профиле и кого я добавил в друзья», «Аааа, они опубликовали мой личный список контактов» и т.д.
Надо просто изначально воспринимать свой профиль в социальной сети не как «моё личное», а как «моё публичное». Т.е. это ваш публичный профиль, помещайте туда только ту информацию, которую сами хотите о себе публиковать.
А всё остальное не тащите туда (даже если думаете, что это никто не увидит). Не хотите, чтобы все видели ваши бухие фотки и фотки с проститутками — не тащите их в свои альбомы в социальной сети. Не хотите, чтобы все знали, что вы смотрите зоофильское порно — не тащите его в свой профиль в социальной сети. Стесняетесь некоторых своих знакомств — не афишируйте их в списке друзей в социальной сети. Не хотите, чтобы кто-то знал какие-то ваши контакты или приватные данные — не вносите их в профиле социальной сети.
Если изначально воспринимать свой профиль в социальной сети как «моя публичная сторона» и соответствующим образом его наполнять, то потом не будет никаких проблем с приватностью.
Найдите его профиль на Хабре (ник был что-то вроде invalidus), скорее всего он уже давно слит и потому не может публиковать пресс-релизы.