Создание централизованной AD. Стандарты именования объектов. Часть 1

Перед тем как мигрировать объекты из старых доменов в новый, необходимо было придумать стандарты именований объектов Active Directory, таких как рабочие станции, серверы, группы, учетные записи пользователей и орг. юниты. Когда мы приходим к единой доменной структуре, нам нужны универсальные стандарты имен для всех площадок (филиалов). То, как именовались объекты в старых доменах нас абсолютно не устраивало. Тем более что в каждом домене именование было по предпочтениям местных администраторов и не было единого принципа. Начнем по порядку:

Рабочие станции:
Имена рабочих станций не должны быть привязаны ни к должности сотрудника, ни тем более к его имени. Рабочие станции должны быть привязаны к их физическому расположению и их принадлежности к тому или иному подразделению, филиалу, управлению, назовем это логической принадлежностью.
Начнем с привязки по физике. Можно разными способами обозначать площадку в имени рабочей станции, на которой находится компьютер. Мы выбрали кодирование площадки цифрами. Далее будет понятно, почему. Как это выглядит. Например, у Вас есть филиалы в Москве, Санкт-Петербурге и Ростове. Мы кодируем цифрами города, в которых находятся офисы.

Например:
Москва - 100
Санкт-Петербург - 200
Ростов - 300

Довольно легко запомнить. Идем дальше, Москва большая и у нас в ней не один офис, а несколько. Тогда именуем дальше:
Москва, Адрес 1, код: 101
Москва, Адрес 2, код: 102
Москва, Адрес 3, код: 103

В Санкт-Петербурге тоже пара офисов:
Санкт-Петербург, Адрес 1, код 201
Санкт-Петербург, Адрес 2, код 202

В Ростове один офис, значит просто оставляем 300.

Перейдем к логической принадлежности. Для примера рассмотрим ситуацию, когда в Москве у нас находится штаб-квартира (центральный офис, который контролирует работу всех остальных филиалов). Обозначим штаб-квартиру как HQ (Headquarters). Но так же в Москве находятся рабочие станции не относящиеся к HQ, а относящиеся к "рядовым" офисам. Обозначим такую принадлежность как MOS (Moscow). Суть в том, что по одному адресу у нас могут располагаться как компьютеры HQ, так и компьютеры MOS. Такая же ситуация может повторяться и с серверами.

Соответственно получаем следующее:
Москва, Адрес 1, Рабочая станция HQ: HQ101
Москва, Адрес 1, Рабочая станция MOS: MOS101

И так же с другими филиалами. Логическая принадлежность станции может быть к чему угодно (главные управления, штаб-квартиры, дочерние фирмы и прочее). Особенно в крупных компаниях разные сотрудники ответственны за IT-активы в разных филиалах. И так же, например, администраторы MOS не должны иметь доступа к станциям HQ. И так далее. Такое разделение добавляет немало гибкости.

Дальше надо обозначить, что это именно рабочая станция находится на данной площадке, а не сервер или, например, принтер. Значит надо придумать обозначение для рабочей станции. В данном случае все просто, рабочие станции обозначим двумя буквами WS (WorkStation). Плюс, надо различать станции между собой, поэтому вводим сквозную нумерацию внутри каждой площадки (логической и физической). Предполагаем, что на каждой площадке не более 100 компьютеров.

Итак, конечный вариант именования станции:
Москва, Адрес 1, Рабочая станция 1, HQ: HQ101WS001
Москва, Адрес 1, Рабочая станция 1, MOS: MOS101WS001
Москва, Адрес 1, Рабочая станция 2, HQ: HQ101WS002

Санкт-Петербург, Адрес 1, Рабочая станция 1, SPB: SPB201WS001
Санкт-Петербург, Адрес 2, Рабочая станция 1, SPB: SPB202WS001
Санкт-Петербург, Адрес 2, Рабочая станция 2, SPB: SPB202WS002

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

Об именованиях других объектов мы поговорим во второй части.

Сказ о создании централизованной Active Directory. Пролог.

Жила была одна маленькая компания и было у нее несколько филиалов в разных регионах страны и конечно же центральный офис красивенный. В каждом регионе был свой домен, не связанный с доменом в главном офисе. То есть не было даже леса как такового. Между какими-то доменами были доверительные отношения, между другими нет. В каждом домене администраторы делали что хотели. Не было единых политик безопасности, ни единых политик именования учетных записей компьютеров и пользователей, ни единых файловых ресурсов да и вообще еще много чего не было. В каком-то регионе и вовсе не было домена и все жили в рабочей группе. В общем полный коллапс. Но, как-то это все работало и в общем-то всех (или почти всех) устраивало. Но тут пришел новый IT директор, посмотрел на все это безобразие, стукнул кулаком по столу и сказал, что так больше продолжаться не может, пора все менять и сделать по человечески. Взял на работу молодых специалистов, правда никогда подобных проектов не делавших, да еще и в подобных масштабах. Но, хлеба не просят, да и денег особо тоже, глаза горят, опыта набираться хотят и даже сертификаты у них заморские имеются. Авось и сдюжат. Описал он им в общих чертах задачу и отправил эту задачу решать, да побыстрее, а то грядут проекты, которые требуют интеграции с Active Directory. А с текущей структурой даже гвоздя ржавого не интегрируешь. Так и началась работа по созданию единой централизованной Active Directory и последующей миграцией в нее всех пользователей из существующих доменов.

Microsoft AD. О чем пойдет речь.

В данной рубрике я буду писать о Microsoft Active Directory преимущественно на базе Windows Server 2008 R2. Поделюсь своим опытом администрирования и участия в проекте создания централизованной однодоменной структуры из распределенной многодоменной и миграции около 2000 компьютеров из разных доменов в один. В данный момент администрирование AD не является моим приоритетным направлением, но все же иногда приходится этим заниматься, да и вообще есть что рассказать. Надеюсь читателям будет полезно и интересно. К тому же хочется узнать о Вашем опыте, услышать Ваши мнения и советы. Ссылки на наиболее интересные и популярные сообщения/статьи будут помещаться на страницу "Microsoft Active Directory".