Что такое Active Directory – как установить и настроить. Поднимаем домен Active Directory (AD)

Будучи хорошо знакомым с малым бизнесом изнутри, меня всегда интересовали следующие вопросы. Объясните, почему сотрудник должен пользоваться на рабочем компьютере тем браузером, который нравится сисадмину? Или взять любое другое программное обеспечение, например, тот же архиватор, почтовый клиент, клиент мгновенных сообщений… Это я плавно намекаю на стандартизацию, причем не по признакам личной симпатии сисадмина, а по признакам достаточности функционала, стоимости обслуживания и поддержки этих программных продуктов. Давайте начнем считать ИТ точной наукой, а не ремеслом, когда каждый делает так, как у него получается. Опять-таки, с этим в малом бизнесе тоже очень много проблем. Представьте, что компания в нелегкое кризисное время меняет нескольких таких администраторов, что в такой ситуации делать бедным пользователям? Постоянно переучиваться?

Давайте посмотрим с другой стороны. Любой руководитель должен понимать, что у него сейчас происходит в компании (в том числе и в ИТ). Это необходимо для отслеживания текущей ситуации, для оперативного реагирования на возникновение разного рода проблем. Но это понимание является более важным для стратегического планирования. Ведь, имея крепкий и надежный фундамент, мы можем строить дом на 3 этажа или на 5, делать крышу разной формы, делать балконы или зимний сад. Точно также и в ИТ, имеем надежную основу – можем в дальнейшем использовать более сложные продукты и технологии для решения бизнес-задач.

В первой статье и пойдет речь о таком фундаменте – службах Active Directory . Именно они призваны стать крепким фундаментом ИТ-инфраструктуры компании любого размера и любого направления деятельности. Что это такое? Вот давайте об этом и поговорим…

А разговор начнем с простых понятий – домена и служб Active Directory.

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

Службы Active Directory (службы активного каталога ) представляют собой распределённую базу данных, которая содержит все объекты домена. Доменная среда Active Directory является единой точкой аутентификации и авторизации пользователей и приложений в масштабах предприятия. Именно с организации домена и развёртывания служб Active Directory начинается построение ИТ-инфраструктуры предприятия.

База данных Active Directory хранится на выделенных серверах – контроллерах домена. Службы Active Directory являются ролью серверных операционных систем Microsoft Windows Server. Службы Active Directory имеют широкие возможности масштабирования. В лесу Active Directory может быть создано более 2-х миллиардов объектов, что позволяет внедрять службу каталогов в компаниях с сотнями тысяч компьютеров и пользователей. Иерархическая структура доменов позволяет гибко масштабировать ИТ-инфраструктуру на все филиалы и региональные подразделения компаний. Для каждого филиала или подразделения компании может быть создан отдельный домен, со своими политиками, своими пользователями и группами. Для каждого дочернего домена могут быть делегированы административные полномочия местным системным администраторам. При этом всё равно дочерние домены подчиняются родительским.

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

Для обеспечения отказоустойчивости служб Active Directory необходимо развернуть два или более контроллера домена в каждом домене. Между контроллерами домена обеспечивается автоматическая репликация всех изменений. В случае выхода из строя одного из контроллеров домена работоспособность сети не нарушается, ведь оставшиеся продолжают работать. Дополнительный уровень отказоустойчивости обеспечивает размещение серверов DNS на контроллерах домена в Active Directory, что позволяет в каждом домене получить несколько серверов DNS, обслуживающих основную зону домена. И в случае отказа одного из DNS серверов, продолжат работать остальные. О роли и значимости DNS серверов в ИТ-инфраструктуре мы еще поговорим в одной из статей цикла.

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

1. Единая точка аутентификации

В рабочей группе на каждом компьютере или сервере придётся вручную добавлять полный список пользователей, которым требуется сетевой доступ. Если вдруг один из сотрудников захочет сменить свой пароль, то его нужно будет поменять на всех компьютерах и серверах. Хорошо, если сеть состоит из 10 компьютеров, но если их больше? При использовании домена Active Directory все учётные записи пользователей хранятся в одной базе данных, и все компьютеры обращаются к ней за авторизацией. Все пользователи домена включаются в соответствующие группы, например, «Бухгалтерия», «Финансовый отдел». Достаточно один раз задать разрешения для тех или иных групп, и все пользователи получат соответствующий доступ к документам и приложениям. Если в компанию приходит новый сотрудник, для него создаётся учётная запись, которая включается в соответствующую группу, – сотрудник получает доступ ко всем ресурсам сети, к которым ему должен быть разрешён доступ. Если сотрудник увольняется, то достаточно заблокировать – и он сразу потеряет доступ ко всем ресурсам (компьютерам, документам, приложениям).

2. Единая точка управления политиками

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

3. Повышенный уровень информационной безопасности

Использование служб Active Directory значительно повышает уровень безопасности сети. Во-первых – это единое и защищённое хранилище учётных записей. В доменной среде все пароли доменных пользователях хранятся на выделенных серверах контроллерах домена, которые, как правило, защищены от внешнего доступа. Во-вторых, при использовании доменной среды для аутентификации используется протокол Kerberos, который значительно безопаснее, чем NTLM, использующийся в рабочих группах.

4. Интеграция с корпоративными приложениями и оборудованием

Большим преимуществом служб Active Directory является соответствие стандарту LDAP, который поддерживается другими системами, например, почтовыми серверами (Exchange Server), прокси-серверами (ISA Server, TMG). Причем это не обязательно только продукты Microsoft. Преимущество такой интеграции заключается в том, что пользователю не требуется помнить большое количество логинов и паролей для доступа к тому или иному приложению, во всех приложениях пользователь имеет одни и те же учётные данные – его аутентификация происходит в едином каталоге Active Directory. Windows Server для интеграции с Active Directory предоставляет протокол RADIUS, который поддерживается большим количеством сетевого оборудования. Таким образом, можно, например, обеспечить аутентификацию доменных пользователей при подключении по VPN извне, использование Wi-Fi точек доступа в компании.

5. Единое хранилище конфигурации приложений

Некоторые приложения хранят свою конфигурацию в Active Directory, например, Exchange Server. Развёртывание службы каталогов Active Directory является обязательным условием для работы этих приложений. Хранение конфигурации приложений в службе каталогов является выгодным с точки зрения гибкости и надёжности. Например, в случае полного отказа сервера Exchange, вся его конфигурация останется нетронутой. Для восстановления работоспособности корпоративной почты, достаточно будет переустановить Exchange Server в режиме восстановления.

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

Основные понятия Active Directory

Служба Active Directory

Расширяемая и масштабируемая служба каталогов Active Directory (Активный каталог) позволяет эффективно управлять сетевыми ресурсами.

Active Directory - это иерархически организованное хранилище данных об объектах сети, обеспечивающее удобные средства для поиска и использования этих данных . Компьютер, на котором работает Active Directory, называется контроллером домена . С Active Directory связаны практически все административные задачи.

Технология Active Directory основана на стандартных Интернет - протоколах и помогает четко определять структуру сети.

Active Directory и DNS

В Active Director y используется доменная система имен.

Domen Name System , (DNS) - стандартная служба Интернета, организующая группы компьютеров в домены. Домены DNS имеют иерархическую структуру, которая составляет основу Интернета. Разные уровни этой иерархии идентифицируют компьютеры, домены организаций и домены верхнего уровня. DNS также служит для преобразования имен узлов, например z eta.webatwork.com, в численные IP-адреса, например 192.168.19.2. Средствами DNS иерархию доменов Active Directory можно вписать в пространство Интернета или оставить самостоятельной и изолированной от внешнего доступа.

Для доступа к ресурсам в домене применяется полное имя узла, например zeta.webatwork.com. Здесь z eta - имя индивидуального компьютера, webatwork - домен организации, a com - домен верхнего уровня. Домены верхнего уровня составляют фундамент иерархии DNS и потому называются корневыми доменами (root domains ). Они организованы географически, с названиями на основе двухбуквенных кодов стран (ru для России), по типу организации (сот для коммерческих организаций) и по назначению (mil для военных организаций).

Обычные домены, например microsoft.com, называются родительскими (parent domain ), поскольку они образуют основу организационной структуры. Родительские домены можно разделить на поддомены разных отделений или удаленных филиалов. Например, полное имя компьютера в офисе Microsoft в Сиэтле может быть jacob.seattle.microsoft.com, где j acob - имя компьютера, s e altle - поддомен , а microsoft.com - родительский домен. Другое название поддомена - дочерний домен (child domain ).

Компоненты Active Directory

Active Directory объединяет физическую и логическую структуру для компонентов сети. Логические структуры Active Directory помогают организовывать объекты каталога и управлять сетевыми учетными записями и общими ресурсами. К логической структуре относятся следующие элементы:

организационное подразделение (organizational unit ) - подгруппа компьютеров, как правило, отражающая структуру компании;

домен (domain ) - группа компьютеров, совместно использующих общую БД каталога;

дерево доменов (domain tree ) - один или несколько доменов, совместно использующих непрерывное пространство имен;

лес доменов (domain forest ) - одно или несколько деревьев, совместно использующих информацию каталога.

Физические элементы помогают планировать реальную структуру сети. На основании физических структур формируются сетевые связи и физические границы сетевых ресурсов. К физической структуре относятся следующие элементы:

подсеть (subnet ) - сетевая группа с заданной областью IP- адресов и сетевой маской;

сайт ( site ) - одна или несколько подсетей. Сайт используется для настройки доступа к каталогуи для репликации.

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

Организационные подразделения (ОП) - это подгруппы в доменах, которые часто отражают функциональную структуру организации. ОП представляют собой своего рода логические контейнеры, в которых размещаются учетные записи, общие ресурсы и другие ОП. Например, можно создать в домене microsof t . com подразделения Resourses , IT , Marketing . Потом эту схему можно расширить, чтобы она содержала дочерние подразделения.

В ОП разрешается помещать объекты только из родительского домена. Например, ОП из домена Seattle.microsoft.com содержат объекты только этого домена. Добавлять туда объекты из m y . m icrosoft.com нельзя. ОП очень удобны при формировании функциональной или бизнес - структуры организации. Но это не единственная причина их применения.

ОП позволяют определять групповую политику для небольшого набора ресурсов в домене, не применяя ее ко всему домену. С помощью ОП создаются компактные и более управляемые представления объектов каталога в домене, что помогает эффективнее управлять ресурсами.

ОП позволяют делегировать полномочия и контролировать административный доступ к ресурсам домена, что помогает задавать пределы полномочий администраторов в домене. Можно передать пользователю А административные полномочия только для одного ОП и в то же время передать пользователю В административные полномочия для всех OП в домене.

Домены

Домен Active Directory - этогруппа компьютеров, совместно использующих общую БД каталога. Имена доменов Active Directory должны быть уникальными. Например, не может быть двух доменов m icrosoft.com, но может быть родительский домен microsoft.com с дочерними доменами seattle.microsoft.com и m y.microsoft.com. Если домен является частью закрытой сети, имя, присвоенное новому домену, не должно конфликтовать ни с одним из существующих имен доменов в этой сети. Если домен - часть глобальной сети Интернет, то его имя не должно конфликтовать ни с одним из существующих имен доменов в Интернете. Чтобы гарантировать уникальность имен в Интернете, имя родительского домена необходимо зарегистрировать через любую полномочную регистрационную организацию.

В каждом домене действуют собственные политики безопасности и доверительные отношения с другими доменами. Зачастую домены распределяются по нескольким физическим расположениям, т. е. состоят из нескольких сайтов, а сайты - объединяют несколько подсетей. В БД каталога домена хранятся объекты, определяющие учетные записи для пользователей, групп и компьютеров, а также общие ресурсы, например принтеры и папки.

Функции домена ограничиваются и регулируются режимом его функционирования. Существует четыре функциональных режима доменов:

смешанный режим Windows 2000 (mixed mode ) - поддерживает контроллеры доменов, работающие под управлением Windows NT 4.0, Windows 2000 и Windows Server 2003;

основной режим Windows 2000 (native mode ) - поддерживает контроллеры доменов, работающие под управлением Windows 2000 и Windows Server 2003;

промежуточный режим Windows Server 2003 ( interim mode ) - поддерживает контроллеры доменов, работающие под управлением Windows NT 4.0 и Windows Server 2003;

режим Windows Server 2003 - поддерживает контроллеры доменов, работающие под управлением Windows Server 2003.

Леса и деревья

Каждый домен Active Directory обладает DNS -именем типа microsoft .com . Домены, совместно использующие данные каталога, образуют лес (forest ). Имена доменов леса в иерархии имен DNS бывают несмежными (discontiguous ) или смежными (contiguous ).

Домены, обладающие смежной структурой имен, называют деревом доменов. Если у доменов леса несмежные DNS-имена, они образуют отдельные деревья доменов в лесу. В лес можно включить одно или несколько деревьев. Для доступа к доменным структурам предназначена консоль Active Directory - домены и доверие (Active Directory Domains and Trusts ).

Функции лесов ограничиваются и регулируются функциональным режимом леса. Таких режимов три:

Windows 2000 - поддерживает контроллеры доменов, работающие под управлением Windows NT 4.0, Windows 2000 и Windows Server 2003;

промежуточный ( interim ) Windows Server 2003 - поддерживает контроллеры доменов, работающие под управлением Windows NT 4.0 и Windows Server 2003;

Windows Server 2003 - поддерживает контроллеры доменов, работающие под управлением Windows Server 2003.

Самые современные функции Active Directory доступны в режиме Windows Server 2003. Если все домены леса работают в этом режиме, можно пользоваться улучшенной репликацией (тиражированием) глобальных каталогов и более эффективной репликацией данных Active Directory . Также есть возможность отключать классы и атрибуты схемы, использовать динамические вспомогательные классы, переименовывать домены и создавать в лесу односторонние, двухсторонние и транзитивные доверительные отношения.

Сайты и подсети

Сайт - это группа компьютеров в одной или нескольких IP-подсетях, используемая для планирования физической структуры сети. Планирование сайта происходит независимо от логической структуры домена. Active Directory позволяет создать множество сайтов в одном домене или один сайт, охватывающий множество доменов.

В отличие от сайтов, способных охватывать множество областей IP-адресов, подсети обладают заданной областью IP-адресов и сетевой маской. Имена подсетей указываются в формате сеть/битовая маска , например 192.168.19.0/24, где сетевой адрес 192.168.19.0 и сетевая маска 255.255.255.0 скомбинированы в имя подсети 192.168.19.0/24.

Компьютеры приписываются к сайтам в зависимости от местоположения в подсети или в наборе подсетей. Если компьютеры в подсетях способны взаимодействовать на достаточно высоких скоростях, их называют хорошо связанными (well connected ).

В идеале сайты состоят из хорошо связанных подсетей и компьютеров, Если скорость обмена между подсетями и компьютерами низка, может потребоваться создать несколько сайтов. Хорошая связь дает сайтам некоторые преимущества.

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

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

Можно настроить порядок репликации данных каталога, используя связи сайтов (site links ). Например, определить сервер-плацдарм (bridgehead ) для репликации между сайтами.

Основная часть нагрузки от репликации между сайтами ляжет на этот специализированный сервер, а не на любой доступный сервер сайта. Сайты и подсети настраиваются в консоли Active Directory - сайты и службы (Active Directory Sites and Services).

Работа с доменами Active Directory

В сети Windows Server 2003 служба Active Directory настраивается одновременно с DNS . Тем не менее у доменов Active Directory и доменов DNS разное назначение. Домены Active Directory помогают управлять учетными записями, ресурсами и защитой.

Иерархия доменов DNS предназначена, главным образом, для разрешения имен.

В полной мере воспользоваться преимуществами Active Directory способны компьютеры, работающие под управлением Windows XP Professional и Windows 2000. Они работают в сети как клиенты Active Directory и им доступны транзитивные доверительные отношения, существующие в дереве или лесу доменов. Эти отношения позволяют авторизованным пользователям получать доступ к ресурсам в любом домене леса.

Система Windows Server 2003 функционирует как контроллер домена или как рядовой сервер. Рядовые серверы становятся контроллерами после установки Active Directory ; контроллеры понижаются до рядовых серверов после удаления Active Directory .

Оба процесса выполняет мастер установки Active Directory . В домене может быть несколько контроллеров. Они реплицируют между собой данные каталога по модели репликации с несколькими хозяевами, которая позволяет каждому контроллеру обрабатывать изменения каталога, а затем передавать их на другие контроллеры. Благодаря структуре с несколькими хозяевами все контроллеры по умолчанию обладают равной ответственностью. Впрочем, можно предоставить некоторым контроллерам домена приоритет над другими в определенных задачах, например, создать сервер-плацдарм, который обладает приоритетом при репликации данных каталога на другие сайты.

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

Для всех компьютеров с Windows 2000, Windows XP Professional и Windows Server 2003, присоединенных к домену, создаются учетные записи, хранящиеся, подобно другим ресурсам, в виде объектов Active Directory . Учетные записи компьютеров служат для управления доступом к сети и ее ресурсам, Прежде чем компьютер получает доступ к домену по своей учетной записи, он в обязательном порядке проходит процедуру аутентификации.

Структура каталога

Данные каталога предоставляются пользователям и компьютерам через хранилище данных (data stores ) и глобальные каталоги (global catalogs ). Хотя большинство функций Active Directory затрагивают хранилище данных, глобальные каталоги (ГК) не менее важны, поскольку используются для входа в систему и поиска информации. Если ГК недоступен, обычные пользователи не смогут войти в домен. Единственный способ обойти это условие - локальное кэширование членства в универсальных группах.

Доступ и распространение данных Active Directory обеспечиваются средствами протоколов доступа к каталогу (directory access protocols ) и репликации (replication ).

Репликация нужна для распространения обновленных данных на контроллеры. Главный метод распространения обновлений - репликация с несколькими хозяевами, но некоторые изменения обрабатываются только специализированными контроллерами - хозяевами операций (operations masters ).

Способ выполнения репликации с несколькими хозяевами в Windows Server 2003 также изменился благодаря появлению разделов каталога приложений (application directory partitions ). Посредством их системные администраторы могут создавать в лесу доменов разделы репликации, которые представляют собой логические структуры, используемые для управления репликацией в пределах леса доменов. Например, можно создать раздел, который будет ведать репликацией информации DNS в пределах домена. Другим системам домена репликация информации DNS запрещена.

Разделы каталога приложений могут быть дочерним элементом домена, дочерним элементом другого прикладного раздела или новым деревом в лесу доменов. Реплики разделов разрешается размещать на любом контроллере домена Active Directory , включая глобальные каталоги. Хотя разделы каталога приложений полезны в больших доменах и лесах, они увеличивают издержки на планирование, администрирование и сопровождение.

Хранилище данных

Хранилище содержит сведения о важнейших объектах службы каталогов Active Directory - учетных записях, общих ресурсах, ОП и групповых политиках. Иногда хранилище данных называют просто каталогом (directory ). На контроллере домена каталог хранится в файле NTDS.DIT, расположение которого определяется при установке Active Directory (это обязательно должен быть диск NTFS). Некоторые данные каталога можно хранить и отдельно от основного хранилища, например, групповые политики, сценарии и другую информацию, записанную в общем системном ресурсе SYSVOL.

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

Реплицируются не все данные каталога, а только:

Данные домена - информация об объектах в домене, включая объекты учетных записей, общих ресурсов, ОП и групповых политик;

Данные конфигурации - сведения о топологии каталога: список всех доменов, деревьев и лесов, а также расположение контроллеров и серверов ГК;

Данные схемы - информация обо всех объектах и типах данных, которые могут храниться в каталоге; стандартная схема Windows Server 2003 описывает объекты учетных записей, объекты общих ресурсов и др., её можно расширить, определив новые объекты и атрибуты или добавив атрибуты для существующих объектов.

Глобальный каталог

Если локальное кэширование членства в универсальных группах не производится, вход в сеть осуществляется на основе информации о членстве в универсальной группе, предоставленной ГК.

Он также обеспечивает поиск в каталоге по всем доменам леса. Контроллер, выполняющий роль сервера ГК, хранит полную реплику всех объектов каталога своего домена и частичную реплику объектов остальных доменов леса.

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

По умолчанию сервером ГК становится первый контроллер домена. Поэтому, если в домене только один контроллер, то сервер ГК и контроллер домена - один и тот же сервер. Можно расположить ГК на другом контроллере, чтобы сократить время ожидания ответа при входе в систему и ускорить поиск. Рекомендуется создать по одному ГК в каждом сайте домена.

Есть несколько способов решения этой проблемы. Разумеется, можно создать сервер ГК на одном из контроллеров домена в удаленном офисе. Недостаток этого способа - увеличение нагрузки на сервер ГК, что может потребовать дополнительных ресурсов и тщательного планирования времени работы этого сервера.

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

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

Членство в универсальной группе индивидуально для каждого сайта. Напомним, что сайт - это физическая структура, состоящая из одной или нескольких подсетей, имеющих индивидуальный набор IP-адресов и сетевую маску. Контроллеры домена Windows Server 2003 и ГК, к которому они обращаются, должны находиться в одном сайте. Если есть несколько сайтов,придется настроить локальное кэширование на каждом из них. Кроме того, пользователи, входящие в сайт, должны быть частью домена Windows Server 2003, работающего в режиме леса Windows Server 2003.

Репликация в Active Directory

В каталоге хранятся сведения трех типов: данные домена, данные схемы и данные конфигурации. Данные домена реплицируются на все контроллеры домена. Все контроллеры домена равноправны, т.е. все вносимые изменения с любого контроллера домена будут реплицированы на все остальные контроллеры домена Схема и данные конфигурации реплицируются на все домены дерева или леса. Кроме того, все объекты индивидуального домена и часть свойств объектов леса реплицируются в ГК. Это означает, что контроллер домена хранит и реплицирует схему для дерева или леса, информацию о конфигурации для всех доменов дерева или леса и все объекты каталога и свойства для собственного домена.

Контроллер домена, на котором хранится ГК, содержит и реплицирует информацию схемы для леса, информацию о конфигурации для всех доменов леса и ограниченный набор свойств дл я всех объектов каталога в лесу (он реплицируется только между серверами ГК), а также все объекты каталога и свойства для своего домена.

Чтобы понять суть репликации, рассмотрим такой сценарий настройки новой сети.

1. В домене А установлен первый контроллер. Этот сервер - единственный контроллер домена. Он же является и сервером ГК. Репликация в такой сети не происходит, поскольку нет других контроллеров.

2. В домене А устанавливается второй контроллер, и начинается репликация. Можно назначить один контроллер хозяином инфраструктуры, а другой - сервером ГК. Хозяин инфраструктуры следит за обновлениями ГК и запрашивает их для измененных объектов. Оба этих контроллера также реплицируют данные схемы и конфигурации.

3. В домене А устанавливается третий контроллер, на котором нет ГК. Хозяин инфраструктуры следит за обновлениями ГК, запрашивает их для измененных объектов, а затем реплицирует изменения на третий контроллер домена. Все три контроллера также реплицируют данные схемы и конфигурации.

4. Создается новый домен Б , в него добавляются контроллеры. Серверы ГК в домене А и домене Б реплицируют все данные схемы и конфигурации, а также подмножество данных домена из каждого домена. Репликация в домене А продолжается, как описано выше, плюс начинается репликация внутри домена Б.

Active Directory и LDAP

Упрощенный протокол доступа к каталогам (Lightweight Directory Access Protocol , LDAP) - стандартный протокол Интернет соединений в сетях TCP/IP. LDAP спроектирован специально для доступа к службам каталогов с минимальными издержками. В LDAP также определены операции, используемые для запроса и изменения информации каталога.

Клиенты Active Directory применяют LDAP для связи с компьютерами, на которых работает Active Directory , при каждом входе в сеть или поиске общих ресурсов. LDAP упрощает взаимосвязь каталогов и переход на Active Directory с других служб каталогов. Для повышения совместимости можно использовать интерфейсы служб Active Directory (Active Directory Service - Interfaces , ADSI ).

Роли хозяина операций

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

Хозяин схемы (schema master ) - управляет обновлениями и изменениями схемы каталога. Для обновления схемы каталога необходим доступ к хозяину схемы. Чтобы определить, какой сервер в данное время является хозяином схемы в домене, достаточно открыть окно командной строки и ввести: dsquery server - has f smo schema .

Хозяин именования доменов (domain naming master ) - управляет добавлением и удалением доменов в лесу. Чтобы добавить или удалить домен,требуется доступ к хозяину именования доменов. Чтобы определить, какой сервер в данное время является хозяином именования доменов, достаточно в окне командной строки ввести: dsquery server - has f smo name .

Эти роли, общие для всего леса в целом, должны быть в нем уникальными.

В каждом домене Active Directory в обязательном порядке существуют следующие роли.

Хозяин относительных идентификаторов (relative ID master ) - выделяет относительные идентификаторы контроллерам доменов. Каждый раз при создании объекта пользователя, группы или компьютера контроллеры назначают объекту уникальный идентификатор безопасности, состоящий из идентификатора безопасности домена и уникального идентификатора, который был выделен хозяином относительных идентификаторов. Чтобы определить, какой сервер в данное время является хозяином относительных идентификаторов в домене, достаточно в окне командной строкиввести: dsquery server - has f smo rid .

Эмулятор PDC (PDC emulator ) - в смешанном или промежуточном режиме домена действует как главный контроллер домена Windows NT. Он аутентифицирует вход в Windows NT, обрабатывает изменения пароля и реплицирует обновления на P DC. Чтобы определить, какой сервер в данное время является эмулятором PDC в домене, достаточно в окне командной строкиввести dsquery server - hasfsmo pdc .

Хозяин инфраструктуры (infrastructure master ) - обновляет ссылки объектов, сравнивая данные своего каталога с данными ГК. Если данные устарели, он запрашивает из ГК обновления и реплицирует их на остальные контроллеры в домене. Чтобы определить, какой сервер в данное время является хозяином инфраструктуры в домене, достаточно в окне командной строки и ввести dsquery server -hasfsmo infr .

Эти роли, общие для всего домена, должны быть в нем уникальными. Иными словами, можно настроить только один хозяин относительных идентификаторов, один эмулятор PDC и один хозяин инфраструктуры для каждого домена.

Обычно роли хозяина операций назначаются автоматически, но их можно переназначить. При установке новой сети все роли хозяев операций получает первый контроллер первого домена. Если позднее будет создан новый дочерний домен или корневой домен в новом дереве, роли хозяина операций также автоматически назначаются первому контроллеру домена. В новом лесу доменов контроллеру домена назначаются все роли хозяина операций. Если новый домен создается в том же лесу, его контроллеру назначаются роли хозяина относительных идентификаторов, эмулятора Р D С и хозяина инфраструктуры. Роли хозяина схемы и хозяина именования доменов остаются у первого домена леса.

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

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

Администрирование Active Directory

C помощью службы Active Directory создаются учетные записи компьютеров, проводится подключение их к домену, производится управление компьютерами, контроллерами домена и организационными подразделениями (ОП).

Для управления Active Directory предназначены средства администрирования и поддержки. Перечисленные ниже инструменты реализованы и виде оснасток консоли ММС (Microsoft Management Console ):

Active Directory - пользователи и компьютеры (Active Directory Users and Computers ) позволяет управлять пользователями, группами, компьютерами и организационными подразделениями (ОП);

Active Directory - домены и доверие ( Active Directory Domains and Trusts ) служит для работы с доменами, деревьями доменов и лесами доменов;

Active Directory - сайты и службы (Active Directory Sites and Services) позволяет управлять сайтами и подсетями ;

Результирующая политика (Resultant Set of Policy ) используется для просмотра текущей политики пользователя или системы и для планирования изменений в политике.

В Microsoft Windows 2003 Server можно получить доступ к этим оснасткам напрямую из меню Администрирование (Administrative Tools ).

Еще одно средство администрирования - оснастка Схема Active Directory (Active Directory Schema ) - позволяет управлять и модифицировать схему каталога.

Утилиты командной строки Active Directory

Для управления объектами Active Directory существуют средства командной строки, которые позволяют осуществлять широкий спектр административных задач:

DSADD - добавляет в Active Directory компьютеры, контакты, группы, ОП и пользователей.

DSGET - отображает свойства компьютеров, контактов, групп, ОП, пользователей, сайтов, подсетей и серверов, зарегистрированных в Active Directory .

DSMOD - изменяет свойства компьютеров, контактов, групп, ОП, пользователей и серверов, зарегистрированных в Active Directory .

DSMOVE - перемещает одиночный объект в новое расположение в пределах домена или переименовывает объект без перемещения.

DSQXJERY - осуществляет поиск компьютеров, контактов, групп, ОП, пользователей, сайтов, подсетей и серверов в Active Directory по заданным критериям.

DSRM - удаляет объект из Active Directory .

NTDSUTIL - позволяет просматривать информацию о сайте, домене или сервере, управлять хозяевами операций (operations masters ) и обслуживать базу данных Active Directory .

Аннотация: Данная лекция описывает основные понятия служб каталогов Active Directory. Даются практические примеры управления системой безопасности сети. Описан механизм групповых политик. Дается представление о задачах сетевого администратора при управлении инфраструктурой службы каталогов

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

Решение проблемы управления такой разнородной сетью было найдено с разработкой службы каталога. Службы каталога предоставляют возможности управления любыми ресурсами и сервисами из любой точки независимо от размеров сети, используемых операционных систем и сложности оборудования. Информация о пользователе, заносится единожды в службу каталога, и после этого становится доступной в пределах всей сети. Адреса электронной почты, принадлежность к группам, необходимые права доступа и учетные записи для работы с различными операционными системами - все это создается и поддерживается в актуальном виде автоматически. Любые изменения, занесенные в службу каталога администратором, сразу обновляются по всей сети. Администраторам уже не нужно беспокоиться об уволенных сотрудниках - просто удалив учетную запись пользователя из службы каталога, он сможет гарантировать автоматическое удаление всех прав доступа на ресурсы сети, предоставленные ранее этому сотруднику.

В настоящее время большинство служб каталогов различных фирм базируются на стандарте X.500 . Для доступа к информации, хранящейся в службах каталогов, обычно используется протокол (LDAP ). В связи со стремительным развитием сетей TCP/IP , протокол LDAP становится стандартом для служб каталогов и приложений, ориентированных на использование службы каталога.

Служба каталогов Active Directory является основой логической структуры корпоративных сетей, базирующихся на системе Windows . Термин " Каталог " в самом широком смысле означает " Справочник ", а служба каталогов корпоративной сети - это централизованный корпоративный справочник. Корпоративный каталог может содержать информацию об объектах различных типов. Служба каталогов Active Directory содержит в первую очередь объекты, на которых базируется система безопасности сетей Windows , - учетные записи пользователей, групп и компьютеров. Учетные записи организованы в логические структуры: домен, дерево , лес , организационные подразделения .

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

6.1 Основные термины и понятия (лес, дерево, домен, организационное подразделение). Планирование пространства имен AD. Установка контроллеров доменов

Модели управления безопасностью: модель "Рабочая группа" и централизованная доменная модель

Как уже говорилось выше, основное назначение служб каталогов - управление сетевой безопасностью. Основа сетевой безопасности - база данных учетных записей (accounts) пользователей, групп пользователей и компьютеров, с помощью которой осуществляется управление доступом к сетевым ресурсам. Прежде чем говорить о службе каталогов Active Directory, сравним две модели построения базы данных служб каталогов и управления доступом к ресурсам.

Модель "Рабочая группа"

Данная модель управления безопасностью корпоративной сети - самая примитивная. Она предназначена для использования в небольших одноранговых сетях (3–10 компьютеров) и основана на том, что каждый компьютер в сети с операционными системами Windows NT/2000/XP/2003 имеет свою собственную локальную базу данных учетных записей и с помощью этой локальной БД осуществляется управление доступом к ресурсам данного компьютера. Локальная БД учетных записей называется база данных SAM (Security Account Manager ) и хранится в реестре операционной системы. Базы данных отдельных компьютеров полностью изолированы друг от друга и никак не связаны между собой.

Пример управления доступом при использовании такой модели изображен на рис. 6.1 .

Рис. 6.1.

В данном примере изображены два сервера (SRV-1 и SRV-2) и две рабочие станции (WS-1 и WS-2). Их базы данных SAM обозначены соответственно SAM-1, SAM-2, SAM-3 и SAM-4 (на рисунке базы SAM изображены в виде овала). В каждой БД есть учетные записи пользователей User1 и User2. Полное имя пользователя User1 на сервере SRV-1 будет выглядеть как "SRV-1\User1", а полное имя пользователя User1 на рабочей станции WS-1 будет выглядеть как "WS-1\User1". Представим, что на сервере SRV-1 создана папка Folder, к которой предоставлен доступ по сети пользователям User1 - на чтение (R), User2 - чтение и запись (RW). Главный момент в этой модели заключается в том, что компьютер SRV-1 ничего "не знает" об учетных записях компьютеров SRV-2, WS-1, WS-2, а также всех остальных компьютеров сети. Если пользователь с именем User1локально зарегистрируется в системе на компьютере, например, WS-2 (или, как еще говорят, "войдет в систему с локальным именем User1 на компьютере WS-2"), то при попытке получить доступ с этого компьютера по сети к папке Folder на сервере SRV-1 сервер запросит пользователя ввести имя и пароль (исключение составляет тот случай, если у пользователей с одинаковыми именами одинаковые пароли).

Модель "Рабочая группа" более проста для изучения, здесь нет необходимости изучать сложные понятия Active Directory. Но при использовании в сети с большим количеством компьютеров и сетевых ресурсов становится очень сложным управлять именами пользователей и их паролями - приходится на каждом компьютере (который предоставляет свои ресурсы для совместного использования в сети) вручную создавать одни и те же учетные записи с одинаковыми паролями, что очень трудоемко, либо делать одну учетную запись на всех пользователей с одним на всех паролем (или вообще без пароля), что сильно снижает уровень защиты информации. Поэтому модель "Рабочая группа" рекомендуется только для сетей с числом компьютеров от 3 до 10 (а еще лучше - не более 5), при условии что среди всех компьютеров нет ни одного с системой Windows Server.

Доменная модель

В доменной модели существует единая база данных служб каталогов, доступная всем компьютерам сети. Для этого в сети устанавливаются специализированные серверы, называемые контроллерами домена , которые хранят на своих жестких дисках эту базу. На рис. 6.2 . изображена схема доменной модели. Серверы DC-1 и DC-2 - контроллеры домена, они хранят доменную базу данных учетных записей (каждый контроллер хранит у себя свою собственную копию БД, но все изменения, производимые в БД на одном из серверов, реплицируются на остальные контроллеры).

Рис. 6.2.

В такой модели, если, например, на сервере SRV-1, являющемся членом домена, предоставлен общий доступ к папке Folder, то права доступа к данному ресурсу можно назначать не только для учетных записей локальной базы SAM данного сервера, но, самое главное, учетным записям, хранящимся в доменной БД. На рисунке для доступа к папке Folder даны права доступа одной локальной учетной записи компьютера SRV-1 и нескольким учетным записям домена (пользователя и группам пользователей). В доменной модели управления безопасностью пользователь регистрируется на компьютере ("входит в систему") со своей доменной учетной записью и, независимо от компьютера, на котором была выполнена регистрация, получает доступ к необходимым сетевым ресурсам. И нет необходимости на каждом компьютере создавать большое количество локальных учетных записей, все записи созданы однократно в доменной БД . И с помощью доменной базы данных осуществляется централизованное управление доступом к сетевым ресурсам независимо от количества компьютеров в сети .

Назначение службы каталогов Active Directory

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

Active Directory отвечает не только за создание и организацию этих небольших объектов, но также и за большие объекты, такие как домены, OU (организационные подразделения ) и сайты.

Об основных терминах, используемых в контексте службы каталогов Active Directory , читайте ниже.

Служба каталогов Active Directory (сокращенно - AD ) обеспечивает эффективную работу сложной корпоративной среды, предоставляя следующие возможности:

• Единая регистрация в сети ; Пользователи могут регистрироваться в сети с одним именем и паролем и получать при этом доступ ко всем сетевым ресурсам и службам (службы сетевой инфраструктуры, службы файлов и печати, серверы приложений и баз данных и т. д.);
• Безопасность информации . Средства аутентификации и управления доступом к ресурсам, встроенные в службу Active Directory, обеспечивают централизованную защиту сети;
• Централизованное управление . Администраторы могут централизованно управлять всеми корпоративными ресурсами;
• Администрирование с использованием групповых политик . При загрузке компьютера или регистрации пользователя в системе выполняются требования групповых политик; их настройки хранятся в объектах групповых политик ( GPO ) и применяются ко всем учетным записям пользователей и компьютеров, расположенных в сайтах, доменах или организационных подразделениях;
• Интеграция с DNS . Функционирование служб каталогов полностью зависит от работы службы DNS. В свою очередь серверы DNS могут хранить информацию о зонах в базе данных Active Directory;
• Расширяемость каталога . Администраторы могут добавлять в схему каталога новые классы объектов или добавлять новые атрибуты к существующим классам;
• Масштабируемость . Служба Active Directory может охватывать как один домен, так и множество доменов, объединенных в дерево доменов, а из нескольких деревьев доменов может быть построен лес;
• Репликация информации . В службе Active Directory используется репликация служебной информации в схеме со многими ведущими (multi-master ), что позволяет модифицировать БД Active Directory на любом контроллере домена. Наличие в домене нескольких контроллеров обеспечивает отказоустойчивость и возможность распределения сетевой нагрузки;
• Гибкость запросов к каталогу . БД Active Directory может использоваться для быстрого поиска любого объекта AD, используя его свойства (например, имя пользователя или адрес его электронной почты, тип принтера или его местоположение и т. п.);
• Стандартные интерфейсы программирования . Для разработчиков программного обеспечения служба каталогов предоставляет доступ ко всем возможностям (средствам) каталога и поддерживает принятые стандарты и интерфейсы программирования (API).

В Active Directory может быть создан широкий круг различных объектов. Объект представляет собой уникальную сущность внутри Каталога и обычно обладает многими атрибутами, которые помогают описывать и распознавать его. Учетная запись пользователя является примером объекта. Этот тип объекта может иметь множество атрибутов, таких как имя, фамилия, пароль , номер телефона, адрес и многие другие. Таким же образом общий принтер тоже может быть объектом в Active Directory и его атрибутами являются его имя, местоположение и т.д. Атрибуты объекта не только помогают определить объект , но также позволяют вам искать объекты внутри Каталога.

Терминология

Служба каталогов системы Windows Server построена на общепринятых технологических стандартах. Изначально для служб каталогов был разработан стандарт X.500 , который предназначался для построения иерархических древовидных масштабируемых справочников с возможностью расширения как классов объектов, так и наборов атрибутов (свойств) каждого отдельного класса. Однако практическая реализация этого стандарта оказалась неэффективной с точки зрения производительности. Тогда на базе стандарта X.500 была разработана упрощенная (облегченная) версия стандарта построения каталогов, получившая название LDAP (Lightweight Directory Access Protocol ). Протокол LDAP сохраняет все основные свойства X.500 (иерархическая система построения справочника, масштабируемость , расширяемость ), но при этом позволяет достаточно эффективно реализовать данный стандарт на практике. Термин " lightweight " (" облегченный ") в названии LDAP отражает основную цель разработки протокола: создать инструментарий для построения службы каталогов, которая обладает достаточной функциональной мощью для решения базовых задач, но не перегружена сложными технологиями, делающими реализацию служб каталогов неэффективной. В настоящее время LDAP является стандартным методом доступа к информации сетевых каталогов и играет роль фундамента во множестве продуктов, таких как системы аутентификации , почтовые программы и приложения электронной коммерции. Сегодня на рынке присутствует более 60 коммерческих серверов LDAP , причем около 90% из них представляют собой самостоятельные серверы каталогов LDAP , а остальные предлагаются в качестве компонентов других приложений.

Протокол LDAP четко определяет круг операций над каталогами, которые может выполнять клиентское приложение . Эти операции распадаются на пять групп:

• установление связи с каталогом;
• поиск в нем информации;
• модификация его содержимого;
• добавление объекта;
• удаление объекта.

Кроме протокола LDAP служба каталогов Active Directory использует также протокол аутентификации Kerberos и службу DNS для поиска в сети компонент служб каталогов (контроллеры доменов, серверы глобального каталога , службу Kerberos и др.).

Домен

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

Имена доменов Active Directory формируются по той же схеме, что и имена в пространстве имен DNS. И это не случайно. Служба DNS является средством поиска компонент домена - в первую очередь контроллеров домена.

Контроллеры домена - специальные серверы, которые хранят соответствующую данному домену часть базы данных Active Directory. Основные функции контроллеров домена:

• хранение БД Active Directory (организация доступа к информации, содержащейся в каталоге, включая управление этой информацией и ее модификацию);
• синхронизация изменений в AD (изменения в базу данных AD могут быть внесены на любом из контроллеров домена, любые изменения, осуществляемые на одном из контроллеров, будут синхронизированы c копиями, хранящимися на других контроллерах);
• аутентификация пользователей (любой из контроллеров домена осуществляет проверку полномочий пользователей, регистрирующихся на клиентских системах).

Настоятельно рекомендуется в каждом домене устанавливать не менее двух контроллеров домена - во-первых, для защиты от потери БД Active Directory в случае выхода из строя какого-либо контроллера, во-вторых, для распределения нагрузки между контроллерами.it.company.ru есть поддомен dev.it.company.ru , созданный для отдела разработчиков ПО ИТ-службы.

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

Организационные подразделения (ОП).

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

Глобальный каталог

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

В 2002 году, прогуливаясь по коридору кафедры информатики своего любимого университета, я увидел на двери кабинета «Системы NT» свежий плакат. На плакате были изображены иконки пользовательских аккаунтов, объединенные в группы, от которых в свою очередь отходили стрелки к другим иконкам. Все это схематично объединялось в некую структуру, было написано что-то про единую систему входа, авторизацию и тому подобное. Насколько сейчас понимаю на том плакате была изображена архитектура систем Windows NT 4.0 Domains и Windows 2000 Active Directory. С этого момента началось и сразу же закончилось мое первое знакомство с Active Directory, так как потом была тяжелая сессия, веселые каникулы, после которых друг поделился дисками FreeBSD 4 и Red Hat Linux, и на ближайшие несколько лет я погрузился в мир Unix-подобных систем, но содержимое плаката я так и не забыл.
К системам на платформе Windows Server мне пришлось вернуться и более тесно с ними познакомиться, когда я перешел работать в компанию, где управление всей ИТ-инфраструктурой было основано на Active Directory. Помню, что главный админ той компании на каждом совещании все время что-то твердил про какие-то Active Directory Best Practices. Теперь, после 8 лет периодического общения с Active Directory, я достаточно хорошо понимаю, как работает данная система и что такое Active Directory Best Practices.
Как вы уже, наверное, догадались, речь пойдет про Active Directory.
Всем, кому интересна данная тема, добро пожаловать по кат.

Данные рекомендации справедливы для клиентских систем начиная с Windows 7 и выше, для доменов и лесов уровня Windows Server 2008/R2 и выше.

Стандартизация
Планирование Active Directory следует начать с разработки своих стандартов назначения имен объектов и их расположения в каталоге. Необходимо создать документ, в котором определить все необходимые стандарты. Конечно, это довольно частая рекомендация для ИТ специалистов. Принцип «сначала пишем документацию, а потом по данной документации строим систему» является очень хорошим, но он редко реализуем на практике по многим причинам. Среди этих причин - простая человеческая лень или отсутствие соответствующей компетенции, остальные причины являются производными от первых двух.
Рекомендую - сначала напишите документацию, все обдумайте и только потом приступайте к инсталляции первого контроллера домена.
Для примера приведу раздел документа по стандартам названия объектов Active Directory.
Именование объектов.

• Название пользовательских групп должно начинаться с префикса GRUS_ (GR - Group, US - Users)
• Название компьютерных групп н должно начинаться с префикса GRCP_ (GR - Group, CP - Computers)
• Название групп делегирования полномочий должно начинаться с префикса GRDL_ (GR - Group, DL - Delegation)
• Название групп доступа к ресурсам должно начинаться с префикса GRRS_ (GR - Group, RS - resources)
• Название групп для политик должно начинаться с префиксов GPUS_, GPCP_ (GP - Group policy, US - Users, CP - Computers)
• Название клиентских компьютеров должно состоять из двух, трех букв от названия организации, за которыми через дефис должен следовать номер, например, nnt-01.
• Название серверов должно начинаться только из двух букв, за которыми через дефис должна следовать роль сервера и его номер, например, nn-dc01.

Рекомендую называть объекты Active Directory таким образом, чтобы вам не приходилось заполнять поле «Description». Например, из названия группы GPCP_Restricted_Groups понятно, что это группа для политики, которая применяется для компьютеров и выполняет работу механизма Restricted Groups.
Ваш подход к написанию документации должен быть очень основательным, это позволит сэкономить большое количество времени в дальнейшем.

Упрощайте все, что возможно, старайтесь достигнуть равновесия
При построении Active Directory необходимо следовать принципу достижения равновесия, делая выбор в пользу простых и понятных механизмов.
Принцип равновесия заключается в том, чтобы достигнуть необходимого функционала и безопасности при максимальной простоте решения.
Необходимо стараться построить систему так, чтобы ее устройство было понятно самому не искушенному администратору или даже пользователю. Например, в свое время была рекомендация создавать структуру леса из нескольких доменов. Более того рекомендовалось разворачивать не только мультидоменные структуры, но и структуры из нескольких лесов. Возможно, такая рекомендация существовала из-за принципа «разделяй и властвуй», либо потому-то Microsoft всем твердила, что домен - это граница безопасности и разделив организацию на домены, мы получим отдельные структуры, которые проще контролировать по отдельности. Но как показала практика, что более просто обслуживать и контролировать однодоменные системы, где границами безопасности являются организационные единицы (OU), а не домены. Поэтому избегайте создания сложных мультидоменных структур, лучше группируйте объекты по OU.
Конечно, следует действовать без фанатизма, - если невозможно обойтись без нескольких доменов, то нужно создавать несколько доменов, также и с лесами. Главное, чтобы вы понимали, что делаете, и к чему это может привести.
Важно понимать, что простую инфраструктуру Active Directory проще администрировать и контролировать. Я бы даже сказал, что чем проще, тем безопаснее.
Применяйте принцип упрощения. Старайтесь достигнуть равновесия.

Соблюдайте принцип – «объект - группа»
Начинайте создание объектов Active Directory с создания группы для данного объекта, и уже группе назначайте необходимые права. Рассмотрим на примере. Вам необходимо создать аккаунт главного администратора. Создайте сначала группу Head Admins и только потом создайте сам аккаунт и добавьте его в данную группу. Группе Head Admins назначьте права главного администратора, например, добавив ее в группу Domain Admins. Почти всегда получается так, что через некоторое время приходит на работу еще один сотрудник, которому нужны аналогичные права, и вместо того, чтобы заниматься делегированием прав на разные разделы Active Directory, будет возможно просто добавить его в необходимую группу, для которой в системе уже определена роль и делегированы необходимые полномочия.
Еще один пример. Вам необходимо делегировать права на OU с пользователями группе системных администраторов. Не делегируйте права напрямую группе администраторов, а создайте специальную группу вроде GRDL_OUName_Operator_Accounts, которой назначьте права. Потом просто добавьте в группу GRDL_OUName_Operator_Accounts группу ответственных администраторов. Обязательно получиться так, что в скором будущем, вам понадобиться делегировать другой группе администраторов права на данную OU. И в этом случае вы просто добавите группу данных администраторов в группу делегирования GRDL_OUName_Operator_Accounts.
Предлагаю следующую структуру групп.

• Группы пользователей (GRUS_)
• Группы администраторов (GRAD_)
• Группы делегирования (GRDL_)
• Группы политик (GRGP_)

Группы компьютеров

• Группы серверов (GRSR_)
• Группы клиентских компьютеров (GRCP_)

Группы доступа к ресурсам

• Группы доступа к общим ресурсам (GRRS_)
• Группы доступа к принтерам (GRPR_)

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

Архитектура OU.
Архитектуру OU в первую очередь следует продумывать с точки зрения безопасности и делегирования прав на данную OU системным администраторам. Не рекомендую планировать архитектуру OU с точки зрения привязки к ним групповых политик (хотя так чаще всего и делают). Для некоторых покажется немного странной моя рекомендация, но я не рекомендую вообще привязывать групповые политики к OU. Подробности читайте в секции Групповые политики.
OU Admins
Рекомендую выделить для административных аккаунтов и групп отдельную OU, куда поместить аккаунты и группы всех администраторов и инженеров технической поддержки. К данной OU следует ограничить доступ для обычных пользователей, а управление объектами из данной OU делегировать только главным администраторам.
OU Computers
OU для компьютеров лучше всего планировать с точки зрения географической принадлежности компьютеров и типов компьютеров. Распределите компьютеры с разных географических локаций по разным OU, а их в свою очередь разделите на клиентские компьютеры и серверы. Серверы можно еще поделить на Exchange, SQL и другие.

Пользователи, права в Active Directory
Пользовательским аккаунтам Active Directory следует уделять особое внимание. Как было сказано в секции про OU, пользовательские аккаунты следует группировать исходя из принципа делегирования полномочий на данные аккаунты. Также важно соблюдать принцип минимальных привилегий - чем меньше у пользователя прав в системе, тем лучше. Рекомендую сразу закладывать уровень привилегий пользователя в название его аккаунта. Аккаунт для повседневной работы должен состоять из Фамилии пользователя и инициалов на латинице (Например, IvanovIV или IVIvanov). Обязательными полями являются: First Name, Initials, Last Name, Display Name (на русском), email, mobile, Job Title, Manager.
Аккаунты администраторов должны быть следующих типов:

• С правами администратора на пользовательские компьютеры, но не серверы. Должны состоять из инициалов владельца и приставки local (Например, iivlocal)
• С правами на администрирование серверов и Active Directory. Должны состоять только из инициалов (Например, iiv).

Поле Surname обоих типов административных аккаунтов следует начинать с буквы I (Например, iPetrov P Vasily)
Поясню, зачем следует разделять административные аккаунты на администраторов серверов и администраторов клиентских компьютеров. Делать это необходимо, из соображений безопасности. Администраторы клиентских компьютеров будут иметь право на установку софта на клиентских компьютерах. Какой и для чего софт будет устанавливаться, сказать никогда точно нельзя. Поэтому запускать установку программы с правами доменного администратора небезопасно, можно скомпрометировать весь домен. Необходимо администрировать клиентские компьютеры только с правами локального администратора данного компьютера. Это сделает невозможным целый ряд атак на аккаунты доменных администраторов, вроде «Pass The Hash». Дополнительно администраторам клиентских компьютеров необходимо закрыть подключение через службу терминалов и подключение по сети к компьютеру. Компьютеры технической поддержки и администраторов следует поместить в отдельный VLAN, чтобы ограничить к ним доступ из сети клиентских компьютеров.
Выделение прав администратора пользователям
Если вам необходимо дать права администратора пользователю, ни в коем случае не помещайте его учетную запись для повседневной работы в группу локальных администраторов компьютера. Учетная запись для повседневной работы должна быть всегда ограничена в правах. Создайте для него отдельную административную учетную запись вида namelocal и добавьте данную учетную запись в группу локальных администраторов при помощи политики, ограничив ее применение только на компьютере пользователя при помощи item-level targeting. Данной учетной записью пользователь сможет пользоваться, используя механизм Run AS.
Политики паролей
Создайте отдельные политики паролей для пользователей и администраторов при помощи fine-grained password policy. Желательно, чтобы пользовательский пароль состоял минимум из 8 символов и менялся хотя бы раз в квартал. Администраторам желательно менять пароль каждые два месяца, и он должен быть минимум из 10-15 символов и отвечать требованиям сложности.

Состав доменных и локальных групп. Механизм Restricted Groups
Состав доменных и локальных групп компьютерах домена должен контролироваться только в автоматическом режиме, при помощи механизма Restricted Groups. Почему это необходимо делать только таким образом, объясню на следующем примере. Обычно после того, как разрвенут домен Active Directory, администраторы добавляют себя в доменные группы вроде Domain admins, Enterprise admins, добавляют в нужные группы инженеров технической поддержки и остальных пользователей тоже распределяют по группам. В процессе администрирования данного домена процесс выдачи прав повторяется многократно и будет крайне сложно вспомнить, что ты вчера временно добавлял бухгалтера Нину Петровну в группу администраторов 1С и что сегодня необходимо ее из это группы убрать. Ситуация усугубится, если в компании работает несколько администраторов и каждый время от времени выдает права пользователям в подобно стиле. Уже через год будет почти невозможно разобраться в том, какие кому права назначены. Поэтому состав групп должен контролироваться только групповыми политиками, которые при каждом применении будут приводить все в порядок.
Состав встроенных групп
Стоит сказать, что встроенные группы вроде Account Operators, Backup operators, Crypt Operators, Guests, Print Operators, Server Operators должны быть пустыми, как в домене, так и на клиентских компьютерах. Эти группы в первую очередь необходимы для обеспечения обратной совместимости со старыми системами, и пользователи данных групп наделяются слишком большими правами в системе, и становятся возможны атаки на повышение привилегий.

Учетные записи локальных администраторов
При помощи механизма Restricted Groups необходимо блокировать учетные записи локальных администраторов на локальных компьютерах, блокировать гостевые учетные записи и очищать группу локальных администраторов на локальных компьютерах. Ни в коем случае не используйте групповые политики для установки паролей на учетные записи локальных администраторов. Этот механизм не безопасен, пароль можно извлечь прямо из политики. Но, если вы решили не блокировать учетные записи локальных администраторов, то для корректной установки паролей и их ротации используйте механизм LAPS. К сожалению, настройка LAPS не до конца автоматизирована, и поэтому нужно будет в ручном режиме добавлять атрибуты в схему Active Directory, выдавать на них права, назначать группы и так далее. Поэтому проще заблокировать аккаунты локальных администраторов.
Сервисные учетные записи.
Для запуска сервисов используйте сервисные учетные записи и механизм gMSA (доступен в системах Windows 2012 и выше)

Групповые Политики
Документируйте политики перед созданием/изменением.
При создании политики используйте принцип «Политика - группа». То есть перед созданием политики создайте сначала группу для данной политики, уберите из области применения политики группу Authenticated users и добавьте созданную группу. Политику привяжите не к OU, а к корню домена и регулируйте область ее применения при помощи добавления объектов в группу политики. Такой механизм я считаю более гибким и понятным, чем линковку политики к OU. (Именно про это я писал в секции про Архитектуру OU).
Всегда регулируйте область применения политики. Если вы создали политику только для пользователей, то отключайте структуру компьютер и наоборот, отключайте структуру пользователь, если создали политику только для компьютеров. Благодаря этим настройкам, политики будут более быстро применяться.
Настройте ежедневное резервное копирование политик при помощи Power Shell, чтобы в случае ошибок конфигурирования можно было всегда вернуть настройки к исходным.
Центральное хранилище шаблонов (Central Store)
Начиная с Windows 2008 стало возможным хранить ADMX-шаблоны групповых политик в центральном хранилище, в SYSVOL. До этого по умолчанию все шаблоны политик хранились локально, на клиентах. Чтобы разместить шаблоны ADMX в центральном хранилище, необходимо скопировать содержимое папки %SystemDrive%\Windows\PolicyDefinitions вместе с подпапками с клиентских систем (Windows 7/8/8.1) в директорию контроллера домена %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions со слиянием содержимого, но без замены. Далее следует сделать такое же копирование с серверных систем, начиная с самой старой. В последнюю очередь, при копировании папок и файлов с самой последней версии сервера, сделайте копирование со слиянием и ЗАМЕНОЙ.

Копирование ADMX-шаблонов

Дополнительно в центральном хранилище можно размещать ADMX-шаблоны для любых программных продуктов, например, таких как Microsoft Office, продукты Adobe, Google и других. Зайдите на сайт поставщика программного продукта, скачайте ADMX-шаблон групповой политики и распакуйте его в папку %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions на любом из контроллеров домена. Теперь вы сможете управлять нужным вам программным продуктом через групповые политики.
Фильтры WMI
Фильтры WMI не очень быстро работают, поэтому предпочтительнее использовать механизм item-level targeting. Но если item-level targeting использовать невозможно, и вы решили использовать WMI, то рекомендую сразу создать для себя несколько самых распространённых фильтров: фильтр «Только клиентские операционные системы», «Только серверные операционные системы», фильтры «Windows 7», фильтры «Windows 8», «Windows 8.1», «Windows 10». Если у вас будут готовые наборы WMI фильтров, то потом будет проще применить нужный фильтр к нужной политике.

Аудит событий Active Directory
Обязательно включите аудит событий на контроллерах домена и других серверах. Рекомендую включить аудит следующих объектов:

• Audit Computer Account Management - Success, Failure
• Audit Other Account Management Events - Success, Failure
• Audit Security Group Management - Success, Failure
• Audit User Account Management - Success, Failure

• Audit Kerberos Authentication Service - Failure
• Audit Other Account Logon Events - Failure
• Audit Audit Policy Change - Success, Failure

Аудит необходимо конфиругировать в разделе Advanced Audit Policy Configuration и обязательно включить настройку в разделел Local Policy/Security Options - Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings , которая отменит настройки верхнего уровня и применит расширенные.

Расширенные настройки аудита

Подробно останавливаться на настройках аудита не буду, так как в Сети есть достаточное количество статей, посвященных данной теме. Дополню только, что помимо включения аудита, следует настроить оповещения по e-mail о критических событиях безопасности. Стоит также учесть то, что в системах с обильным количеством событий стоит выделить отдельные серверы для сбора и анализа файлов журнала.

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

Ручное администрирование
Часть операций по администрированию вам и вашим коллегам будет необходимо делать в ручном режиме. Для этих целей рекомендую использовать консоль mmc с добавленными в нее оснастками.
Как будет сказано далее, контроллеры домена у вас должны функционировать в режиме Server Core, то есть администрирование всего окружения AD следует выполнять только со своего компьютера при помощи консолей. Для администрирования Active Directory необходимо на свой компьютер поставить Remote Server Administration Tools. Консоли следует запускать на вашем компьютере из-под пользователя с правами администратора Active Directory, которому делегировано управление.
Искусство управления Active Directory при помощи консолей требует отдельной статьи, а может быть даже и отдельного обучающего видео, поэтому здесь только говорю про сам принцип.

Контроллеры домена
В любом домене, контроллеров должно быть, как минимум два. На контроллерах домена должно быть, как можно меньше служб. Не стоит делать из контроллера домена файловый сервер или, упаси вас бог, поднять на нем роль сервера терминалов. Используйте на контроллерах домена операционные системы в режиме Server Core, удалив полностью поддержку WoW64, это значительно уменьшит количество необходимых обновлений и увеличит их безопасность.
Microsoft раньше не рекомендовала виртуализировать контроллеры домена в виду того, что при восстановлении из моментальных снимков были возможны трудноразрешимые конфликты репликации. Возможно, были еще причины, точно сказать не могу. Сейчас гипервизоры научились сообщать контроллерам о восстановлении их из моментальных снимков, и эта проблема исчезла. Я же все время виртуализировал контроллеры, не делая никаких моментальных снимков, так как не понимаю, зачем вообще может понадобиться делать таковые на контроллерах домена. По-моему, проще сделать резервную копию контроллера домена стандартными средствами. Поэтому, рекомендую виртуализировать все контроллеры домена, которые только возможно. Такая конфигурация будет более гибкой. При виртуализации контроллеров домена располагайте их на разных физических хостах.
Если вам необходимо разместить контроллер домена в незащищенной физической среде или в филиале вашей организации, то для этих целей используйте RODC.

Роли FSMO, первичные и вторичные контроллеры
Роли FSMO контроллеров домена продолжают порождать страх в головах начинающих администраторов. Часто новички изучают Active Directory по устаревшей документации или слушают рассказы других администраторов, которые что-то где-то когда-то читали.
По всем пяти + 1 ролям вкратце следует сказать следующее. Начиная с Windows Server 2008 больше не существует первичных и вторичных контроллеров домена. Все пять ролей контроллеров домена переносимы, но не могут размещаться одновременно более, чем на одном контроллере. Если мы возьмем один из контроллеров, который, к примеру, был хозяином 4 ролей и удалим его, то все эти роли мы без проблем сможем перенести на другие контроллеры, и в домене ничего страшного не произойдет, ничего не сломается. Такое возможно потому, что всю информацию по работе, связанной с той или иной ролью ее хозяин хранит прямо в Active Directory. И если мы передаем роль другому контроллеру, то он в первую очередь обращается за сохраненной информацией в Active Directory и приступает к несению службы. Домен может достаточно долгое время существовать без хозяев ролей. Единственная «роль», которая должна быть всегда в Active Directory и без которой будет все очень плохо, это роль глобального каталога (GC), ее могут нести на себе все контроллеры в домене. Рекомендую назначать роль GC каждому контроллеру в домене, чем их больше, тем лучше. Конечно, вы сможете найти случаи, когда на контроллер домена не стоить устанавливать роль GC. Что ж, если не надо, так не надо. Следуйте рекомендациям без фанатизма.

Служба DNS
Служба DNS критична для работы Active Directory и работать она должна без сбоев. Службу DNS лучше всего ставить на каждый контроллер домена и хранить DNS зоны в самой Active Directory. Если вы будете использовать Active Directory для хранения зон DNS, то вам следует настраивать свойства TCP/IP соединения на контроллерах домена, таким образом, чтобы на каждом контроллере в качестве первичного DNS-сервера был любой другой DNS-сервер, а в качестве вторичного можно поставить адрес 127.0.0.1. Такую настройку делать необходимо потому, что для нормального старта службы Active Directory требуется работающий DNS, а для старта DNS должна быть запущена служба Active Directory, так как в ней лежит сама зона DNS.
Обязательно настройте зоны обратного просмотра для всех своих сетей и включите автоматическое безопасное обновление записей PTR.
Рекомендую дополнительно включить автоматическую уборку зоны от устаревших записей DNS (dns scavenging).
В качестве DNS-Forwarders рекомендую указать защищенные серверы Яндекс, если нет других более быстрых в вашей географической локации.

Сайты и репликация
Многие администраторы привыкли считать, что сайты - это географическое объединение компьютеров. Например, сайт Москва, сайт Петербург. Такое представление появилось из-за того, что первоначально деление Active Directory на сайты было сделано с целью балансировки и разделения сетевого трафика репликации. Контроллерам домена в Москве не обязательно знать, что в Петербурге было сейчас создано десять учетных записей компьютеров. И поэтому подобную информацию об изменениях можно передавать раз в час по расписанию. Или вообще производить репликацию изменений один раз в сутки и только ночью, для экономии полосы пропускания.
Про сайты я бы сказал так: сайты - это логические группы компьютеров. Компьютеров, которые соединены между собой хорошим сетевым соединением. А сами сайты соединены между собой соединением с малой пропускной способность, что в наше время большая редкость. Поэтому, я делю Active Directory на сайты не для балансировки трафика репликации, а для балансировки сетевой нагрузки вообще и для более быстрой обработки клиентских запросов компьютеров сайта. Поясню на примере. Есть 100-мегабитная локальная сеть организации, которую обслуживают два контроллера домена и есть облако, где располагаются серверы приложений этой организации с двумя другими облачными контроллерами. Такую сеть я поделю на два сайта для того, чтобы контроллеры в локальной сети обрабатывали запросы клиентов из локальной сети, а контроллеры в облаке запросы от серверов приложений. Дополнительно это позволит разделить запросы к службам DFS и Exchange. И так как сейчас я редко где встречаю канал в Интернет менее 10 мегабит в секунду, то я включу Notify Based Replication, это когда репликация данных происходит сразу, как только появились какие-либо изменения в Active Directory.

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

Вы можете помочь и перевести немного средств на развитие сайта

Александр Емельянов

Принципы построения доменов Active Directory

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

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

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

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

Не верю. Администрирование – это процесс, включающий в себя многолетний опыт с «набитыми шишками», огромным количеством прочитанной документации (в массе своей на английском языке) и «задушевными» беседами с начальством и пользователями.

Есть еще один нюанс – перед тем, как пройти курс по внедрению Active Directory, вы должны иметь успешно сданный курс по администрированию сетевой инфраструктуры на базе Windows Server 2003, который тоже требует некоторых финансовых затрат со стороны обучающегося. Лишний раз убеждаемся, что Microsoft своего не упустит. Но речь не об этом…

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

Также посмотрим, что нового появилось в Active Directory с выходом Windows Server 2003.

Стоит отметить, что в последнем квартале прошедшего года Microsoft выпустила Windows Vista, а вместе с ней и обновленную службу каталогов. Однако старые технологии не потеряли своей актуальности и по сей день.

В рамках статьи мы пройдем путь от понимания сущности AD до создания своего собственного домена. Дальнейшая его настройка и инструменты управления и диагностики будут освещены в следующих номерах.

Чем поможет Active Directory

Приведу неполный список всех «вкусностей», которые вы получите, развернув службу каталогов:

• единая база регистрации пользователей, которая хранится централизованно на одном либо нескольких серверах; таким образом, при появлении нового сотрудника в офисе вам нужно будет всего лишь завести ему учетную запись на сервере и указать, на какие рабочие станции он сможет получать доступ;
• поскольку все ресурсы домена индексируются, это дает возможность простого и быстрого поиска для пользователей; например, если нужно найти цветной принтер в отделе автоматизации;
• совокупность применения разрешений NTFS, групповых политик и делегирования управления позволит вам тонко настроить и распределить права между участниками домена;
• перемещаемые профили пользователей дают возможность хранить важную информацию и настройки конфигурации на сервере; фактически, если пользователь, обладающий перемещаемым профилем в домене, сядет работать за другой компьютер и введет свои имя пользователя и пароль, он увидит свой рабочий стол с привычными ему настройками;
• с помощью групповых политик вы можете изменять настройки операционных систем пользователей, от разрешения пользователю устанавливать обои на рабочем столе до настроек безопасности, а также распространять по сети программное обеспечение, например, Volume Shadow Copy client и т. п.;
• многие программы (прокси-серверы, серверы баз данныхи др.) не только производства Microsoft на сегодняшний день научились использовать доменную аутентификацию, таким образом, вам не придется создавать еще одну базу данных пользователей, а можно будет использовать уже существующую;
• использование Remote Installation Services облегчает установку систем на рабочие места, но, в свою очередь, работает только при внедренной службе каталогов.

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

Я лишь заострю внимание на том факте, что все вышеперечисленное будет иметь силу при наличии гомогенной сети на базе семейства ОС Windows 2000 и выше.

Логика построения

Рассмотрим основные составляющие службы каталогов.

Домены

Это основная логическая единица построения. В сравнении с рабочими группами домены AD – это группы безопасности, имеющие единую базу регистрации, тогда как рабочие группы – это всего лишь логическое объединение машин. AD использует для именования и службы поиска DNS (Domain Name Server – сервер имен домена), а не WINS (Windows Internet Name Service – сервис имен Internet), как это было в ранних версиях NT. Таким образом, имена компьютеров в домене имеют вид, например, buh.work.com, где buh – имя компьютера в домене work.com (хотя это не всегда так, об этом читайте далее).

В рабочих группах используются NetBIOS-имена. Для размещения доменной структуры AD возможно использование DNS-сервера не компании Microsoft. Но он должен быть совместим с BIND 8.1.2 или выше и поддерживать записи SRV (RFC 2052), а также протокол динамической регистрации (RFC 2136). Каждый домен имеет хотя бы один контроллер домена, на котором располагается центральная база данных.

Деревья

Это многодоменные структуры. Корнем такой структуры является главный домен, для которого вы создаете дочерние. Фактически Active Directory использует иерархическую систему построения, аналогичную структуре доменов в DNS.

Например, если мы имеем домен work.com (домен первого уровня) и создаем для него два дочерних домена first.work.com и second.work.com (здесь first и second – это домены второго уровня, а не компьютер в домене, как в случае, описанном выше), то в итоге получим дерево доменов (см. рис. 1).

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

AD помогает автоматически создавать доверительные отношения между каждым доменом и его дочерними доменами.

Таким образом, создание домена first.work.com ведет к автоматической организации двухсторонних доверительных отношений между родительским work.com и дочерним first.work.com (аналогично и для second.work.com). Поэтому с родительского домена могут применяться разрешения для дочернего, и наоборот. Нетрудно предположить, что и для дочерних доменов будут существовать доверительные отношения.

Еще одно свойство доверительных отношений – транзитивность. Получаем – для домена net.first.work.com создаются доверительные отношения с доменом work.com.

Леса

Также как и деревья это многодоменные структуры. Но лес – это объединение деревьев, имеющих разные корневые домены.

Предположим, вы решили иметь несколько доменов с именами work.com и home.net и создать для них дочерние домены, но из-за того, что tld (top level domain) не в вашем управлении, в этом случае вы можете организовать лес (см. рис. 2), выбрав один из доменов первого уровня корневым. Вся прелесть создания леса в этом случае – двухсторонние доверительные отношения между двумя этими доменами и их дочерними доменами.

Однако при работе с лесами и деревьями необходимо помнить следующее:

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

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

Организационные единицы (OU)

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

Попросту говоря, можно назначить администратора в домене, который сможет управлять OU, но не иметь прав для администрирования всего домена.

Важной особенностью OU в отличие от групп (немного забегаем вперед) является возможность применения к ним групповых политик. «А почему нельзя разбить исходный домен на несколько доменов вместо использования OU?» – спросите вы.

Многие специалисты советуют иметь по возможности один домен. Причина этому – децентрализация администрирования при создании дополнительного домена, так как администраторы каждого такого домена получают неограниченный контроль (напомню, что при делегировании прав администраторам OU можно ограничивать их функционал).

В дополнение к этому для создания нового домена (даже дочернего) нужен будет еще один контроллер. Если же у вас есть два обособленных подразделения, соединенных медленным каналом связи, могут возникнуть проблемы с репликацией. В этом случае более уместным будет иметь два домена.

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

Группы пользователей и компьютеров

Они используются для административных целей и имеют такой же смысл, как и при использовании на локальных машинах в сети. В отличие от OU, к группам нельзя применять групповые политики, но для них можно делегировать управление. В рамках схемы Active Directory выделяют два вида групп: группы безопасности (применяются для разграничения прав доступа к объектам сети) и группы распространения (применяются в основном для рассылки почтовых сообщений, например, в сервере Microsoft Exchange Server).

Они подразделяются по области действия:

• универсальные группы могут включать в себя пользователей в рамках леса, а также другие универсальные группы или глобальные группы любого домена в лесу;
• глобальные группы домена могут включать в себя пользователей домена и другие глобальные группы этого же домена;
• локальные группы домена используются для разграничения прав доступа, могут включать в себя пользователей домена, а также универсальные группы и глобальные группы любого домена в лесу;
• локальные группы компьютеров – группы, которые содержит SAM (security account manager) локальной машины. Область их распространения ограничивается только данной машиной, но они могут включать в себя локальные группы домена, в котором находится компьютер, а также универсальные и глобальные группы своего домена или другого, которому они доверяют. Например, вы можете включить пользователя из доменной локальной группы Users в группу Administrators локальной машины, тем самым дав ему права администратора, но только для этого компьютера.

Сайты

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

Например, если вы имеете несколько филиалов в разных концах страны, соединенных низкоскоростными линиями связи, то для каждого филиала вы можете создать свой сайт. Делается это для повышения надежности репликации каталога.

Такое разбиение AD не влияет на принципы логического построения, поэтому как сайт может содержать в себе несколько доменов, так и наоборот, домен может содержать несколько сайтов. Но такая топология службы каталогов таит в себе подвох. Как правило, для связи с филиалами используется Интернет – очень небезопасная среда. Многие компании используют средства защиты, например, брандмауэры. Служба каталогов в своей работе использует около полутора десятков портов и служб, открытие которых для прохождения трафика AD через брандмауэр, фактически выставит ее «наружу». Решением проблемы является использование технологии туннелирования, а также наличие в каждом сайте контроллера домена для ускорения обработки запросов клиентов AD.

На рис. 3 представлена логика вложенности составляющих службы каталогов. Видно, что лес содержит два дерева доменов, в которых корневой домен дерева, в свою очередь, может содержать OU и группы объектов, а также иметь дочерние домены (в данном случае их по одному у каждого). Дочерние домены также могут содержать группы объектов и OU и иметь дочерние домены (на рисунке их нет). И так далее. Напомню, что OU могут содержать OU, объекты и группы объектов, а группы могут содержать другие группы. Более подробно о вложенности групп и их составляющих читайте в следующей статье.

Сущность службы каталогов

Чтобы обеспечить некоторый уровень безопасности, любая операционная система должна иметь файлы, содержащие базу данных пользователей. В ранних версиях Windows NT для этого использовался файл SAM (Security Accounts Manager – менеджер учетных записей). Он содержал учетные данные пользователей и был зашифрован. Сегодня SAM также используется в операционных системах семейства NT 5 (Windows 2000 и выше).

Когда вы повышаете роль рядового сервера до контроллера домена с помощью команды DCPROMO (фактически она запускает мастер установки службы каталогов), подсистема безопасности Windows Server 2000/2003 начинает использовать централизованную базу данных AD. Это можно легко проверить – попробуйте после создания домена открыть на контроллере оснастку Computer Management и найти там «Локальные пользователи и группы». Более того, попробуйте войти на этот сервер под локальной учетной записью. Вряд ли у вас получится.

Большинство данных пользователей сохраняются в файле NTDS.DIT (Directory Information Tree – дерево информации каталога). NTDS.DIT – это модифицированная база данных. Она создана с использованием той же технологии, что и база данных Microsoft Access. Алгоритмы работы контроллеров домена содержат вариант движка JET базы данных Access, который был назван ESE (Extensible Storage Engine – расширяемый движок хранения информации). NTDS.DIT и службы, обеспечивающие взаимодействие с этим файлом, фактически и есть служба каталогов.

Структура взаимодействия клиентов AD и основного хранилища данных, аналогично как и пространство имен службы каталогов, представлены в статье . Для полноты описания нужно упомянуть об использовании глобальных идентификаторов. Глобальный уникальный идентификатор (Global Unique Identifier, GUID) – это 128-разрядное число, сопоставляемое каждому объекту при его создании для обеспечения уникальности. Имя объекта AD можно изменить, а вот GUID останется неизменным.

Глобальный каталог

Наверняка вы успели заметить, что структура AD может быть весьма сложной и вмещать в себя большое количество объектов. Чего стоит только тот факт, что домен AD может включать в себя до 1,5 млн. объектов. Но из-за этого могут возникнуть проблемы с производительностью при выполнении операций. Эта проблема решается с помощью Глобального каталога (Global Catalog, GC). Он содержит сокращенную версию всего леса AD, что помогает ускорять поиск объектов. Владельцем глобального каталога могут выступать специально назначенные для этого контроллеры домена.

Роли FSMO

В AD существует определенный перечень операций, выполнение которых можно возложить только на один контроллер. Они называются ролями FSMO (Flexible Single-Master Operations – операции с одним хозяином). Всего в AD 5 ролей FSMO. Рассмотрим их более подробно.

В рамках леса обязательно должна существовать гарантия уникальности доменных имен при добавлении нового домена к лесу доменов. Такая гарантия осуществляется исполнителем роли владельца операции именования доменов (Domain Naming Master) Исполнитель роли владельца схемы (Schema Master) осуществляет все изменения в схеме каталога. Исполнители ролей владельца доменных имен и владельца схемы должны быть уникальны в рамках леса доменов.

Как я уже говорил, при создании объекта ему сопоставляется глобальный идентификатор, гарантирующий его уникальность. Именно поэтому контроллер, отвечающий за генерацию GUID и исполняющий роль владельца относительных идентификаторов (Relative ID Master), должен быть один-единственный в рамках домена.

В отличие от доменов NT в AD нет понятия PDC и BDC (основной и резервный контроллеры домена). Одной из ролей FSMO является PDC Emulator (эмулятор основного контроллера домена). Сервер под управлением Windows NT Server может выступать в роли резервного контроллера домена в AD. Но известно, что в доменах NT может использоваться только один основной контроллер. Именно поэтому Microsoft сделала так, что в рамках одного домена AD мы можем назначить единственный сервер – носитель роли PDC Emulator. Таким образом, отступая от терминологии, можно говорить о наличии главного и резервных контроллеров домена, имея в виду обладателя роли FSMO.

При удалении и перемещении объектов один из контроллеров должен сохранить ссылку на этот объект, пока не будет полностью завершена репликация. Такую роль выполняет владелец инфраструктуры каталога (Infrastructure Master).

Последние три роли требуют уникальности исполнителя в рамках домена. Все роли возлагаются на первый контроллер, созданный в лесу. При создании разветвленной инфраструктуры AD вы можете передавать эти роли другим контроллерам. Могут возникать также ситуации, когда владелец одной из ролей недоступен (вышел из строя сервер). В этом случае необходимо выполнить операцию захвата роли FSMO с помощью утилиты NTDSUTIL (о ее использовании мы поговорим в следующих статьях). Но стоит быть осторожным, так как при захвате роли служба каталогов полагает, что предыдущего владельца нет, и не обращается к нему вовсе. Возвращение в сеть прежнего исполнителя роли может привести к нарушению ее функционирования. Особенно это критично для владельца схемы, владельца доменных имен и владельца идентификаторов.

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

Последний шаг теоретика

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

Как руководство по установке AD могу посоветовать использовать статьи и , а также базу знаний Microsoft.

Напоследок несколько советов:

• Постарайтесь по возможности не совмещать роли PDC Emulator и прокси-сервера на одной машине. Во-первых, при большом количестве машин в сети и пользователей Интернет возрастает нагрузка на сервер, а во-вторых, при удачной атаке на ваш прокси «упадет» не только Интернет, но и основной контроллер домена, а это чревато некорректной работой всей сети.
• Если вы постоянно администрируете локальную сеть, а не собираетесь заняться внедрением Active Directory для заказчиков, вносите машины в домен постепенно, скажем, по четыре-пять в день. Поскольку если у вас в сети большое количество машин (50 и больше) и вы управляете ею один, то вряд ли вы управитесь даже за выходные, а если и управитесь, то насколько все будет корректно, неизвестно. К тому же для обмена документацией внутри сети вы можете использовать файловый или внутренний почтовый сервер (такой был описан мной в №11 за 2006 г.). Единственное, в этом случае стоит корректно разобраться в настройке прав пользователей для доступа к файловому серверу. Потому что, если, например, он не будет включен в домен, аутентификация пользователей будет осуществляться, основываясь на записях локальной базы SAM. Там нет данных о доменных пользователях. Однако если ваш файловый сервер будет в числе первых машин, включенных в AD, и не будет контроллером домена, то будет существовать возможность аутентификации посредством как локальной базы SAM, так и учетной базы AD. Но для последнего варианта вам нужно будет в локальных настройках безопасности разрешить (если это еще не сделано) доступ к файловому серверу по сети как участникам домена, так и локальным учетным записям.

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

Приложение

Новшества Active Directory в Windows Server 2003

С выходом Windows Server 2003 в Active Directory появились следующие изменения:

• Стало возможным переименование домена после его создания.
• Улучшился пользовательский интерфейс управления. Например, можно изменить атрибуты сразу нескольких объектов.
• Появилось хорошее средство управления групповыми политиками – Group Policy Management Console (gpmc.msc, ее нужно скачивать с сайта Microsoft).
• Изменились функциональные уровни домена и леса.

О последнем изменении нужно сказать подробнее. Домен AD в Windows Server 2003 может находиться на одном из следующих уровней, перечисленных в порядке роста функциональности:

• Windows 2000 Mixed (смешанный Windows 2000) . В нем допускается иметь контроллеры различных версий – как Windows NT, так и Windows 2000/2003. Причем если серверы Windows 2000/2003 равноправны, то сервер NT, как уже говорилось, может выступать только резервным контроллером домена.
• Windows 2000 Native (естественный Windows 2000) . Допускается иметь контроллеры под управлением Windows Server 2000/2003. Этот уровень более функционален, но имеет свои ограничения. Например, вы не сможете переименовывать контроллеры доменов.
• Windows Server 2003 Interim (промежуточный Windows Server 2003) . Допускается иметь контроллеры под управлением Windows NT, а также Windows Server 2003. Используется, например, когда главный контроллер домена под управлением сервера Windows NT обновляется до W2K3. Уровень имеет чуть большую функциональность, чем уровень Windows 2000 Native.
• Windows Server 2003 . Допускается наличие в домене контроллеров только под управлением Windows Server 2003. На этом уровне можно воспользоваться всеми возможностями службы каталогов Windows Server 2003.

Функциональные уровни леса доменов практически те же, что и для доменов. Единственное исключение – существует только один уровень Windows 2000, на котором возможно использование в лесу контроллеров под управлением Windows NT, а также Windows Server 2000/2003.

Стоит заметить, что изменение функционального уровня домена и леса является операцией необратимой. То есть отсутствует обратная совместимость.

1. Коробко И. Active Directory – теория построения. //«Системный администратор», №1, 2004 г. – C. 90-94. ().
2. Марков Р. Домены Windows 2000/2003 – отказываемся от рабочей группы. //«Системный администратор», №9, 2005 г. – C. 8-11. ().
3. Марков Р. Установка и настройка Windows 2К Server. //«Системный администратор», №10, 2004 г. – C. 88-94. ().