Active Directory, пожалуй, самая распространенная и популярная на сегодня служба каталогов. Мы решили немного отступить от обычного формата изложения материала об AD и простым, понятным языком рассказать о довольно сложных вещах, намеренно упростив некоторые моменты. На начальном этапе гораздо важнее иметь цельное представление о предмете и на этом фундаменте углублять свои знания, чем пытаться разобраться в каше из малопонятных вещей.
Active Directory - сложный программный продукт, способный удовлетворить потребности как небольших фирм, так и крупных корпораций, и кажущаяся простота освоения не должна создавать ложного впечатления, что изучение продукта можно ограничить "методом научного тыка" а возникающие проблемы решать по мере их поступления. Да, AD имеет низкий порог вхождения, что позволяет за полчаса методом Next -> Next -> Finish получить вполне работоспособный результат не имея никаких специфических знаний в данной области. Многие материалы для начинающих освещают именно практическую сторону развертывания AD, оставляя без внимания более общие и сложные вещи, как не нужные на данном этапе. Возможно это так, администратору небольшой фирмы нет дела до лесов и доменных деревьев, но по мере роста IT-инфраструктуры эти вопросы появятся на повестке дня и окажется что текущая схема каталога, построенная по принципу "что вижу, о том и пою", не позволяет "малой кровью" провести необходимые изменения и в ряде случаев бывает проще создать инфраструктуру заново.
Поэтому мы считаем, что структуре AD следует уделить самое пристальное внимание и уже с учетом полученных знаний подходить к проектированию службы каталогов на вашем предприятии, ведь видя картину в целом окажется что дремучий лес не настолько уж и дремуч, а решения будут учитывать как текущие, так и будущие задачи с пониманием зачем и почему нужно делать именно так, а не иначе.
Высшим уровнем логической иерархии службы каталогов является лес, лесом называется полностью самостоятельная организации Active Directory, имеющая определенный набор атрибутов и являющаяся периметром безопасности организации. В состав леса могут входить как один, так и несколько доменов. Все объекты создаваемые внутри леса имеют общий набор атрибутов, например объект пользователя содержит имя, фамилию, адрес, телефон, сведения о членстве в группах и т.д., изменяя этот набор мы меняем его для всех объектов леса. Этот набор называется схемой AD, которая описывает все объекты которые мы можем создать и их структуру, схема общая для всего леса.
Чаще всего в пределах одной организации достаточно одного леса, создание схемы с несколькими лесами может понадобиться когда в состав фирмы входят организации имеющие низкий уровень доверия между собой и имеющие абсолютно различные направления деятельности, в каждой из которых свой IT-персонал и своя инфраструктура. Это позволяет надежно изолировать организации друг от друга, оставляя свободу действий внутри каждой из них.
Основой структуры каталога является домен, это административная единица внутри которой действуют свои правила и политики, домен представляет собой еще одну границу безопасности и репликации. Если границу леса можно сравнить с государственной границей, то границы домена представляют границы административных единиц, любой пользователь любого домена может получить доступ к любому объекту другого домена если, конечно, имеет на это права. Репликация (синхронизация каталога между контроллерами домена) также ограничена границами домена, это значит что записи об объектах этого домена будут храниться только в его пределах и не будут доступны администратору другого домена. Это позволяет разграничить полномочия IT-персонала: каждый отдел отвечает за свой домен и ошибки администратора одного из доменов не приведут к выходу из строя всей сети.
Рассмотрим схему AD гипотетической организации. Сначала, когда фирма была небольшая в лесу существовал единственный домен domain.org, который содержал в себе все объекты предприятия: пользователей, группы, сервера, компьютеры, ресурсы.
Постепенно фирма развивается и возникает необходимость выделить отдельно региональные подразделения, допустим российское и украинское, текущее подразделение будет выполнять административные функции и также должно управляться отдельно. Нет проблем, создаем еще два домена: ru.domain.org и ua.domain.org, которые имеют с корневым доменом общее пространство имен, получившая схема носит название дерева доменов. В свою очередь в пространстве имен региональных доменов можно создать домены для более мелких подразделений, например spb.ru.domain.org.
Следует запомнить одну важную вещь: все домены в лесу равноправны и автономны, вне зависимости от их положения в дереве. Это значит, что домены вида ru.domain.org, хоть и входят в адресное пространство domain.org, никоим образом от него не зависят, никаких настроек и политик не наследуют и администраторы корневого домена не имеют доступа к управлению поддоменами.
Что дает выделение подразделений в отдельные домены? Прежде всего безопасность, пользователи имеют доступ только к ресурсам своего домена, учетные записи хранятся только на "своих" контроллерах, администраторы могут настраивать политики не оглядываясь на другие отделы и подразделения и, в тоже время, не опасаясь что неудачные эксперименты другого IT-отдела приведут к неработоспособности сети.
Со временем в организации появляется подразделение не связанное с основным видом деятельности, например своя транспортная компания или служба техподдержки, которая обслуживает как предприятие, так и сторонних клиентов. Для нее создается отдельный домен в отдельном пространстве имен office.com, точно также мы можем выделить в отдельный домен некую структурную единицу данного подразделения, например ou.office.com. Таким образом мы создадим новое дерево доменов в текущем лесу.
Почему новое дерево? Просто так удобнее, иной вид деятельности, иное пространство имен. Как мы уже говорили, расположение домена в лесу никак не влияет на его настройки и взаимодействие с другими доменами, поэтому строить одно разветвленное дерево доменов или несколько отдельных вопрос сугубо организационный, обычно структура дерева повторяет структуру компании.
Разобравшись с доменами, перейдем к более глобальным вещам, а именно к глобальному каталогу. Глобальный каталог предназначен для обработки запросов информацией о которых не обладает контроллер домена, например при обращении к ресурсам другого домена или универсальным ресурсам. Глобальный каталог содержит полную копию объектов своего домена и частичную копию объектов всех остальных доменов, какие именно атрибуты объектов включаются в глобальный каталог определяется схемой AD.
Одна из основных функций глобального каталога - поиск объектов, позволяя производить поиск в рамках леса максимально быстро и с минимальным трафиком. Допустим пользователь Иванов Иван из домена office.com ищет компьютер sales1 входящий в домен ua.domain.org, при обычном поиске пришлось бы последовательно опрашивать контроллеры доменов, пока один из них не вернул бы необходимую информацию, реально достаточно одного запроса к глобальному каталогу.
Вторая роль глобального каталога - проверка подлинности пользователя при входе, если контроллер домена не располагает сведениями об учетной записи, например при входе в систему физически находясь в другом домене. Реально глобальный каталог используется при любом входе пользователя в домен и при его недоступности вход будет невозможен.
Почему? Потому что глобальный каталог хранит сведения об универсальных группах, в которые могут входить любые учетные записи леса и разрешения которым могут быть назначены для любого домена. Это важно для работы таких сервисов как Exchange, который при отказе глобального каталога просто перестанет работать. Глобальным каталогом может быть любой контроллер домена или несколько, рекомендуется иметь, как минимум один глобальный каталог в каждом домене, это позволяет снизить трафик между доменами и повысить отказоустойчивость и автономность доменов (пропала связь, отказал сервер и т.д. и т.п.)
Кроме глобального каталога существуют роли называемые мастерами (хозяевами) операций, которые отслеживают уникальность критически важных объектов AD. Например, сразу два администратора решат создать домены с одинаковым именем или внести изменения в схему. Поэтому в каждом лесу существует только один контроллер с ролью хозяина операций и при его недоступности соответствующие действия будут невозможны. Всего существует пять ролей FSMO (flexible single master operation): две для леса и три для каждого домена, сейчас мы не будем их подробно рассматривать, это тематика отдельной статьи, просто коротко перечислим выполняемые ими функции:
- Хозяин именования домена - отслеживает уникальность имен доменов в лесу.
- Хозяин схемы - здесь также все понятно из названия.
- Хозяин инфраструктуры - обеспечивает информацию об объектах другого домена в локальных группах своего домена.
- Хозяин RID - осуществляет выдачу уникальных идентификаторов безопасности (SID), да это те самые записи вида S-1-5-21-165875785-1005667432-441284377-1023.
- Эмулятор PDC - нужен в первую очередь для клиентов ниже Windows 2000, отслеживает блокировки пользователей при ошибках паролей и является эталоном времени домена.
Хозяин именования домена и хозяин схемы одни на весь лес, остальные роли FSMO приходятся по одной на каждый домен. Отказ ролей FSMO не приводит к неработоспособности домена, однако делает невозможным многие операции, фактически переводя домен в режим "только чтение".
На этом мы закончим наш сегодняшний рассказ. Несмотря на то, что затронутая тема весьма обширна, для понимания структуры приведенных знаний вполне достаточно и, на наш взгляд, не стоит излишне усложнять начальную модель. Более подробно об элементах AD мы поговорим позже, когда будем рассматривать конкретные решения.
Наконец закончил очередную статью по Службам каталогов. Данный материал дался очень нелегко и три раза переписывался, хотелось простыми словами, буквально "на пальцах", объяснить весьма сложные веши. При этом выделить основное и не размениваться на малопонятные мелочи, удерживая статью в разумных объемах. Поэтому многие вещи поданы обзорно и весьма упрощенно, кому нужны подробности могут обратиться к документации MS, цель данного материала дать цельную картину для начинающих.
Спасибо за статью. С нетерпением жду продолжения статьи про программный роутер.
Долгожданное продолжение!!!
Спасибо!
Спасибо огромное!
Спасибо большое за такой полезный и нужный материал. Ждем продолжения!
С нетерпением ждал именно этой части статьи про AD. Просто идеально кратко но при этом очень доходчиво передано то, что во многих книгах про AD расписано страниц на сто, отделываясь при этом некими общими понятиями и абстрактными примерами. В статье же напротив, на вполне конкретном примере рассказано об очень важных вещах. СПАСИБО!
P's ну и конечно же поддержу предыдущего читателя: статей о роутере ждем еще :)
Здравствуйте!
Недавно начал разбираться с Microsoft AD. Очень помог ваш материал в понимании "что, и для чего"!
Хотел бы задать следующий вопрос: как создать перемещаемые профили (папки) пользователей, которые входят в домен с машинок под управлением Ubuntu?
Может быть у вас "под рукой" имеется ссылка на подобный материал. Буду очень признателен.
Поздравления, задуманное получилось буквально "на пальцах". Вообще сайт интересный, а вот объем можно и больше. Успехов.
Здравствуйте, могли бы вы показать на практике как создать и настроить AD и службу доменов, или есть у вас подродная инструкция или мануал по развертыванию службы AD, буду благодарен.
Перед тем, как разворачивать AD желательно четко представлять ее архитектуру, сама служба развертывается методом Next-Next-Finish и данный процесс сложностей у подготовленного человека вызвать не должен. Собственно в чем у вас загвоздка?
В организации есть 15компов, сеть настроена через "рабочую группу" хочу настроить AD.
Это понятно что next>next>finish. Просто хочу настроть нормально а не абы как, чтобы все функционировало не боясь того, что какой-нибудь компьютер отвалиться от сети из-за того что что-то не так или криво сделал, ну настроить групповую политику.
Сначала возьмите лист бумаги и нарисуйте логическую схему каталога: подразделения, группы, общие ресурсы, права доступа к ним. Согласуйте полученный результат с руководством, после чего можно будет приступать к развертыванию.
Как бы так мягко сказать...)) начальство не разбирается в компьютеризации, для них, главное есть соединение с главным сервером БД откуда они могу брать\заносить нужную им информацию, а остальное как оно работает и как будит работать их не колышит :-)
В любом случае вам нужно рассказать и показать ему то, что вы собираетесь делать, так как доменная сеть предусматривает принципиально иной подход к разграничению прав и администрированию. Иначе может получится, что у пользователей не окажется прав для чего либо и крайним окажетесь вы. Нам уже встречались случаи "внедрений" AD, где все пользователи имели права доменного администратора.
У вас есть подробная инструкция или мануал по развертыванию AD, или не могли бы дать ссылку, где более-менее подробно написано?? хочу пока что на виртуальной машине по тренероваться.
А что там подробно расписывать? Если вы представляете, что и как хотите сделать - сделаете. Технически развертывание AD - десять минут и пять нажатий мышкой. Я вам еще раз говорю - первична схема (которая на бумаге) и ее согласование с руководством (как минимум понимание последним проблем и возможных сложностей), техническая реализация проблем не составляет.
очень интересная статья для понимания.Сам недавно развернул АД, но есть пробелы в понимании некоторых вещей,хотел бы продолжение статьи.Сейчас есть необходимость соединить свой домен с другим в большой локальной сети пока не знаю как это сделать грамотно.