Базовые принципы Active Directory

Все слышали, все знают, но вот "на пальцах" рассказать что же это такое и с чем его едят, думаю, сможет далеко не каждый. Назначение Active Directory - единое информационное пространство для сквозной авторизации различных ресурсов. Например, пользователя, желающего войти на определенную рабочую станцию тоже нужно как-то идентифицировать, аутентифицировать, и подумать, давать ему вход, или нет. Другими словами идеология AD ходит вокруг да около каталога пользователей и машин, попутно совмещая побочные функции, как то, адресная книга, управление политиками, правами и хранение других различных атрибутов. Слово Directory уже говорит само за себя, это в первую очередь каталог, каталог учетных записей пользователей и учетных записей машин, Active говорит о том, что каталог "активный", постоянно пополняемый, обновляемый, да и вообще живущий своей жизнью.

Так сложилось в уме разрабочиков, что наиболее подходящей технологией для хранения аккаунтов машин, их IP адресов и прочей описательной информации является технология DNS, что позволяет также мягко ложиться AD с абстрактного на сетевой уровень представления, строить из доменов узлы, деревья, леса. Так сложилось исторически, что понятие домена в AD и домен в DNS вроде и называются одинаково, вроде бы одно и то же, но на самом деле это лишь небольшое заблуждение. И действительно при создании нового домена мы должны задать два названия: полное DNS имя домена и краткое название. Я бы не советовал задавать полное имя, как это делает Microsoft, совпадающее с вашим честным внешним доменом, т.е. it-link.com.ua не самое лучшее название, т.к. любые записи в домене, скажем для веб-сервера, которые должны быть доступны публично (если вы даже настроите репликацию зоны на внешние DNS сервера) потянут за собой необходимость публикации ВСЕХ записей домена, что приведет к раскрытию нежелательной информации публично, зачем кому-то знать диапазоны IP адресов и названий компании? Таким образом выберем название, которого точно нет в мире, скажем, в нашем примере было бы резонно выбрать название it-link.kiev, т.к. зоны kiev точно нет в публичных серверах, и название отражает местоположение домена (конечно, если у вас домен международный, нет смысла в использовании такого названия). Короткое название можно выбрать по первому слову до точки, скажем, it-link подойдет. Именно это название будет отражено в выпадающих списках доменов в окнах для входа в систему. Что происходит в тот момент, когда мы "присоединяем" компьютер к домену? Первое что происходит: создается учетная запись компьютера в домене, которую вы сможете обнаружить в "Domain->Computers", ключевым параметром и уникальным идентификатором компьютера является его SID (Security ID) вот почему при клонировании компьютера нам необходимо обнулять SID и переподсоединять к домену. Вторым этапом создаются криптованные ключи (тикеты, билеты), которые будут использоваться в "разговоре" контроллер домена-компьютер. Криптованный протокол, по которому они будут общаться и есть пресловутый Kerberos5, затем компьютер получает дополнительные параметры и настройки указанные для аккаунта в домене и применяет их на себя. Примером таких политик может быть: установка ПО, настройки путей ключевых программ, настройки безопасности, фаервола, апдейтов и прочее. Таким образом AD позволяет накладывать определенные политики на компьютеры, собранные по какому-либо принципу в одной "Организационной единице" OU, аналог папки в файловой системе. Например, все клиенствкие машины будут в одном OU, а все серверы - в отдельном OU с более жесткими настройками безопасности. Имя компьютера которое мы выбираем при инсталляции системы будет прописано в аккаунте компьютера в AD, а также динамически в DNS, где будет сопоставлен IP адрес, например, мы выбрали при инсталляции имя "NEXUS", ip адрес 192.168.0.48 (не важно каким образом мы получили адрес, по DHCP, или нет), то в DNS записях домена автоматически появится запись "nexus in a 192.168.0.48". При удалении аккаунта также будет удален адрес и из DNS.

Удаленные офисы.

Но вот сложилась ситуация, когда мы имеем удаленный офис с каналом связи не самого лучшего качества, и мы хотим давать пользователям в этом офисе возможность доступа к ресурсам главного офиса также со сквозной авторизацией. В этом случае нам на помощь приходит дополнительный контроллер домена, который будет хранить полную копию записей главного контроллера домена, и будет периодически синхронизировать с основным по выбранным нами протоколам. Протоколов этих всего три, первый, который и стоит по умолчанию RPC протокол (remote procedure call), так же есть возможность выбрать IP, либо SMTP протокол (в случае наличия разнородных сетей). Текущее состояние синхронизации домена определяется уникальным числом UID, которое с каждым изменением в AD увеличивается, и служит для отслеживания изменений записей и проведения стабильной синхронизации. Допустим произошел сбой в канале связи, два-три часа контроллеры домена между собой не "разговаривали", и у того и у другого в домене зафиксированы изменения в записях (добавлены аккаунты, удалены некоторые записи) так вот именно при помощи UID домены определят какая из записей "посвежее". Также имеет смысл ставить дополнительный контроллер домена рядом с основным еще в двух случаях: обеспечить бесперебойность работы контроллеров домена, когда один выходит из строя - второй будет выполнять его функцию. И в случае, если главный контроллер домена испытывает очень большую нагрузку на Directory, тогда дополнительный контроллер также участвует в обслуживании клиентских запросов и снижает нагрузку на основной контроллер в половину.

Когда использовать дочерние домены и доверительные отношения?

Бывают ситуации, когда уже есть домен дружественной организации, либо тестовой лаборатории, где необходимо иметь свое адресное пространство, свои IP адреса, имена, аккаунты, политики безопасности. Но также мы хотим, что бы члены этого домена имели полный доступ к записям и ресурсам нашего главного домена. Тогда мы установим т.н. доверительные отношения между доменами, т.е. мы скажем, что этому домену мы доверяем, а этот домен доверяет нам. Также у нас будет возможность выбора домена для входа на клиентских машинах, там где обычно в выпадающем списке находится домен у нас появится возможность выбрать и другой домен для входа. Дочерние домены представляют собой приблизительно такие же доверительные отношения, за исключением того, что дочки будут управляться родительскими контроллерами домена, иметь свои поддоменные имена и будут объединены в "дерево". Деревья могут объединяться в лес, но случай этот, думается мне, встречается крайне редко, в очень уж больших и распределенных организациях типа самой Microsoft :)

Схема домена.

Каждая запись пользователя имеет определенный набор полей, логин, пароль, ФИО, адрес, почтовый адрес, веб-страница и так далее. Список полей строго определен и называется схемой Active Directory. Схема Active Directory может быть изменена в одностороннем порядке, т.е. дополнить полями ее можно, а удалить нельзя, поэтому необходимо очень тщательно относиться к расширению схемы. Расширение схемы повлияет также и на объем баз AD и на время репликации. Некоторые системы требуют для своей работы AD, и расширяют его схему, дополняя полями, например Microsoft Exchange дополнит полями e-mail адресов, алиасов и прочей информацией карточку пользователя. К таким продуктам относятся Microsoft Systems Management Server, Microsoft Operations Manager, Veritas Storage Central и другие.

Выводы: при большом количестве пользователей и компьютеров в организации без AD не обойтись. Спасибо дяде Биллу за хорошую реализацию AD. Не могу не сказать о том, как с этим обстоят дела у Линуксов. А у Линуксов было, ага, OpenLDAP называется, по-моему остутствуют графические инструменты работы с Directory, и рулит командная строка, пусть линукс-гуру меня поправят, если это не так.