Active Directory с человеческим лицом. Редактирование схемы

Active Directory с человеческим лицом

Привет.

Кастомизация Active Directory – тема вечная. Вокруг неё накручено много вымыслом, шаманства и прочего, однако тема эта никакого волшебства в себе не содержит. Я это наглядно покажу.

История первая – Глючные картинки

История вторая – Как Вася в алкоголе запутался

История третья – Как Васе правозащитники помогали

История четвертая – Родная сеть родного предприятия

 

История первая – Глючные картинки

Однажды к одному CIO пришёл руководитель IT-департамента.

– В Active Directory есть глючные объекты, у которых нет картинки. Вот, смотри:

– Траст до партнёрского домена есть, а судя по картинке – глючный. Люди волнуются, говорят, что надо домен переставлять, наверное.

“Люди не должны волноваться. Чистый разум, по которому бежит рябь мысли о переустановке Active Directory, подобен нечистому разуму, а таких по ТК премии лишают. Нельзя так с людьми.” – подумал CIO.

Последовательность действий

Отображение всех объектов в Active Directory предприятия регулируется в контейнере CN=Display Specifiers,CN=Configuration,DC=доменный контекст. В нём Вы найдёте отдельные контейнеры, название которых соответствует языковому коду – для английского это будет 409, если хотите, чтобы объекты отображались в разных в плане языков консолях Active Directory по разному – просто поправьте не в одном, а в нескольких. Откуда берётся число 409? Это 1033 в hex-варианте, а справочник по кодам языков Вы можете легко найти, никуда не выходя с локальной машины – откройте ключ реестра HKLM\SYSTEM\CurrentControlSet\Control\ContentIndex\Language, там в каждом разделе будет Locale, которое, путём перевода в hex, и даст искомый код. Выглядеть в нашем случае консоль для редактирования этих свойств будет как-то так:

Объект, который мы хотим поправить, имеет класс trustedDomain-display. Откроем вкладку Attribute Editor, и в ней найдём атрибут iconPath. Данный атрибут позволит нам задать до 16 различных картинок, используемых для разных состояний объекта (например, у пользователя разные картинки, когда он в обычном состоянии или в Disabled). Картинку, которую мы поставим, мы заранее выложим в папку \\FQDN домена\SYSVOL\FQDN домена\Pics – этим мы решим вопрос с автоматической репликацией картинки на все контроллеры домена, да и подгружаться она будет с ближайшего, что тоже плюс.

Нам будет нужна только дефолтная, поэтому мы зададим путь к картинке номер нуль для данного типа объектов:

Результат будет таким:

Теперь у этого типа объектов своя, хорошо заметная картинка. Она будет автоматически появляться в любой консоли Active Directory Users & Computers. Ничего дописывать не надо, никаких хаков не делается, всё штатно, централизовано и удобно. Переустановка “глючного домена” отменяется.

История вторая – Как Вася в алкоголе запутался

Однажды к одному CIO пришёл руководитель IT-департамента.

– Помнишь Васю, которому мы обещали проставиться?

– Конечно помню.

– Вот и я помню. А если забудем? Надо как-то сделать так, чтобы такое не забылось. Иначе мы потеряем лицо.

– Ты не поверишь – но это – встроенная возможность Active Directory

Последовательность действий

В схеме Active Directory есть штатный атрибут drink – его описание выглядит как “The drink (Favourite Drink) attribute type specifies the favorite drink of an object (or person)”.

Это пачка текстовых строк в Unicode, которая благоразумно не добавлена в объект user по умолчанию. Мы её добавим – сделать это несложно:

  • Зарегистрируем оснастку для редактирования схемы Active Directory – выполнив команду regsvr32 schmmgmt.dll
  • Откроем новый экземпляр mmc, добавим туда оснастку Active Directory Schema, и найдём там в контейнере Classes класс user
  • Далее на вкладке Attributes добавим данный атрибут к пользователю

Закроем оснастку Active Directory Schema, т.к. она нам больше не понадобится, и откроем ADSI, чтобы теперь добавить этот замечательный атрибут в GUI оснастки Active Directory Users & Computers. Путь наш будет лежать туда же, как и в прошлой истории – в контейнер CN=код языка,CN=Display Specifiers,CN=Configuration в лесу Active Directory. Мы выберем тот тип контейнеров, при просмотре которых у нашего пользователя должны выводиться дополнительные атрибуты – например, OU; называться он будет organizationalUnit-Display, а интересовать нас в нём будет атрибут extraColumns:

Формат добавления строки достаточно прост:

  • Название атрибута
  • Заголовок колонки с атрибутом
  • Будет ли отображаться по умолчанию (мы поставим единицу)
  • Ширина колонки в пикселях (если поставить -1, будет подобрана автоматически)
  • Зарезервированное на будущее значение, ставим нуль

Таких строк, как понятно, можно добавить несколько – всё зависит от того, что Вам конкретно надо отображать в первую очередь. Это удобнее, чем каждый раз кликать на пользователе, чтобы просмотреть нужный атрибут, отсутствующий в консоли Active Directory Users & Computers по умолчанию.

Как понятно, и тип родительского контейнера, и тип объекта, и атрибут можно менять произвольно – плюсом будет то, что это не потребует никакой модификации стандартной консоли и будет сразу работать “из коробки” во всей организации.

История третья – Как Васе правозащитники помогали

Однажды к одному CIO пришёл руководитель IT-департамента.

– Слышал вчера вопли у sales’ов. Михась орал на какого-то своего, мол, “Какое ты имеешь право пить на работе, скотина?”

– Да, работать в такой ситуации невозможно. Ведь администратору Active Directory непонятно по учётной записи пользователя, имеет ли он право пить на работе или нет. Отсюда непонимание, а это – корень всех бед в коллективе. Надо исправлять.

Последовательность действий

Типы прав в Active Directory – динамическая структура, поэтому мы добавим нужное нам право. Откроем ADSI и зайдём в контейнер CN=Extended-Rights,CN=Configuration в нашем лесу Active Directory.

Мы создадим новый пустой экземпляр объекта класса controlAccessRight и назовём его предсказуемо:

Какие же нам надо будет задать атрибуты, чтобы всё заработало? Их не очень много.

Привязка к типу объектов

Мы хотим, чтобы это право было у пользователя – открываем ADSI, зацепляемся за схему, находим там classSchema с названием User, и копируем у него атрибут schemaIDGUID:

Этот GUID будет bf967aba-0de6-11d0-a285-00aa003049e2; мы добавим его в атрибут appliesTo у нашего нового типа прав:

Этого хватит – нам же не нужно, чтобы контроллер домена имел право бухать на работе.

Читаемое имя

В атрибут displayName нам надо будет добавить то, что будет выводиться при просмотре ACL штатными средствами – т.е. “человеческое” название этого права.

GUID права

Чтобы клиентский софт мог запросить у системы состояние данного права у конкретного объекта, надо задать атрибут rightsGUID. Требования простые – не совпадать с другими, поэтому я взял один из GUID’ов от других прав и поправил, чтобы не было претензий со стороны Минздрава:

Включаем

Осталось только сказать, что это всё может работать – для этого в атрибут validAccesses запишем 256 – это включит 9й бит, и мы наконец-то увидим плоды нашей работы.

Сделали? Смотрим.

Теперь сотрудника Василия никто не упрекнёт, что он не может бухать на работе – может. Ну, а какое применение такой возможности он найдёт, да и Вы – тут уж сами думайте.

История четвертая – Родная сеть родного предприятия

Однажды к одному CIO пришёл руководитель IT-департамента.

– Никто не любит сотрудников техподдержки так, как люблю их я. Их, этих воинов переднего края, этот штрафбат духа и знаний, этот…

– Ты по делу, наверное?

– Да, есть косяк. Состоит он в том, что людям неудобно понимать, когда доменная машина “увидела сетку”, а когда – нет. Просветлённые понимают, а у остальных столько духовности, что их предположения “видит комп доменную сетку или вроде нет” заставляют меня потерять веру в человечество. А ведь без веры нельзя жить.

– Понимаю. Устроит ли ситуация, когда факт нахождения в доменной сети будет идентифироваться путём отображения на сетевом интерфейсе логотипа фирмы с соответствующей подписью?

– Вполне.

 

Последовательность действий

В момент, когда Windows подключается к новой сети, пользователю предлагается выбор – домашняя ли это сеть, рабочая или “внешняя”-гостевая. В зависимости от того, что выберет пользователь, будут установлены настройки общего доступа, а также ряд других параметров. Во что ткнёт пользователь – неизвестно. Отсюда “Подключение по локальной сети 5″ с картинкой домика, а впоследствии – вагон разных сетей с жуткими именами и невнятными задачами – поди вспомни, откуда это подключение номер пять взялось – то ли когда в Макдоналдсе сидел, то ли когда дома роутер купил и в него переподключился. Для сотрудников техподдержки же крайне желательно, чтобы можно было задать вопрос “В какой Вы сейчас сети?” и получить относительно вменяемый ответ.

Для начала мы возьмём откуда-нибудь иконку с логотипом нашей организации. Ей хватит размера 64×64 пикселя. Я буду использовать этот файл для примера:

Теперь можно открыть объект групповой политики, действующий на доменные компьютеры, на которых нужно изменить отображение и логику определения сетей, и зайти там в следующий раздел:

Computer Configuration / Policies / Windows Settings / Security Settings / Network List Manager Policies

Так как я редактирую политики с рабочей станции, которая уже находится в домене (что, в общем-то, логично), то картинка будет выглядеть примерно так:

Три строчки из четырёх – это Unidentified Networks, Identifying Networks, All Networks – стандартные, а четвёртая – мой тестовый домен domain7.local. Для начала, поменяем настройки для стандартных объектов.

Настройки для Unidentified Networks

Здесь будет две настройки – Location Type и User Permissions. Первая будет обозначать то, как будет трактоваться местоположение для неизвестных сетей – как частная сеть (Private), общедоступная (Public) либо отдаваться на откуп локальному пользователю (т.е. у него при подключении новой сети будет то самое окно с выбором из 3х вариантов типов сетей – домашней, предприятия или общедоступной). Мы выставим их так – Location Type сделаем Public, а пользователю запретим менять тип Unidentified сети (User cannot change location). Это отсечёт ситуации, когда пользователь неверно определит тип сети (допустим, в кафе поставит сеть как домашнюю), что ощутимо снизит уровень безопасности (например, появится возможность обнаружения других устройств, да и возможности в плане общего доступа к ресурсам, которые никак не нужны в сети кафе).

Настройки для Identifying Networks

Это те сети, которые находятся “в процессе” идентификации. Визуально это рисуется анимацией на иконке подключения, занимает обычно некоторое количество секунд. Настройка здесь одна – “как трактовать тип сети, находящейся в этой фазе”. Почему она важна? Потому что если пользователь хоть раз выбирал вручную тип новой сети, добрая операционная система дала ему возможность выставить галку вида “… И все дальнейшие новые сети считать такими же, как ты выбрал сейчас”. Это уязвимость, потому что ситуация может быть простой – человек дома поставил новый роутер, ОС повторно “нашла” локальную сеть, предложила выбрать – человек выбрал, что сеть доверенная, домашняя, и нажал галку “больше меня не спрашивай, остальные неизвестные сети такие же”. В результате, когда он пойдёт в кафе, где есть Wifi, у него сеть, будучи в процессе Identifying, будет трактоваться как домашняя, давая излишние возможности его соседям по IP-диапазону. Мы выставим этот параметр как Public – т.е. любая сеть, которая “в процессе определения”, будет по определению общедоступной, внешней, и к ней будут применяться максимальные ограничения по совместной работе и доступу к соседским ресурсам.

Настройки для All Networks

Это общие настройки для всех сетей. Логика их действия простая – если что-то не зафиксировано администратором, то это можно изменять пользователю. Так как речь идёт о рабочей системе, то такие настройки неправильные. Мы явно определим сеть предприятия, если надо – так же, через политики, раздадим настройки беспроводных сетей. Пользователю не нужно ничего менять. Соответственно, мы выставляем следующие настройки:

Теперь пришла очередь настроить отображение и настройки нашей, доменной сети.

Настройки для родной сети предприятия

Их будет четыре, и они будут распределены по двум вкладкам. Можно будет задать картинку, имя сети, и права пользователей на смену картинки и имени. Права мы, конечно, отнимем, а название сети и картинку сменим:

Важный момент – картинку мы будем хранить в SYSVOL’е и задавать её местоположение тоже через UNC. Поэтому наши доменные рабочие станции будут забирать картинку с ближайшего SYSVOL, реплицироваться она будет автоматически, и её не надо будет никуда копировать вручную:

Выводы

Задача решена – теперь определить тип сети визуально что сотрудникам, что IT-товарищам из техподдержки стало проще.

Повысилась безопасность – пользователь не может объявить все сети домашними и таким образом ослабить защиту своего хоста. Мелочь, никакого шаманства и кодинга, а из таких мелочей состоит то, что с точки зрения ряда восточных практик отличает работу от искусства. ActiveDirectory-до лучше, чем ActiveDirectory-дзюцу.

Возможностей, которые предоставляет Active Directory – масса. Главное – знания.

Удач.

WBR, Ruslan V. Karmanov

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.