Проектирование схемы именования объектов

В любой серьезной ИТ-инфраструктуре и проектах, связанных с её созданием и модернизацией, присутсвуют соглашения об именовании объектов. Однако, собранных в одном месте лучших практик по этой теме я не нашел ни в русских интернетах, ни в заграничных.

В этой статье я попытаюсь восполнить сей пробел и изложу своё видение и подход к проектированию схем именования: учетных записей пользователей и групп, компьютеров, сетевых устройств и других объектов в Active Directory.

Предложенные варианты схем основаны на личном проектном опыте и в результате анализа достоинств и недостатков в ИТ-инфраструктурах, которые приходилось встречать.

Я приведу аргументы практически для каждого решения, принятого при проектировании предлагаемых ниже схем. Буду рад увидеть альтернативные мнения в комментариях.

Содержание:

• Поиск по неполным данным
• Учетные записи пользователей
• Группы
• Сетевые устройства
• Организационные подразделения
• Другие объекты
• Годные ссылки

Поиск по неполным данным

Одной из замечательных возможностей AD является поиск по неполным данным. Прелесть его в том, что для выбора нужного нам объекта (пользователя, компьютера, группы) можно просто ввести несколько начальных символов из его имени. Если подходящих объектов будет найдено несколько, предоставят возможность выбрать тот объект, который нужен. Поиск по неполным данным может очень сильно облегчить выполнение регулярных задач по администрированию AD… Если атрибуты AD заполнены удобным, стандартизированным и структурированным образом.

Приведенные в этой статье рекомендации по именованию объектов учитывают особенности неполного поиска в AD таким образом, чтобы пользу от него можно было использовать в большинстве случаев.

Учетные записи пользователей

Логины

В среде AD в качестве логина могут использоваться 2 формата:

• User Principal Name (UPN) [userPrincipalName]: upnlogin@argnon.pro
• User logon name (pre-Windows 2000) [sAMAccountName]: argon\samlogin

Имеется возможность для учётки пользователя задать разные значения upnlogin и samlogin, однако это не практично, если того не требуют особые обстоятельства. Далее по тексту под словом «логин» я буду понимать одинаковое значение для атрибутов userPrincipalName и sAMAccountName.

Примечание

В неполном поиске участвует только sAMAccountName.

При создании схемы именования учетных записей пользователей разумно в первую очередь учитывать следующие критерии:

• удобство для администраторов — организация, сортировка и поиск учетных записей
• удобство для пользователей — запоминаемость, читаемость, возможность продиктовать по телефону
• совместимость — возможность работы с широким спектром устройств и приложений.

Всем вышеперечисленным требованиям удовлетворяет следующая схема:

• только латинские буквы — чтобы избежать проблем со сторонними (например, Linux Samba Server) и не очень (даже Remote Desktop Gateway, входящий в Windows Server 2008 R2 не работает, если встретит не латинские буквы в логине) приложениями, а также с аппаратурой (отсутствие русской раскладки, поддержки кодировки).
• не более 10 букв — для случаев ввода с не очень удобных устройств (мобильников, экранных клавиатур)
• содержать в себе фрагменты имени и фамилии хозяина — для удобства идентификации учётки с конкретным пользователем.

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

• личный — основанный на именах
• обезличенный — основанный на табельных номерах и прочих идентифицирующих данных

Некоторых мазохистов может привлекать обезличенный способ именования логинов своей стандартностью и предсказуемостью. В логине вида mza-t90361 можно закодировать массу информации, однако пользы от этого не будет никому, а неудобств доставит массу:

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

Итак, надеюсь, я показал, почему считаю обезличенную схему именования учёток пользователей неудачной. Далее я приведу свой ход рассуждений по созданию более удачной, «личной» схемы именования.

При формировании логина на основании имени и фамилии пользователя тоже возникают трудности. Ныне популярна такая схема именования:

<Имя>.<Фамилия> [Игорь Романовский → Igor.Romanovsky]

Согласен, выглядит красиво, однако, возникнут проблемы:

• с длинными именами и фамилиями [Иннокентий Петропавловский → Innokenty.Petropavlovsky]
• с трудностями однозначной транслитерации [Евгений Дряхлых → Eugene Dryakhlykh и еще массы вариантов]

Выход — сокращать логин, например, так:

<1я-буква-имени><часть-фамилии> [Евгений Баев → ebaev]

<часть-фамилии><1я-буква-имени> [Алексей Бармин → barmina]

Выше показаны несчастные случаи, когда сочетание буквы имени и фамилии дает результат, который вряд ли понравится владельцу логина, и объяснения про унификацию логинов вряд ли станут утешением.

Возможный выход из ситуации — как-то разделять фрагменты имени и фамилии, например, точкой:

<1я-буква-имени>.<часть-фамилии> [Игорь Романовский → i.rom]

Этот вариант мне очень нравится, но все же имеет следующие недостатки:

• точка занимает лишний символ в логине
• рады видеть точку в логине не все люди (не ожидают и переспрашивают) и устройства (например, при вводе с телефона, она либо не предполагается, либо где-то очень далеко спрятана)
• проблема с коллизиями в именах учеток (для разных людей создается один и тот же логин) не решается очевидным образом

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

<часть-имени><часть-фамилии> [Алексей Волков → alvol, Фёдор Бондарчук → fbond, Феликс Бунин → felixb]

Прелесть схемы в том, что части имени и фамилии выбираются так, чтобы:

• выглядело благовидно
• избежать коллизии
• логин оставался кратким

Я был очень приятно удивлен, когда узнал, что логины в компании Microsoft формируются именно по такой схеме.

Служебные логины

Общепризнанной лучшей практикой является использование отдельных учетных записей для выполнения административных задач. При выполнении этой рекомендации часто можно встретить такую крайность:

• на предприятии используются несколько обезличенных «ролевых» учетных записей типа Administrator, NetAdmin, WebAdmin, TechSupport…
• ими пользуется куча народа, исполняющего соответствующие роли

Печальность ситуации в том, что при коллективном использовании «ролевой» учетки личность реального пользователя установить затруднительно. Не трудно представить ситуации саботажа, разглашения паролей и прочих неприятностей, в которых виноватого не найти.

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

• использовать отдельные личные учетки для выполнении административных задач, с логинами вида a-login, где вместо login — обычный логин данного пользователя
• привилегии на выполнение административных операций всегда назначать на уровне ролевых групп безопасности

Display Name

Значение атрибута displayName учетной записи отображается в заголовке меню Пуск вошедшего в систему пользователя, в контактах адресной книги Exchange, в поле От исходящих почтовых сообщений и во многих других местах, где требуется отобразить «дружественное» имя.

При создании пользователя в Active Directory предлагается заполнить поля имени, инициалов и фамилии. На основе этих данных предлагается значение атрибута Display Name по следующей схеме:

<Firstname> <Initials>. <Lastname>

Примечание

Путем редактирования некоторых параметров в AD эту схему можно изменить (например, на Lastname, Firstname), но на то нет веских причин. Советские времена, когда к людям было принято обращаться тов. Фамилия прошли, в современном деловом обществе принято обращаться по Имя Фамилия.

Для Display Name можно задать произвольное значение, что удобно:

• для служебных учетных записей, которые не имеют имён и фамилий
• если в поле AD «имя» введено Имя Отчество(так как под отчество нет отдельного поля), а отображать нужно в формате Имя Фамилия

Full Name

В момент создания пользователя значение Display Name присваивается другому атрибуту пользователя — cn (Canonical Name, часто он упомиается как Full Name). Значение cn широко используется в Active Directory:

• является частью фундаментального атрибута distinguishedName, который представляет собой путь к объекту в пределах AD (CN=Firstname Lastname,OU=Test Accounts,DC=argon,DC=pro), из него же формируется Canonical Name (argon.pro/Test Accounts/Firstname Lastname)
• именно это имя отображается в поле Full Name в оснастке Active Directory Users and Computers
• по этому параметру выполняется неполный поиск объектов в AD

Стоит обратить внимания на следующие особенности:

• атрибуты Display Name и Full Name напрямую не связаны, и после создания учетки их можно редактировать как угодно
• значение Full Name должно быть уникальным в пределах своего Organization Unit, к Display Name таких требований не предъявляется
• оба значения Display Name и Full Name следует держать согласованными, если нет необходимости в обратном, для чего редактирования первого нужно аналогично отредактировать и второе значение.

Группы

На имена групп нет таких строгих ограничений, как на логины, но есть смысл придерживаться схожих правил:

• избегать нелатинских символов и пробелов
• стремиться к кратким названиям

В дополнение к вышеперечисленному, удобно, чтобы имена групп соответствовали следующим характеристикам:

• чем-то явно отличались от логинов
• отражали назначение группы (например, из имен Техподдержка и Бухгалтерия не понять, что есть группа безопасности, а что — группа рассылки)
• признаки, содержащиеся в имени, следовали в порядке значимости (например, ExchangeAdmins и ExchangeHelpdesk, а не Администраторы Exchange и Техническая поддержка Exchange)

При этом, включать в имя группы признак её области действия (локальная, глобальная, универсальная) нет необходимости по следующим причинам:

• часто область действия группы можно безболезненно конвертировать
• практически во всех отображениях имеется столбец области действия

Итак, я предлагаю следующую схему именования групп:

g<p>-<Name>

где:

• g — признак отличия имени группы от логина
• p — назначение группы, принимает значения:
  • f — функциональная
  • r — ресурсная
  • d — распространения
  • a — административная
• Name — собственно, имя группы; при необходимости, содержит признаки принадлежности к области действия, например:
  • GlobHelpdesk
  • MscPrinters

Пример имён групп:

• gf-Operators
• gr-ProjectDocs
• gd-AllCompany
• ga-Helpdesk

Примечание

Назначение группы определяется ролевой моделью привилегий (также известной как UGLP), в которой:

• пользователи включаются в глобальные группы (функциональные), в соответствии с выполняемыми ролями
• разрешения на ресурсы назначаются локальным группам (ресурсным)
• в состав ресурсных групп включаются ролевые группы
• при необходимости, на более высоком иерархическом уровне используются универсальные группы, в которые включают глобальные группы
• отдельно выделяются административные группы и группы рассылки

Для групп рассылки есть замечательный атрибут Display Name, который позволяет отображать «человеческое» имя в адресной книге, а также произносить ее голосом в Exchange UM, и одновременно с этим не уходить от общей конвенции именования групп.

Сетевые устройства

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

Примеры неудачных имен с попыткой их расшифровать и комментариями:

• SR-PSSRV001 (сервер-принт-сервер-сервер-номер001) — слово «сервер» закодировано 3 раза, порядковый номер 3-разрядный, хотя таких серверов всего 2 штуки
• SR-msExch04 (сервер, почтовый сервер-эксчендж сервер-номер04) — многократно закодировано слово «сервер», но нет данных о его размещении
• W-430400764 (рабочая станция-43регион, офис 04, инвентарный номер 00764) — без таблицы — не найти!
• МАШЕНЬКА-ПК (без комментариев)

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

• нелатинские символы исключены
• имя должно содержать некие признаки, которые позволяют удобно классифицировать устойства
• классификационные признаки должны следовать в порядке значимости
• имя должно быть достаточно описательным, чтобы свести к минимуму обращения к таблицам для идентификации устройства
• если требуется совместимость с Netbios, длину имени следует ограничить 15 символами

А вот и схема:

<Site>-<Class>-<[Type]Name[Number]>

• Site — признак расположения компьютера (определение сайта в терминологии AD вполне подходит), такие как HQ, NOC, MSC, KZN и прочее.
• Class — класс устройства, например:
  • SR — сервер
  • WS — рабочая станция
  • MB — мобильное устройство
  • DV — другое сетевое устройство
• Type — опциональное дальнейшее уточнение назначения устройства (зависит от класса), например:
  • DC — контроллер домена
  • PR — принтер
  • DT — десктоп
  • LT — ноутбук
• Name — имя устройства, краткое и описательное, например:
  • ExMB — сервер почтовых ящиков Exchange
  • Gate — шлюз
  • Proxy — …
• Number — опциональный номер, если подобных устройств несколько. Разрядность номера следует планировать заранее, но и фиксировать количество разрядов для абсолютно всех устройств не стоит, так большая разрядность уместна в редких случаях, а в большинстве случаев достаточно номера в пределах десятка.

Примеры имен, образованных по такой схеме:

• NOC-SR-DCLAB18 (сайт NOC, сервер, контроллер домена LAB, номер 18)
• MSC-SR-MONITOR (сайт MSC, сервер, занимается мониторингом)
• NOC-CL-HV4 (сайт NOC, кластер Hyper-V, номер 4)
• NOC-CL-HV4-N7 (сайт NOC, кластер Hyper-V номер 4, узел номер 7)
• HQ-SR-EXMB3 (сайт HQ, cервер, Exchange c ролью Mailbox, номер 3)
• KOS-WS-DTFIN06 (сайт KOS, рабочая станция, настольная, финансовый отдел, номер 06)
• EXT-WS-LTIROM (внешний сайт, рабочая станция, ноутбук пользователя с логином irom)
• NOC-DV-ROUTER12 (сайт NOC, устройство, маршрутизатор, номер 12)
• EXT-MD-WMIROM (внешний сайт, мобильное устройство, windows mobile пользователя с логином irom)

Организационные подразделения

Существующих несколько моделей построения структуры OU и делегирования. Здесь я не буду пытаться описать их все, это хорошо сделано в более серьёзной литературе.

Из всех популярных моделей я рекомендую использовать административную модель построения OU, которая призвана обеспечить наибольшее удобство для, как можно догадаться, задач администрирования:

• объединения объектов признакам
• делегирования полномочий
• назначения групповых политик
• эффективного использования возможностей наследования

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

• противоречива и изменчива
• не применима к управлению ИТ-инфраструктурой

Я предлагаю строить структуру OU по следующей концепции:

• Создавать структуру OU исходя в первую очередь из удобства делегирования полномочий.
• Для тонкого назначения групповых политик на пользователей, рабочие станции и сервера использовать ролевую модель, основанную на членстве в группах в безопасности. Не эффективно пытаться строить ролевую модель на OU. Непременно найдутся объекты, которые исполняют несколько ролей, но архитектура AD предусматривает членство объекта только в одном OU.

При этом придерживаться следующих технических особенностей:

• в именах OU не использовать нелатинских символов и пробелов
• придерживаться принципов краткости и не избыточности
• умеренно использовать иерархию (глубокая вложенность замедляет выполнение некоторых операций)
• активно пользоваться полем Description
• избегать использования встроенных контейнеров Users и Computers для хранения в них объектов, назначения политик
• не создавать своих контейнеров (куда-то вложенных) с именами Users и Computers — могут быть проблемы совместимости

Пример структуры OU, который следует вышеизложенным рекомендациям:

• lab.argon.pro — домен
  • Company – сразу отделяем наше дерево иерархии от встроенных объектов AD
    • Global
    • Kazan
    • Kirov– уровень территориальной принадлежности
      • Services – служебные пользователи и группы, управляет которыми только IT-отдел
      • Comps – компьютеры: сервера и рабочие станции
      • Accounts – учетные записи и группы рядовых пользователей, управление которыми можно делегировать простым пользователям (конечно, через другие группы безопасности, прав на управление которыми у данного пользователя не будет)
    • Moscow

Другие объекты

К остальные объектам, требующим внимательного назначения имен, таким как: сайты, объекты групповых политик и т. п. тоже применимы большинство рекомендаций, описанных в этой статье. Вкратце:

• совместимость
• не избыточность и краткость
• простота и наглядность
• наличие признаков группировки, идущих в порядке значимости

[To be continued and edited…]

Годные ссылки

• The 12 Mighty Chores of Active Directory Administration in Depth
• Оптимизация AD: Cтруктура орг. подразделений(OU) служит для делегирования прав и назначения групповых политик
• RFC 2142 — Mailbox Names for Common Services, Roles and Functions